Germany's e-invoice mandate is live. Most companies aren't ready.

Germany's e-invoice mandate is live. Most companies aren't ready.

Germany's B2B e-invoicing requirement went into force on January 1, 2025. It affects every business operating in Germany that buys from other businesses. And in conversations I keep having, most companies either don't know it exists or have the wrong idea about what it requires.

The most common misconception: a PDF invoice emailed to a supplier counts as an electronic invoice. It doesn't.

What a compliant e-invoice actually is

The Jahressteuergesetz 2024 redefined what "electronic invoice" means in German law. A compliant e-invoice must follow the European standard EN 16931 and be machine-readable. That rules out PDFs, scans, Word documents, and Excel files.

Two formats meet the requirements.

XRechnung is pure XML. No PDF layer, no visual presentation. If you open one in a text editor you see markup. It was built for automated processing, not human reading.

ZUGFeRD (version 2.1 or later) is a hybrid. Visually it looks like a normal PDF invoice. But the file contains an embedded XML dataset with all the same structured invoice data. Which means some of your suppliers may already be sending ZUGFeRD invoices without telling you, because the PDF looks exactly the same as it always did.

The timeline

Since January 1, 2025: all businesses must be able to receive e-invoices. This is already in effect.

From January 1, 2027: companies with annual revenue above 800,000 euros must send invoices in a compliant format.

From January 1, 2028: the sending requirement applies to all businesses.

The sending mandate is a few years out for most companies. The receiving mandate is not.

What "capable of receiving" means in practice

There's no legal requirement to use specific software. Being capable of receiving e-invoices means you have a workflow that can handle an XRechnung XML file or a ZUGFeRD-embedded PDF when one arrives.

Technically, you could receive an XRechnung, open it in a viewer, read the values, and type them into your accounting system. That satisfies the letter of the law. It misses the point entirely.

Structured invoice data doesn't need to be read by a human before it enters your accounting system. Vendor name, amounts, IBAN, line items, tax rates are all machine-readable. If your accounting software is configured to handle these formats, it pulls that data in automatically. No one types anything.

What this means for how you process invoices

Processing a supplier invoice today typically looks like this: someone opens a PDF, reads the amounts, types them into the accounting system, checks against an order, and files the document. Ten to fifteen minutes per invoice in a reasonably efficient setup.

Structured invoice data changes that flow. A configured system receives the file, extracts the fields, pre-populates the accounting record, and can match it against open purchase orders before a human ever looks at it. Manual work shifts to exceptions, the invoices where something doesn't add up.

I've worked with clients who cut invoice processing time by more than half after getting this right. Not through any sophisticated AI. Just by stopping the manual re-entry of data that was already machine-readable.

What to check in your current setup

First: can your accounting system actually receive XRechnung and ZUGFeRD? Not in theory. Test it with a real file. Sample XRechnung files are freely available online. Most standard systems, DATEV, SAP, Lexoffice, Sage, support these formats already, but the feature often needs to be activated and configured. Turned on isn't the same as working.

Second: where do invoices arrive right now? A shared email inbox? Someone's personal inbox? Directly into the accounting system? Technical receiving capability only matters if the file reaches a place where it can be processed.

Third: how are you archiving invoices? E-invoices must be stored in a tamper-proof format, the same legal standard as paper invoices. Saving files to a network folder usually doesn't qualify. Most compliant accounting software handles this automatically, but worth verifying.

Who already has to send XRechnung

For private B2B invoicing, the sending mandate is 2027 or 2028. Public-sector clients are a different situation.

If you invoice German federal agencies, state governments, or many municipalities, XRechnung is often required today, via the federal receiving platform ZRE or through PEPPOL. This gets missed by companies that mostly work with private clients and only occasionally handle public contracts.

Why getting this right pays off

Treating e-invoicing as a pure compliance exercise is the most expensive approach.

If you receive structured invoice data and still process invoices by hand, you paid for the transition and got nothing from it. The actual value is the automation the format makes possible. Most companies running manual invoice processes have been doing it the same way for years. The mandate is an unusually good reason to finally change that.

Start with the basics: receiving works, data lands in your accounting system automatically, archiving is compliant. That's a real improvement on its own. From there you can layer in purchase order matching, automated approval routing below a threshold, and whatever else fits your workflow.

The law is the starting point. The benefit is a process that doesn't depend on someone typing numbers from one system into another.

If you want to map out what this looks like for your specific setup and where the biggest leverage is, the free Automations Check covers that in 30 minutes.