Three-way matching: what to check, and when to call a person

Three-way matching is the check that stops you paying for something twice, or paying for goods that never arrived. It compares three documents written by different people at different times: your purchase order, the invoice the supplier sent, and the record that the goods or the work were received. If the three agree, the invoice can be posted. If they do not, somebody has to look at it.

Most of what it catches is ordinary error, and some of it is not: an invoice with nothing to check it against is also how a shell company gets paid.

The comparison is the easy part. Most of the work of automating it goes into deciding, in advance, what counts as agreement.

What it looks like when it is not goods

This is from my own experience. I have a service agreement. I have SOW one, SOW two, SOW three. Then I have invoice one and invoice two, which relate to one or another SOW. Then we change, for example, the jurisdiction, or the address of the company, and that is an additional amendment. Then we deliver and close SOW three, but SOW two and SOW six are still actual.

That structure is very difficult to find, and very difficult to keep control on. Whether we already hit the cap of SOW two or not - I don't know. I have to go and learn about SOW two, and I have to calculate all the invoices.

Whether the subcontractors of my contractor, the ones included into SOW five, have symmetrical amendments to their contracts, the ones which reflect our NDA and the service agreement - yes or no? I don't know. It is difficult to calculate.

And if you want to give fast feedback on what was paid and what was not, and send it to your accountant, you have to go through all the documents. You don't have a status. What is signed, what is agreed, what is paid, what is not, and whether it is still within the cap or already not. And also who agreed, who signed, who confirmed, who still has not, and what the status is in DocuSign.

That is the whole picture, and usually you don't have it. On top of it you have a lot of messages from your contractors about the agreement procedure itself.

The three documents

The order says what you asked for, in what quantity and at what price. The invoice says what you are being billed for. The third document says what actually turned up: a delivery note, a goods receipt, or, on a services contract, an acceptance act signed by whoever took the work.

Two-way matching drops that third document and compares the invoice against the order alone. It is quicker to set up, and it is blind to the one thing the control exists to catch - a bill for something nobody received.

The same check is written a dozen ways in the trade: 3 way matching, three-way match, purchase order matching. They all mean this.

The invoice is becoming structured. The other two are not.

In Poland the invoice side of this has already been settled by law. Since 1 February 2026 the largest taxpayers have issued their B2B invoices through KSeF, the national e-invoicing system, in a published XML schema; everyone else joined on 1 April 2026. The EU is going the same way: from 1 July 2030 intra-EU B2B invoices move to the EN 16931 standard under the VAT in the Digital Age package.

An invoice that comes out of a government system in a published schema does not need reading. The fields are named, and they are where the schema says they are. That takes one document out of the extraction problem and leaves two, and the receipt is the hard one: a delivery note signed at a gate, a warehouse scan, a supplier's portal, a photograph attached to an email, an act written in prose.

With KSeF a lot has changed. First of all, when you issue invoices it is already in KSeF. You cannot change anything. You can amend something at the end, but it is very difficult to do. So the preparation should be very well done, and after the preparation, when you send it to KSeF, that is all. That is something in concrete.

From the other hand, it is very convenient when you buy services or goods. You can be sure that nobody will scan invoices or send them through mail, and that your accountant or your back office will not lose one, or ask you about it one more time. All the data will be in place and all the invoices will be in your inbox. That is good enough.

But it still does not eliminate the problems with the service agreement or the frame agreement, because we have limitations, we have obligatory assignments, and we have acts and reports which should be related to these invoices. The easiest part is to get the electronic invoice. The hardest part is to check whether it correlates with the SOW, with the report, with the act and with the agreement.

Agree the fields before you automate anything

A matching run fails on data far more often than on logic. Write down the answers to these before the first document goes through it.

What links the three documents. Usually the order number, printed on the invoice by the supplier. Decide what happens when it is missing, when it is wrong, and when one invoice covers several orders - each needs an answer that is not "a person will notice".

What tolerance applies, and to what. A tolerance in money and a tolerance in quantity are different decisions, and rounding on a converted currency is a third. Each one usually needs a cash figure and a percentage of the line together, whichever binds first. Set them as amounts your finance team would recognise. A rule nobody can explain six months later gets overridden by hand until it may as well not be there.

Which date governs. The order date, the delivery date and the invoice date can straddle a period end or a price change, and under a national e-invoicing system the date the tax authority holds is a fourth. Pick the one that governs and write down why.

Who owns each kind of exception. Not a queue that everybody can see and nobody answers. A name, or a role, per type. And keep two of those rights apart: whoever can change a tolerance should not also be clearing the exceptions it lets through.

None of this is software. It is the schema the software then works to. An expert sets the axes of a domain once and the machine works under them; a team that has never written its own down will discover them one exception at a time.

The three outcomes

Every document that goes through the check lands in one of three places. Count them separately: they mean different things and they are fixed in different ways. Two of the three end with a person.

It matched

The three documents agree inside the tolerance you set. The invoice is posted and nobody reads it. This is what you are buying.

No link was found

The invoice arrived, but nothing ties it to an order or to a receipt. The order number may be absent or mistyped. The goods may be sitting in the warehouse with nobody having booked them in. Or there was never an order, which is a procurement problem wearing an accounts payable hat.

This is the outcome people forget to plan for, and it is the one that grows. There is nothing to compare yet, so the card has to help a person find the other document rather than judge a difference. It is also where the goods received not invoiced account fills up with items nobody can explain, which is often the argument that gets the project funded.

The invoice does not match the purchase order

There is a link, and the numbers disagree. A price that moved, a part delivery, a short delivery invoiced in full, a freight line the order never had, tax applied where the contract says it should not be. Each of these is a different conversation with the supplier, so the card should say which one it is rather than reporting that something is wrong.

The order of work is much the same whichever it turns out to be.

1. Work out which of the three documents is wrong. It is often not the invoice. A receipt booked short because the second pallet came the next morning looks exactly like an overbill.
2. Read the contract before the order. A price the order does not carry may still be the agreed price, and the order is what is out of date.
3. Post what both sides agree on and hold back the difference, so one line in dispute does not age the whole document.
4. Put it to the supplier in writing, with the three documents attached and a date to come back by.
5. Record the decision against the document itself. An agreement that lives in one person's mailbox is not there in March, when the same supplier does the same thing.

What belongs on an exception card

The measure of a good exception is how long it takes a person to settle it. Opening the source documents in three systems and reading them side by side is half an hour. It should be a minute, and that is a question of what the card carries:

• The three documents named, dated and linked, so nothing has to be searched for.
• The fields that disagree, shown next to each other - ordered, delivered, invoiced - and nothing else competing for attention.
• The size of the difference in money, in one currency, with the rate used if one was.
• Every value clicking through to the exact page and position it was read from. That position has to be recorded when the document is taken in and carried the whole way.
• The supplier's history on this point. The same price gap three months running is a contract to renegotiate.
• One action, or a small set of them. Accept, query, hold, send back - and whatever is chosen, recorded against the document.

The click matters because the position of the fragment has to be checked - by a human, or by a model as well - against specific, strictly extracted values, with a strict understanding of what those values are and of whether they fit into the agreement.

The people who check will have a summary from the AI, and that is good. But they have to confirm that everything is grounded in the documents, first of all. And second, they will possibly issue some amendments to the documents, and they have to do that based on the current situation, which they check by going into the guts of the agreements. That is the only way to be sure that everything is in place, because those humans will take the responsibility, not the AI.

Services: the acceptance act is the third document

The act comes to you together with the invoice, usually, and with the report of work done - and with the sources, in our case. We issue them together. The act confirms that everybody is happy with the work we delivered and with the product delivered.

Sometimes it is necessary. In Poland it is necessary; in other countries it is not. I try to use acts always, because the act confirms that everybody understands what was delivered and that everybody is happy with it. For us it is part of the customer satisfaction programme: it allows the client to understand, one more time, that everything was delivered, to ask questions, and to be sure that all that was requested was delivered.

It is harder to match than a delivery note, for one reason: the act is written in prose rather than in lines. The period, the scope and the sums have to be read out of a document that was never designed to be parsed, and the signature matters as much as the figure. That is an extraction problem before it is a matching problem.

Who this actually lands on

I don't know who signs for this. In every case different people can be the decision makers. But I believe it is those people who work with a lot of documents - in investment, for example, or in lending to the B2B segment, where they have to control a lot of covenants according to the contract. Those who work with a lot of documents and have to control everything are the ones responsible for it.

And it is not the CTO at all. This is not a technological question. It is a process question and a predictability question.

What to ask of invoice matching software

Automated invoice reconciliation is a well-worn category, and most of the products in it will match a clean invoice against a clean order. The differences show up on the documents that do not fit:

• Can it take a structured invoice as it stands, rather than pushing it back through an extraction step it no longer needs?
• Does it hold the tolerances and rules as something your team can read and change, or are they buried in a configuration nobody owns?
• When it cannot match, does it say what it looked for and where it stopped?
• Can a reviewer get from any value on the screen to the place in the document it came from?
• Does it record what a person decided, and why, in a form an auditor can follow a year later?
• Does it measure the three outcomes over time, so you can see whether the exceptions are falling?

The last one is the one to insist on. Nobody can tell you what share of your documents will go straight through before they have seen your documents, so a figure quoted in a sales deck is a figure about somebody else's post room. What you should hold a supplier to is that the share is measured at all, and that it is the thing they are improving.

Where to start

Take one supplier, or one contract, with a steady flow of documents and a known set of problems. Write down the fields, the key and the tolerances for that one alone. Run the check over a month of documents you have already processed by hand, and compare the outcomes against what your team decided at the time. The disagreements are the specification.

There is a budget question underneath this, and it is simpler than it usually gets made. Most companies already pay somebody outside to process incoming documents: a contractor, a shared service centre, an outsourcer. That line is in the budget today. So the conversation is about replacing it document by document, and not about headcount. Three questions settle the size of it - how many counterparty documents arrive each month, who handles them now, and what you pay for that.

WislaSearch does this inside your own perimeter: classify the document, extract the fields your schema names, match it to its order or contract, pass it through, or hand a person an exception card with the source page attached. If you want to try it on your own documents, pick one class of document and we will run it with you.