Invoice capture where the model proposes and a person confirms
Photograph a supplier invoice, a vision model reads the line items, validation catches the malformed ones, and only a person's confirmation writes to the books.
Getting a model to read a supplier invoice is quick to demonstrate. Getting a finance team to let it near the ledger takes a good deal longer, and the difference is nearly all in the engineering around the model rather than in the model.
The decision that makes it acceptable is that the model never writes. On the system we built for a trading business, photographing an invoice produces a proposed set of line items on screen and nothing has happened yet. Stock quantities, item cost prices and the supplier balance move only when a person confirms, and it is the confirmation, not the extraction, that creates the purchase invoice. A data-entry job becomes a review job.
To be exact about the evidence: that capture pipeline was built as part of one client's ERP, writing into that ERP. We have not built a standalone invoice product, and no published case study covers an integration with a named accounting package. The pipeline itself is independent of where the confirmed data lands, which is what the later sections are about.
Five steps between the photograph and the ledger
The trading ERP shipped capture by camera, confirmation by a person, the approval states, key rotation with provider failover and the audit log. The validation checks, the side-by-side image and the image storage practice below are what we build and set out in our AI document extraction article, not features claimed for that case study.
- 01
Capture
A supplier invoice is photographed and a vision model reads the line items. The scanner on the trading build runs across multiple API keys per provider and can fall through to a second provider, which is covered below.
- 02
Validate before a person sees it
What we build in front of the review screen: the output is parsed against an explicit schema, and a response that does not conform is a retry, not a result. Line items are checked against the stated total, and where they do not sum the whole document is flagged, because the model may have misread the total rather than a line. A supplier name that nearly matches an existing supplier offers the match instead of creating a duplicate. Showing a malformed extraction to a reviewer spends human attention on a machine fault.
- 03
Review against the original
We keep the source image beside the extraction so a doubtful field can be checked on the same screen. Handwriting and poor scans can sometimes be read, and both are the hardest inputs, so test them on your own documents before relying on it. This step and the arithmetic check are what they are for.
- 04
Confirm, and only then write
On the trading ERP, a person's confirmation creates the purchase invoice and moves stock quantities, item cost prices and the supplier balance. Invoices then move through draft, pending review and approved, and drafts and those under review are excluded from revenue, purchases and outstanding totals until approved.
- 05
Record who confirmed what
On the trading ERP every write goes through one data-access layer that stamps the acting user and appends a field-level diff to an append-only table, so a confirmed extraction can be traced to the person who confirmed it. We treat the source images as business records too, kept in private storage with access policies and attached to the document they produced.
Where AI invoice capture fails in practice
The provider stops in your busiest hour
Rate limits, quota exhaustion and transient outages are ordinary operating conditions. The scanner holds several keys per provider, advances to the next on any rate limit, quota or auth failure, then falls to the second provider before giving up. The trading build uses Claude and OpenAI. Rate limits are often applied per organisation or project rather than per key, so extra keys in one account may not add capacity; check how your provider scopes them.
Not configured looks like nothing found
A pipeline with no keys set can return an empty result that looks identical to a model that found nothing. With no keys configured it says so plainly instead of failing silently, because the first is an alert and the second is a missing supplier balance at month end.
A near-miss becomes a duplicate supplier
Extraction that creates a new supplier for every slightly different spelling fills the ledger with duplicates faster than anyone clears them. The design we recommend, set out in our extraction article rather than claimed for the trading ERP, is to cross-reference against suppliers you already hold and offer the match, which keeps the duplicate out of the review screen.
The model is trusted before it is measured
A prompt change or a model upgrade is a guess without a small evaluation set of real documents, including the bad ones, with known-correct answers. With one it takes minutes to measure. We treat the model as a swappable component for the same reason.
Most of the time goes on review, validation, failover and the audit trail
A working extraction prototype comes together quickly. A version a finance team will run its books on takes longer, and most of that goes on the review screen, validation, failover and the audit trail rather than on prompting. We would scope it against your own documents instead of quoting a duration here.
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, and the trading ERP case study states neither a price nor a duration, so we do not attribute the range to it. The three variables from the cost article apply directly:
- Exceptions: the invoice that arrives as a photograph of a fax, the supplier spelled two ways, the credit note. Each needs a decision to automate, route to a person or refuse loudly.
- Systems that must agree: capture feeding one system of record is close to linear. Capture feeding a ledger and a stock sheet that both get edited by hand is a reconciliation.
- Rules that need a database: an approval step that must hold however the data was written, and a log that outlives the platform run history.
Running cost is model usage, so match the model to the difficulty of the job. Classifying or routing a document can often be done by a smaller, cheaper model, while reading a creased photograph taken in poor light may need a stronger vision model. Test both on your own documents, and check each provider's current pages, since model lists and pricing change often.
What leaves your systems, and what does not
The document image or text goes to the provider's API, so decide deliberately what that includes: send only what the extraction needs, and redact what is irrelevant. Anthropic's and OpenAI's own documentation say that data sent through their APIs is not used to train their models by default (Anthropic: not without your express permission; OpenAI: unless you opt in). Retention differs by provider, feature and contract: both offer zero-data-retention arrangements for eligible customers, and OpenAI describes API logs kept for up to 30 days by default. This is not legal advice, and consumer products and other providers can differ, so check your provider's and plan's current terms, and again when they change.
Storage deserves the same care. We keep source images in private storage with access policies, attached to the document they produced.
When AI invoice processing is the wrong answer
If the accounting product you already pay for offers invoice capture that handles your documents, use it. Building is justified only where the capture has to feed a process the product cannot express, such as stock and cost prices moving on confirmation. Buy by default is our rule for the general case, and it applies here too.
It is also the wrong answer when volume is low enough that a person typing an invoice costs less than maintaining a review screen, and when nobody will be accountable for the confirm step. The design starts with a human reviewing before the write, because an extraction error otherwise becomes a ledger error found at month end. Once accuracy has been measured on your own documents, auto-approving narrow, low-risk cases can be considered, but start with review, and ask of any step whether it could be reversed quietly next week. If not, it needs a confirmation.
Where it has shipped
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
The disciplines behind it
Related reading
AI invoice processing, specifically
We do not publish an accuracy figure, because none of our case studies states one and a number without a test set means nothing. It depends on your documents. Measure field-level accuracy on a set of your own invoices, poor scans included, and time the review step against typing. Because a person confirms before anything is posted, what matters is how often the reviewer has to correct a field.
Sometimes, and both are the hardest inputs, so test them specifically on your own documents before relying on it. That is what the review screen and the arithmetic check are for: a doubtful document is flagged and the reviewer compares it with the image, so a low-confidence read never enters the ledger unseen.
No published case study of ours covers those products. If your accounting system has an API or an import route, the extraction pipeline is independent of where the confirmed data lands, so it is feasible to scope; where there is no usable route, extraction still produces a validated, structured record for whatever manual entry route you have. Check your specific package with us before assuming.
Not by default, according to the providers' own documentation: Anthropic and OpenAI both say data sent through their APIs is not used to train their models unless you opt in or give permission, and retention varies by provider, feature and contract. This is not legal advice, so check your provider's and plan's current terms, and again when they change. We also scope what is sent so the model sees the fields it needs rather than whole records.
Someone confirms every invoice that writes to the books, yes, and that is by design rather than a limitation. Checking a pre-filled screen should be quicker than typing, though you should time it on your own documents. Once you have measured accuracy you can consider auto-approving narrow, low-risk cases, but start with review, so that an extraction error is caught before it reaches a balance instead of at month end.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- API and data retention · Anthropic (Claude Platform Docs)
- Is my data used for model training? · Anthropic (Privacy Center)
- Data controls in the OpenAI platform · OpenAI
- Rate limits · Anthropic (Claude Platform Docs)
- Rate limits · OpenAI
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no