Accounts payable has had electronic invoicing standards for decades, and most finance teams still work a large share of their invoices by hand. Ardent Partners, which has benchmarked the function for two decades in its State of ePayables research, keeps reporting the same gap: its leaders clear an invoice in roughly 3.1 days against 17.4 for everyone else, and almost all of that difference is manual handling. The technology to close the gap has existed for a long time, yet the manual work around it persists, and that distance between an available standard and a hand-worked process is where accounts payable automation either pays or quietly fails to.
The AP team grows, and the cost per invoice refuses to fall
An accounts payable operation scales in a way that looks unremarkable from the outside. Invoice volume climbs as the business grows, and the team climbs with it, another clerk added each time the backlog gets uncomfortable. The headcount rising with volume reads as normal, and finance leaders rarely question it, because processing invoices has always taken people. Underneath, the cost of getting a single invoice from inbox to payment is not falling the way it should as the operation grows, because most of the work between those two points is still being done by people moving data between systems that were never designed to hand off to each other. At Digital Forms we call the point where that catches up with a function the Manual Wall: the growth ceiling an operation reaches when it keeps adding headcount to absorb volume that software should be carrying.
The AP version of the wall is easy to recognise once you look for it. An invoice arrives as a PDF attached to an email, and someone reads it, keys the header and line data into the ERP, assigns the general-ledger codes, matches it against the purchase order and the receiving record, routes it to the right approver, chases that approver when it stalls, and resolves whatever does not reconcile. Each of those is a handoff, and the Human API problem is the name for what fills the space between them: the clerks who spend their days as the connective tissue between the invoice, the ERP, the purchasing records, and the approvers’ inboxes. The judgement in AP is small and occasional. The manual movement of data around it is constant.
Why this bites harder now
Two pressures have made the manual layer more expensive than it used to be. The first is simple cost scrutiny. Finance is under pressure to run leaner, and an AP function whose cost scales in a straight line with invoice volume is the kind of line a CFO is now expected to bend, because every invoice handled by hand is a fixed cost dressed up as a variable one. The spread between teams is wide: APQC’s benchmarking puts the cost of processing a single invoice at around two dollars for the top quartile of finance teams and above ten for the bottom quartile, and most of that gap is automation. When the business doubles its purchasing, the AP team should not have to double with it.
The second is that the rails to avoid all this already exist and mostly go unused. The Business Payments Coalition, working with the Federal Reserve, built a US e-invoice exchange framework that reached market-ready status in 2023, letting invoices flow between systems as structured data rather than PDFs, and adoption remains partial while most invoices still arrive as email attachments and scans. The standard being available and the work being automated are not the same thing, and the distance between them is the cost a finance team is quietly paying to bridge by hand. That gap also carries risk beyond cost, because manual invoice handling is where duplicate payments and fraud find room to hide, and the AFP Payments Fraud and Control Survey has for years found checks to be the payment type most exposed, with more than three-quarters of organisations reporting attempted or actual fraud.
What is accounts payable automation, really?
The phrase usually gets heard as a product category, a question of which AP-automation platform to buy and bolt onto the ERP. That framing is where a lot of the disappointment starts, because the platform is rarely the thing that was missing. Most finance functions of any size already run an ERP with an AP module. Accounts payable automation, in the sense that actually moves the cost line, is the automation of the manual work that persists around those systems: the capture of the invoice, the coding and matching, and the resolution of the exceptions that the standard flow throws off.
It helps to separate two things that get blurred together. The ERP holds the ledger and issues the payment once an approved, coded, matched invoice is in it. The AP module manages the workflow for invoices that behave. Neither of them reads a PDF that arrived by email, decides which cost centre a services invoice belongs to, or works out why a three-way match failed on a partial delivery. That work sits in the gap between the inbox and the ledger, and a person does it because nothing was ever built to. The platform is doing its job in each case, and the hours are piling up in the space it was never designed to cover.
What to automate first in accounts payable
The mistake finance teams make when they finally attack the manual layer is to try to automate the whole process at once, which is slow, expensive, and rarely lands. The cost is not spread evenly across the invoice lifecycle. It concentrates at the front, in capture and matching, the steps every invoice passes through regardless of its value, which is why invoice capture is almost always where automation pays first.
Automating capture means turning the emailed PDF into structured, coded data the moment it arrives, so a clerk opens a prepared invoice rather than a blank ERP screen and an attachment. Paired with automated two-way and three-way matching against the purchase order and receipt, it removes the highest-volume manual touch in the function and does it on every invoice, including the majority that are low-value and never needed a human in the first place. The same structural pattern shows up across every back-office we work in, which is why the diagnosis here mirrors what we describe for claims processing, where the highest-value first step is almost always the intake of the case rather than the decision at the end.
The next concentration, once capture and matching are handled, is exception resolution, the invoices that do not match cleanly and currently pull an experienced clerk into an investigation. Routing exceptions intelligently and giving the resolver the context in one place, rather than across four systems, is usually the step that follows capture in the sequence. The reason to sequence this way is that the first automated step has to earn the next one: an operation that starts with capture sees cost per invoice fall before the appetite for the project runs out, and that early result funds the rest rather than a budget request that competes with everything else finance needs.
What your ERP was never going to do
It is worth being direct about the limit of the software, because the gap is predictable. An ERP is built to hold the ledger and pay approved invoices, and an AP module is built to route invoices that follow the rules. Neither is built to know that a particular vendor always bills for services on a PO meant for goods, or that one business unit sends its invoices to a personal inbox instead of the AP address, or that a recurring charge was approved once with a handling note only a senior clerk remembers. That knowledge lives in experienced people because the workarounds were never built into a system, which is exactly why a function cannot simply hire cheaper staff to carry the same volume.
That is the real constraint behind the Manual Wall in accounts payable. The operation is not short of an ERP, and it is not short of capable clerks. It is short of the automation that would let those clerks stop spending their time on capture and matching and spend it on the genuine exceptions and the vendor relationships that need a person. Adding clerks buys more of the same manual capacity at a rising cost per invoice, which is the opposite of what a finance team trying to run leaner actually needs.
What this looks like inside a mid-market finance team
Picture the shape without a name attached. A mid-market company runs its accounts payable through a capable ERP and a shared-services team, and the invoice numbers look fine at the summary level. What does not show at the summary level is that most of the team’s week goes to capture, coding, matching, and chasing approvals, before any judgement is applied, and that the backlog spikes hard at month-end when everything has to close. During a growth push that work multiplies, the team covers it with overtime and temps, and the finance leader adds another permanent clerk because the backlog is real and the hire is the visible lever.
The upside becomes real the moment someone counts the hours going into the repetitive front end of the invoice and prices what recovering them is worth. In operations of this scale the recoverable figure is routinely large enough to matter to the finance budget within the first year, not because of a heroic transformation but because the capture and matching work was never automated in the first place. That is the operational lever in concrete terms, and it is available in most AP functions precisely because manual processing has been treated as simply what the function costs.
How to find the manual work worth automating
The starting point is measurement, not a software decision. Before committing to any build, a finance team needs to know where its handling cost and its month-end risk actually concentrate, which invoice types consume the most clerk time and which steps put the close at risk when volume spikes. Surfacing that is what we built our Profit Leak Diagnostic to do, because operators consistently underestimate how much cost is trapped in steps they have stopped noticing, and the same discipline is what we describe in how to run an operational efficiency assessment that finds the money rather than measuring how busy people look.
From there the discipline is to build narrow and prove it fast, so the first result funds the next rather than a budget request competing with everything else. The initial move we make is usually an Operations Sprint that automates a single high-volume step, most often invoice capture and matching, and puts a working result live in weeks. It is the same approach we use to help finance and operations teams scale without adding headcount: replace the assumption that manual processing is simply what AP costs with a number the team can act on.
The question worth asking at the next AP hire
The next time an accounts payable function reaches for another clerk to keep up with invoice volume, the useful thing to examine is not whether the person is needed to clear the current backlog, because they almost certainly are. It is whether the backlog exists because purchasing genuinely grew or because the same capture and matching is being done by hand on every invoice that comes through the door. One of those is a reason to hire, and the other is a reason to automate, and a finance team that has never separated the two is paying clerk wages for work that stopped needing a person years ago.
