aistack
Book consultation →
← All articles
Finance / MCP

Invoice matching: the check your bookkeeper should not do by hand

Does the supplier invoice agree with what you ordered and with what actually arrived? How Claude runs that check across accounting, stock and approval history, and what it does when the numbers disagree.

August 2026·7 min read·Milan Janoštík·
ClaudeMCPInvoicing
Infographic: an incoming invoice on the left, a blue MCP conduit with a small Claude orb and an identity lock in the centre, order and goods receipt cards on the right with green matching rows and one amber difference row.

Automated invoice processing usually means one thing to people: get the PDF into the accounting system without retyping it. That is half the job. The other half is the check: does the amount on the supplier invoice agree with what we ordered, and with what actually arrived? In most small and mid-sized companies a person still does that part by hand, with three windows open side by side.

The work nobody wants

A supplier invoice lands. Someone opens it, finds the matching order, finds the goods receipt from the warehouse and compares three numbers: quantity, unit price, total. For half the invoices this takes thirty seconds. For the other half something is off. Eight units arrived, ten are invoiced. Freight appeared that nobody agreed to. An old price list was applied.

Then the detective work starts. Who ordered it. Whether a line exists somewhere in mail where a salesperson accepted the higher price. Whether it was an agreement or a mistake. Month end ends up looking like this: the bookkeeper is not doing accounting, she is reconciling thirty documents that almost agree with each other.

The invoice matches the order. The order does not match what arrived. And nobody knows which of the three is right.

Month end, abridged

What the check actually is

The trade name for it is three-way matching: lining up the invoice, the purchase order and the goods receipt. There is nothing mysterious about it. It is a comparison of three lists that were created at different times, in different systems, in different shapes. The whole difficulty is that those three lists never sit on one desk at the same moment. They only meet inside the head of the person switching between windows.

We do it differently. Claude does not receive the invoice as a mail attachment. It gets read access, through an MCP server, to the three places where the data already lives. MCP is the protocol Claude uses to talk to company systems. The server is small and does only a few specific things: read the received invoice, find the order, find the goods receipt. And it signs in with your identity, not with a universal service account.

The rule the bridge holds
Claude never sees more than the person asking
The bridge carries the identity and the permissions of whoever asked. When a warehouse lead asks about an invoice, they see quantities and the receipt. When the finance director asks, they also see margins and price terms. No copy of the accounting database is made anywhere, and no shared account holds rights to everything.
Incoming invoice, an MCP bridge carrying your identity, order and goods receipt. Green rows agree, the amber row is the difference someone has to decide on.

Concretely: Pohoda, the stock module and the approval trail

Say your books are in Pohoda, goods receipts are created in the stock module, and orders live in mail and on Drive. In a Czech company under fifty people that is an entirely ordinary setup. We change none of it and migrate none of it. We add one bridge that reads what it needs from each place in order to compare.

  • Finds the matching order for a received invoice by supplier, amount and date, even when the order number is missing from the invoice.
  • Compares the lines: quantity, unit price, currency and VAT rate against the valid price list.
  • Pulls the goods receipt and establishes what actually arrived, not what was supposed to arrive.
  • When the numbers disagree, searches mail and Drive and shows whether the difference was ever agreed in writing.
  • Writes a difference report: what matches, what does not, by how much, with a link to the source document on every line.

Picture a small construction firm with two hundred supplier invoices a month. In the morning the list is on the desk: a hundred and seventy clean, twenty with a small price deviation, ten where the delivered quantity does not agree. The bookkeeper does not start by searching. She starts by deciding. That is the whole change. Some suppliers already send invoices as ISDOC, the Czech structured invoice format, and the European VAT in the Digital Age package pushes further in that direction before the decade is out. There will be more structured data, not less.

What invoice matching will not do, and why that is good

Claude does not pay. It does not approve a difference, does not edit the order, does not call the supplier and does not write anything back into the accounting system. It reads and compares. That is where its role ends and yours begins.

That boundary is not a technical limitation we plan to remove later. It is the reason the pattern can be trusted. A system that sees a lot and changes nothing has a very small blast radius. On top of that, every query and every human approval sits in one audit trail, so in three months you can still find out who accepted the difference and on what grounds. You report line-level data from received invoices to the tax authority anyway, so keeping it clean is not an academic question.

3 sources
invoice, order, goods receipt in one query
~4 min
manual chase of one disputed invoice, in this illustration
0 copies
the data stays inside your own systems

What it would take

This does not start a year-long project. It starts with one supplier or one document type, so that within a week you can see whether the report matches reality. The bridge runs on your infrastructure, in your tenant, with your audit log. Switch it off and your systems keep working exactly as they did before.

Received invoiceMCP server (your identity)Order and goods receiptDifference reportHuman approval

What is left

The model is not the bottleneck. The bottleneck is the gap between Claude and the data your company already has. The invoice, the order and the receipt all exist. They simply never meet until a person makes them meet. Closing that gap is the work we do.

Write to us. A short call is enough to walk through how an invoice travels from mail to payment at your company, and to tell you which point is worth connecting first.