The Third Document That Is Our Own
Three-way matching compares what you ordered, what arrived, and what you were billed. We do the first two properly, with tolerances and a payment gate behind them. The third document is one we generate ourselves from our own prices — so we call this a two-way match, in the product and here.
Almost every procurement system in this bracket advertises three-way matching. Very few of them have anywhere to put a supplier's invoice. It is worth understanding why those two facts coexist so comfortably.
The two documents we genuinely have
The purchase order, with its lines, quantities and prices. And the receipt, recorded at check-in, with what actually arrived.
The comparison between them is careful, and several of the details are the ones that separate a working match from a demonstration.
- Tolerances on quantity and price are set per organisation, so a small variance is not an exception.
- An order with nothing received yet is treated as open, not as a shortage. Getting this wrong makes every new order an exception and the queue unusable within a week.
- Partial deliveries are summed. A split delivery is compared against the order in total rather than one row at a time.
- Receipts are resolved through the order's own adjustment, so a check-out can never be mistaken for a receipt.
- The result is persisted on the order — a status, a discrepancy count, and when it was last checked — and discrepant orders collect in an exception queue.
And it has teeth. A single gate decides whether an order may be paid, and every payment path in the product calls it: the web order payment, the API, manual vendor payments, two mobile-money paths and the card processor. A discrepancy blocks by default. Paying before receipt only warns, because prepayments are legitimate, and that warning can be turned into a block per organisation.
Overriding needs a dedicated permission — deliberately not the one that approves purchase orders — plus a written reason, stamped with who and when. And the override is pinned to the discrepancy count it authorised, so if the documents change into a different problem the authorisation withdraws itself rather than continuing to release money.
Two documents, compared carefully, with a gate on the money. That part is real and we would put it against anybody's.
The third document, and what it actually is
There is an invoice record in the matching path. It is created at check-in, by us, valued from our own item prices. It carries no vendor and no supplier invoice number, because it is not a supplier's invoice — it is a valuation of what was received.
Your supplier's actual invoice exists in the system as a file attached to the order. Nothing reads it. There is no capture, no OCR, no line extraction, and no way for its numbers to enter the comparison.
So a match against that third document compares our valuation of the receipt against our own order. It is a real check and it can find real things — a price on the order that does not match the item master, for instance — but it is not the control that three-way matching exists to provide. That control is the one that catches a supplier billing you for something other than what they delivered, and it requires the supplier's numbers.
Why this is the wrong thing to be relaxed about in Thai manufacturing supply
Because the invoice discrepancies that matter in a components and contract-manufacturing supply chain are rarely dramatic. They are a unit price a fraction above the agreed one, a quantity billed against an order that was partially delivered, a surcharge added at invoice stage, a currency applied differently from the quote.
Every one of those is invisible to a match that does not read the invoice. And every one of them recurs, monthly, across a supplier relationship that lasts years — which is what makes the aggregate large even though each instance is small enough to wave through.
Four questions that test a three-way-matching claim in ten minutes
Where do I enter my supplier's invoice number?
A good answer sounds like
A field, on a record, that the match reads.
What it actually means
This one question settles it. If the answer is an attachment or a note, the third document is not in the comparison.
Whose price is on the third document?
A good answer sounds like
The supplier's, from their invoice.
What it actually means
Ours is our own. A match against your own prices cannot catch a supplier billing differently from the order.
Show me an order where the invoice disagrees with the order but the receipt agrees.
A good answer sounds like
An exception.
What it actually means
The scenario three-way matching exists for. Ask for it specifically rather than for a demonstration of the feature.
What stops payment when there is a discrepancy?
A good answer sounds like
A single gate, named, called by every payment path.
What it actually means
Ours is exactly that, and it took finding six separate payment doors to build. Ask how many doors theirs has.
Our position
Buy this for the two-way match and the payment gate, which are genuinely strong and which stop the largest category of loss — paying for goods that did not arrive. Do not buy it as three-way matching, because it is not, and we will not describe it that way. Keep invoice checking as a human control against the order until there is somewhere to capture a supplier invoice, and make sure your finance team knows that is where the boundary is.
What AWRA OpsHub does today
- A two-way match comparing ordered against received, per line, with per-organisation quantity and price tolerances.
- Partial deliveries summed, an unreceived order treated as open rather than short, and receipts resolved so an issue cannot be read as a receipt.
- Match status, discrepancy count and last-checked time persisted on the order, plus an exception queue.
- A single payment gate called by all six payment entry points, blocking a discrepant order by default.
- Payment before receipt warning rather than blocking, switchable to a block per organisation.
- Overrides requiring a dedicated permission and a written reason, pinned to the discrepancy count they authorised so they self-withdraw when the problem changes.
What it does not do
- Any capture of a supplier invoice. There is no vendor, no invoice number and no supplier-supplied line data in the matching path.
- Invoice OCR or line extraction. The supplier invoice is a file on the order and nothing reads it.
- A genuine three-way match, and we do not use the phrase in the product.
- A payment run or batch payment approval — payments are recorded one at a time.
- An inspection or quality gate at receipt, so four-way matching is not achievable either.
Not ours, by choice
- The invoice-shaped record in the matching path is our own valuation of the receipt. Calling it an invoice in the schema is a naming legacy and we would rather explain it than rename it quietly.
- The two-way match catches the largest single loss in procurement — paying for what did not arrive. The gap is the second-largest, not the first.
- Nothing here is Thai. It is what a match without a supplier invoice can and cannot see; Thailand is where the long-running components relationship makes the small recurring discrepancy worth the most.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax authority pipeline, a local-language interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax authority pipelines and reporting
Electronic invoicing against your authority's published interface or its accredited network, with retries, a failure queue and a daily report of sales that never reached it. The regimes here range from a live clearance model to a purely voluntary scheme, so this is one build per country and we will say which country rather than sell an ASEAN integration that does not exist.
Local-language interface, banks and wallets
Interface text and document templates in the language your finance floor and your statutory documents actually require, plus real-time payment collection, e-wallet settlement and bank statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Social security, provident fund and withholding computed on live records, with the contribution files produced in the layout each agency expects and any statutory bonus accrued through the year rather than found at the end of it.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedCheck the boundary before your finance team assumes it
The most expensive misunderstanding here is a finance team believing invoices are being checked automatically. Ten minutes with us and your accounts-payable process will know exactly where the machine stops.
Walk the boundaryFrequently asked questions
Can I attach the supplier invoice at all?
Yes — there is a place on the order for the file, and it is worth using because it puts the document where anybody investigating a discrepancy will look. What it does not do is enter the comparison; nothing parses it.
What does the two-way match actually catch, then?
Short delivery, over-delivery beyond your tolerance, and a price on the order that disagrees with the item master beyond your tolerance. In cost terms that is the largest category — paying for goods that never arrived — and it is the one worth having automated.
Would you build invoice capture?
It is the same project as the missing third document and we treat it as one piece of work: somewhere to record a supplier invoice with its own number, vendor and lines, and then optionally a way to get those lines in without typing. Describe the volume you process and we will scope it properly rather than guessing.
