Invoice capture into the accounting system

Invoice capture is the process by which the finance team receives supplier invoices, either by email or physical post, extracts the relevant data, assigns a cost centre and GL code, and posts the result to the ERP system. The process runs daily at high frequency, covering around 6,000 invoices per year. Every invoice must end up correctly coded and posted with a full audit trail that satisfies statutory requirements including VAT compliance and seven-year document retention.

At present, a three-person finance team and an external accountant handle this entirely by hand. A team member re-keys invoice data manually, decides on cost centre and GL coding based on supplier context and rules that live largely in people's heads, passes the item along via email or spreadsheet, and eventually posts it to the ERP. Exceptions, which account for roughly 10 to 15 percent of volume, require additional judgement and take a disproportionate share of the team's time. Errors often surface only at month-end closing, which creates pressure and rework. At 22 minutes per invoice, the process consumes approximately 2,200 hours of skilled finance time every year.

The ERP system has an available API that the external accountant has already integrated with, which is a meaningful advantage. There is no in-house developer, but budget is available to engage an external one. The combination of high volume, a working API, clear rules for the majority of cases, and a compliance requirement that demands explainable human approval gates makes this process a strong candidate for a carefully designed hybrid automation approach.

The recommended path is a Hybrid AI workflow with human-in-the-loop approval gates. The core logic is straightforward: use AI-assisted OCR and a rules-based classification engine to handle the routine 85 percent of invoices end-to-end, and route anything below a confidence threshold to a lightweight human review queue where a finance team member can approve or correct with full context. This design directly matches the client's stated goal, automates the repetitive majority, and preserves the human touchpoints that the statutory audit trail actually requires.

The client noted no in-house developer and a preference for engaging an external one alongside the existing ERP integration. That context matters here. The ERP API has already been used by the external accountant, which means the integration path is known, the endpoints are understood, and the risk of an expensive discovery phase is low. An external developer can build the AI extraction layer, the coding engine, and the ERP connector with a realistic scope and budget, precisely because the groundwork has already been laid. The recommended build cost range of 18,000 to 35,000 GBP reflects that de-risked starting position, with a projected payback period of around four months against an annual saving of approximately 123,750 GBP.

The reason Hybrid scores higher than a fully automated AI Workflow is compliance, not capability. A fully automated path could handle the standard cases competently, but the statutory requirement for explainable automated postings and an auditor-traceable approval record means that human gates are not optional. Adding those gates to a fully automated AI Workflow effectively produces a Hybrid, so the recommendation names it correctly from the start rather than treating compliance as a retrofit.

RPA was considered and scored as viable for structured invoices, but it handles supplier format variability poorly and has no native mechanism for cost centre judgement. The 10 to 15 percent exception rate would require extensive bespoke exception-handling logic that increases maintenance burden over time, particularly as supplier formats change. Traditional Code faces the same limitation: a rules-based coded integration would work for known formats but would become brittle as supplier layouts evolve, and maintaining a growing library of hard-coded rules is a significant ongoing cost. Neither path is wrong in principle, but both require more engineering effort to reach the same outcome that a Hybrid with AI-assisted OCR achieves more naturally.

An autonomous AI Agent was assessed and not recommended. For a regulated finance process with a hard statutory audit trail requirement, a fully autonomous posting agent that acts without human approval gates creates compliance exposure that outweighs the efficiency gain. The audit trail must record not just what was posted but who approved it and when. An agent that bypasses that gate, even accurately, fails the auditability test. Education alone scored at the bottom because the team already understands the process well. The problem is not a skills gap; it is 2,200 hours of manual re-keying. Training cannot recover those hours.

The top two contenders here are Hybrid and AI Workflow, and the gap between them comes down to one word: compliance. A fully automated AI Workflow could handle the standard cases well, and in a less regulated context it might be the right call. But the statutory audit trail requirement, the VAT rules, and the need for every automated posting to be explainable to an auditor mean that a hands-off approach carries real legal exposure. The moment you add the human approval gates that compliance demands, you have effectively built a Hybrid anyway, so it makes more sense to design for that from the start rather than retrofit it.

RPA is worth addressing because it often comes up in invoice processing conversations. It can automate re-keying for perfectly structured, consistent invoice formats, but supplier format variability is the defining characteristic of this process. Ten to fifteen percent of invoices arrive in non-standard formats, and RPA has no native intelligence to handle that variability without extensive exception-handling logic that becomes a maintenance burden every time a supplier changes their template. The AI-assisted OCR layer in the Hybrid path handles format variability as a core capability, not an edge case to be bolted on later.

Hybrid wins here because it was designed for exactly this kind of process: high volume, well-defined rules for the majority of cases, genuine exceptions that require human judgement, and hard compliance requirements that cannot be designed around. It automates the routine 85% end-to-end and routes everything else to a human reviewer with full context, preserving the audit trail without slowing down the standard flow.

The build starts with a discovery and rules capture phase before a single line of code is written. The cost centre assignment logic and GL coding rules currently live in the heads of two or three people, and that tacit knowledge has to be made explicit and documented before an AI classifier can be trained on it. During this same phase, the external accountant who previously integrated with the ERP pulls the relevant API documentation and endpoint details, which significantly de-risks the integration work that comes later. This is typically one to two weeks of focused time with the most experienced finance team member, and it is the phase that most teams underestimate.

With the rules documented, the next step is deploying an AI-assisted OCR service to handle data extraction across the varied supplier invoice formats. Azure AI Document Intelligence, formerly known as Azure Form Recognizer, is a strong candidate here given its pre-built invoice model and the ability to fine-tune on a labelled set of real supplier invoices. The extraction layer is trained and validated against a test set of historical invoices before any downstream logic is connected, so the team has a clear accuracy baseline before the build proceeds. Once extraction is reliable, a rules engine and machine-learning classifier maps the extracted fields to GL codes and cost centres using the documented rules and historical posting data as training signal. A confidence threshold is configured so that any invoice the system is uncertain about is automatically flagged for human review rather than posted.

The ERP integration is built next, connecting the coding engine to the ERP via its existing API. Every automated posting writes a full processing log to the audit trail: the source document reference, the extracted field values, the confidence score, and the coding decision. This is not optional and it is not added at the end; it is designed into the data model from the start so that every record is auditor-ready from day one. The external accountant reviews and validates this integration layer against their prior work, which keeps the build low-risk and avoids rediscovering integration quirks during the parallel run.

The human review queue is a lightweight interface, which could be built as a simple web app or a no-code tool like Retool or even a structured Microsoft Teams workflow depending on the client's existing tooling, where exceptions and low-confidence invoices are presented with the extracted data, the suggested coding, and a clear approve or correct action. Every approval action logs the reviewer's identity and timestamp automatically. Once the full solution is assembled, it runs in parallel with the manual process for four weeks, with the team comparing outputs daily. Discrepancies are resolved, the classifier is refined, and the solution goes live only once extraction and coding accuracy meets the agreed threshold. The external accountant and the finance team are trained and handed documentation they can actually use.