AI invoice processing automation takes an invoice from the inbox to a draft bill in your accounting system without anyone keying it. A parser or OCR pulls out the text, and a large language model maps that text onto a fixed set of fields. Deterministic rules then check the maths, the VAT and the supplier details, and anything that fails goes to a review queue for a person. The LLM does the reading, plain code does the checking, and a human decides on the exceptions. Below is a worked example of that pipeline from end to end, with the design choices and the places where it breaks.
The example is illustrative, not a client story. Picture a hypothetical Irish wholesaler with around 40 regular suppliers, a few hundred invoices a month, one person in accounts payable and an accounting package with an API (Xero, Sage or Business Central would all do). The figures make the mechanics concrete. They are not a promised result. If you want the broader picture of replacing keyed data with reliable workflows first, our piece on how to automate manual data entry covers the general pattern. This article is the invoice-specific version.
The starting point: what accounts payable actually looks like
Invoices arrive in a shared mailbox. Most are PDFs generated by the supplier’s own system, so they have a real text layer. A minority are scans of paper invoices. A few are phone photos of a delivery docket with the invoice stapled behind it. The occasional supplier sends a structured e-invoice or a link to a portal. For each one, the AP clerk opens it, checks it against the purchase order and keys supplier, date, invoice number, line items and VAT into the accounting system. Then they attach the PDF and queue it for approval.
Keying is the obvious target, but it is not always the real cost. Before building anything, check where the time actually goes. If most of the clerk’s day is spent chasing approvals or resolving price disputes with suppliers, faster extraction will not change much. We wrote about that trap in Should I Automate My Bottleneck First? Not Always. For this example, assume keying and matching make up most of the work. That is typical when invoice volume is steady and the supplier base is stable.
The pipeline, step by step
1. Intake and deduplication
Point a dedicated address (invoices@ or ap@) at a small service that polls the mailbox and pulls every attachment. It stores each original file untouched in object storage, along with a content hash. The hash catches the supplier who emails the same PDF twice. A later check on supplier plus invoice number catches the supplier who sends a reprint as a different file. Every downstream step references the stored original, so an auditor can always see exactly what arrived and when.
Split bundles at this stage too. A single PDF containing three invoices and a statement is normal, and a model will happily merge them into one mangled record if you let it. Run a cheap first pass that classifies each page as invoice, credit note, statement, delivery docket or other, and groups the pages into documents. It saves a lot of grief later.
2. Getting the text out: text layer, OCR or vision model
For digitally generated PDFs, read the text layer directly, which is exact and costs nothing. For scans and photos you have two options:
- Classic OCR plus an LLM. OCR (Tesseract locally, or a cloud document service) produces text with positions, which you then pass to an LLM. This is cheaper per page and easier to debug, because you can inspect the intermediate text.
- A multimodal model reading the page image directly. This copes better with skewed photos, stamps and handwritten notes. It costs more, though, and it hides its mistakes inside a single step.
A sensible default is text layer first, OCR second, and the vision model as a fallback when OCR confidence is low.
3. Extraction into a fixed schema
This is where the LLM earns its place. You do not write a template for each supplier layout. Instead, you give the model the document text and a JSON schema and ask for structured output. Most current model APIs can constrain the response to the schema, which removes a whole category of parsing errors.
Two prompt rules matter more than any clever wording. First, the model must return null for any field it cannot find, rather than guessing. Second, it must copy values exactly as printed, leaving arithmetic and normalisation to code. The table below lists the fields in the example and the check each one goes through after extraction. Supplier names and numbers are invented for illustration.
| Field | Example value | Check after extraction |
|---|---|---|
| Supplier name | Example Packaging Ltd | Matched to the supplier master; unknown suppliers go to review |
| Supplier VAT number | IE1234567T | Must equal the VAT number held on the supplier master |
| Invoice number | INV-20419 | Unique per supplier; duplicates blocked |
| Invoice date | 03/04/2026 | Parsed as day/month; flagged if in the future or unusually old |
| Currency | EUR | Must match the supplier’s usual currency |
| Line items | 400 × carton 400mm @ €3.10 | Quantity × unit price must equal the line total, to the cent |
| Net / VAT / gross | €1,240.00 / €285.20 / €1,525.20 | Lines sum to net; VAT at a valid rate; net + VAT = gross |
| Bank details (IBAN) | As printed | Must match the supplier master; any difference is a hard stop |
| PO number | PO-7712 | Exists, is open, and belongs to this supplier |
4. Deterministic validation
Every check in the right-hand column is ordinary code, not a model call, and that split is the central design decision. An LLM is good at finding “Total excl. VAT” on a layout it has never seen. It is not a reliable calculator, and it should never be the thing that decides an invoice is safe to pay. So code re-adds the lines and recomputes VAT at the valid Irish rates. It confirms the supplier’s VAT number and bank details against your master data and checks that the invoice number has not been seen before. If the figures do not reconcile to the cent, the invoice goes to review with the discrepancy shown. That same check also catches the cases where the model misread a digit.
The bank details check is worth singling out. Changing bank details on an invoice is a long-standing fraud. A pipeline that trusts whatever account number is printed on the PDF would make that fraud easier, not harder. Bank details should change only through a separate, verified supplier-master process, never from an invoice.
5. Matching against purchase orders and receipts
Once the data is clean, matching becomes simple joins with tolerances. Two-way matching compares the invoice with the PO. Three-way matching adds the goods received note. Agree the tolerances explicitly with whoever owns AP: perhaps a few cent for rounding, a small margin on freight and zero on unit price. Lines within tolerance pass. Anything else becomes an exception with a specific reason, such as “unit price €3.25 vs PO €3.10”, rather than a vague “needs review”.
6. The exception queue
Exceptions are where people will spend their time, so make them fast to clear. Each item shows the original page beside the extracted fields and highlights the check that failed. It then offers a small set of actions: correct a field, approve with a note, reject back to the supplier, or escalate to the budget holder. Where the decision is simple, it should be possible to make it with one tap from a phone. We run that pattern in our own lab and described it in Human-in-the-Loop Action Tags. Log every correction. That gives you a labelled dataset for free and shows you which suppliers and fields cause the most trouble.
7. Posting
Invoices that pass every check are created as draft bills in the accounting system through its API, with the original PDF attached and a link back to the extraction record. Keep posting as drafts at first, and let a person release them in batches. After a few months of proven field-level accuracy on your own documents, you can promote clean invoices from known suppliers straight to approved bills. Payment runs stay a separate, human-authorised step. Nothing in this pipeline moves money.
Where it breaks, and how to design for it
Most failures in invoice data extraction are predictable. That means you can test for them before go-live, instead of discovering them months later during a supplier statement reconciliation. These are the ones to plan for:
- Credit notes read as invoices. They share the same layout but carry the opposite sign. Classify the document type explicitly and check that the sign of the totals matches it.
- Ambiguous dates. 03/04/2026 is 3 April in Ireland and 4 March under a US default. Parse dates using the supplier’s locale and flag anything outside a sensible window.
- Multi-page invoices with carried-forward subtotals. Models sometimes count a page subtotal as a line item. The reconciliation check catches this, and the fix is usually a prompt rule or page-aware chunking.
- Invented values. If a field is missing and the schema marks it as required, a model may fill it with something plausible. Make fields nullable and treat null as a trigger for review, not as an error.
- Supplier name drift. “Example Packaging”, “Example Packaging Ltd” and the trading name on the letterhead are all the same supplier. Match on VAT number first and name second.
- Text in the document aimed at the model. A PDF can carry instructions as easily as figures. Because the extraction step has no tools and no write access, and code validates everything it returns, injected text can at worst produce a bad extraction that then fails validation.
That last point applies more widely. The safest architecture gives the model exactly one job, which is reading, and no ability to act. For a fuller treatment of where to draw those boundaries, see our LLM integration guide for production systems.
Measuring it honestly
Before switching anything on, build a test set of real invoices with the correct values keyed by hand, and score the pipeline field by field. A single overall “accuracy” figure hides the failures that matter. You want to know separately how often invoice numbers, totals, VAT and line items come out right. A wrong line description is an annoyance; a wrong total is a payment error. In production, track three numbers:
- Straight-through rate: the share of invoices that post with no human touch.
- Exception handling time: how long a person spends clearing each exception.
- Correction rate per field: taken from the review log.
Those numbers feed directly into the kind of calculation set out in Process Automation ROI: How to Calculate It Properly.
Model cost is rarely the deciding factor. An invoice is a page or two of text, and extracting it with a current model costs little next to a person keying it. The real costs lie elsewhere: the build, the integration with your accounting system and supplier master, and the ongoing human time spent on exceptions. On tooling, intake and posting fit comfortably in a workflow tool, while extraction and validation are usually better as versioned code you can test. Our comparison of n8n vs Make vs Zapier vs custom code covers that trade-off.
Then there is the data. Invoices from sole traders contain personal data, so GDPR applies. Know where documents are processed and stored. Set retention to match your statutory record-keeping obligations. Choose model providers whose terms cover EU data processing. Our AI security and compliance guide for EU firms goes through the checks.
This week: hand-key 50 invoices into a spreadsheet
Pull the last 50 invoices from your AP inbox, and deliberately include the awkward ones: scans, credit notes, multi-page invoices and the supplier whose layout everyone dreads. Key the fields from the table above into a spreadsheet, one row per invoice. Note how long each one took and which ones needed a question to someone else. That gives you three things:
- a ground-truth test set you can score any extraction approach against;
- an honest view of how much of the work is keying and how much is chasing;
- the list of exceptions that will shape your review queue.
It takes an afternoon or two and costs nothing.
D3X Solutions LABS is an AI engineering studio in Ireland that builds this kind of pipeline. We start from that test set. We score candidate extraction approaches against it and agree validation rules and tolerances with whoever owns AP. Then we build the pipeline into your existing mailbox and accounting system rather than replacing them, with the review queue and audit trail in place from the first day. If you would like to talk through your invoice flow and whether it is worth automating, book a free 30-minute call.
Frequently Asked Questions
Can an LLM read invoices accurately enough for accounts payable?
An LLM is good at finding the right fields on layouts it has never seen, but it should not be trusted on its own. The reliable pattern is LLM extraction into a fixed schema, followed by deterministic checks on totals, VAT, supplier VAT number, bank details and duplicates. Anything that fails goes to a person, so a misread digit is caught before it reaches a payment run.
Do I still need OCR if I use an LLM for invoice processing?
For digitally generated PDFs you need neither. Read the text layer directly, which is exact and free. For scans and photos, OCR plus an LLM is cheaper and easier to debug, while a multimodal model handles poor-quality images better at a higher cost. A practical setup uses the text layer first, OCR second and a vision model as the fallback.
Is AI invoice automation safe from invoice fraud?
It can be safer than manual keying if it is designed properly. Bank details should never be taken from the invoice. They should be checked against a verified supplier master, with any mismatch treated as a hard stop. The model should have no ability to post or pay anything, and payment runs should stay a separate, human-authorised step.
How much does AI invoice processing cost per invoice?
The model cost per invoice is small, because most invoices are only a page or two of text. The larger costs are building the pipeline, integrating it with your accounting system and supplier master, and the human time spent on exceptions. Measure straight-through rate and exception handling time to see the real return.
Does the EU AI Act or GDPR affect invoice processing automation?
Invoice data extraction is not one of the high-risk use cases the EU AI Act singles out, but GDPR applies where invoices contain personal data, for example from sole traders. You need to know where documents are processed and stored. Set retention to match your record-keeping obligations, and use model providers with suitable EU data processing terms.
Want this working in your business?
D3X Solutions LABS builds AI agents and automation that pay back fast. Book a free 30-minute call and we will look at where AI would pay back first in your workflow.
Get in touch
