The problem it solves
Your supplier calls themselves "Anthropic, PBC" in their invoice header. Your accounts system knows them as "ANT-001". Harold extracts "Anthropic, PBC" perfectly — but your ERP needs "ANT-001". Without Key Field Match, you would need to manually recode every single document.
Key Field Match is the translation layer. You tell Harold once that "Anthropic, PBC" maps to "ANT-001" and it will apply that mapping to every document from that supplier forever.
How it works
Key Field Match lets you create mappings between raw extracted values and your internal codes. Each mapping has a source field (the field Harold extracts, such as supplier_name), a raw value (what the document actually says, such as "Anthropic, PBC"), a mapped value (what your system needs, such as "ANT-001"), and an optional document type scope — apply the mapping only to purchase invoices, for example.
You can also set a match confidence threshold. If Harold extracts a value that is an 80% fuzzy match to a known raw value, it will apply the mapping. This handles minor variations — "Anthropic PBC" vs "Anthropic, PBC" — without requiring a separate mapping for every typo.
What kinds of mappings make sense
The most common use case is supplier name to supplier code. But Key Field Match works on any extracted field: product codes, cost centre names, currency names, and payment terms. Anything that appears in your documents in one form but needs to be in a different form downstream is a candidate for a mapping.
Building your mapping library
You build mappings one of two ways. You can create them manually through the Key Field Match interface — useful when you know upfront what your supplier codes are. Or you can create them during the review process — when you correct a field value during document review, Harold offers to save that correction as a permanent mapping.
The second approach is the more natural one. Your mapping library grows organically as you process real documents. After a month of processing invoices you will have mappings for all your regular suppliers without having spent any specific time building them.
Ease of use
The Key Field Match interface is a simple table. You can add, edit, and delete mappings. The fuzzy match threshold is configurable per mapping — tighten it for fields where precision matters, loosen it for fields where suppliers are inconsistent.
The main thing to understand is that mappings are applied at export time, not at extraction time. The original extracted value is always preserved. This means you can change or delete a mapping and it affects future exports without corrupting historical data.
Limitations
Key Field Match is pattern-matching, not intelligence. If your supplier sends a document with a completely new format and the supplier name appears in an unexpected form, the mapping will not apply until either Harold extracts it correctly or you add a new mapping.
It is also not a rules engine. For conditional logic — "if the supplier is X and the amount is over Y, use cost centre Z" — that is the job of the Rules Engine.
The aim
Key Field Match exists because the last mile of document processing — getting extracted data into the exact format your systems need — is often where the manual work happens. The goal is to eliminate that entirely. Once your mapping library is built, Harold's output should be ready to push straight into your ERP or downstream tool via Zapier without any manual intervention.