AP Match is purchase-to-pay reconciliation - two-way, three-way and four-way. It reads the whole case sideways, checks every row of every invoice against the order and the receipt, and reports what does not add up with the amount at stake beside it.
Not a model making judgement calls. An agent is a case type, its document roles, its canonical field mappings and its rule pack. AP Match and Insurance Claims Audit run on exactly the same engine - the difference between them is entirely content.
Declares which documents a case requires - so a case always knows what it is still waiting for.
Purchase order, goods receipt, supplier invoice, inspection certificate.
Every extracted field bound to a shared concept, so one rule serves every layout.
Deterministic rules addressing values by document role, not by a vendor's labels.
A supplier invoice arrives. Somebody has to confirm it matches a purchase order, that the goods actually arrived, that the price is what was agreed, that no line is billed twice, and that this exact invoice was not already paid last quarter under a slightly different reference. It is line-by-line, cross-document, arithmetic-heavy work - done under time pressure, by sampling.
The same line billed twice on one invoice, or the same invoice resubmitted later under a slightly different reference. Both are invisible to a spot check.
Small differences between what was ordered and what was billed. Individually trivial, collectively material across thousands of lines.
Invoices raised against goods that had not arrived, and rounding applied one way consistently, on every row, for as long as nobody adds them up.
Six stages, and nothing in the decision path is a guess. The same case produces the same findings every time, and every finding can be traced to a rule you can read.
Documents arrive by whichever route suits the supplier, assemble into a case by the order number on their own faces, and results are written back beside them.
The number in "N-way" is just how many document roles the case type declares. The engine does not care; the rule pack does.
| Match | Documents reconciled | Typical use |
|---|---|---|
| Two-way | Purchase Order ↔ Supplier Invoice | Services, subscriptions, anything with no physical delivery |
| Three-way | Purchase Order ↔ Goods Receipt ↔ Supplier Invoice | Goods procurement. The shipping default |
| Four-way | + Inspection / Quality Certificate | Regulated, high-value or QA-gated receipt |
SUPPLIER_INVOICE.INVOICE_TOTAL against
PURCHASE_ORDER.ORDER_TOTAL - so a rule reads sideways across
the case rather than down one document.
Eight deterministic checks, each one naming the two documents that disagree, the values that disagree, and the amount at stake.
Line arithmetic is checked on every row of every invoice, not on a sample.
The economics of manual review force sampling. The economics here do not - which is why rules 6, 7 and 8 exist at all.It exists as rows in a table. Rendering that to a page so it can be photographed and guessed at again is absurd - and it is what every OCR-first tool does. A data contract template takes the payload directly.
| Document template | Data contract template | |
|---|---|---|
| Onboarded from | A sample PDF | A sample JSON payload |
| Values come from | OCR and layout analysis | Declared paths, read directly |
| Confidence | Variable - that is what review queues are for | Exact |
| Goes to review | When below threshold | Never |
Four failure modes that survive manual review precisely because they are small, repetitive and spread thinly across a lot of documents.
The same line, or the same invoice, paid twice - across quarters and across references.
Drift between order and invoice that nobody reconciles at the line level.
Payment released for a receipt that does not exist, or that belongs to another order.
Rounding applied consistently in one direction across thousands of lines.
Priced per case reconciled, per tenant. A case is one matter - the purchase order, the receipt and the invoice reconciled together, whenever each of them turns up.
A single entity running two-way and three-way match on a shipped rule pack.
Multiple suppliers and layouts, ERP data straight in, your own rules.
Multi-entity, multi-region, with content packs you control.
Indicative plans shown for illustration. Final pricing is confirmed after a scoping call.
Send us one purchase order, one goods receipt and one invoice. We will return the findings - ranked worst-first, with the money at stake on every row.
+91 7702820516