E-Rechnung 2025: What Every German B2B Company Must Do Now

Definition

E-Rechnung (electronic invoice) in Germany means a structured, machine-readable invoice: not a scanned PDF or image. Compliant formats include XRechnung (EN 16931 XML) and ZUGFeRD/Factur-X (PDF with embedded XML). The Wachstumschancengesetz phased mandate requires German B2B companies to receive structured invoices now and issue them on a rolling schedule through 2028.

Why It Matters Now

The compliance window is narrower than most finance teams realize. Receiving capability was mandatory from January 2025. Issuance deadlines follow turnover thresholds: large companies first, then the Mittelstand. Companies that treat this as a PDF problem will fail audits, delay payment cycles, and break ERP integrations.

The operational impact extends beyond legal compliance. Structured invoices enable straight-through processing: automatic matching against POs, faster approval workflows, and direct DATEV import without manual data entry. Companies that implement E-Rechnung properly reduce AP processing cost by 60–80% per invoice.

Format Decision Matrix

Most Mittelstand companies should standardize on ZUGFeRD 2.1 EN 16931 for outbound invoices and accept both XRechnung and ZUGFeRD inbound.

Technical Architecture

Billing System → Invoice Generator → Validation (KoSIT) → Delivery
       ↓                                      ↓
   Stripe/ERP                          Peppol / Email / Portal
       ↓
   DATEV Export (CSV/XML)

Outbound Invoice Generation

Your billing system must emit structured data, not just render PDFs. Here is a minimal Node.js example using @e-invoice-eu/core patterns:

const { createZugferdInvoice } = require('./invoice-builder');

async function generateInvoice(billingEvent) {
  const invoice = {
    invoiceNumber: billingEvent.number,
    issueDate: billingEvent.created,
    seller: {
      name: 'Muster GmbH',
      vatId: 'DE123456789',
      address: { street: 'Mainzer Landstraße 1', city: 'Frankfurt', postalCode: '60329', country: 'DE' }
    },
    buyer: {
      name: billingEvent.customer.name,
      vatId: billingEvent.customer.taxId,
      address: billingEvent.customer.address
    },
    lineItems: billingEvent.lines.map(line => ({
      description: line.description,
      quantity: line.quantity,
      unitPrice: line.unitAmount / 100,
      taxRate: line.taxRate,
      taxCategory: 'S' // Standard rate
    })),
    paymentTerms: { dueDate: billingEvent.dueDate, iban: 'DE89370400440532013000' }
  };

  const zugferdPdf = await createZugferdInvoice(invoice);
  await validateAgainstKoSIT(zugferdPdf);
  return zugferdPdf;
}

Validation Before Send

Every outbound invoice must pass KoSIT validation. Run validation in CI/CD, not just at send time:

# Using KoSIT validation tool
java -jar validationtool-1.5.0-standalone.jar \
  -s scenarios.xml \
  -o validation-report \
  -h invoice.xml

Reject and quarantine invoices that fail validation. Sending invalid structured invoices creates liability and breaks recipient AP automation.

Inbound Processing

Receiving E-Rechnungen requires an intake pipeline, not an email inbox:

1. Intake channel: Peppol Access Point, dedicated email (ZUGFeRD attachments), or supplier portal
2. Format detection: Identify XRechnung XML vs ZUGFeRD embedded XML
3. Validation: KoSIT rules + business rules (VAT ID, PO match)
4. ERP import: Map to DATEV/Lexware/SAP fields
5. Archive: GoBD-compliant storage with hash verification

import xml.etree.ElementTree as ET
from pypdf import PdfReader

def extract_invoice_data(file_path, mime_type):
    if mime_type == 'application/xml':
        return parse_xrechnung(ET.parse(file_path).getroot())
    elif mime_type == 'application/pdf':
        reader = PdfReader(file_path)
        embedded = reader.attachments.get('ZUGFeRD-invoice.xml')
        if embedded:
            return parse_zugferd(ET.fromstring(embedded[0]))
    raise ValueError(f'Unsupported format: {mime_type}')

DATEV Integration

DATEV Unternehmen online accepts structured invoice data via DATEVconnect or CSV import. Map these fields precisely:

Export from your invoice store nightly. Do not rely on manual CSV creation: field mismatches cause DATEV import failures that block month-end close.

Stripe and SaaS Billing Gap

Stripe Invoicing, Chargebee, and most SaaS billing tools output PDF invoices. None produce compliant XRechnung or ZUGFeRD natively as of 2026. Your options:

• Middleware: Tools like InvoicePortal, Storecove, or custom Node/Python services
• ERP-first: Generate invoices in Lexware/DATEV and sync payment status back to Stripe
• Hybrid: Stripe handles payment collection; ERP generates compliant invoice on invoice.finalized webhook

// Stripe webhook handler
app.post('/webhooks/stripe', async (req, res) => {
  const event = stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], secret);
  if (event.type === 'invoice.finalized') {
    const stripeInvoice = event.data.object;
    await erpService.createEInvoice({
      externalId: stripeInvoice.id,
      customerId: stripeInvoice.customer,
      lines: stripeInvoice.lines.data,
      tax: stripeInvoice.tax
    });
  }
  res.sendStatus(200);
});

Implementation Checklist

1. Audit current invoice flow: Map every outbound and inbound path
2. Choose formats: ZUGFeRD 2.1 for B2B outbound; accept XRechnung + ZUGFeRD inbound
3. Select validation tooling: KoSIT validator in CI pipeline
4. Build or buy generation layer: Do not depend on PDF-only billing
5. Connect DATEV/ERP: Automated import, not manual re-keying
6. Train AP team: Structured invoices skip manual entry: update approval workflows
7. Test with top 10 vendors/customers: Validate end-to-end before mandate deadlines

Common Mistakes

• Sending PDF invoices labeled as "E-Rechnung": a PDF without embedded XML is not compliant
• Skipping KoSIT validation and discovering failures at the recipient
• Building intake as email-only without format detection
• Ignoring reverse charge and intra-EU VAT rules in structured fields (BT-151 tax category codes)
• Storing invoices without GoBD-compliant immutability (timestamped, hash-verified archives)

Peppol and Cross-Border Delivery

For customers requiring Peppol delivery (increasingly common with large German enterprises), register as a Peppol participant or use a certified Access Point provider. Peppol wraps XRechnung-compatible UBL documents for network delivery:

async function deliverViaPeppol(invoice, recipientPeppolId) {
  const ublDocument = convertToUbl(invoice);
  await peppolAccessPoint.send({
    document: ublDocument,
    recipientId: recipientPeppolId, // e.g. '9930:DE123456789'
    processId: 'urn:fdc:peppol.eu:2017:poacc:billing:01:1.0',
    documentType: 'urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'
  });
}

Maintain a registry mapping customer VAT IDs to Peppol endpoint IDs. Not every B2B customer uses Peppol, but enterprise procurement portals increasingly require it.

Timeline and Enforcement

BaFin and tax authorities focus initially on public sector and large enterprise compliance. Mittelstand enforcement ramps through 2027–2028. Early implementation avoids rushed vendor selection and untested integrations under deadline pressure.

Business Outcomes

Companies that implement E-Rechnung as structured data infrastructure: not a compliance checkbox: reduce invoice processing time from 15 minutes to under 2 minutes per document, eliminate manual DATEV entry errors, and accelerate month-end close by 2–3 days.

Related: DATEV Integration with Stripe · E-Rechnung integration