Voucher Matching

A cross-border payment is only safe when six documents agree: the sales order, the delivery note, the invoice, the customs declaration, the payment instruction, and the internal approval. Today a finance team reads all six by hand, for every payment, so reconciliation takes days and the quiet mismatches in quantity, currency, tax, or payee surface at month-end, after the money has already gone. Voucher Matching reads the whole pack at once, cross-checks it line by line against your own tolerance rules, pays the clean packs automatically, and routes the risky ones to a named approver with the exact mismatch highlighted and a fix already drafted. It runs in production today on a multi-business-unit trading group's own infrastructure, every released payment carries a full citation trail, and the running cost stays roughly flat as volume grows.

A payment voucher is the pack of paperwork that says "this money should move." It is not a single document. For a cross-border or contract payment, it is a set of six separate records that each tell one part of the same story, and the payment is only safe to release when all six tell the same story. If even one disagrees, the business is about to send money out wrong, in the wrong amount, the wrong currency, to the wrong payee, or against goods that never arrived.

The pack is built up over the life of a single shipment, and a different person or system touches each document along the way:

• The sales order, what was agreed: the supplier, the line items, the quantities, the unit prices, the currency, and the agreed payment terms. Raised by procurement or the commercial desk at the start.
• The delivery note (or goods-received note), proof of what physically arrived: the quantities actually delivered, against the quantities ordered. Signed off by the warehouse or receiving site.
• The invoice, what the supplier is charging: line items, quantities, prices, tax, freight, totals, and the invoice currency. Sent by the supplier, often weeks after the goods.
• The customs declaration, what crossed the border: declared value, HS codes, duty and tax, country of origin, and the consignment it belongs to. Filed by a customs broker, frequently in another language and another tax regime.
• The payment instruction, how the money is meant to leave: the payee name and bank details, the amount, the currency, and the value date. Drafted by the payments desk.
• The internal approval, the sign-off that authorises release: who approved, at what limit, against which budget or contract.

Putting the pack together, and checking it, is almost entirely manual today. The documents arrive in every format imaginable, on their own timelines, from parties who do not coordinate with each other: a digital PDF invoice, a scanned and signed paper delivery note, a customs declaration emailed by a broker in a third country, a payment instruction in a spreadsheet, an approval sitting in someone's inbox. A finance clerk gathers them, lays them side by side, and reads across all six to confirm they reconcile, checking that:

• the quantity invoiced matches the quantity ordered and the quantity actually delivered;
• the currency on the payment instruction matches the currency on the invoice and the approval;
• the tax and declared value reconcile with the customs declaration;
• the payee on the payment instruction matches the supplier on the sales order and the supplier master;
• every total, sub-total, freight line, and reference number ties out across the documents that should share it.

Only when all of that lines up, within whatever tolerance the business allows for that supplier and that currency, is the payment released.

Doing this by hand, at the volume a cross-border payments desk runs, is slow, costly, and error-prone in ways that compound:

• Finance is permanently behind. The pack on the desk is always from last week's shipment, because reading six documents per payment eats the whole day. There is no version of the manual process that catches up.
• The chasing costs more than the payment. Suppliers email to ask where their money is, and answering them, hunting down the missing approval or the broker's declaration, takes more time than the payment itself.
• The quiet mismatches are the expensive ones. A wrong currency, an over-charged quantity, a tax line that doesn't reconcile with customs, a payee that doesn't match the supplier master, these don't announce themselves. They get caught at month-end, if at all, and usually after the money has already gone, which turns a check that should have taken seconds into a write-off and a recovery effort.
• There is no time left for genuine review. Because the clerk's whole day goes on the mechanical cross-checking, the judgment that should sit on top of it, "does this payment actually make sense?", never happens.

The pattern is always the same: the pack arrives, the reconciliation takes days, and the supplier emails again. The currency was wrong all along.

Voucher Matching applies AI extraction, document matching, and rule-based decisioning across every payment pack a desk processes, turning six loose documents into one checked, released-or-flagged decision with its evidence attached. Where a clerk reads one pack at a time and tires by the afternoon, the agent reads every pack the same way, every time, and keeps a record of how it reached each result.

Across thousands of packs, it produces a consistent, checkable understanding of each payment:

• whether all six documents are present, and which one is missing if they are not;
• whether the quantity invoiced reconciles with the quantity ordered and the quantity delivered, within tolerance;
• whether the currency is consistent across the invoice, the payment instruction, and the approval;
• whether the tax and declared value reconcile with the customs declaration;
• whether the payee on the payment instruction matches the supplier on the order and the supplier master;
• whether every total, freight line, and reference number ties out across the documents that should share it;
• which packs are clean enough to release automatically, and which carry a mismatch that needs a person;
• for every flagged pack, exactly which field disagrees, in which two documents, and by how much;
• and, across the whole book of payments, where time and money are leaking, how many packs are sitting on a currency mismatch this week, what the voucher-to-payment cycle time is, which suppliers generate the most exceptions.

The clean packs pay themselves. The risky ones arrive on an approver's desk already explained, with the mismatch highlighted and a fix drafted, so the human spends their judgment on the genuine exception instead of on the mechanical reading.

Voucher Matching transforms six disconnected documents, sales orders, delivery notes, invoices, customs declarations, payment instructions, and approvals, into a single, central, source-backed decision on whether a payment is safe to release. It helps the organisation:

• release clean payments in seconds instead of days;
• catch currency, tax, quantity, and payee mismatches before the money moves, not at month-end;
• free working capital and pay suppliers on the right terms;
• make currency exposure and payment-cycle health visible in real time;
• cut the supplier chasing that today costs more than the payments themselves;
• give auditors a full citation trail behind every released payment;
• grow pack volume without growing the finance headcount to match;
• and preserve the desk's matching rules and tolerances as a consistent, enforced policy rather than tribal knowledge.

In simple terms, Voucher Matching lets a finance team approve every cross-border payment with the same rigour, every time, and only spend human judgment where there's a real exception.

It sits on top of your current process and quietly removes the part everyone dreads, the manual cross-checking of six documents. Nothing to rip out, nothing new to learn. The finance team keeps working the way they always have; the only thing that disappears is the dread of reading six documents per payment.