How an invoice is scored against an ERP record

Every ERP row is stamped on import with four normalised keys, and every extracted invoice gets the same four. They are deliberately boring:

The candidate lookup is an OR over those keys — same invoice number; same supplier and total; same supplier; same total on the same day — limited to the newest 500 rows of the catalog. If it finds nothing, the engine samples 50 rows, re-infers which columns mean what, re-stamps the keys and tries once more. That retry is what makes an export with headers like VendName, Invoice No. and GrossAmt work without anyone mapping columns by hand; the repository keeps a “golden” test for exactly that export shape.

Once candidates exist, each is scored on up to seven header fields: invoice number, supplier, total, invoice date, currency, subtotal and tax. Every field scores exactly 1 or 0. The composite is the plain average of the fields present on both sides — a field your export doesn’t carry is skipped, not penalised. There are no weights to tune.

A clean case first. Note that the ERP total has decimals and the extracted total does not:

{
  "composite": 1,
  "allOk": true,
  "fieldScores": { "invoiceNumber": 1, "supplier": 1, "totalAmount": 1 },
  "discrepancies": []
}

Amounts are compared after rounding both sides to 2 decimals, which is why 1100 and 1100.00 agree. The order of checks inside a field comparison matters: pure-digit invoice tokens are compared as integers; then a 1–4 letter series prefix is tolerated when the shared part is at least 6 characters; then amounts; then dates by UTC day; then 3-letter currency codes; and only then a plain case-insensitive string match. That prefix rule handles the common case where the ERP stores a series and the invoice prints only the number:

{
  "composite": 1,
  "allOk": true,
  "fieldScores": { "invoiceNumber": 1, "supplier": 1, "totalAmount": 1 },
  "discrepancies": []
}

Now a genuine disagreement. The total differs and the ERP date is in a different format:

{
  "composite": 0.6,
  "allOk": false,
  "fieldScores": { "invoiceNumber": 1, "supplier": 1, "totalAmount": 0, "invoiceDate": 0, "currency": 1 },
  "discrepancies": [
    { "field": "totalAmount", "extracted": "100.00",     "erp": "200.00" },
    { "field": "invoiceDate", "extracted": "2026-04-17", "erp": "17/04/2026" }
  ]
}

Two things to notice. The currency matched despite EUR vs eur. The date did not: 17/04/2026 is ambiguous (day-first or month-first), so the engine does not guess, and the discrepancy shows both raw values so the reviewer can see at a glance that it is a format problem in the export rather than a different date. The fix is on the ERP side (export ISO dates), after which Match again re-scores without re-reading the PDF.

Subtotals get one extra allowance: when the gap between the two equals the printed discount, it counts as agreement.

{
  "composite": 1,
  "allOk": true,
  "fieldScores": { "invoiceNumber": 1, "supplier": 1, "totalAmount": 1, "subtotal": 1 },
  "discrepancies": []
}

Lines are paired by item code (exact, case-insensitive). If either line has no code, they are paired by description similarity — 1 minus the edit distance over the longer length — of at least 0.75. For each pair, quantity, unit price and line total must agree within 0.5% or 0.02. A line missing on either side scores 0, and the line score is the share of lines that passed, which is then blended into the composite as one extra field.

{
  "score": 0.667,
  "discrepancies": [
    { "field": "lineItem.quantity",   "extracted": 10,  "erp": 12,  "lineItemDiscrepancyType": "QUANTITY_MISMATCH",
      "itemCode": "HM1607815", "itemDescription": "Horizon Slim Suit Pants Navy" },
    { "field": "lineItem.totalPrice", "extracted": 260, "erp": 312, "lineItemDiscrepancyType": "TOTAL_MISMATCH",
      "itemCode": "HM1607815", "itemDescription": "Horizon Slim Suit Pants Navy" }
  ],
  "compared": true
}

The discrepancy carries the item code and description, so the reviewer reads “10 vs 12 pairs of Horizon Slim Suit Pants” rather than “line 2 differs”.

Independently of the ERP row, the extracted figures are self-checked: line totals (minus discount) against the subtotal, subtotal × tax rate against the tax, subtotal + tax against the total, each within 0.5% or 0.02. An Austrian invoice at 20% VAT with a net of 290 and a gross of 348 produces no findings. The same invoice with the total mis-read as 358 produces one:

[{ "field": "arithmetic.totalAmount", "extracted": 358, "erp": 348 }]

Any arithmetic finding downgrades a would-be full match to a partial one. A 0% reverse-charge or intra-Community invoice is recognised from the printed statement and does not trigger the tax check.

1. Not matched when there is no candidate, or the best composite is below 0.55.
2. Fully matched when every field that could be compared scored 1 (allOk) and the arithmetic check passed.
3. Partially matched otherwise — a candidate exists, and the result lists exactly what disagrees.

The stored result keeps the composite score, the per-field 0/1 scores, and the discrepancy list with the extracted value next to the ERP value. When the extraction has an invoice number and a supplier but no candidate matched on any key, the engine leaves the document Not matched instead of scoring the newest 400 rows — a confident “nothing found” beats a plausible-looking wrong pair.