Do not automate the reading of an invoice. Automate the controlled path from intake to accounting. Structured e-invoices are parsed, PDFs and scans are extracted, and both paths meet in one shared invoice model. After that, deterministic checks against authoritative master data and accountable people decide, not a confidence score.
OCR is a building block, not the process. A model can extract supplier, invoice number, date, amounts, and line items. It does not decide whether the supplier is known, whether the invoice already exists, whether a purchase order matches, or whether an approval is missing. That combination of AI-assisted preparation and operationally reliable workflow integration is what turns document recognition into invoice processing.
- Which business state should a document have after intake?
- Where does the rule end and a person's responsibility begin?
- Who owns the operation when the ERP handoff runs into a timeout?
An invoice is a business operation, not an image file
Many projects start by asking which OCR service recognizes fields best. The more useful question is which business state should exist after intake. An invoice can be new, incomplete, duplicate, matched to an order, unresolved, approved, rejected, transferred, or posted. Until those states, transitions, and responsibilities are described, better extraction moves the problem into another system.
The target process therefore starts with a business operation identifier and an unaltered source. Every transformation produces a new, traceable representation but never quietly replaces the original. The record must trace back to the document received, its intake channel, its processing stages, and the decisions taken, which is equally the basis for support, internal control, and a later audit.
| Layer | Required outcome | Typical failure | Ownership |
|---|---|---|---|
| Intake | Source, format, timestamp, and operation identifier | Attachment missing or collected twice | Finance operations |
| Extraction | Fields, line items, evidence location, and confidence | Value read incorrectly or mapped to the wrong field | Document pipeline |
| Validation | Rule results against authoritative data | Supplier, amount, or order reference conflicts | Finance and system owner |
| Approval | Decision, role, timestamp, and reason | No clear responsibility, or the case simply waits | Named approvers |
| Handoff | Confirmed target state in the ERP or accounting system | Timeout creates an unclear or duplicated state | Integration owner |
| Operations | Monitoring, queue, and recovery | Failure stays invisible or is retried forever | Product and operations |
Structured e-invoices and OCR are different intake paths
Since 1 January 2025, under the current German finance ministry definition, an e-invoice in the German B2B context is a structured electronic format that enables electronic processing. A plain PDF is another kind of invoice under that definition, even when it arrives by email. For the project that means XML-based data and unstructured documents must not be pushed through OCR indiscriminately.
A structured record is validated syntactically and then against business rules. In a hybrid format, the structured part and the human-readable rendering must be handled together, without silently overwriting the XML data from the PDF. A scan needs text recognition and semantic field extraction instead. The two paths converge only after normalization, in a shared model.
Important: being e-invoice capable does not replace invoice verification. A formally readable record can still carry an unknown supplier, an unexpected purchase order, conflicting amounts, or a required approval.
Intake, extraction, and normalization
A mailbox is a delivery route, not a controlled intake. Define which addresses, portals, uploads, and interfaces are accepted, which channel is authoritative, and what rules each source has for file type, size, malware scanning, unreadable files, and repeated delivery. A document must not disappear because a parser could not open it. On first successful receipt, an immutable source reference and an internal operation identifier are created.
Classification then decides whether an intake is an invoice at all and which parser applies. For every relevant field, keep the raw value, the normalized value, the evidence location, the parser version, and the confidence. A person can then see why the system accepted an amount, and a correction creates a traceable decision instead of overwriting the original proposal.
Normalization translates XML fields, extraction output, and portal metadata into one shared internal model. Currencies, dates, tax details, supplier identifiers, and line numbers need unambiguous types; empty values stay empty rather than being filled from assumptions. The model must not grow into the largest conceivable schema: a field with no business use is maintenance and data-protection load.
Deterministic validation and human approval
An extraction can look highly confident and still be wrong. The supplier name may be read correctly yet match no active creditor, the total may be right while the tax components conflict, and an invoice number may already exist in the target system. After extraction, rules therefore run against authoritative data.
| Check type | Question | Data source | Possible outcome |
|---|---|---|---|
| Extraction signal | How confidently was this value recognized? | Parser or document model | Show the value or flag it for correction |
| Master-data check | Is the supplier unambiguous and active? | Authoritative ERP or accounting | Match, or stop as an exception |
| Duplicate check | Does the same business operation already exist? | Target system and process register | Link, review, or reject |
| Arithmetic check | Do net, tax, and gross agree? | Normalized invoice data | Pass, or report the deviation |
| Order matching | Do order, delivery, and invoice agree? | Purchase order, goods receipt, service record | Continue automatically, or resolve manually |
| Approval rule | Who may take responsibility for this case? | Role and process model | Create a task, or block the handoff |
Human in the loop does not mean somebody retypes every field. A good approval screen shows the source, the proposed data, the checks that passed, the deviations, and the decision expected. The approver must be able to tell whether they are confirming a delivered service, an account assignment, payment details, or only a technical match. Deputies, absence, queries, and rejection are real process states, and an email notification must not become the authoritative status.
Which cases may continue automatically is decided with finance, procurement, audit, and system owners. Unknown suppliers, changed payment details, missing order references, and conflicting tax data are typical candidates for review, but not a universal list. Where an individual tax assessment is required, it belongs with qualified people; an automation project does not replace tax advice.
Handoff, idempotency, and recovery
The handoff is not successful because an HTTP call was sent. It succeeds when the target system has accepted the operation and returned a durable reference. Define in advance whether the target receives a draft, a pre-recorded document, or an approved invoice. Posting period, accounts, cost centres, and tax codes stay with the authoritative system.
When a connection breaks, it is often unclear whether the target processed the write, and a blind retry creates the same document twice. RFC 9110 describes idempotency as the same intended effect for one or several identical requests. Implemented in business terms that means a stable operation identifier, a check of the target state before any repeat, then bounded retries with backoff. Permanent validation errors are not retried.
Anti-pattern: a job runs every minute across all open invoices and resends them as long as no local success flag is set. If the target response is lost once, that pattern produces duplicate effects. The target state must be established before the repeat.
Recovery repeats only the necessary part: after a corrected supplier match, validation runs again without re-reading the original; after a manual approval, the handoff continues without losing earlier decisions. Exceptions are not a leftover pile but their own product path, with a cause, the affected fields, the decisions so far, and the permitted next steps.
Audit trail and monitoring
An audit trail answers more than who clicked save. It connects the document received, the parser output, the normalized values, the rule versions executed, human corrections, approvals, handoff attempts, and the target reference. Corrections stay visible as new events, and access rights separate reading, editing, approving, and administrative intervention.
The current German finance ministry FAQ and the 2025 amendment to the GoBD cover the retention of structured e-invoice data. Which records a specific company must retain for tax purposes needs professional review. The technical consequence is clearer: source format, relevant structured data, and processing evidence must not be replaced by a convenient working copy.
A green server says nothing about invoices stuck in the wrong state. Watch intake failures, unclassifiable documents, validation exceptions, the age of open approvals, handoff errors, retry counters, and cases without an owner. Every alert needs an action: who resolves an unknown supplier, who may check the target state after a timeout and restart the operation? Without those answers, monitoring stays a collection of red numbers.
Standard product, custom integration, or hybrid
Architecture does not follow the most impressive demo. A standard product fits when intake channels, checks, approvals, and target systems largely follow the process the product intends; a custom integration pays off when several systems, your own business rules, or demanding exceptions create a clearly bounded gap. A hybrid often carries furthest, but only with a bounded data model, defined failure cases, an owner, and an exit path settled in both directions. Our software and ERP development therefore starts at process and system boundaries, not at a preferred product.
Rollout and ownership
Do not start with the simplest sample document if it does not represent the later risks. Choose a bounded but representative slice with real formats, known and unknown suppliers, order and non-order cases, credit notes, deviations, and technical failures. Personal test data belongs in a controlled environment. Acceptance criteria come before the pilot: which formats must be readable, which rules stop the operation, when does an ERP handoff count as confirmed, how do you roll back?
A single accuracy rate is not a sufficient acceptance criterion, because one incorrectly transferred critical case can matter more than many correctly recognized routine documents. Every part then needs a named owner: intake channels, document model, master data, validation rules, approval matrix, target integration, monitoring, and data protection. The handover covers the configurations, interface contracts, validation rules, and runbooks defined in the agreed scope; it does not categorically promise every conceivable artifact. On where AI agents help and where they do not, see AI agents in the Mittelstand; the same discipline applied to company knowledge is covered in our overview of RAG.
What the entsorgo reference proves, and what it does not
In the published case on AI-assisted document processing at entsorgo, AI prepares documents, structured validation supports the review, and the team confirms critical steps before a controlled handoff. That reference demonstrates that DUNA can combine document AI with human control and a real business process.
It proves no universal accuracy, no particular vendor, no automatically suitable architecture, and no guaranteed saving. Customer-specific fields, thresholds, routing, volumes, topology, prices, margins, and recovery mechanisms remain unpublished. This article therefore transfers only the general decision method.
Frequently asked questions about invoice processing automation
Does a structured e-invoice still need OCR?
For the structured data part of a valid e-invoice, OCR is not the route, because the relevant data is already machine readable. For plain PDFs, images, and scans, document extraction remains necessary. A dependable intake must therefore recognize both formats and process them separately.
May a high confidence score lead straight to posting?
Not on its own. A confidence score describes the certainty of an extraction, not the business correctness of the invoice. Supplier, invoice number, amounts, tax logic, purchase order, and approval rules need deterministic checks against authoritative data. Which cases then continue automatically must be decided, tested, and monitored as a business matter.
How do you prevent duplicate invoices when a request is retried?
With a stable operation identifier, the duplicate rules of the authoritative system, and an idempotent handoff. The same business operation must resolve to the same outcome on a repeat instead of creating a second record. After a timeout, the target state is checked first, and only then may a bounded retry follow.
Sources and review date
The legal notes are a technical classification, not tax or legal advice. The current official publications and the specific case are authoritative.
