The reconciliation is not the work; the exceptions are
A finance team closes its month by matching supplier invoices to purchase orders and delivery notes. Three systems hold those three records, and none of them agrees on identifiers, on which quantity is authoritative, or on what tolerance means. The matching is done by a person who opens several screens and reads. Nothing fails dramatically. The close simply takes longer than it should, and takes the same extra time every month.
The cost people discuss is the extra days. The cost that matters is everything behind that number: the invoice matched only because somebody remembered a credit note from August, the price variance accepted because arguing would have taken longer, the payment term conceded to a supplier without anyone deciding to concede it. Those outcomes are defensible individually and invisible in aggregate, because each one lands in a different account.
Four cost lines that never appear on the same page
- Rework. Time spent finding the missing document, re-reading the email thread, re-entering the correction and re-approving it. This is the largest line and the least visible, because the corrected version is what appears in the ledger.
- Duplicate entry. The same invoice, claim or credit recorded twice under slightly different keys. It reads as a volume problem and is actually an identifier problem.
- Approval delay. Time a transaction spends waiting for a signature from someone who returns from leave on Monday. It is booked as elapsed time and experienced as somebody else's delay.
- Unpriced exception. Disputed quantities, undocumented credits, and short-delivery claims that a person absorbs to keep the supplier relationship intact. The relationship is real; the cost of it is not recorded anywhere.
Duplicate entry is an identity problem, not an accounting one
When the same supplier invoice is booked twice, the instinct is to tighten the review. That treats the symptom. The cause is usually that two systems describe the same transaction with different keys — one keyed on the invoice number as printed, one on an internally generated posting reference — and no rule states which one is authoritative for the purpose of detecting the second entry.
The same pattern explains matching failures, credit notes that never offset an invoice, and delivery notes that cannot be tied to the purchase order they belong to. This is not a finance problem at all; it is an identifier and definition problem that finance is absorbing. The engineering treatment of it is set out in business ontology explained.
Approval delay is a design decision about authority
Most approval policies are written as thresholds and read as if they were thresholds. In practice they encode an assumption about who is available. A limit set for a named manager produces a queue whenever that manager is travelling, and the queue is then worked around rather than escalated, so the control becomes nominal.
The fix is unglamorous. Publish a delegation rule, set a time limit after which the request escalates rather than waits, and record which approver actually decided. A transaction that times out silently is worse than one that is refused, because the business has no record that anybody looked. The mechanics of that pattern, and where human approval must sit in a workflow, are covered in designing AI workflows with approval and exception handling.
Four exception types account for most of the effort
| Exception | What decides it | Who should own it |
|---|---|---|
| Quantity or price disagreement | Contract terms against the received line | Category buyer, with finance supplying the evidence |
| Missing or duplicate document | An identifier rule stated once | Accounts payable, as a process owner |
| Credit requested after payment | Contractual grounds and the supplier's position | Credit control |
| Unbudgeted or unusual settlement | A named threshold with a stated exception route | Finance business partner |
Naming these separately matters because each has a different remedy and a different person who can apply it. A consolidated exception queue treats them as one queue, and the result is that the quick items are cleared alongside the contested ones so that the volume looks healthy.
Priority assigned from volume will always be wrong
Exception queues are commonly ordered by arrival or by value, and both orderings are poor guides. A large routine adjustment delayed for a week is cheaper than a small disputed invoice that sits unpaid because nobody has chased the supplier, and neither of them matters as much as the transaction that will fail an audit. Priority should come from consequence and age, not from size, and the rule should be written down rather than held by whoever is most senior that week.
Where automation must stop
Reading an invoice, matching it against an order, extracting the discrepancy and presenting the evidence is exactly the kind of unstructured work worth delegating, and it is where most of the rework lives.
What must not be delegated is the decision. Whether a variance is accepted, whether a credit is written off, whether a settlement is approved outside policy, and whether evidence is sufficient for the audit file are judgements with a named owner and a signature attached. The line to hold is between reading what the documents say and deciding what the business will stand behind. Automating the second without the first in place produces a faster route to an unaccountable decision.
What to do in the first ninety days
- Pick one process with high volume and low value per item — expense claims, invoice approval or delivery-note matching — and count how many items currently require intervention.
- Classify each intervention by cause: missing identifier, missing document, disputed value, or absent approver. The distribution decides where the work belongs.
- Write down which system is authoritative for each field involved, and which key identifies the same transaction across systems.
- State the priority rule for the exception queue, including how age and consequence outweigh value, and name the owner of each exception type.
- Record the baseline — items needing intervention, days to close, and hours spent on exceptions — before changing anything.
- Agree the review date and the stopping condition before the build starts, not after it.
The measures that survive scrutiny are unglamorous and already collectable: the share of transactions cleared without manual intervention, the number of days to close an exception, the age of the oldest open item, and the hours spent per thousand transactions. A figure nobody can check is not worth reporting. The engineering work behind holding those records together across systems is described in enterprise agent engineering, and the sibling problem in the same collection is procurement coordination.