A workload, in the open
The rules an invoice matching workflow actually follows
Invoice reconciliation matches each invoice line to a purchase order line on SKU, never on line position, because vendors list lines in their own order. Unit price is allowed ±2%. Quantity must be exact. Freight is ignored and reconciled separately. Anything outside tolerance goes to a person, never to an auto-approval.
This is an engagement, not software
There is no product to buy on this page. Shashtram Labs is a services firm: we map one workflow, build the layer that runs it, and stay on it after go-live. If you are shopping for accounts-payable software, better to know that now than five screens down.
0 systems replaced — it reads the ones you run. No migration, no replacement, no data-warehouse project that has to finish first.
Match on SKU, never on line position
The rule the workflow follows, from the note it lives in:
Invoices from this vendor list line items in a different order than the purchase order. Match on SKU, never on line position.
ops/vendor-onboarding.md
Position matching is the default an automation reaches for, and it works right up until a vendor reorders its lines. The note records why it survived review:
Position matching passed review for six weeks because the first vendors we onboarded happened to preserve PO order. It is not a rule, it is a coincidence.
ops/vendor-onboarding.md
The tolerance rules
| Field | Tolerance | What it means in practice |
|---|---|---|
| Unit price | ±2% | A line within two per cent of the PO price matches. Outside it, a person looks. |
| Quantity | Exact | No tolerance at all. A quantity that does not agree is an exception, not a rounding. |
| Freight | Excluded | Ignored by the line match and reconciled separately in freight-accrual. |
Those are numbers, not a configuration screen. Every vendor rule set has them; almost none are published, which is why what tolerance should you allow is a question with no straight answer anywhere on the web.
What happens to everything outside tolerance
Anything outside tolerance goes to escalation-queue. It is never auto-approved, regardless of confidence score. An operator decides.
ops/vendor-onboarding.md
A confidence score does not get a line out of it. Where an unmatched invoice waits for a person is the command center's exception queue, beside the live state and the audit trail behind a held invoice.
When the purchase order and the invoice system disagree
The layer reconciles the conflict and names which source it believed. Where an ERP says 400 and a CRM says 380, it applies the rule your team set, records the decision with that rule and that source attached, and escalates anything it should not decide alone to a person.
Consolidated invoices covering several purchase orders
Two vendors send consolidated invoices covering several POs. Current behaviour splits them, which is wrong about a third of the time. Not yet solved — tracked in consolidated-invoice-handling.
ops/vendor-onboarding.md
That is the honest state of it. The rule set handles one invoice against one purchase order; an invoice spanning several is named as open rather than decided badly. Structured invoicing does not fix it either — e-invoicing mandates do not do the matching.
Freight, reconciled separately
Freight is excluded from the line match by rule. It arrives on the invoice, rarely appears on the purchase order, and matching it against a line it was never on produces a mismatch on every shipped order.
So it is accrued and reconciled in its own note, freight-accrual, against the carrier terms. A freight charge never blocks a line that otherwise matches, and never gets absorbed into a price tolerance either.
Why this rule set exists
Three invoices auto-approved against the wrong lines because quantities matched by position. Caught at month-end, not by the agent.
ops/vendor-onboarding.md
The fix was not a better model. The fix was writing down what "matching" actually means here.
ops/vendor-onboarding.md
Where the rules live, and who can change them
In a plain markdown note in your own storage — not in code, not in a console. An accounts-payable lead who decides the price band should be 3% edits the line that says 2%, and the next run applies it. No redeploy, and the change is a diff with their name on it.
The whole file, field by field, is published on the plain-text note these rules live in.
Matching without replacing the ERP
No. Nothing is replaced and nothing is migrated. The layer sits above the software you already run and reads it where it is — read-only at the boundary — then writes results back into the tool your people already have open. There is no data-warehouse project that has to finish first.
What three-way matching is
Three-way matching is the accounts-payable practice of agreeing an invoice against both the purchase order and the goods receipt before it is paid — price and quantity against what was ordered, quantity again against what arrived. Standard terminology, belonging to nobody.
The rules published here cover the purchase-order-to-invoice leg only. There is no goods-receipt leg in the note behind them, so nothing on this page describes receipt-matching rules, GRN tolerances or receipt exceptions.
How the result is measured
We stay after go-live, and the measure is set before anything is built. If the number did not move, we say so.
Questions
Straight answers.
How do you match an invoice to a purchase order?
Line by line, on SKU rather than on line position, because vendors list lines in their own order. Unit price is allowed a two per cent band, quantity must be exact, and freight is excluded and reconciled separately. Anything outside those bands goes to a person.
Why should invoices be matched on SKU, not line position?
Because line order is not line identity. An invoice can list the same items in a different order from the purchase order, so position matching silently pairs the wrong lines. It passes review for as long as your vendors happen to preserve PO order — a coincidence, not a rule.
What price tolerance should you allow on invoice matching?
In this published rule set, two per cent on unit price and no tolerance at all on quantity. A price inside the band matches; outside it, a person decides. The number is a line in a note rather than a hidden setting, so it can be changed and audited.
Can you automate invoice matching without replacing the ERP?
Yes. The layer reads the ERP and the accounts-payable system where they are, read-only at the boundary, applies the matching rules, and writes the result back into the tool the team already has open. Nothing is migrated and no warehouse project has to finish first.
What is an exception queue?
An exception queue holds every decision the layer refused to make alone. Anything outside the tolerance your team set — a price mismatch, an unmatched line, a missing document — waits there for a person rather than being approved automatically. It sits in the command center, beside the live state and the audit trail.
What is three-way matching in accounts payable?
Agreeing an invoice against both the purchase order and the goods receipt before payment: price and quantity against what was ordered, quantity again against what arrived. The rules published here cover the purchase-order leg only, because no note behind the receipt leg exists yet.
Start here
Bring us one workflow.
Tell us the process that crosses the most systems. You get a scope, a measure and a delivery plan back — and a straight answer if we think it is not worth building.
Get in touch