Clearing a 40,000-invoice AP backlog with local models: a worked example
TL;DR
Extraction is the small part: 64,000 backlog pages is about 53 GPU-hours on one A100-class card, roughly €96 of on-demand rental. Triage, rules, exceptions and the ERP load are the four weeks.
Dedupe twice (file hash, then vendor + invoice number + gross), parse e-invoices instead of extracting them, and run the largest format families first.
Validation rules catch what the model misses: VAT arithmetic, the IBAN mod-97 checksum against the vendor master, PO match, duplicates and date order — each returning a reason code.
With a 10% human-touch assumption, the backlog puts 4,000 invoices in the exception queue — about 200 hours, or two people for two and a half weeks. That cost exists on every route.
In the scenario, month one costs about €773 on GPT-4.1 with retries (inference only), €4,999 on Ækora’s Scale plan (pipeline included) or €600 on a reserved EU GPU (pipeline not included); steady state is €101, €999 and €600.
Questions people ask
How long does it take to clear a 40,000-invoice backlog with AI?
In the illustrative scenario, about four weeks: one week of triage, schema and a labeled sample; one week for a 200-invoice pilot and validation rules; one week of bulk extraction with a staffed exception queue; one week to finish, switch new invoices to the daily flow and hand over. The compute itself is about 53 GPU-hours on a single A100-class card.
What does it cost to clear an invoice backlog with AI?
Using list prices and the scenario’s 73,600 pages in month one: about €773 on GPT-4.1 with a 1.5× retry multiplier (inference only), €4,999 on Ækora’s Scale plan (schema, validation, exceptions and delivery included), or €600 for a reserved EU GPU without the pipeline. Exception labor — about 200 hours at a 10% human-touch rate — is the same on every route.
Which validation rules should an AP extraction pipeline have?
VAT arithmetic (net × rate = VAT, net + VAT = gross, line items sum to net), the IBAN mod-97 checksum plus a match against the vendor master, PO existence and amount tolerance, a duplicate check on vendor + invoice number + gross, and date sanity. Each rule returns pass or a reason code that routes the invoice to the right person.
Do e-invoices need AI extraction?
No. Structured e-invoices — XRechnung, ZUGFeRD, Factur-X, Peppol BIS — carry every field in XML, so they should be parsed and sent straight to validation. Extraction with a document model is for PDFs, scans and photos. Splitting the two during triage removes work and avoids scoring e-invoices as if they were scans.
Can supplier invoices be sent to OpenAI under GDPR?
Supplier invoices contain personal data — sole traders’ names, contact persons, bank details — so sending them to a US API is a transfer under GDPR Chapter V that needs a legal basis and a processor agreement. Local models running in the EU or on your own hardware avoid the transfer; a hybrid design can still route a small share of hard pages to a frontier API under a documented basis.
How do you keep an invoice backlog from coming back?
Switch new invoices to a daily pipeline before the backlog is finished, monitor volume, straight-through rate per family and exception age, give the queue an owner and a two-business-day clock, review reason codes monthly and turn them into rules, and re-score a fresh 100-invoice labeled sample each quarter to catch accuracy drift.
Want this worked out on your documents?
We will price a real sample against OpenAI or Anthropic and tell you whether Bulk document processing or a local model on your hardware is the cheaper first step.
A backlog of 40,000 unprocessed supplier invoices — about 64,000 pages — can be extracted, validated and loaded into the ERP in roughly four weeks with local models, and the extraction is the small part. On a single A100-class GPU at about 1,200 pages an hour, 64,000 pages is about 53 GPU-hours: two and a half days of compute, or about €96 of on-demand rental. What takes four weeks is the triage, the schema, the validation rules, the exception queue and the ERP load. This article walks one illustrative scenario end to end and prices three routes — a frontier API, a managed pipeline on Ækora’s published plans, and a DIY GPU — from the same assumptions.
Week 1: triage before extraction
Do not point a model at the pile. Backlogs are full of files that should never be extracted, and every one you remove now is one you neither pay for nor double-book.
Dedupe twice. First on the file hash, which catches the same PDF forwarded three times. Then on vendor plus invoice number plus gross amount, which catches the reminder copy a supplier sent when the first one went unpaid — the normal way a backlog grows duplicates.
Split out what needs no extraction. Structured e-invoices — XRechnung, ZUGFeRD, Peppol BIS, Factur-X — carry every field in XML already. Parse them and send them straight to validation. Extraction is for PDFs and scans.
Group the rest by format family. PDF-native invoices from the top vendors, scanned or photographed invoices, foreign-language and multi-currency invoices, multi-page invoices with long line-item tables. Sort the families by count and run the biggest ones first; a handful of vendors usually account for most of the volume, and each family gets its own accuracy number.
Pull the pilot sample. 200 invoices, in proportion to the families, keyed by your AP clerks as ground truth. Nobody on the pipeline side sees the ground truth until scoring.
The schema
The schema is the contract between the pipeline and the ERP, so write it before the pilot and freeze it for the run. For supplier invoices it looks like this:
Header: vendor name, vendor VAT ID, invoice number, invoice date, due date, currency, net amount, VAT rate or rates, VAT amount, gross amount, IBAN, purchase-order number, payment terms.
Line items: description, quantity, unit price, line net, line VAT rate — one row per line, keyed to the header.
Normalization: dates in ISO 8601, amounts as integers in cents, IBAN uppercase without spaces, VAT ID with country prefix, currency as ISO 4217. “Correct” means correct after normalization; 1.234,56 and 1234.56 are the same value.
Pipeline fields: per-field confidence, source file reference, format family, and a status of auto-approved, reviewed or rejected.
The 200-invoice pilot
Run the 200 invoices through the candidate model and score them against the ground truth, per field and per family: precision (of the values emitted, how many were right), recall (of the values on the page, how many were found), the straight-through rate (invoices that passed every rule with no edit) and the human-touch rate. The scoring method is in our buyer’s guide to document processing with local models. Expect the misses to cluster: line items that continue onto a second page, VAT amounts on mixed-rate invoices, IBANs on stamped or low-resolution scans. Those clusters tell you which validation rules matter most and where a second model or a human should sit. The pilot also gives you the number the business case needs: the human-touch rate, which sets the size of the exception queue.
Validation rules that catch what the model misses
A model reads; rules check. The rules are cheap, deterministic and catch most single-digit misreads, because a wrong digit almost always breaks arithmetic somewhere.
VAT arithmetic. Net × rate equals VAT within €0.02; net plus VAT equals gross; line nets sum to the header net. A misread “8” for “3” in the net fails all three at once.
IBAN checksum. Every IBAN carries a mod-97 check (ISO 13616); a misread character fails it. Then compare against the vendor master. A valid IBAN that does not match the vendor on file is not an extraction error, it is a fraud flag, and it goes to a person every time.
PO match. The purchase order exists, belongs to the same vendor, and the amount is within tolerance. No PO is not a failure; it is a route to the approver.
Duplicate and date checks. Vendor plus invoice number plus gross already booked in the ERP; invoice date not in the future; due date not before invoice date.
Each rule returns pass or a reason code. All pass: the invoice is auto-approved. Any fail: it goes to the exception queue with the reason attached, so the person opening it already knows what to look at.
The exception queue is the real project
With the 10% assumption, 4,000 of the 40,000 backlog invoices need a human. At 3 minutes each, that is 200 hours — two people for about two and a half weeks, working in parallel with the bulk run. In steady state it is 600 invoices and 30 hours a month. This work exists on every route, API or local, and it is the line most business cases leave out.
Three things shrink it. Route by reason code, so IBAN mismatches go to the person who can call the vendor and PO mismatches go to the buyer. Give low-confidence pages a second opinion before a human — a frontier API on the hard 5% is the hybrid pattern we describe in the hybrid local-plus-frontier stack, and it keeps the routine 95% on the local model. And review the reason codes weekly: every category that recurs becomes a new rule or a layout fix, which is how the queue gets smaller month by month instead of staying at 10%.
Delivery to the ERP
Two CSV files — headers and line items, keyed by invoice ID — or one JSON document per invoice pushed to the ERP’s API. Every record carries its status, its per-field confidence and the source file reference, so an auditor can walk from a booking back to the page. Load the first batch into the test company, reconcile the counts (invoices in equals auto-approved plus reviewed plus rejected), then load production family by family. Nothing about this step is clever; skipping it is how a clean extraction becomes a messy ledger.
The four-week timeline
Illustrative four-week plan for the scenario above (64,000 backlog pages plus 9,600 new pages in month one). Compute is not the constraint; people and rules are.
Week
Pipeline work
People work
Output by Friday
Week 1
Dedupe, split e-invoices, group by family, freeze schema
AP keys ground truth for 200 invoices; ERP team agrees CSV/API format
Clean inventory by family; schema v1; labeled sample
Week 2
Run and score the 200-invoice pilot; write validation rules; set confidence threshold
Review pilot misses; define reason codes and who works each
Field-level scores per family; go/no-go; exception queue staffed
Week 3
Bulk run, largest families first (about 53 GPU-hours total); first CSV batches to ERP test, then production
Two people on the exception queue; daily straight-through rate reported
Most of the backlog booked; queue draining
Week 4
Remaining families; new invoices switched to the daily flow; monitoring live
Queue cleared; reason-code review; handover to AP
Backlog at zero; run rate on the daily pipeline
Illustrative four-week plan for the scenario above (64,000 backlog pages plus 9,600 new pages in month one). Compute is not the constraint; people and rules are.
What the three routes cost
Same scenario, three ways to run it. The API row uses GPT-4.1 at list price with a 1.5× multiplier for retries and second passes. The Ækora rows use our published plans: Pilot at €999 a month for 10,000 pages with €0.15 per extra page, Scale at €4,999 for 75,000 pages with €0.09 per extra page. The DIY rows are the shared local-compute figures.
Illustrative scenario, assumptions in the note above. Month one is the backlog plus one month of new invoices (73,600 pages); steady state is 9,600 pages a month. API rows are inference only. GPU rows exclude the engineers who build the schema, rules, queue and ERP delivery. Ækora rows are published plan prices and include those. Exception labor (about 200 hours in month one) is the same on every route and is not in the table.
Same pipeline; 63,600 overage pages at €0.15 in month 1
DIY on-demand EU GPU, compute only
€110
€14
GPU hours at €1.80; nothing else
DIY reserved EU GPU
€600
€600
Card, power, slice of ops; no pipeline engineering
Illustrative scenario, assumptions in the note above. Month one is the backlog plus one month of new invoices (73,600 pages); steady state is 9,600 pages a month. API rows are inference only. GPU rows exclude the engineers who build the schema, rules, queue and ERP delivery. Ækora rows are published plan prices and include those. Exception labor (about 200 hours in month one) is the same on every route and is not in the table.
Read it plainly. On inference, the API is cheap and the on-demand GPU is cheaper. The money in this project is not inference; it is the pipeline and the 200 hours of exceptions. A fixed plan buys the pipeline. A GPU line buys capacity you must build around. The API buys neither, and at 9,600 pages a month it never reaches the crossover where local compute wins on price alone — which we work through in fixed cost versus per-token at 100,000 invoice pages. What the API route does not buy is residency: supplier invoices carry personal data — sole traders’ names, contact persons, bank details — so a US API is a transfer under GDPR, and the questions in GDPR-compliant document AI apply before the cost table does. If the team is already paying per invoice on an API, the arithmetic in stop paying OpenAI per invoice is the same arithmetic with your numbers in it.
What “kept at zero” requires afterwards
The backlog came from somewhere: invoices arriving faster than people could key them. Clearing it once changes nothing unless the daily flow changes too. Four things keep the count at zero.
Ongoing routing. Daily ingestion from the AP mailbox, SFTP or the e-invoicing network; e-invoices bypass extraction; invoices from a vendor never seen before are flagged as a new family rather than silently scored badly.
Monitoring. Volume in and out, straight-through rate per family, exception age, and an alert when a family’s straight-through rate drops — a supplier changing its template is the usual cause.
An owner and a clock. One person owns the queue; exceptions are cleared within two business days; reason codes are reviewed monthly and turned into rules.
A quarterly re-score. A fresh 100-invoice labeled sample each quarter, so accuracy drift is measured rather than discovered in the ledger.
One capacity note. At 9,600 pages a month the extraction is about 8 GPU-hours; a reserved card would sit idle almost all the time. That is why, at this run rate, a per-page plan or a right-sized deployment beats a dedicated GPU — what a right-sized stack looks like is on our local document models page.
How to run it
Count pages, not invoices, and separate the backlog from the monthly run rate.
Dedupe, split out e-invoices, and group by family. Sort families by count.
Freeze the schema with normalization rules, and have AP key 200 invoices of ground truth.
Run the pilot and score per field and per family. Record the human-touch rate; that is your queue size.
Write the rules — VAT arithmetic, IBAN checksum, PO match, duplicates, dates — with reason codes and owners.
Bulk-run the largest families first, with the exception queue staffed from day one of the run.
Load to the ERP test company, reconcile counts, then production, family by family.
Switch the daily flow on before the backlog is finished, with monitoring and an owner, so the pile does not start again.
If you have a pile like this, three numbers decide the plan: pages in the backlog, pages a month from now on, and the human-touch rate on a labeled sample of 200. With those, we can tell you in one call whether it is a month of Scale and then Pilot on bulk document processing, or a deployment on your own hardware — and how many people the exception queue will need in week three.