Invoice automation: from delivery note to journal entry

Invoice automation means, in practice, taking the typing out of a circuit that today passes through three or four pairs of hands: the delivery note from the warehouse, the invoice issued from the ERP, the supplier invoice that arrives as a PDF by email, the match against the purchase order, and the journal entry. Automating the whole circuit at once is the fast route to failure. Automating the two stages where the hours actually go —capturing incoming invoices and reconciliation— usually frees up 40% to 70% of the time spent on that process, and you notice it at month-end.

This guide is for finance directors, back-office teams and accounting firms that already run an ERP or accounting package and want to know what can safely be handed to software, what still needs a person, and in what order to build it. No promises of "paperless in a month".

What does invoice automation actually mean, and which stage can be automated?

"Invoicing" covers two circuits that have almost nothing in common:

• Issuing (accounts receivable). From the order or delivery note to the invoice that goes out to the customer, with its taxes, its series and its delivery. The information already lives in your systems. The problem is rules and formats, not interpretation.
• Receiving (accounts payable). The supplier invoice that arrives as a PDF, on paper or via EDI. Someone has to read it, check it matches a purchase order, that the price is the one agreed and that the goods arrived, and then post it. Here the problem is that every supplier invoices with a different layout.

Issuing is automated with rules: if the ERP knows the order, the price list and the customer, the invoice generates itself. What breaks is not the technology but the edge cases —rebates, freight charges, partial deliveries, credit notes— and the quality of your customer and item master data.

Receiving is where automated extraction comes in: models that read the document and return supplier, tax ID, number, date, net amount, VAT, total and line items. We cover that in depth in document data extraction; here we focus on what happens after the reading, which is where the project is won or lost.

If someone sells you "end-to-end automated invoicing", ask what their system does with a partial credit note against a delivery that arrived incomplete. The answer tells you whether they have ever been inside a real back office.

Which stage should you tackle first?

Rank by volume and by time lost, not by what looks impressive. This is the typical picture in a company of 30 to 200 employees:

| Stage | Volume/month | Where the time goes | Automatable today? | |---|---|---|---| | Issuing from order/delivery note | High | Edge cases, manual review before sending | Yes, with rules in the ERP | | Sending and chasing the invoice | High | Manual emails, resends, customer portals | Yes, almost fully | | Capturing supplier invoices | High | Typing header and line items | Yes, with human validation | | Matching to order and delivery note | Medium | Finding the order, comparing prices | Yes, with rules and tolerances | | Spend approval | Medium | Chasing sign-offs by email | Yes, with a workflow and reminders | | Bank reconciliation | High | Matching receipts to invoices | Partly: 70-90% automatic | | Chasing overdue payments | Medium | Nobody does it until it hurts | Yes, with escalating reminders | | Accounting close | Monthly | Hunting for what is missing | No: it gets shorter, not eliminated |

If you have to pick one, start with supplier invoice capture. It is the stage with the most pure typing, the easiest to measure (invoices per hour before and after) and the one that depends least on changing another department's behaviour.

How does supplier invoice capture with human validation work?

The pattern that works has four pieces, and one of them is a person:

1. A single entry point. One mailbox (`invoices@`) and one folder. Anything that arrives there enters the circuit. If invoices keep arriving on a sales rep's phone, you have not automated anything: you have added another channel. 2. Extraction. The model reads the document and returns each field with a confidence score. Misreading an invoice number is not the same as misreading a net amount. 3. An exception review queue. This is the trick. You set a threshold: above it, the field goes straight through; below it, the invoice lands on a screen where a person sees the PDF on the left and the fields on the right, and fixes it in ten seconds. The goal is not that nobody looks at anything — it is that only the doubtful cases get looked at. 4. Posting to the ERP and archiving. With the document linked to the journal entry, so that during an audit nobody has to dig through a network folder.

Two rules that save a lot of grief:

• Hard validation always, however high the confidence. Net + VAT = total. Tax ID with valid format and check digit. Supplier exists in the master file. Invoice not a duplicate (same series, same number, same supplier). These checks are five lines of code and catch more errors than any model.
• Measure the correction rate over the first six weeks. If 30% of invoices land in review, the system is still saving time. If 80% do, you have a threshold problem, odd layouts, or suppliers missing from the master file — and that is data quality, not artificial intelligence.

The classic mistake is building the extraction and not building the exception queue. Then someone reviews 100% anyway "just in case", and the company pays a licence to do the same work with one extra step.

What is three-way matching and why does it jam reconciliation?

Three-way matching compares purchase order, delivery note and invoice. If all three agree, the invoice approves itself. If they do not, someone decides.

In reality they almost never agree to the cent, so what matters are the tolerances — and they should be written down as policy, not left to whoever happens to be reviewing:

• Amount difference: up to 2% or €20, whichever is lower, goes through automatically.
• Quantity difference: zero tolerance on serialised products; an agreed tolerance on bulk goods.
• Freight and surcharges that were not ordered: never automatic, always to approval.
• Suppliers with no linked order (services, utilities): route to a cost-centre approval flow, not to matching.

Bank reconciliation is the other front. Matching incoming payments to issued invoices is 70-90% automatable with rules: exact amount, reference in the payment description, regular customer. The rest —grouped payments, partial payments, withholdings, bank-fee differences— needs human judgement. A good system proposes the match and lets a person confirm with one click; a bad one reconciles on its own and forces you to unwind journal entries.

When the ERP and the CRM do not talk to each other, none of this flows: the customer exists twice under two different tax IDs and no rule matches. If that is your situation, the prior problem is ERP and CRM integration.

Which errors cost you a close?

These are the ones we have seen delay month-end, in order of frequency:

• Duplicates. The same invoice arrives by email and on paper, or the supplier resends it "just in case". Without a duplicate check on (supplier, series, number) you pay twice. It is the most expensive error and the easiest to prevent.
• Period allocation. A December invoice that arrives in January and gets posted in January. The invoice date has to win over the arrival date.
• Misclassified VAT. Intra-community transactions, reverse charge, non-deductible VAT. A model should not decide this on its own: the transaction type is resolved by supplier and ledger account, with rules, and exceptions go to review.
• A dirty supplier master. "García Supplies Ltd", "Garcia Supplies Ltd" and "GARCÍA SUPPLIES" as three separate records. It breaks matching, reconciliation and any spend report.
• Nobody owns the circuit. If an invoice sits waiting for approval with no deadline and no reminder, the automated flow becomes a graveyard of pending documents.

What about mandatory e-invoicing?

Two things are worth keeping apart, and the detail varies by country — in Spain, where we work, it looks like this:

• Invoicing to public administrations, which has required a structured format and submission through official entry points for years. It is an old, settled requirement.
• Business-to-business e-invoicing and the requirements on invoicing software derived from anti-fraud legislation and the business growth act: a tamper-proof record of issued invoices, traceability, a chained hash and, for many companies, submission of those records to the tax authority.

The entry-into-force dates have moved several times, so do not take your calendar from a blog post — this one included: confirm the current timetable with your accountants and your software vendor. What is stable as a buying criterion: if you are going to change or adapt your invoicing system, do it once and get the vendor to state in writing that their version complies. Changing invoicing software twice in two years costs more than any licence.

One more piece of common sense: a regulatory deadline is a good excuse to tidy up the circuit, but it is not why you automate. You automate because five people are typing data that already exists inside a PDF.

How do you build the first stage in 90 days?

A plan we have seen reach the finish line, rather than one that looks good on a slide:

| Weeks | What happens | What must exist at the end | |---|---|---| | 1-2 | Measure: invoices received and issued per month, hours spent, % with issues, days to close | The baseline in writing. Without it you cannot tell whether it worked | | 3-4 | Clean the supplier and customer masters; one single invoice entry channel | A master file with no duplicates and a working `invoices@` mailbox | | 5-8 | Extraction + hard validations + exception queue on real invoices, running alongside the current process | A correction rate measured over at least 300 invoices | | 9-10 | Posting to the ERP, document archived and linked to the journal entry | Invoices posted with no typing on the happy path | | 11-12 | Order matching with written tolerances; approval reminders with deadlines | A tolerance policy signed off by finance |

On cost: the software licence is usually the small part. What you really pay for is the ERP integration, the master-data cleanup and the weeks of parallel review. For numbers and ranges by project type, we break them down in what an AI project costs, and how to measure the return honestly in measuring AI ROI.

Frequently asked questions

How much time does invoice automation actually save?

On supplier invoice capture, the usual move is from 3-6 minutes per invoice to under 1 minute on average, including the ones that land in review. The saving depends more on how many invoices you process and how dirty your supplier master is than on which model you use.

Do I need artificial intelligence, or are rules enough?

To issue invoices from the ERP, rules. To read supplier documents with a thousand different layouts, extraction models. Most projects that work combine both: the model reads, the rules validate. If the choice is unclear, we unpack it in RPA versus AI.

Can I automate if an external accounting firm does my books?

Yes, and it is usually the best scenario: you tidy up the intake and validation, and your accountants receive clean data instead of a ZIP full of PDFs. Agree the exchange format and who corrects what before you start. AI for accounting firms covers the other side of the same circuit.

What about paper invoices that arrive by post?

They get scanned at a single point and enter the same circuit. Bulk scanning with a decent document feeder costs very little; digitising is not the problem — the problem is someone keeping the paper on their desk for two weeks before walking it to the scanner.

If you are deciding where to start and which part of your invoicing circuit can be automated safely, an audit gives you the picture and the numbers before you sign any licence. And if you would rather talk it through in half an hour, let's talk: with your invoice volume and the ERP you run, there is already plenty to say.