DEV Community

MaKriRich
MaKriRich

Posted on

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

#backend #developers #news #softwaredevelopment

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>
Enter fullscreen mode Exit fullscreen mode

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):

  1. Minimum -- Invoice number, date, amounts only
  2. Basic WL -- Basic without line items
  3. Basic -- With line items
  4. EN16931 -- Full EN 16931 compliance (recommended)
  5. 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:

  1. Generate a visual PDF (the human-readable invoice)
  2. Convert it to PDF/A-3 (add ICC color profile, XMP metadata)
  3. Embed the CII XML as a file attachment named factur-x.xml
  4. 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:

  1. XML well-formedness check
  2. XSD schema validation
  3. 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:

  1. Start with receiving: Parse incoming XRechnung (UBL) and ZUGFeRD (CII + PDF) -- extract the structured data
  2. Add validation: At minimum, check the BR-DE rules
  3. Build sending: Generate valid XML, test against the KoSIT test suite
  4. 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.

Top comments (0)