Since 1 January 2025, every company in Germany has to be able to receive e-invoices. Formally that is easy: an email inbox will do. But nothing has been processed at that point: the structured XML goes unread, accounting retypes the visible PDF, and the whole point of e-invoicing is lost. My field report after one year of the receiving mandate shows how common this pattern is.
I set up the receiving process so that structured invoice data is validated, archived in line with GoBD (the German rules for audit-proof bookkeeping) and posted without retyping. The consulting works with the systems you already run; in parallel I am building an e-invoicing middleware that automates this document flow, demo appointment on request.
Receiving means processing
GoBD requires you to retain the original digital format. For an e-invoice that is the XML file, not the PDF view. Archiving only the PDF creates a compliance issue on top of the extra work. Validation belongs before posting: mandatory fields, tax categories and format conformity get checked so that broken files go back to the sender instead of into manual rework.
What I set up in practice
- An inbound channel with format detection for XRechnung and the ZUGFeRD profiles
- Validation of the structured data before posting
- GoBD-compliant archiving of XML and PDF together
- Handover to ERP and accounting, including automated account assignment
- The return path from DATEV, so ERP and tax advisor stay in sync
The return path: finalized posting batches from DATEV
Processing does not end at the handover to the tax firm. The DATEV integration whitepaper documents the way back: scheduled synchronization of finalized posting batches from DATEV into the ERP, with automatic document creation. The ERP then knows what was actually booked, and differences between ERP reports and DATEV totals become visible before your tax advisor asks about them.
How receiving fits into the full path from document to posting batch is laid out on the E-Invoicing & DATEV overview.