How do you automate purchase invoice processing without losing control?

Automated invoice processing saves time, but blindly trusting extraction is risky. Here is how to build a system that verifies its own work.

Jack van der Vall

Jack van der Vall

7 min read

Nederlands
A paper invoice next to a cup of coffee on a desk, symbolizing the daily stream of purchase invoices.

Summary: Manually entering purchase invoices and re-checking payment runs line by line costs significant time and remains error-prone. Fully blind automation is risky too: extraction from PDFs makes mistakes, and invoice fraud is becoming more professional. This article describes the architecture of a system that processes automatically and verifies itself, using independent reconciliation totals and invoice matching. Discrepancies are never paid silently but always presented to an employee.

Last updated: 23 July 2026 · By Jack van der Vall, AI Engineer

Related: also read which administrative processes you can responsibly automate, how to link legacy systems to modern automation, and our process automation services.

Why is purchase invoice processing so error-prone?

Invoices arrive every week: by e-mail, as PDFs, sometimes still on paper. Someone transfers the data into the accounting software, checks the amounts, and prepares payments. For a technical company with dozens of suppliers, this is a structural time drain.

The problem is not just the time. Manual data entry introduces errors, and those errors are expensive to find. According to the Billentis e-invoicing report, typically 20 to 30% of all invoices have to be treated as exceptions, resulting in very high processing costs. Think of deviating amounts, missing references, or unclear supplier details.

The reflex is: automate it. Modern AI models read an invoice PDF in seconds. But that is where a new problem begins.

What goes wrong when you trust extraction blindly?

Automated extraction is powerful, but not flawless. A model can misread a digit, skip a line, or attribute an amount to the wrong supplier. On a single invoice, such an error might get noticed. On a payment run of a hundred lines, it will not.

The fundamental point is this: an extracted amount is a hypothesis, not a fact. A system that passes extraction results straight through to payments does not just automate the work. It also automates the errors, and removes exactly the human check that used to catch them.

Then there is fraud. With a ghost invoice, a fraudster bills for services that were never delivered. With invoice manipulation, a genuine bank account number is replaced by the perpetrator’s. Research by Dialogic for the Dutch House of Representatives shows that the average damage of invoice fraud reported to the Dutch Fraudehelpdesk in 2024 exceeded 44,000 euros per incident. The number of reports is limited, but the damage per case is substantial. A processing pipeline without verification makes you more vulnerable to this, not less.

How does a robust system verify its own work?

The solution is not a choice between manual work and blind trust. A well-designed system uses a principle from accounting itself: independent totals that must reconcile.

Take a payment run exported from the accounting software as a PDF: one line per invoice, grouped by supplier, with subtotals per supplier and a grand total. Those subtotals are not formatting. They are checkpoints. Every extracted line is verified against a second, independently extracted number: the subtotal of its own supplier and the grand total of the report.

If the sum of the lines does not reconcile with the subtotal, the system knows not only that something is wrong, but also where. It flags the specific supplier where the difference sits. An employee then reviews one block of a few lines, instead of re-checking an entire report.

graph TD
    A[Payment run exported as PDF] --> B[Automated extraction of all invoice lines]
    B --> C{Do the per-supplier totals reconcile?}
    C -->|Yes| D[Match every line to a received invoice]
    C -->|No| E[Deviating supplier flagged for review]
    D --> F{Do supplier, account number and amount match?}
    F -->|Yes| G[Line approved for payment]
    F -->|No| H[Line presented to an employee]
    E --> H

Accessible summary: A flowchart of controlled invoice processing. A payment run is read automatically. First, the system verifies the totals per supplier against the subtotals in the report. Then every line is matched to a real received invoice, on supplier, bank account number, and amount. Only lines that pass both checks are approved. All discrepancies go to an employee.

How do you know every payment line belongs to a real invoice?

Reconciling totals prove the extraction is complete and correct. They do not prove the payment is justified. That requires a second check: matching.

Every incoming purchase invoice is processed and stored separately: supplier name, bank account number, invoice number, and amount. When verifying a payment run, the system looks up the corresponding received invoice for every payment line. A payment line is only approved when supplier, bank account number, and amount match an invoice you actually received.

This link catches exactly the risks that extraction alone cannot see. A duplicate payment has two lines against one invoice. A ghost invoice has no counterpart in your records. A manipulated bank account number deviates from the number on the original invoice. In all three cases, the line is flagged and presented to an employee. Nothing is paid silently.

What does this look like in practice?

This architecture is not theory. We built this system for a full-service mechanical contractor in the process industry, with its own production facilities. Payment runs at this company regularly exceed a hundred invoice lines, spread across dozens of suppliers.

Previously, that meant someone checked the report line by line, or trusted that it was correct. Now the system reads the complete payment run automatically, verifies the totals per supplier, and matches every line to a received invoice. The employee only reviews the lines that the system itself flags as deviating.

The difference is not less control, but targeted control. Every line is still verified, only the system does the routine work and the human decides on the exceptions. That is a fundamentally different approach from a script that passes invoices into your records unchecked.

Where do you start with automation?

The direction is clear. In 2025, according to the Dutch government’s digital affairs office, 86% of all invoices received by the Dutch central government were electronic, nearly two million in total, roughly half of them via the Peppol network. E-invoicing is becoming the norm, and structured invoices are easier to process reliably than PDFs.

Practically, you start like this:

  1. Map your invoice flow. How many purchase invoices per month, through which channels, and who processes them now?
  2. Identify the checkpoints. Which totals, subtotals, and references does your current process already contain? These become the anchors of automated verification.
  3. Automate the verification first, then the processing. A system that reliably flags discrepancies earns trust. After that, you can hand over more routine work step by step.
  4. Keep the human in the loop for exceptions. The goal is not zero human actions, but human attention in the places where it adds value.

Raw data available: Purchase Invoice Processing Benchmark Data


Frequently Asked Questions

Can I automate invoice processing entirely without human review?

No, and you should not want to. A well-designed system automates the verification itself: it checks every line against independent totals and received invoices. Only discrepancies are presented to an employee. The work shifts from re-checking everything to reviewing exceptions.

How does automation prevent me from paying a fraudulent invoice?

By matching every payment line to an invoice you demonstrably received, with the same supplier, the same bank account number, and the same amount. A ghost invoice or manipulated account number has no matching counterpart and is automatically flagged for review.

Does this work with my current accounting software?

Usually, yes. This approach builds on what your accounting software already produces: payment overviews, subtotals, and invoice data. The verification system runs alongside it and does not replace your records. Unlike off-the-shelf invoice processing software, it is built around your existing process, which makes it a feasible route precisely for companies running older software.


Key Takeaways

  • Manual invoice processing is error-prone: typically 20 to 30% of invoices require exception handling.
  • Automated extraction makes mistakes too. An extracted amount is a hypothesis that must be verified, not a fact.
  • Independent reconciliation totals per supplier pinpoint errors precisely, instead of merely signaling that something is wrong.
  • Matching against real received invoices catches duplicate payments, ghost invoices, and manipulated bank account numbers.
  • Discrepancies are never paid silently: the human reviews the exceptions, the system does the routine work.

About the author

Jack van der Vall is an AI Engineer at Opusmatic, specializing in AI automation for technical installation companies and SMEs in Zuid-Holland. He builds processing systems for purchase invoices and payment runs in which automated extraction is always verified against independent checks.

Opusmatic | LinkedIn | Contact