An AP lead at a mid-sized manufacturer told me her team does "three-way matching" and then, without pausing, listed the other three things they check on every invoice. The contract rate. Whether the GST credit has turned up in their 2B yet. Whether the bank account on the invoice is the one they have on file. Nobody had named it. They were already doing a six-way match by hand.
That conversation is why this post exists. Three-way matching is the textbook control, and it is still the one most ERP vendors sell. But the invoice that lands in an Indian AP queue in 2026 has more claims on it than a PO can verify, and the teams that get burned are usually the ones whose process stopped at three. This is part of our series on agentic AI in finance, and it gets into the mechanics more than most of the others.
What three-way matching checks, and what it misses
The classic control compares three documents before an invoice is approved for payment. The purchase order says what you agreed to buy and at what price. The goods receipt note says what turned up at the gate. The invoice says what the vendor wants to be paid. If quantities and prices agree across all three, within tolerance, the invoice goes through.
The three records
Purchase order
The PO is the anchor. Every other check hangs off it. It carries the line items, unit prices, and the delivery terms you committed to, and it is usually the only one of the three documents your own team wrote.
Goods receipt
The GRN, or the service entry sheet for services, proves that something arrived. It is also the record most often missing or late. In a lot of plants the goods have been on the floor for a week before anyone books the receipt, and the invoice is already sitting in the queue waiting for it.
Invoice
The vendor's claim. This is the document that turns up in twelve formats, with line descriptions that never quite match the PO wording, and with a tax breakdown that depends on which state the goods crossed into.
Where three-way matching lets you down
Three-way matching answers one question well: did we get what we ordered at the price we ordered it? It says nothing about whether that price was the right one in the first place, whether the tax on it will ever be creditable, or whether the vendor asking for the money is who they say they are. Those three gaps are where most of the real money leaks.
Why three checks stopped being enough
Two things changed, and neither was a software decision. The PO stopped being a reliable source of the agreed price. For anything bought under a framework agreement or annual rate contract, the PO is raised by a buyer who looks up the rate, and buyers make mistakes. A PO that matches an invoice at the wrong contract rate passes three-way matching cleanly. The error was baked in before AP ever saw the invoice.
The second is GST. Since input tax credit got tied to what your vendor files, an invoice that matches your PO and GRN can still cost you the tax on it if the vendor never uploaded it, uploaded it with a different GSTIN, or cancelled the IRN after sending you the PDF. The credit shows up in GSTR-2B or it does not, and no amount of PO matching tells you which.
Add vendor fraud, which has moved from fake invoices to changed bank details on real ones, and you have three more records that need checking before payment. Hence six.
The six-way match, one layer at a time
A quick caveat before the list. Six-way matching is not an accounting standard. Two, three, and four-way are the established terms. Six-way is how we describe what a finance team ends up checking in practice once contract pricing, GST, and vendor verification are pulled into the same control, and different teams draw the lines in slightly different places. Here is where we draw them.
Layers one to three: the classic match
PO, goods receipt, invoice. Nothing changes here except the tolerance logic, which gets tighter once you trust the other layers to catch what these miss.
Layer four: the contract or rate card
The invoice price is checked against the agreed rate in the contract, not against the PO. If the PO and the contract disagree, that is a finding in its own right, and one worth surfacing to procurement rather than AP. This is the layer that catches slow price creep, where a vendor nudges the unit rate by a couple of percent every few months and nobody notices because each PO was raised fresh.
What the check looks like
Pull the active contract for that vendor and SKU or service line. Compare unit price, currency, and any volume tiers. Flag anything above the contract rate. Flag anything below it too, since a suspiciously low rate is often a wrong SKU.
Layer five: the tax record
For Indian entities this means two things. First, does the e-invoice IRN on the document verify against the IRP, and does the QR payload match what is printed? Second, does the invoice appear in your GSTR-2B for the period, with the same taxable value and tax amount? An invoice that fails either check should not be paid in full until it is resolved, because you may be funding a tax credit you will never receive.
Timing is the hard part
2B is generated on the 14th of the following month, so an invoice dated the 3rd may be fully matched on five layers and stuck on the sixth for weeks. The practical answer is to pay the base value on a five-way match and hold the GST component until 2B confirms. That is a policy decision, and it is worth making it explicit rather than leaving it to whoever is on the queue that day.
A note on cancelled IRNs
A vendor can cancel an IRN within 24 hours of generating it. We have seen cases where the PDF that reached AP was generated before the cancellation and the replacement invoice never arrived. The printed IRN looks fine. Only a live check catches it.
Layer six: the vendor master
The GSTIN on the invoice should match the GSTIN in your vendor master. The bank account in the payment instruction should match the one on file, and any change to it should have been confirmed through a channel other than email. The vendor's MSME status matters too, since it changes your payment terms under the MSMED Act and what you have to report. Most of the bank-detail fraud I have seen in the last two years would have been stopped at this layer, and none of it would have been caught by the first three.
What changes when an agent runs the match
Six checks done by a person means six systems open on one screen and a lot of tabbing. That is why teams quietly drop layers under month-end pressure. An agent does not get bored on the fifth tab, and it does not skip layer five because it is the 28th and the close is tomorrow. It reads the invoice, pulls the other five records, compares them, and returns a single decision with the mismatches listed. A person looks only at the invoices that failed something.
The read step is where agentic document extraction does the work. Rather than transcribing the invoice and handing a spreadsheet to a rules engine, the agent reasons about the fields in context: this line description maps to that PO line, this tax breakdown implies an interstate supply, this IRN is worth verifying live because the invoice date is within the cancellation window.
Ranges observed across PTAS FinSuite and DocPro deployments in Indian AP teams. They are field observations, not published benchmarks, and they move with invoice volume, how clean the vendor master is, and how many vendors are on rate contracts.
The part people get wrong
The temptation is to make the agent auto-approve anything that passes. Do not. The agent's job is to clear the easy 80% and give the remaining 20% to a person with the evidence already gathered. The moment a six-way match becomes a black box that pays invoices, your auditors will want to see inside it, and you will want to be able to show them.
On confidence scores. Every field the agent reads carries a confidence score, and every layer returns a pass, a fail, or an "unsure". An invoice where the total is read at 99% but the IRN is read at 71% is not a clean pass on layer five, even if the number it read happens to verify. Build the review queue on confidence, and the audit trail writes itself.
On the vendor master. Layer six is only as good as the data it checks against. If your vendor master has duplicate GSTINs and bank accounts nobody has verified since 2021, the agent will faithfully match invoices against bad data. Clean the master first. It is dull work. It is also where most of the value sits.
Getting from three to six without stalling
Nobody switches on all six layers on a Monday. The teams that make it tend to add layers in the order below, and the order is not accidental: each step uses data the previous one cleaned.
Fix the read
Get invoice extraction to the point where PO, GRN, and invoice match without re-keying. If the read is wrong, every later layer inherits the error.
Add the vendor master
GSTIN and bank-account checks first. This is the cheapest layer to add and the one that stops the most expensive mistakes.
Add the tax record
Live IRN verification, then 2B reconciliation. Decide the hold-the-GST policy before you switch it on, or the queue will decide it for you.
Add the contract
Hardest to wire because contracts live in procurement's systems or in a drawer. Start with your top 20 vendors by spend and widen from there.
Questions we get asked
What is 6-way invoice matching?
Six-way invoice matching checks an invoice against six records before it is approved: the purchase order, the goods receipt, the invoice itself, the contract or rate card, the tax record (in India, the e-invoice IRN and GSTR-2B), and the vendor master. Three-way matching covers only the first three.
Is six-way matching a standard accounting term?
No. Two-way, three-way, and four-way matching are the established terms. Six-way is how we describe the set of checks a finance team ends up doing in practice once contract pricing, GST reconciliation, and vendor verification are added. Different teams draw the lines in slightly different places.
Can you do six-way matching without AI?
You can, and many teams do it by hand. The problem is time. Each extra check means pulling another record, so a six-way match done manually takes two to three times longer than a three-way match. Agents make it practical by reading the invoice, fetching the other five records, and returning only the mismatches for a person to decide.
Is it worth the extra three checks?
If your invoices are mostly from a handful of vendors on fixed prices with no GST complexity, probably not yet. Three-way with a clean vendor master will hold. For everyone else, the question is whether you would rather find a wrong contract rate or a missing 2B entry before payment or after. The AP lead I mentioned at the start had been finding them after, in a spreadsheet, at quarter-end, and recovering maybe half.
The fastest way to know where you stand is to put a month of real invoices through all six layers and count what fails. The number is usually higher than the team expects, and it is rarely the three-way layers that fail.