Germany’s e-invoicing rules were supposed to end manual invoice handling. The promise was simple: structured data in, automated posting out. Yet in many AP departments running SAP, someone still opens the invoice, checks the numbers by eye and keys in corrections. If that sounds familiar, you are not behind.
This article explains why e-invoices still end up in manual review, even in well-run SAP landscapes, and what it takes to actually remove that manual step.
The obligation is already here
The legal pressure is not a future problem. Since 1 January 2025, domestic businesses in Germany must be able to receive e-invoices. From 1 January 2027, businesses with prior-year turnover above EUR 800,000 must also issue them for in-scope domestic B2B transactions. From 2028, the remaining general transition period ends, subject to statutory exceptions, including the issuing exemption for small businesses under the Kleinunternehmer rules.
A plain PDF without structured invoice data does not count as an e-invoice under the new definition; it is a so-called other invoice. Receiving a PDF by email may still happen under applicable transitional rules and exceptions, but it is not the same as receiving a structured e-invoice. Treating the two identically is the root of many process problems.
XRechnung and ZUGFeRD: two formats, two behaviours
Both formats can support invoices compliant with the European standard EN 16931, but they arrive in very different shapes, and that matters for your SAP invoice receipt. The ZUGFeRD version and profile used must meet the applicable requirements.
XRechnung is a pure XML document. There is no built-in PDF layout. A human cannot simply open it and read it the way they read a PDF, so a team without suitable viewing tools has no practical way to check it.
ZUGFeRD is a hybrid. It is a PDF/A-3 file with embedded XML. The visible PDF and the embedded data should match, but inconsistencies can occur. This is a classic source of manual review: an AP clerk reads the PDF, the system reads the XML, and the two disagree.
Most companies receive both formats at once, plus the occasional legacy PDF. Your process has to handle all three.
Why manual review persists in SAP
1. The XML is received but not truly used. Many setups store the incoming file and display the PDF layer to the clerk, while the structured data sits unused. The invoice is technically an e-invoice, but the workflow is still the old paper one. Manual keying survives because the structured data never feeds the posting.
2. Nobody validates the invoice before it enters SAP. To validate an e-invoice properly, you need to check the XML against the schema and the EN 16931 business rules, confirm mandatory fields, and verify tax and totals logic. If this happens late, or only inside the ERP, errors surface as confusing posting failures rather than clear rejection reasons. The clerk then investigates by hand.
3. Master data does not match. An e-invoice carries a supplier’s VAT ID, bank details and address exactly as the sender entered them. If your vendor master differs by a character, automatic matching may fail and the invoice lands in an exception queue. The invoice is fine; the mapping is not.
4. PO and goods receipt matching breaks on small differences. Missing or malformed order references, rounding differences between line and total amounts, and unit-of-measure mismatches all push otherwise valid invoices into manual clearing. Structured data makes these mismatches easier to detect, but only if matching rules are tuned to use it.
5. Mapping XML to SAP fields is incomplete. Handling XML invoice data in SAP means mapping many data elements: tax categories, allowances and charges, payment terms, buyer references. Partial mappings work for the standard case and fail on anything else, such as credit notes, advance payments or mixed tax rates. Those exceptions are exactly what clerks end up reviewing.
6. Trust is low, so people check anyway. Even when automation works, teams keep reviewing because no one can see why an invoice passed. Without a clear validation result and audit trail, manual review becomes a safety habit rather than a necessity.
7. Archiving and audit questions remain open. The original structured file must be kept, and auditors will ask for it. German VAT law generally requires invoices to be retained for eight years under §14b UStG; the structured component must be preserved in its original form, with GoBD requirements observed. When the archive process is unclear, teams hold on to manual checks as a form of insurance.
What actually removes the manual step
Moving from manual review to straight-through processing is less about buying another tool and more about fixing the sequence of steps.
Validate first, post second. Check every incoming file at the door, before it touches your accounting data. Give rejected invoices a clear, human-readable reason and route them back to the sender.
Use the structured data as the source of truth. For ZUGFeRD, compare the embedded XML with the visible PDF and flag mismatches automatically, rather than asking a clerk to spot them.
Clean the vendor master. Align VAT IDs, bank details and addresses so that automatic supplier matching succeeds on valid invoices.
Extend your mappings beyond the standard case. Test credit notes, corrections, advance invoices and multi-rate invoices before they arrive in volume.
Make validation visible. When AP can see that an invoice passed schema, business-rule and tax checks, the instinct to re-check by hand fades.
Close the loop with archiving. Store the original XML alongside the posted document so audit requests do not trigger a manual hunt.
A quick self-check
Ask your team three questions. What share of incoming e-invoices is posted without anyone opening them? Where do rejected invoices go, and who sees them? Can you show an auditor the original XML for any invoice in seconds? If the answers are “we don’t know”, the manual review is not caused by the invoices. It is caused by missing visibility.
See it working on your own invoices
If you want to find out where your SAP invoice receipt loses automation, a short walkthrough with your real XRechnung and ZUGFeRD files is the fastest way. Book a demo with Docnova and we will show you validation, matching and exception handling on your own invoice samples.
For invoice processing inside SAP ECC and SAP S/4HANA, explore the Add-on de Melasoft SAP e-invoicing.
Source for German VAT invoicing and retention requirements: Federal Ministry of Finance e-invoicing FAQ.