E-Invoicing in Germany: What Developers Need to Know (2027 Deadline)

If you build software for the German market, you need to know about e-invoicing. Germany is rolling out mandatory electronic invoicing for all B2B transactions, and the deadlines are closer than you think.

This article covers the technical side: what formats you need to support, how they work, and what tools are available.

The Timeline

Date	Requirement
Jan 1, 2025	All businesses must be able to receive e-invoices
Jan 1, 2027	Businesses with >800K EUR revenue must send e-invoices
Jan 1, 2028	All businesses must send e-invoices

"E-invoice" means structured, machine-readable data. A PDF attached to an email is NOT an e-invoice, even if it looks like one.

The Two Formats

XRechnung

Standard: CIUS (Core Invoice Usage Specification) based on EN 16931
Syntax: UBL 2.1 (Universal Business Language) or CII
Use case: Primarily B2G (business to government), increasingly B2B
Current version: 3.0.2

An XRechnung is a pure XML file. No visual representation -- just data. Government portals (ZRE, OZG-RE) require this format.

Example structure (simplified):

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <ID>RE-2026-0042</ID>
  <IssueDate>2026-03-18</IssueDate>
  <InvoiceTypeCode>380</InvoiceTypeCode>
  <DocumentCurrencyCode>EUR</DocumentCurrencyCode>
  <BuyerReference>04011000-12345-67</BuyerReference>
  <AccountingSupplierParty>
    <Party>
      <PartyName><Name>Beispiel GmbH</Name></PartyName>
    </Party>
  </AccountingSupplierParty>
  <LegalMonetaryTotal>
    <TaxExclusiveAmount currencyID="EUR">1500.00</TaxExclusiveAmount>
    <TaxInclusiveAmount currencyID="EUR">1785.00</TaxInclusiveAmount>
    <PayableAmount currencyID="EUR">1785.00</PayableAmount>
  </LegalMonetaryTotal>
</Invoice>

ZUGFeRD / Factur-X

Standard: Based on EN 16931, using CII (Cross Industry Invoice) syntax
Container: PDF/A-3 with embedded XML
Use case: B2B (universal), human-readable AND machine-readable
Current version: 2.3

ZUGFeRD is the pragmatic format. It looks like a normal PDF to humans (you can print it, email it, archive it), but it contains a hidden XML file (factur-x.xml) with all the structured data. Software can extract and process the XML automatically.

Profiles (from least to most data):

Minimum -- Invoice number, date, amounts only
Basic WL -- Basic without line items
Basic -- With line items
EN16931 -- Full EN 16931 compliance (recommended)
Extended -- Additional fields beyond the standard

Factur-X is the French name for the same standard. ZUGFeRD 2.3 = Factur-X 1.0.06.

Key Technical Challenges

Different XML Trees for the Same Data

UBL and CII represent the same invoice data in completely different XML structures. If you need to support both, you need separate builders/parsers or an internal format that maps to both.

Example -- Seller name:

UBL: Invoice > AccountingSupplierParty > Party > PartyName > Name
CII: CrossIndustryInvoice > SupplyChainTradeTransaction > ApplicableHeaderTradeAgreement > SellerTradeParty > Name

German Business Rules (BR-DE)

On top of EN 16931, Germany adds its own rules. The important ones:

Rule	What it checks
BR-DE-01	Payment instructions must be present
BR-DE-02	Bank account required for bank transfers
BR-DE-03	Seller must have email
BR-DE-07	Seller must have VAT ID or tax number
BR-DE-13	Buyer Reference (BT-10) is mandatory
BR-DE-14	Tax rate must be > 0 for standard category
BR-DE-17	German VAT ID format validation
BR-DE-18	IBAN format validation

Full list: KoSIT XRechnung Schematron rules

PDF/A-3 for ZUGFeRD

Creating a ZUGFeRD PDF means:

Generate a visual PDF (the human-readable invoice)
Convert it to PDF/A-3 (add ICC color profile, XMP metadata)
Embed the CII XML as a file attachment named factur-x.xml
Add Factur-X metadata to the XMP

This is harder than it sounds. Many PDF libraries don't support PDF/A-3 properly. In JavaScript, pdf-lib handles it but requires manual metadata management.

Validation

The official validation tool is the KoSIT Validator (Java). For production use, you might want:

XML well-formedness check
XSD schema validation
Schematron business rule validation (the BR-DE rules)

Running full Schematron validation in JavaScript is non-trivial. Pragmatic approach: implement the 20 most common rules as code, defer full Schematron to Phase 2.

Tools and Libraries

For JavaScript/TypeScript

fast-xml-parser -- Parse and build XML without native dependencies
pdf-lib -- Create and modify PDFs (including PDF/A-3), pure JavaScript
einvoice-mcp -- MCP server with 6 tools for XRechnung/ZUGFeRD (MIT, npm)

For Python

factur-x -- Official Factur-X library (ZUGFeRD PDF creation)
xrechnung-python -- XRechnung generation

For Java

KoSIT Validator -- Official validation tool
mustangproject -- ZUGFeRD/Factur-X library

Official Resources

What You Should Do Now

If you're building invoicing software for the German market:

Start with receiving: Parse incoming XRechnung (UBL) and ZUGFeRD (CII + PDF) -- extract the structured data
Add validation: At minimum, check the BR-DE rules
Build sending: Generate valid XML, test against the KoSIT test suite
Prepare for PDF/A-3: If you need ZUGFeRD, budget time for PDF/A compliance

The 2027 deadline is 9 months away. If your software handles German invoices, this isn't optional anymore.

I built einvoice-mcp to make this easier. It's an open-source MCP server that handles XRechnung and ZUGFeRD creation, validation, and conversion. MIT licensed, no native dependencies, runs anywhere Node.js runs.

Questions? Find me on GitHub.