Ask a team whose invoice bot has been in production for a year what went wrong, and they rarely talk about the OCR. They talk about the supplier who changed their template in March, the purchase order that was closed before the invoice arrived, and the week the ERP was patched. Extraction is a solved enough problem. Everything around it is where the work is.
This article walks through the six failure points we see most often in accounts payable automation, and the design decision that closes each one. The examples assume a common stack: an IDP layer for capture, an RPA platform for the ERP work, and a human-in-the-loop queue for exceptions. The principles hold whichever products you use.
1. The document is not an invoice.
Shared mailboxes receive statements, reminders, credit notes, proforma invoices and marketing. A pipeline that assumes every attachment is an invoice will post a statement as a liability. Classification has to come before extraction, and it has to have an explicit unknown class.
Design for it: classify first, route by class, and send anything below a confidence threshold to a review queue with the original image attached. Log the class decision on every transaction item so the rejected cases can be audited later.
2. The field was read correctly and is still wrong.
IDP engines report confidence per field. A confidence of 0.97 on an invoice total means the characters were read well. It says nothing about whether the total equals the sum of line items plus tax, or whether the currency matches the supplier master. The dangerous errors are the confident ones.
Design for it: separate extraction confidence from business validation. Run arithmetic checks, master-data lookups and duplicate detection as a distinct step with its own pass or fail. Only a document that passes both goes to straight-through processing.
3. The purchase order does not match.
Three-way matching sounds binary. It is not. Quantities are partially received. Unit prices differ by rounding. The PO is in a different unit of measure from the invoice. A bot that treats every mismatch as a hard exception will push half the volume to humans and the programme will be judged a failure.
Design for it: define tolerance bands with finance before build, not after. Price variance within a percentage, quantity variance within a count, and a monetary cap per invoice. Inside tolerance, post and flag. Outside tolerance, route to the buyer with the specific variance named. Record which rule fired so tolerances can be tuned from data.
4. The ERP changed under the bot.
UI automation against an ERP is fragile by nature. A patch moves a field, a new mandatory attribute appears, a session timeout shortens. The bot does not know the screen changed. It knows a selector failed, which it reports as a system exception, which someone has to triage at two in the morning.
Design for it: prefer APIs or standard interfaces for posting wherever the ERP offers them, and keep UI automation for the steps that have no alternative. Where UI is unavoidable, use anchor-based selectors, add screen-state checks before every write, and wrap the posting step in a retry policy that distinguishes transient failures from structural ones. Agree a change-notification path with the ERP team so patches are tested against the bot before release.
5. The exception queue became the process.
Early in a programme, exceptions get attention. Six months in, the queue has 400 items, nobody owns it, and the suppliers whose invoices are stuck are phoning the CFO. The automation is technically running. The outcome has quietly reverted to manual.
Design for it: treat the exception queue as a product with an owner, an SLA and a dashboard. Classify exceptions by root cause, not by symptom. Review the top causes fortnightly and fix them at source: a supplier template added to the model, a tolerance adjusted, a master-data record corrected. The goal is that the queue shrinks over time, and that trend is reported to the sponsor.
6. Nobody can explain what the bot did.
Auditors ask a simple question: who approved this payment and on what evidence? If the answer is a log file on a bot machine, the conversation will not go well. Automation raises the bar on evidence rather than lowering it.
Design for it: store the source document, the extracted values, the validation results, the matching decision and the posting response together, keyed by transaction, in a system the audit team can query. Maker-checker remains in place for anything above a threshold, and the checker sees the bot's evidence, not just its conclusion.
What a well-run pipeline looks like.
- Classification with an explicit unknown class, before any extraction.
- Per-field confidence thresholds that route to review rather than fail the document.
- Business validation as a separate, logged step with its own rules.
- Matching tolerances agreed with finance and tuned from data.
- API-first posting, with UI automation only where there is no alternative.
- An owned exception queue with root-cause classification and a shrinking trend.
- Transaction-level evidence that an auditor can query without asking engineering.
Extraction accuracy is table stakes. The quality of an invoice automation is decided by how it behaves when the document, the data or the system is not what it expected.
If you are planning an accounts payable automation, or trying to recover one that has stalled, the six points above make a useful checklist for a design review. We are happy to walk through them against your process.