The exception queue
Three-way matching compares invoice, purchase order and goods receipt. When they agree, it posts automatically. When they do not, it becomes an exception someone investigates.
In most finance teams that queue is the bottleneck, and a large share of it is the same few situations: a partial delivery, a price difference of pennies, a rounding mismatch, freight added on the invoice but not the order.
Rules first, honestly
Before building anything predictive, count your exception reasons. Businesses are routinely surprised to find that a handful of causes account for most of the volume, and that tolerance rules would clear them.
- Value tolerance, absolute and percentage, so a penny difference does not stop an invoice
- Quantity tolerance where partial delivery is normal for that supplier
- Known freight and handling patterns by supplier
- Currency rounding on foreign invoices
- Timing differences where receipt is booked after invoice arrival
This is unglamorous and frequently removes most of the queue. Applying machine learning to a problem that tolerance rules would solve is a common and expensive mistake.
Where prediction earns its place
On what remains, two predictions help: what is the likely cause of this exception, and how has this kind been resolved before.
| Prediction | Use |
|---|---|
| Likely cause | Route to the right person with context |
| Likely resolution | Pre-fill the action for confirmation |
| Probability of approval as-is | Auto-clear the safest cases within limits |
| Expected resolution time | Manage supplier payment expectations |
The second row is where most of the time is saved. Presenting the resolution applied to similar exceptions turns an investigation into a confirmation.
Duplicate invoices
A related and valuable application. Duplicates arrive through resubmission, a supplier changing their reference format, or the same invoice reaching two mailboxes.
Exact matching misses most of them because a reference or date differs. Fuzzy matching across supplier, amount, date proximity and line detail catches considerably more. Given that a duplicate payment is real money out of the door, this often justifies the project on its own.
Keep the controls intact
Purchase-to-pay is a financial control, and auto-clearing exceptions weakens it if done carelessly. Any automation needs value limits, an audit trail of what was cleared and why, and sampling of automatically cleared items.
The sensible design auto-clears only low-value, high-confidence cases within a documented tolerance, and leaves everything else with a human. That preserves the control while removing the bulk of the tedium.
Count your exception reasons before building anything. Most of the queue is usually four or five situations.