Vendor invoice reconciliation in a shared-services finance team
This is a methodology scenario, not a client engagement. Chokmah has not delivered this engagement for a named client. The workflow, constraints and sequence describe how we would run it. Any figures shown are illustrative targets, not measured results.
Vendor invoice reconciliation is the three-way matching of invoices against purchase orders and goods receipts, where the exceptions are the manual work. It is a strong back-office first project because the exceptions are logged and measurable. This page describes how Chokmah would run that engagement.
- Back office is where the returns are; MIT found over half of GenAI budget went elsewhere.
- Separate lookup exceptions a system can propose from judgement exceptions it should not.
- The proposer assembles evidence and names the discrepancy; a person approves the payment.
- False-clear rate is the safety metric and is a release gate on every change.
- Genuine vendor errors are flagged for dispute, never quietly reconciled.
The situation
A shared-services finance team receives vendor invoices across email, a portal and PDF attachments, and matches each one against a purchase order and a goods-receipt record before it can be paid. When the three agree, the invoice clears. When they do not, it becomes an exception.
Exceptions are the work. A quantity is off by one, a tax line is calculated differently, a vendor has billed against the wrong PO line, a partial delivery has not been receipted, a currency or a unit does not match. Each of these lands in a queue and is resolved by a person reading three documents side by side and deciding which one is right.
Back-office document workflows like this are where the returns are, and where the spend usually is not. MIT's 2025 research found that more than half of enterprise GenAI budget went to sales and marketing despite better returns being available in exactly these back-office functions (MIT NANDA, July 2025). This scenario is a composite of invoice, purchase-order and goods-receipt reconciliation as it appears across shared-services centres. It does not describe any specific client.
Constraints
- The three-way match touches the ledger. A wrongly cleared exception is a wrong payment, and reversing a payment is far more expensive than holding one.
- Vendor master data is inconsistent. The same supplier appears under several names, tax IDs and payment terms across systems.
- Segregation of duties is a control requirement. The system that proposes a match cannot be the system that approves the payment.
- Some exceptions are genuine vendor errors that must be disputed, not reconciled. Automating the reconciliation would hide the dispute.
- Month-end concentrates volume and pressure. Behaviour during the last three working days is not the behaviour during the rest of the month.
How we would run it
- 1Week 1
Classify a full quarter of exceptions by cause
Pull a quarter of resolved exceptions with the invoice, the PO, the goods receipt and the resolution taken. Classify by cause: quantity mismatch, price variance, tax discrepancy, wrong PO line, missing receipt, duplicate, genuine vendor error. A quarter is the minimum window because month-end distorts any shorter sample. The cause distribution decides which exceptions are lookups a system can propose and which are judgements it should not touch.
- 2Week 1
Shadow the accounts-payable team and separate lookup from judgement
Watch how exceptions are actually cleared. The distinction that matters is between exceptions resolved by consulting a second document (a clerical lookup a system can do), and exceptions resolved by a decision about who is right, which is judgement. Only the first category is a build candidate. The second stays with a person, and the shadowing is what tells the two apart.
- 3Week 2
Baseline cycle time, touch count and first-pass match rate
Agree and record the metrics before the build. Median and worst-case days to clear an exception, number of people who touch a typical exception, and the first-pass match rate on incoming invoices. Define each one with the finance lead in writing so the post-build number is comparable. If the current process is not measurable at all, that is the first finding and it changes the engagement.
- 4Weeks 3-4
Build a reconciliation proposer that shows its working
The system reads the three documents, identifies the exception cause, retrieves the relevant PO and receipt, and proposes a resolution with the specific mismatched fields highlighted and the source of each value shown. It routes the proposal to an approver. It never posts to the ledger. The value is in assembling the evidence and naming the discrepancy, not in taking the action, and keeping the human as the approver preserves segregation of duties by design.
- 5Weeks 4-5
Build the evaluation harness from historical exceptions
Freeze a labelled set of past exceptions with their correct resolutions and run every change against it. Score whether the system identified the right cause and the right mismatched field, not whether it produced a plausible-looking answer. Track the false-clear rate specifically: a system that proposes clearing an exception that should have been disputed is the failure mode that matters, and it must be measured on its own.
- 6Week 6
Hand over to the finance team with the control model documented
The team keeps the repository, the harness and a written control note stating exactly where the human approval sits and why. Because this workflow touches the ledger and a control framework, the handover includes what the system is not permitted to do, so that a later change cannot quietly remove the approval step without someone noticing.
What we would not automate
Posting a cleared invoice to the ledger without human approval
Clearing an exception releases a payment. Segregation of duties requires that the actor proposing the match is not the actor approving the disbursement, and a payment made in error costs far more to reverse than one held for a day. The approval stays with a person. This is a control boundary, not a phase-two feature waiting to be unlocked.
Reconciling exceptions that are genuine vendor billing errors
Some exceptions exist because the vendor billed wrongly and should be disputed. A system optimised to reconcile will make those disappear quietly, which means paying for errors and losing the record that would have supported a dispute. The correct output for that category is a flag to a human, not a resolution.
Vendor master-data cleanup as part of this build
Inconsistent vendor records are a real problem, but folding a data-cleansing project into a reconciliation sprint is how a four-week engagement becomes a stalled one. We would name the master-data issue in the diagnostic, scope it separately, and refuse to let it expand this workflow's boundary.
Illustrative targets
These are targets used to frame the engagement, not measured results from a delivered client project.
Illustrative target: Exception causes covered at first release: The lookup-resolvable causes only
The first release covers exception causes that are resolved by consulting a document rather than by making a judgement about who is right. Which causes those are is set from your quarter of history in week one. Judgement exceptions are routed to a person from day one and stay there.
Illustrative target: Days to clear a covered exception: Reduction vs a written baseline
The commitment is to a baseline agreed before the build and remeasured after with the same definition. We do not quote a target reduction before seeing the queue, because the movement depends on how much of the current cycle time is waiting and lookup rather than genuine decision-making.
Illustrative target: False-clear rate on the evaluation set: Primary safety metric; every release
A false clear is a proposal to release a payment that should have been held or disputed. It is the failure mode with financial consequences, so it is measured on the frozen historical set on every change and treated as a release gate, not a summary statistic.
Frequently asked questions
The invoice exception queue, not the whole three-way match. Invoices that already match clear on their own; the manual cost sits in exceptions, and those are already logged, timed and owned, which means you can baseline them. MIT's 2025 research found more than half of enterprise GenAI budget went to sales and marketing despite better returns being available in exactly these back-office functions. That is the argument for starting here.
The system proposes and a person approves; it never posts a payment itself. That preserves segregation of duties by design rather than by policy. On every release we measure the false-clear rate (the rate at which the system proposes releasing a payment that should have been held or disputed) against a frozen set of historical exceptions, and treat it as a gate.
They are routed to a person, not reconciled. A system built to make exceptions disappear will make real vendor billing errors disappear too, which means paying for them and losing the evidence for a dispute. The correct output for that category is a flag, and separating disputable exceptions from resolvable ones is part of the week-one classification.
It is a Workflow Sprint: four to six weeks, one workflow, built with three to five of your own finance and engineering people, who keep the code and the evaluation harness. The first two weeks are classification, shadowing and baselining; the build and harness follow; the last week is handover with the control model written down.
No. This is a methodology scenario, not a case study. Chokmah has not delivered this engagement for a named client, the workflow is a composite of how invoice reconciliation appears across shared-services centres, and every number on the page is an illustrative target agreed against a baseline, not a measured result.
Have a workflow like this?
We name the workflow before we start. Book a free AI Reality Check and build one live.