Germany e-invoicing mandate (2025–2028): the XRechnung & ZUGFeRD API for the document itself

Germany's B2B E-Rechnung obligation, introduced by the Wachstumschancengesetz, is already in force: since January 1, 2025 every business established in Germany must be able to receive a structured e-invoice, and the issuing obligation phases in through 2027–2028. The format behind it — EN 16931, carried as XRechnung or ZUGFeRD/Factur-X — is a semantic standard with hundreds of business rules. Slipstack turns that document into the same JSON call you already use for PDF invoices, and validates it against the official core rules before it leaves your system.

The timeline, plainly

• January 1, 2025 — every business established in Germany must be able to receive and process structured EN 16931 e-invoices for domestic B2B transactions. There is no transition period for the receiving capability.
• Through December 31, 2026 — a transition window for issuing: paper and other electronic formats (e.g. a plain PDF) may still be sent, with the recipient's agreement for non-structured formats.
• January 1, 2027 — businesses with prior-year turnover above €800,000 must issue structured e-invoices for domestic B2B.
• January 1, 2028 — the issuing obligation extends to all remaining domestic B2B businesses, and EDI procedures must conform to EN 16931.
• Germany's model is decentralized — there is no PPF/SDI-style hub. Always confirm the live obligations with your tax advisor and the Bundesministerium der Finanzen — Slipstack tracks the document format, not your filing status.

Generate: one endpoint, the German formats

• facturx-pdf — your invoice PDF with the CII XML embedded as factur-x.xml (Factur-X BASIC profile guideline). This is the same hybrid container as ZUGFeRD 2.x — human-readable and machine-readable in one file, the approach Germany and France share.
• xrechnung-cii — standalone UN/CEFACT Cross-Industry Invoice XML, when your buyer or public-sector recipient wants pure structured XML (XRechnung) rather than the hybrid PDF.

// ZUGFeRD / Factur-X hybrid PDF (PDF + embedded CII XML) from plain JSON
const res = await fetch("https://slipstack.dev/api/v1/einvoice", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.SLIPSTACK_KEY}`, // Pro plan
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    options: { format: "facturx-pdf" }, // or "xrechnung-cii" for standalone XML
    data: {
      from: {
        name: "Werkstatt Brandt GmbH",
        countryCode: "DE",              // required for e-invoices
        vatId: "DE123456789",           // required when taxRate > 0
        address: "Friedrichstraße 12",
        city: "Berlin", postalCode: "10117",
      },
      to: { name: "Nordlicht Handels AG", countryCode: "DE", vatId: "DE811569869" },
      number: "RE-2027-0042",
      date: "2027-01-04",
      dueDate: "2027-02-03",
      currency: "EUR",
      items: [{ description: "Beratungsleistung", quantity: 8, unitPrice: 120 }],
      taxRate: 19,
      paymentIban: "DE89370400440532013000",
      paymentReference: "RE-2027-0042",
    },
  }),
});

Validate before you send — free, no account

Whether you build the XML with Slipstack or with your own code, you can check it against the official EN 16931 core schematron (ConnectingEurope release v1.3.16) with the free EN 16931 / XRechnung core validator — paste or upload CII or UBL, up to 20 checks a day, no signup.

Scope, stated plainly: the validator checks the EN 16931 core rules (schematron v1.3.16). It does not check the KoSIT XRechnung CIUS or Peppol BIS rules — stricter supersets that German public-sector recipients may require — and it does not validate XSD structure. The ZUGFeRD/Factur-X hybrid PDF is labeled facturx-hybrid (beta): the embedded XML, attachment wiring and XMP are spec-correct, but the container is not a certified PDF/A-3 file. For strict conformance, use xrechnung-cii XML today.

Parse inbound invoices back to JSON

The 2025 receiving obligation means structured invoices will arrive whether or not you issue them yet. Slipstack's parse endpoint turns inbound XRechnung CII or UBL XML back into clean JSON on any paid plan — so your accounting code reads one shape regardless of which format a supplier sent. (Accepting the file into your system is your ERP's job; Slipstack reads the document once you have it.)

For agents: it's on the MCP server too

The Slipstack MCP server exposes create_einvoice_xml and parse_einvoice — try both without an account on the demo quota.

Selling into France too? See the France e-invoicing mandate guide — same formats, different timeline and a PDP transmission model.