The cost of automating accounts payable is driven almost entirely by variety, not volume. Processing more invoices of the same shape through the same ERP with the same approval rule costs very little more than processing a few. Processing the same number of invoices arriving in a dozen formats, across two or three ERPs, with matching rules that differ by business unit and a long tail of exceptions that only one person in finance knows how to clear — that is where the money goes. When a vendor quotes you a per-invoice price, they are pricing the easy part and putting the hard part into an implementation line item you will not see until later.
Pricing for this kind of work generally breaks into three phases: a pilot that proves the capture and matching accuracy on your real documents, a build that covers integration, routing, exception handling and controls, and a run cost that covers hosting, model maintenance, monitoring and the human handling of whatever the system correctly refuses to decide. Pilot is small and fixed. Build is the largest single number and is driven by the factors below. Run is ongoing and should shrink as a share of spend over time — if it doesn't, something is wrong with the design. Below we walk through each driver so you can estimate where your own case sits before anyone quotes you anything.
Invoice volume sets the ceiling on savings, not the price of the build
Volume matters for one reason: it determines whether automation is worth doing at all. If your AP team handles a modest stream of invoices and nobody is working overtime, the build cost will not pay back within a sensible horizon no matter how elegant the solution. Volume is the denominator in your business case.
But volume barely moves the engineering effort. The work of teaching a system to read a supplier's invoice layout, map it to your chart of accounts and route it for approval is the same whether that supplier sends a handful of invoices a year or thousands. So when you scope, count distinct invoice patterns, not invoices. A company with high volume concentrated in a few large suppliers on structured formats is a cheap build. A company with lower volume spread across a long tail of small suppliers sending PDFs, scans and email bodies is an expensive one.
Format mix is the single biggest capture cost driver
Invoices arrive as EDI feeds, supplier portal downloads, clean machine-generated PDFs, scanned paper, photographs taken on a phone, spreadsheets attached to email, and text typed directly into the body of a message. Each of those is a different extraction problem with a different accuracy profile and a different amount of tuning.
- Structured feeds (EDI, supplier portals, e-invoicing standards) are close to free to consume. The cost is in the connection, not the reading.
- Machine-generated PDFs extract reliably with modern document models and need modest validation work.
- Scans and photos need image handling, quality checks and confidence thresholds, plus a review path for low-confidence fields.
- Line-item detail is dramatically harder than header detail. Pulling a vendor, date, invoice number and total is routine. Pulling accurate line items across multi-page invoices with continuation rows, discounts, freight and tax lines is a different order of work.
Whether you need line items at all is one of the highest-leverage scoping decisions you will make. If your matching rules only require header-level checks, say so early. This is the heart of document and data intelligence work, and it is where a pilot earns its keep: run your genuinely messy documents, not a curated sample, and you will know what the build costs before you commit to it.
Every ERP and every approval path is a separate build
Two ERPs is not twice the cost of one, but it is meaningfully more than one. Each system has its own master data, its own posting rules, its own validation quirks, its own API or lack of one, and its own set of people who understand it. If you are mid-way through a consolidation, the cost of building against both the old and new systems is real and should be weighed against simply waiting.
Approval routing is the same story. A single rule — route by cost center above a threshold — is trivial. What raises cost is the accumulation of exceptions to the rule: delegation during absence, dual approval for certain categories, business units with their own hierarchies, contracts that pre-approve spend, and the entity-level differences that come with acquisitions. Before asking for a quote, write down every routing rule in plain English. The length of that document is a better predictor of build cost than your invoice count. Designing and operating that routing layer is standard intelligent process automation work, but it has to be specified before it can be priced.
Matching rules are where scope quietly doubles
Non-PO invoices need coding and approval. PO-backed invoices need matching, and matching is where most AP automation projects overrun. Two-way matching against a purchase order is straightforward. Three-way matching that brings in goods receipt introduces timing problems: receipts posted late, partial deliveries, over-deliveries within tolerance, services with no physical receipt, and blanket POs drawn down over months.
Then come tolerances. Price variance, quantity variance, freight and tax handling, currency differences, and whether a variance is auto-accepted, auto-rejected or routed to a buyer — each is a decision someone has to make, document and own. If those decisions do not exist today because your team handles variances by judgment, the automation project has to create them. That is policy work, not engineering work, and it is frequently the longest pole in the tent. Budget for the time your own people will spend on it.
Exception rate decides whether the investment pays back
Automation does not eliminate handling; it concentrates it. Invoices that pass capture, coding, matching and approval cleanly cost nearly nothing to process. Everything else still lands on a person, and the cost of that person does not go away. So the economics of AP automation turn on what share of your invoices can go end-to-end untouched — and on how expensive each remaining touch is.
The trap is optimizing the wrong end. Pushing a capture model to squeeze out the last few uncertain fields is expensive and often not worth it. The better move is usually upstream: reduce the number of non-PO invoices, consolidate suppliers onto structured formats, fix the master data that causes coding failures, and tighten receipt discipline in the warehouse. Those changes cost operational effort rather than build budget and they lift automation rates across every future project you run.
A sound design also knows when to stop. Systems that guess on ambiguous invoices create downstream rework, duplicate payments and audit findings that cost far more than the handling they avoided. Confidence thresholds should be set so the system routes uncertainty to a human rather than resolving it, and that behavior should be visible and tunable.
Integration effort: the part buyers underestimate
Integration cost depends less on technical difficulty than on organizational reality. The questions that move the number are: does the ERP expose a supported API or will you be working through flat files and staging tables? Is there a test environment with realistic data, or will testing compete with production change windows? How many approvals does a new service account require, and how long do they take? Are there SSO, network and data residency requirements that add architecture rather than just configuration?
Security and access review is a legitimate line item, not overhead. AP touches payment data, bank details and vendor master records — the exact targets of invoice fraud. Controls around who can change a vendor bank account, how segregation of duties survives automation, and what the audit trail looks like need to be designed in, and they take time. Expect a competent partner to ask about your security and compliance requirements early, because retrofitting them is what turns a clean build into an expensive one.
What it costs to run
The run cost has four components, and you should ask for each to be broken out separately:
- Infrastructure and model usage — the compute and document-processing costs that scale roughly with volume. This is the part that genuinely behaves like a per-invoice price.
- Maintenance — supplier format changes, new entities, ERP upgrades, tax and regulatory changes, and drift in extraction accuracy. This is steady and predictable, and it does not go to zero.
- Monitoring and support — someone watching queue depth, failure rates and stuck items, with a defined response when something breaks at month end.
- Residual human handling — the exceptions the system correctly declines to decide. This belongs in your cost model even though it sits on your payroll rather than an invoice.
Beware of run models that charge purely per invoice with no maintenance commitment. They look cheap and they quietly stop improving.
How pilot, build and run fit together
| Phase | What it buys | What drives the cost |
|---|---|---|
| Pilot | Evidence on your real documents: what extracts cleanly, what matches, what becomes an exception | Number of document types and ERPs in scope; whether sample data can be provided quickly |
| Build | Working integration, routing, matching, exception queues, controls and audit trail | Format mix, ERP count, approval complexity, matching depth, security requirements |
| Run | Operating the system and keeping accuracy from degrading | Volume, rate of supplier and system change, support expectations |
A pilot should be small, fixed in price and short. Its job is to make the build quotable with confidence, and to give you a defensible reason to walk away. Any partner who wants to skip straight to a large fixed-price build on the basis of a discovery call is guessing, and you will pay for the guess through change orders.
When the answer is: don't automate this yet
We turn work down for these reasons regularly, and you should be suspicious of a firm that never does.
- An ERP migration is underway or imminent. Building against a system you are retiring is money spent twice. Wait, and design the AP process into the new implementation.
- Vendor master data is unreliable. Duplicates, stale bank details and inconsistent naming will break matching no matter how good the extraction is. Clean the master first; it is cheaper and it helps everything else.
- Nobody owns the rules. If there is no one who can decide tolerance thresholds and approval hierarchies and make them stick, the project will stall in design. Resolve ownership before spending build budget.
- The volume isn't there. If AP is handled comfortably by a small team with no backlog and no error problem, the payback horizon will be long. Automate something with more pain first.
- The real problem is upstream. If most invoices arrive without a PO, or receipts are posted late and inconsistently, AP is where the symptom shows up, not where the cause lives. Fixing procurement discipline will deliver more than automating the cleanup.
Getting a number you can take to finance
Before you ask for pricing, assemble four things: a breakdown of invoices by arrival format, a list of the ERPs and entities in scope, a written statement of your matching and tolerance rules, and an honest estimate of how much of today's handling is exception work rather than straight-through processing. With those, a serious partner can scope a pilot in a short conversation and a build shortly after. Without them, every quote you receive will be a range wide enough to be useless.
If you want to sanity-check the savings side before you talk to anyone, our value calculator lets you model the effect of different automation rates against your own handling costs. It will not tell you what a build costs — nothing can, without seeing your documents — but it will tell you quickly whether the payback is plausible enough to justify a pilot.
If you have the inputs above, or want help pulling them together, talk to us. We will tell you what your AP process is likely to cost to automate, where the risk sits, and whether we think you should do it yet.
Questions we get asked about this
Because a price without your document mix, ERP count and matching rules is meaningless, and any figure we published would be wrong for most readers. Two companies with identical invoice volumes can differ several-fold in build cost depending on format variety and approval complexity. What we can do is scope a short, fixed-price pilot that turns the question into a real number.
Part of it reasonably is. Infrastructure and document-processing costs scale with volume, so a per-invoice component makes sense for the run phase. But the build — integration, routing, matching, controls — is driven by complexity, not throughput, and a pure per-invoice model usually hides that cost somewhere else or skips the maintenance you'll need.
A pilot should be measured in weeks, not quarters. It should run your genuinely representative documents — including the messy ones — through capture and matching, and report what extracted cleanly, what matched, and what became an exception. The output is evidence that makes the build quotable and gives you grounds to stop if the numbers don't work.
It raises the build cost meaningfully, because each system brings its own master data, posting rules and integration path. It is not a blocker. But if you are actively consolidating onto a single ERP, building against the one you're retiring is usually wasted spend — in that case we'd advise waiting and designing AP into the target system.
Only if your matching or coding rules require it. Header-level extraction — vendor, invoice number, date, totals, tax — is considerably cheaper and more reliable than full line-item capture across multi-page invoices. Deciding this early is one of the largest single levers on cost, so check what your rules actually need rather than asking for everything.
Their work changes shape rather than disappearing. Routine coding and matching drops away and what remains is exception handling, vendor queries and judgment calls — work that needs experience. Most organizations redeploy capacity toward supplier management and controls rather than cutting headcount, and the residual handling cost should stay in your business case either way.
By designing it to refuse. Confidence thresholds route uncertain extractions and out-of-tolerance variances to a person instead of resolving them, and those thresholds are visible and tunable. Guessing on AP creates duplicate payments and audit findings that cost far more than the handling avoided, so we tune conservatively and loosen only with evidence.
Four: infrastructure and model usage that scales with volume, maintenance for supplier format changes and ERP upgrades, monitoring and support with a defined response when something breaks at period end, and the human effort still needed for exceptions. Ask any partner to break these out separately — a run price with no maintenance commitment tends to mean the system stops improving.
Bring us the process you were reading this for
Confidential assessment led by senior engineers. No obligation.