Invoice processing sounds like one task but it is a chain. It starts with a document that arrives one of the usual ways: a PDF in the inbox, paper in the scanner, an attachment from a portal. It should end with a clean posting in the finance system, approved and traceable. In between lie five steps, and each can trip on its own.

Capture means receiving the document and assigning it to the right transaction. Extraction pulls out the relevant fields: supplier, invoice number, date, net, tax, line items. Validation matches these values against what is expected, usually against the purchase order and the goods receipt. Posting writes the result into the system in a structured way. Escalation catches everything that does not run through cleanly. Automate only one of these steps and leave the rest by hand, and you move the work rather than save it.

The first reflex is to automate extraction, because the typing is the visible annoyance. The real time sits elsewhere. It sits in the matching. Does the amount on the invoice match the order? Was the goods really delivered? Do the tax, the cost centre, the supplier fit? This three-way match between invoice, order and goods receipt is the step where people burn the most time, and it is at the same time the step that is easiest to put into rules.

That is the real message. Once the fields are reliably extracted, the match is pure logic: let equal values through, flag deviations. That is where the biggest lever sits, and it needs no judgement call, just clear rules and a defined tolerance.

The bottleneck in invoice processing is rarely the reading. It is the matching, and that is the cleanest part to automate.

An invoice flow that reads and validates but does not bring the result into the accounting system is half a solution. This is exactly where real value is decided. In the German mid-market the path almost always runs through DATEV or a connected finance system. If the checked document lands there in structured form, with a posting record, a document image and an approval note, the flow really does save work. If what remains at the end is an export someone reads in by hand, all you built is a new intermediate station.

A clean connection means: master data matches, the coding logic is set, the document is archived in an audit-proof way, and the return path works too. When accounting rejects an invoice, that information has to flow back into the process, not vanish in a separate inbox. Without that return channel you get exactly the silo that process automation is meant to avoid.

Every honest invoice automation is measured on its exceptions, not on its normal cases. The new supplier without master data, the invoice without an order reference, the amount just over tolerance, the duplicate submission: these are not edge cases, they are the everyday. A good flow spots these cases, holds them and presents them to a specialist with the needed context, instead of silently booking them through.

That is why every productive invoice flow needs a defined point for human control. Not every invoice, but exactly those where the check is uncertain. Human in the loop here means: the flow does the groundwork, the person decides the doubtful cases, and every decision flows back so the next similar case runs smoother. A flow with no clean exception path is not an automated invoice process, it is a risk with a user interface.

This table sets each step against the manual flow and an automated variant with a control point, so the difference becomes concrete.

Walk the flow once from document to posting and answer these questions. Where you get stuck sits the spot that decides the value, and before any budget flows.

• Through which channels do your invoices arrive today, and how many layouts are really in circulation?
• What is checked against, the order, the goods receipt, an approval workflow, and with what tolerance?
• What does the connection to DATEV or your finance system look like, in both directions?
• What is a true exception, and who decides it with what context?
• Who watches hit rate, rework and cost after launch?

Core sentence: automating invoice processing does not mean replacing the typing but putting the matching into rules, connecting the posting and giving the exceptions a clean path.

Extraction is the actual automation.

Extraction is the visible part but rarely the expensive one. The manual time sits in the matching and in resolving deviations. Automate only the extraction and you move the work one step back.

Once the invoice is read, the case is done.

Between a read document and a clean posting lie matching, approval, connection and exception handling. That is exactly where it is decided whether the flow holds in operation.

Document extraction, Intelligent document processing (IDP), Exception handling, Human in the loop.

Does invoice automation need AI, or is classic recognition enough?

For matching and posting, fixed rules are enough. AI helps with extraction once the layouts vary and rigid templates keep breaking. If your document flow is very uniform, you often manage without an AI step.

How confident must recognition be before posting?

Not every invoice needs the same confidence. A sensible approach is a threshold: above the line the posting runs through, below it the case goes to a specialist. You set that line on the real document flow, not on a blanket number.

Do I have to replace my existing DATEV connection?

As a rule, no. Usually the invoice flow is placed in front, checks and structures, then hands over to the existing accounting. The return channel for rejections matters more than a new system.

No external market figures or unapproved client results are asserted. Connection, tolerances and approval logic are checked against the real stack before implementation.