E-Invoicing Becomes Mandatory in 2027: What Your Custom Software Must Support

If your company runs on a custom ERP, a homegrown web shop, or a client portal that generates its own invoices, 2027 is the year the German government stops treating e-invoicing as optional. From January 1, 2027, domestic B2B companies with more than 800,000 EUR in turnover during 2026 must issue electronic invoices in a structured, machine-readable format. A PDF attached to an email no longer satisfies the rule, even if a person can open it and read every line. Every company follows by January 1, 2028, and receiving e-invoices has already been required since 2025 under the Growth Opportunities Act. The obligation comes from the Federal Ministry of Finance, confirmed in the IHK's guidance to member businesses, and it applies no matter whether your invoices come out of SAP, a boutique ERP a contractor built five years ago, or a checkout flow in a custom web shop.

For a company on off-the-shelf accounting software, this is mostly the vendor's problem to solve. For a company whose invoicing runs through custom software, it is squarely yours, and the deadline is close enough that figuring it out later is no longer a safe plan.

What Germany means by e-invoicing in 2027

German law defines an e-invoice using the EN 16931 data model, a European standard that specifies which fields an invoice must carry (buyer and seller identifiers, tax breakdown, payment terms, line items) and how they're structured so a machine can read them without a person re-typing anything into accounting software. A well-formatted PDF, even a nice one with your logo and clean line items, fails this test, because there's no structured data layer underneath it for the recipient's system to parse.

Two formats satisfy EN 16931 in Germany: XRechnung and ZUGFeRD. XRechnung is a pure XML format, the one most government agencies have required for public contracts for years. ZUGFeRD is a hybrid: an ordinary, human-readable PDF with an XML file embedded inside it. Open the PDF and a person sees an invoice. Feed the same file to accounting software and it reads the embedded XML.

XRechnung vs ZUGFeRD: picking the right format

For most B2B companies, ZUGFeRD in its Comfort or Extended profile is the more practical choice. Business partners who aren't ready to parse XML can still open and read the PDF, while your e-invoicing obligation is met underneath it. XRechnung tends to make more sense when a partner, especially a public sector client, specifically requires it, since that's the format most German public contracts already expect.

Either choice depends on who you invoice, not just on which format sounds more modern. A construction firm billing mostly public clients has a different answer than a SaaS company billing other businesses directly.

Validation, archiving, and transmission: the parts owners forget

Generating a file that looks like an XRechnung or ZUGFeRD invoice is not the same as generating one that passes validation. KoSIT, the German coordination office for IT standards, publishes an official validator, and invoices should be checked against it before they go out, not assumed correct because a library's documentation says it's EN 16931 compliant. A missing tax ID field or a malformed date can fail validation on the recipient's side even though the invoice opens fine on yours.

Archiving is the part that gets skipped most often. Under GoBD, Germany's rules for digital bookkeeping, invoices must be stored for eight to ten years in their original, unaltered format. For ZUGFeRD, that means keeping the exact PDF and embedded XML as generated, not a re-rendered copy made later for a client portal. If your current system archives invoices as flattened images or regenerates them on demand, that process needs to change before the deadline, not after an audit flags it.

Transmission is what fewest owners think about. Email with the invoice attached still works for most domestic B2B relationships. But Peppol, the pan-European exchange network, is increasingly the expected channel for public sector and cross-border invoicing, and some larger customers are starting to ask suppliers to send through it rather than by email. It's worth asking your biggest accounts now whether they expect Peppol, because that changes the integration work considerably.

Library, service, or build it yourself

Once the format question is settled, there are three realistic paths for a custom ERP, web shop, or portal.

A dedicated library for your stack handles XML generation and EN 16931 validation in code you integrate directly. For PHP and Symfony applications, this is usually the cheapest path if your invoice data is already reasonably structured, since the library does the format translation and you supply the data mapping. The ongoing cost is keeping the library updated as the standard evolves, which has already happened more than once.

An external invoicing or compliance service takes the data you send it over an API and returns a validated XRechnung or ZUGFeRD file, sometimes handling archiving and Peppol transmission too. It costs more per invoice or per month, but it removes most of the engineering burden, which can make sense for a smaller team or a company that wants one less compliance surface to own internally.

Building the whole thing yourself, generation and validation included, only makes sense at real invoice volume, where the per-invoice cost of a service adds up fast and you already have engineering capacity to track changes to the standard. For most mid-size companies with custom software, this is the option to avoid, since the specification keeps moving and nobody wants to maintain that alone.

Realistic effort and timeline

If your invoicing data is already structured, meaning clean customer records, proper tax fields, and line items that aren't just a text blob, integrating a library or a service is typically a few weeks of work: mapping existing fields to the EN 16931 schema, wiring in generation and validation, testing against the KoSIT validator, and setting up archiving that keeps the original file instead of a flattened copy.

If your invoice data is messy, if tax handling is inconsistent across products, or if the system was never designed with structured line items in mind, the data cleanup can take longer than the e-invoicing integration itself. That's worth finding out now rather than in December 2026. A short codebase assessment is usually enough to tell you which situation you're actually in before committing to a format or a vendor.

If the system in question is one you're already unsure about keeping long-term, this is also a reasonable moment to have the harder conversation about whether to patch the current ERP for compliance or replace it with something built properly. And if you're mid-decision and just need the current system to keep working correctly while you figure that out, legacy software support covers exactly that gap without committing you to either direction yet.

A checklist to forward to your developer

Before the deadline gets close, ask whoever maintains your invoicing system to confirm, in writing, which format they plan to generate, XRechnung or ZUGFeRD, and why it fits your customers. Ask whether invoices will be validated against the official KoSIT validator before sending, and how often that check runs. Ask where and in what format invoices will be archived, and whether that setup actually satisfies the eight to ten year GoBD retention rule rather than just storing a copy somewhere. Ask whether any current or likely future customers expect Peppol transmission. And ask for a realistic timeline and cost to get from where you are now to compliant, given the actual state of your invoice data, not the state you assume it's in.

If the answers come back vague, or if nobody on your team can answer them with confidence, that's worth addressing well before January 2027, not after an invoice bounces back from a customer's accounting system with a validation error nobody can explain.

Wolf-Tech works with companies on exactly this kind of integration, fitting e-invoicing compliance into custom ERPs, web shops, and client portals without forcing a rebuild. If you want a second opinion on where your system stands, reach out at hello@wolf-tech.io or see wolf-tech.io for more on how we approach this kind of work.