AI for Hebrew Supplier Invoices: An Intake Draft With Reconciliation, Not Automatic Entry

A supplier invoice read by a model is a draft, not a record. It becomes a record only after it has been reconciled against something you already hold - a purchase order, a delivery note, or a prior invoice from the same supplier - and the person who approved it saw exactly where the two disagreed.

Why the vendor name is not a matching key in Hebrew

In English, vendor-name matching is mostly a solved problem: normalise case, strip Ltd and Inc, ignore full stops, and you are left with a stable string. In Hebrew each of those steps breaks, and for a different reason each time.

• There is no letter case. The cue that marks a word as a proper noun in English does not exist, so the entity name cannot be separated from the text around it by its shape.
• One-letter prefixes attach. ו, ה, ב, ל, מ, כ and ש glue onto the following word. The same company appears as a bare noun in the invoice header and in an inflected form in a sentence, and both are correct.
• Full and defective spelling. Yod and vav double or vanish. One name is written two ways that even a good search engine will not bridge under exact matching.
• בע"מ. Sometimes written, sometimes not, and sometimes with its gershayim turned into a straight double quote, two apostrophes or a tilde. The comparison breaks on one character.
• The construct state. A Hebrew noun compound changes the form of the first word, so the same component of a name looks different in different contexts.

The practical conclusion is short: the name is a display label, not a key. The key is a nine-digit number. Amazon Textract, describing the standard field taxonomy for expense analysis, separates VENDOR_NAME from TAX_PAYER_ID and PO_NUMBER for exactly this reason, and notes that any field which does not fit the taxonomy is categorised as OTHER. On Hebrew invoices that is precisely what happens to lines like אסמכתא or מספר דרישה, and they stay free text nobody should reconcile on.

What exactly is the draft reconciled against?

Against one declared document, chosen by what exists in your systems, in a fixed order of preference:

1. A purchase order. The strongest reconciliation, because it was written before the invoice arrived. Compare supplier, SKU, quantity, unit price and currency.
2. A delivery note. The right source when the order was open or placed by phone. Compare quantity delivered and delivery date, not price - Israeli delivery notes frequently carry no prices at all.
3. A prior invoice from the same supplier. The right source for a recurring service at a steady amount. Compare against last month and against the twelve-month range, and look for the jump.
4. An agreement or price list. Last, because it defines what was permitted rather than what was delivered.

The rule is one source per draft, recorded in its own field. A draft reconciled simultaneously against an order and a prior invoice produces two different answers and no decision, and that is exactly the situation in which a person approves something without knowing what they approved.

Reconciliation table: key, tolerance and action

Two rows do most of the work. The supplier row, because accidentally creating a new supplier is the ordinary way a payment reaches somebody other than the party that supplied. And the amount-against-VAT row, because it is an arithmetic check that costs nothing: the tax rate printed on the document is what the check runs against, not a constant somebody hard-coded two years ago.

An invoice with no purchase order: what do you reconcile then?

Against a named approver rather than a document. A large share of spend in a small Israeli business never passes through a purchase order at all: telecoms, municipal rates, consultants, software subscriptions. There the three sources are history, one defined approver, and expense classification.

• Against history. Same supplier, same expense line, same amount range as the preceding months. A change above the agreed percentage creates a queue item showing the last twelve months.
• Against an owner. Each expense line has one named approver, not a list. A list means nobody approves in practice.
• Against the classification. An invoice landing in a new category is not an error, but it is a reason to stop, because a new category changes downstream reports.
• Against duplication. The same invoice number from the same supplier inside a fixed window. This is what catches a double payment, not file comparison.

Related: the Israeli invoice allocation number for developers, from supplier invoice approval to a Masav file, confidence and provenance on Hebrew documents.

The draft states, and who is allowed to move one

A draft has four states, and every transition is stored with who and when:

• Received. Created from the file, with no reconciliation, no owner, and no effect on any report.
• Reconciled. A declared source, every difference computed, and every difference beyond tolerance flagged per field.
• Approved. A person saw the differences and clicked. Only here does a bookkeeping record come into existence.
• Rejected. With a reason from a closed list: supplier unrecognised, quantity mismatch, price mismatch, duplicate, unreadable document.

The state that must not exist is approved automatically. Even a regular supplier sending a byte-identical invoice every month passes through a click, because the invoice that changes its amount is precisely the one that arrives when nobody is looking. What you can shrink is how much a person has to read: a good approval screen shows the differences only, never the whole document.

What fails silently, and how you find out

Invoice-intake failures do not raise errors. They produce records that look perfectly healthy:

• A duplicated supplier. The same ח"פ enters twice under two spellings of the name, and the balance splits across two cards. The check is uniqueness on the number, never on the name.
• A credit note taken in as a charge. In Hebrew the difference is a word in the heading, and sometimes a minus sign lost in a direction flip. The check is document type as its own explicit field.
• An amount in display order. A number stored from what was drawn rather than what was read passes the VAT check by coincidence and fails reconciliation against the order. Looking for repeated differences against orders is what surfaces it.
• An invoice for a closed period. A date parsed as month-day instead of day-month lands in the wrong period. A date-range check against the open window catches it immediately.

One measure is worth watching weekly: how many approved drafts needed correcting after approval. That number tells you whether reconciliation is doing work, not the extraction success rate.

Sources

• Amazon Textract - analyzing invoices and receipts
• Google Cloud Document AI - processor field reference
• Unicode UAX #29 - text segmentation