Almost every AI tool sold into accounts payable today is built for the easy majority of cases. The demo works, the pilot works, the tool ships and covers most of the volume. Then the remainder gets handed back to your team. And that remainder is where the real cost lives.
An out-of-the-box tool is trained on the average customer's documents, but your documents aren't the average customer's. Your quirks are exactly what the tool wasn't built for. The misses are the edge cases that will continue to fail in similar ways, and the cost of working those by hand scales up with your volume. Touchless invoice processing is what gets sold, but exception handling is what you actually end up staffing.
I've now seen this same disappointment enough times that it stopped feeling like bad luck and started looking like the business model. I'm a solutions architect at CoPlane, which means I work with one finance team, learn how their work actually happens, and help our engineers build AI workflows to automate exactly that. Many times, after an out-of-the-box solution failed.
Right now I'm working with a mid-sized services company that runs a large subcontractor network and processes their invoices at volume. They bought one of the well-known out-of-the-box invoice extraction tools. It does OCR on invoice PDFs and pulls the obvious fields: date, amount, vendor. It covers something like 80 to 90% of what they need.
But here's what the other 10% actually costs them.
What does out-of-the-box invoice automation actually miss?
It misses the invoices that don't look like everyone else's: nonstandard formats, edge cases in your billing model, anything the vendor's training data didn't cover.
When the extraction misses, a person goes through invoices line by line, meticulously correcting what the tool got wrong. It's excruciating, and it's the exact opposite of why they bought the tool.
The recourse is worse. You file a ticket with the vendor and hope they fix your specific edge case. Every time, you're gambling that your problem is common enough to make their roadmap. It usually isn't. Your 10% is what makes you not average, which is exactly why the vendor won't prioritize it.
And the extraction gap is only the first problem. Even when the numbers come out clean, the team I'm working with still has to deal with:
- Validation by hand. Extracted data gets checked against the system where subcontractor hours are logged. Today that means exporting to Excel and building pivot tables to compare apples to apples. Every invoice. The tool extracted the data, and a human still rebuilds a spreadsheet to confirm it.
- Forcing it into the GL. The connection between the extraction tool and the general ledger runs through esoteric behind-the-scenes plumbing that nobody on the finance team can see into or fix.
- Hot potato. Then there are the invoices that don't fit the model at all: edge cases in the subcontracting setup with no obvious owner. Someone says "I think Janice approved something like this once," forwards it to Janice, and hopes. The invoice gets passed around, the can gets kicked, and eventually it lands somewhere and flows into the GL. Nobody is confident it went to the right place. It just stopped moving.
Add it up: the tool automated the easy part and handed back the hard part in three pieces. Straight-through processing was the promise, and what they got was a faster way to start the manual work. The team absorbs the variance the software couldn't, and those hours never show up next to the accuracy rate that sold the tool. That's the economics of exceptions, and it's where finance headcount goes to die.
How do you actually automate the last 10% of invoice exceptions?
So we're building the future-state version of an extraction tool with them now. Three changes, mapped to the three problems.
- We wrote our own OCR, tailored to them. This sounds like overkill until you look at why it works now. LLMs are good enough that building extraction specific to one company's invoices is realistic, and once you're doing that, you can draw on their historical extractions over time. The model gets tuned on their actual documents instead of the industry average. The long tail shrinks instead of recurring, and there's a lot less manual intervention.
- We validate live against the source system. Instead of Excel exports and pivot tables, we work with the hours-tracking system's API directly, comparing extracted data live against the source. Same comparison the team was doing by hand, running automatically against the real record. That's the robustness this team needs, and it means they aren't meticulously double-checking along the way.
- Hot potato becomes a baton pass. My favorite part. Because we're drawing on history instead of discrete Excel files scattered across different places, the system can look at an invoice and say: this reviewer has handled invoices like this before, high likelihood they're the right approver, route it to them. Somebody is handing the work to a specific person for a reason. It feels less like a hot potato and more like a baton pass.
Then the voucher entries flow into the GL through an API. No esoteric plumbing.
None of this is a bigger model. It's the same LLM capability everyone else has, pointed at one team's actual work instead of the industry average. That's the whole difference.
What's the difference between out-of-the-box and custom invoice automation?
The difference comes down to three things: what the extraction is trained on, how validation happens, and how approvals get routed.
| Out-of-the-box | Custom | |
|---|---|---|
| Extraction | Trained on the industry average | Trained on your historical data |
| Validation | Manual export and pivot table | Live API check against the source |
| Approval routing | Ad hoc, no clear owner | Routed by approval history |
What does custom invoice extraction look like in practice?
It looks like an invoice going in one end and a GL-ready voucher coming out the other, with a human approving at two checkpoints and never opening a spreadsheet to do it.
Here's the workflow in action.
The walkthrough goes end to end: an example invoice PDF flows into the OCR extraction, and the system surfaces the total amount along with the voucher line items that will cascade into the GL, and asks for approval.
Approve and submit, and it moves to validation, which shows up in a table that looks like the pivot tables the team already uses. That's deliberate. A brand-new interface can feel intimidating, and the point is to be congruent with how people actually work today, not to make them learn a new way to check the same thing.
Approve that, and you get a preview in the same Excel format showing exactly how it will look when it opens in the GL.
No surprises at the end. You see what you're going to get before you commit to it.
How do you know if your AP automation has hit its ceiling?
The pattern isn't specific to one company, and it's not unique to accounts payable. If you bought a tool that covers most of your process and your team is quietly absorbing the rest, that gap won't close on its own. It's a gap between a tool built for everyone and a workflow that belongs to you.
It closes when the extraction is built on your data and the process is built around how your team already works. That's the job I do here.
If this resonates, we'd love to talk and dig into your setup. Book time with our team.