Where the Sign-Off Goes When AI Reads Your Invoices

The PDF arrives by email. Somebody in finance opens it, reads the supplier name, the invoice date, the net, the VAT amount printed on it, the currency and the purchase order number, and types those six things into the accounting system. Multiply that by the documents your business receives in a month and you have work that occupies a real person for real hours, produces nothing anyone would call analysis, and goes wrong quietly.

The case for putting AI in front of that is obvious enough that most finance directors have already had the thought. What decides whether the result is safe to run is where the human sign-off gate sits.

What extraction is genuinely good at

Reading a machine-generated PDF and returning structured fields is a solved problem in the ordinary case. The fields are text rather than pixels, and supplier, dates, line items, totals and references come back reliably. And it runs on arrival rather than in a batch on Thursday, which matters more than it sounds: a document read on Tuesday can be queried on Tuesday.

We do not publish an extraction accuracy percentage. A figure measured on someone else's document mix tells you nothing about yours. We will not quote a number we have not measured on your own documents.

Where extraction fails, and it will

Poor scans. A photograph of a creased delivery note taken in a van. Recognition degrades, and it degrades worst on the digits.

Unusual layouts. A rebate applied at the foot, or a summary invoice that refers to a statement rather than stating its own lines. Common in construction, distribution and anything with depots.

Multi-page attachments. One email carries an invoice, a statement, a delivery note and two pages of terms. Reading the pages is not the difficulty. Knowing where one document ends, and which of them is the invoice, is.

Credit notes. A credit note looks almost exactly like an invoice, and the sign is the entire meaning. Read as an invoice it produces a positive where a negative belongs, and it passes every plausibility check, because everything about it is plausible except the direction.

Foreign currency. Reading the currency off the page is easy. Which rate applies, on what date, under which policy, is an accounting decision and not something software should be choosing. The amount and the currency are recorded as printed, and the rest stays with the people who own that policy.

The same principle governs VAT. The amount printed on a document is transcribed as printed, and whether that treatment is correct is a question for your finance team or your accountant. To be plain: SpotDev gives no financial, tax, legal or accounting advice. We are a software engineering firm, and where a question belongs to your accountant or auditor, we will say so.

Duplicate detection matters more than extraction accuracy

A misread field is a correction. Somebody notices, fixes it, and the cost is a minute. A duplicate payment is a loss: the money has left, and recovering it depends on the supplier noticing and agreeing to return it.

Duplicates arrive for ordinary reasons. The supplier emails the invoice and also posts it. A statement chase re-attaches the original. The supplier reissues under a new number for the same work after a query. So matching on invoice number alone catches almost nothing, and useful checking compares supplier, amount, date proximity, purchase order reference and the shape of the line items together, treating a near miss as a question rather than an answer.

Then the part that decides how much this is worth to you: it can only check against what it can see. Checking against documents that have already passed through intake catches the common case, which is the same invoice arriving twice. Catching the expensive case, an invoice already recorded last month, needs history from the accounting system, and how far back that reaches depends on the integration scope agreed and on what your system exposes. That is a scoping decision rather than a feature, and worth settling early. Whatever the reach, nothing is merged, deleted or written off. A suspected duplicate is flagged for a person. The design for document and invoice intake in our AI for Business Operations pack starts from that constraint rather than working around it.

Completeness, and asking for what is missing

Extraction tells you what is on the document. The more useful check is what should be on it and is not: a missing purchase order reference, a total that does not equal the sum of the lines, new bank details against a familiar supplier.

The valuable behaviour here is not rejection, it is requesting. An item with a missing reference goes back to the internal owner with the specific gap named, under rules your finance lead has set. That chase is real work that reliably does not get done in the last week of the month.

The source document is evidence, the extracted record is a claim about it

Keep the two attached. A reviewer who can see the page the agent saw settles a query in seconds. One who has to go and find the original does not bother, which is how a wrong figure survives.

When the document, the extracted record, the approval and the audit trail are one thing in the systems you already run, an auditor's question has one answer. When the documents sit in a separate platform holding its own copy of your data, every reconciliation becomes a small project.

Where the approval gate goes

The gate is not a formality bolted on at the end. It is the centre of the design, and the rest exists to make the person standing at it faster and better informed.

Autonomy is granted per action, not per agent. Every action is placed on a ladder in writing before release, and the table below is what that looks like for this workflow. For invoice intake, the correct steady state for most of it is draft or recommend, permanently.

Where your accounting system exposes an approval route we can write into, we use that, because a second queue nobody opens is worse than no queue. Where it does not, we build one and it becomes part of the scope. Either way the item arrives with the source document attached and a named person approves or corrects it. That is why the output is safe to rely on.

What happens when a document is read wrongly

It will happen, so the design question is what happens next. Nothing is posted on the strength of an extraction alone, so a misread field is a correction rather than an incident. The source file stays attached, so the reviewer sees what the agent saw. And the failure route is explicit: retry, stop, reconcile or escalate. An item that cannot be handled confidently appears on a queue with its age against it, rather than completing silently or disappearing.

Which is the honest summary of the design. When a document is read wrongly, a person catches it, because a person approves it.

The systems this connects to

The premise is intake connected into the finance stack you already run, not another document tool with its own login. The accounting systems in our integration library include Xero, QuickBooks, Sage 50, Sage 200, Sage X3, Sage Intacct, Exact Online, FreeAgent, iplicit and Access Financials, and on the ERP side Microsoft Business Central and NetSuite. The full integration library lists the rest.

Naming a system is not a claim about what it will do for your edition or estate. Sometimes a capability you already pay for covers the workflow, and we will say so.

How you would know it worked

Capture the baseline first, because the only comparison worth having is against your own numbers. Document volume per month. Touches per document. Elapsed time from arrival to approval. Correction rate at the gate. Duplicates caught before payment. Items still unresolved after a week.

Measure the same things afterwards and report them separately from anything financial. Time saved is not automatically cost reduction. The AI Accelerator programme runs department by department across twelve months, one quarter at a time, and every wave ends in a decision that includes stopping.

The next step

If your team is retyping documents today, the useful first move is not a build. It is establishing what actually arrives, in what condition, and which queues carry consequence when they go wrong.

That is a short, fixed-scope assessment with no obligation. Book a diagnostic and we will tell you what is worth building, and what is not. For where each department falls in a rollout, we have set out the sequencing separately.