The Third Document Nobody Has
Matching an order against a receipt against the supplier's invoice is the standard control over paying for goods. We do two of those three. The third is not weakly implemented — it has no data behind it at all, because what we call an invoice is a document we generated ourselves.
The control everybody names when asked how they stop paying for goods they did not get is a comparison between three documents: what you ordered, what arrived, and what you were billed. Agreement on all three, within tolerance, and the payment is safe to release.
We compare two of them properly. The third one we do not have.
What the third document actually is in our system
When goods are received, a record is created that the system calls an invoice. It carries line items, a total and a currency, and it is attached to the receipt. It looks like the third leg of the match and it is positioned where the third leg would be.
It carries no supplier. It carries no invoice number. And its prices are our own purchase prices, taken from our item records — not from anything the supplier sent us. It is a valuation of the goods we received, priced by us, generated by us, at the moment we received them.
Comparing that against the receipt is comparing the receipt with a copy of itself.
A three-way match where you wrote the third document yourself is a two-way match with a longer name.
The supplier's real invoice does exist in the system. It is a file attached to the purchase order. You can open it, and a person can read it. Nothing else in the product ever does — every use of it either hands you the attachment or checks whether one is present. No line, no total, no number and no date is ever extracted from it, which means no control can ever be built on it.
What that means for the control itself
It is worth being precise about what survives, because a great deal does. The two-way match is real and it is careful: it compares per line, applies tolerances you set for quantity and price, sums partial deliveries rather than reading one of them, treats an order with nothing received as open rather than short, and keeps an exception queue. A discrepancy blocks payment by default, and overriding it needs a specific permission plus a written reason that is pinned to the discrepancy it authorised.
So the machinery is good. What it can catch is the question.
What each comparison can and cannot catch
Everything in the first group is a discrepancy between what you asked for and what turned up, and we handle those well. Everything in the second is a discrepancy between what turned up and what you were billed — which is the entire reason the third document exists, and it is the group we cannot see.
Why this is a Latin American post
Because of an irony that is specific to this region and getting sharper every year.
In much of the world the supplier's invoice arrives as a PDF or on paper, and the reason systems struggle to use it as data is that it genuinely is not data. Extracting it means scanning, reading and guessing, which is why invoice capture is a whole product category.
That is not the situation here. Across this region the supplier invoice is increasingly a structured electronic document by default — issued, validated and delivered in a machine-readable form, with a number and an issuer identity that are meaningful outside your organization. The hard problem that stops three-way matching elsewhere has largely already been solved for you, by regulation, at the supplier's end.
And we still take it as a file attachment. In a region where the third document arrives as data, the reason our match has only two legs is not that the third is hard to read — it is that we never built anywhere to put it.
What we would need to record before the match could have a third leg
- A supplier invoice as a record, not a file — with the issuing supplier on it.
- The invoice number the supplier used, so the same bill cannot be received twice under two references.
- The invoice date, which is what payment terms actually run from.
- Its lines, resolved to the items they refer to, so a per-line comparison is possible at all.
- Its own totals and tax, so the document can be checked against itself before it is checked against anything else.
- A link to the order it bills, which is the only part of this we have today.
That list is deliberately short and deliberately unglamorous. None of it is difficult. It is simply absent, and its absence is the whole reason the control stops where it does.
Two, and the first is the whole thing
This is the largest genuine gap in our procurement module and we would rather describe it accurately than in stages that make it sound smaller.
A supplier invoice as a first-class record
Vendor, number, date, lines resolved to items, totals and tax — captured manually to begin with, because even typed by hand it makes duplicate detection, price comparison and a genuine third leg possible. Everything else here depends on it, and nothing else is worth building first.
Ingesting the electronic invoice directly
Once the record exists, populating it from the structured document the supplier already issued is the natural next step, and in this region it is a far smaller problem than optical capture would be elsewhere. This is the part where the regional situation works in our favour rather than against it.
We would not sell the second without the first. A parser feeding nowhere is a demonstration, and the value is entirely in what the record then makes checkable.
Talk to us about invoice matchingFour questions that find out whether a match is really three-way
Where does the supplier invoice live — a record, or a file?
What a straight answer sounds like
One word. Ours is a file.
Why it matters
This single question settles it. A file cannot be compared to anything.
What stops the same invoice being paid twice?
What a straight answer sounds like
A number, uniquely constrained. Ours does not exist.
Why it matters
Duplicate payment is the most common loss in accounts payable and it needs exactly one field to prevent.
Bill me for 100 when 60 arrived. What happens?
What a straight answer sounds like
A block, or nothing. Ours is nothing.
Why it matters
This is the scenario the third document exists for. If it passes silently, the control is two-way whatever it is called.
Can you ingest an electronic invoice as data?
What a straight answer sounds like
Yes with a format named, or no.
Why it matters
In this region the answer should increasingly be yes, and a vendor who has not noticed the invoice is already structured is not paying attention to your market.
What AWRA OpsHub does today
- A per-line comparison of what was ordered against what was received, with quantity and price tolerances you set.
- Partial deliveries summed, so a split delivery cannot creep past the comparison one receipt at a time.
- An exception queue and a match status kept on the order, rather than a check that runs and is forgotten.
- A payment gate — a discrepancy blocks payment by default across every payment route, and an override needs a specific permission, a written reason, and is pinned to the discrepancy it authorised so it self-withdraws if the problem changes.
- The supplier's invoice retained as a document, attached to the order and served securely.
What it does not do
- No supplier invoice as a record. No vendor on it, no invoice number, no invoice date, no lines.
- Nothing reads the attached invoice file. It is served to people and never parsed.
- No duplicate-invoice detection, because there is no invoice number to compare.
- No price comparison against what you were billed — only against what you ordered.
- No electronic invoice ingestion, in any format, in any market.
- Therefore no three-way match, and we do not use the term for what we have.
Not ours, by choice
- We cite no country's electronic invoicing rules in this post. Where our copy discusses a specific regime it does so with a date and a source, and this argument needs neither.
- We describe our control as a two-way match because that is what it is. If you see the phrase three-way matching used about this product anywhere, it is wrong and we would like to know where.
The verdict
Our controls over receiving are good and our control over paying is honest but narrow: we can prove what you ordered agrees with what arrived, and we cannot tell you whether the bill agrees with either. In most markets the excuse for that is that the supplier's invoice is a picture of a document. Here it usually is not, which makes the gap ours rather than the world's. If your accounts payable exposure is the invoice rather than the delivery, ask the file-or-record question first, of us and of everyone else — it takes one sentence to answer and it settles the whole conversation.
Send us a supplier invoice as you receive it
In whatever form it arrives. We will tell you exactly what we can do with it today, which is less than you would hope, and what capturing it as a record would let you check.
Talk to us about accounts payable