Was XRechnung ist, was das deutsche B2B-E-Rechnungs-Mandat konkret verlangt, und wie Sie konforme Rechnungen nach EN 16931 per REST API senden und empfangen — ohne in XML zu ertrinken.

Wenn Sie ein Unternehmen in Deutschland betreiben oder deutsche Kunden abrechnen, fallen Sie bereits unter das 2025er E-Rechnungs-Mandat. Dieser Leitfaden erklärt, was XRechnung ist, was Sie unterstützen müssen und wie Sie es umsetzen, ohne in XML zu ertrinken. Unsere XRechnung API übernimmt jeden der unten beschriebenen Schritte; wenn Sie Anbieter vergleichen, ist das die Produktseite.

Was ist XRechnung?

XRechnung ist die deutsche Referenzumsetzung des EU-Rechnungsstandards EN 16931. Es ist ein strukturiertes XML-Format, das Maschinen durchgehend lesen können — kein OCR, kein PDF-Parsing, keine manuelle Erfassung. Für Rechnungen an Bundesbehörden ist es seit 2020 verpflichtend; seit 2025 erfasst der Geltungsbereich sämtliche inländischen B2B-Transaktionen.

XRechnung existiert in zwei XML-Syntaxen:

UBL (Universal Business Language) — ein OASIS-Standard, EU-weit verwendet
UN/CEFACT CII (Cross Industry Invoice) — älter, aber weiterhin gültig

Beide transportieren denselben semantischen Inhalt. Die meisten deutschen Behörden-Portale akzeptieren beide; bei Neuentwicklung UBL wählen.

Was das Mandat konkret verlangt

Der 2025–2028er Rollout in drei Phasen:

Datum	Wen betrifft es	Was ändert sich
2025-01-01	Alle umsatzsteuerpflichtigen Unternehmen	Müssen E-Rechnungen von inländischen Lieferanten empfangen können
2027-01-01	Unternehmen mit > 800.000 € Jahresumsatz	Müssen E-Rechnungen im inländischen B2B versenden (kleinere Unternehmen haben Schonfrist)
2028-01-01	Alle Unternehmen, unabhängig von der Größe	Müssen E-Rechnungen für sämtliche inländischen B2B-Geschäfte versenden

"Empfangen" bedeutet: Ihr Kreditorenprozess kann eine strukturierte Rechnung (keine PDF) annehmen und verarbeiten, ohne dass ein Mensch Daten neu eintippt. Viele Unternehmen unterschätzen das. Wenn Ihr aktueller Workflow "Rechnung kommt als PDF-Anhang, Buchhaltung tippt sie in DATEV" ist, sind Sie nicht konform.

XRechnung vs. ZUGFeRD vs. Factur-X — wo liegt der Unterschied?

Leicht zu verwechseln. Kurzfassung:

XRechnung — reines XML, verwendet für Rechnungen an die deutsche öffentliche Hand und (nun auch) im B2B.
ZUGFeRD — hybrides Format: ein reguläres PDF/A-Dokument mit vollständiger XML-Rechnung eingebettet. Menschen sehen das PDF; Maschinen parsen das XML. Im deutschen B2B beliebt, weil es Legacy-Prozesse schont.
Factur-X — französisches Äquivalent zu ZUGFeRD. Technisch identisch, nur anderes Branding.

Eine gut entworfene API behandelt alle drei Formate austauschbar. Das Datenmodell ist dasselbe — nur die Verpackung unterscheidet sich.

Das minimale Datenmodell

Auf semantischer Ebene muss jede EN-16931-Rechnung enthalten:

Rechnungsnummer, Ausstellungsdatum, Fälligkeit
Verkäufer-Identifikation (Name, Anschrift, USt-IdNr.)
Käufer-Identifikation plus Leitweg-ID bei Behörden-Empfängern
Rechnungspositionen mit Beschreibung, Menge, Einzelpreis
USt-Aufschlüsselung pro Steuersatz
Summen (netto, Steuer, brutto)
Zahlungsbedingungen und Bankverbindung

Das Feld, das Neueinsteiger am häufigsten übersehen, ist die Leitweg-ID — eine Routing-Kennung, die für Behörden-Empfänger zwingend ist. Sie ist nicht optional und nicht offensichtlich (der Käufer liefert sie). B2B-Rechnungen benötigen sie nicht.

Eine Rechnung über die API validieren

So sieht ein typischer Validierungs-Aufruf aus:

curl -X POST https://api.postscale.io/v1/invoices/validate \
  -H "Authorization: Bearer ps_live_..." \
  -H "Content-Type: application/xml" \
  --data-binary @invoice.xml

Antwort bei gültiger Rechnung:

{
  "valid": true,
  "format": "xrechnung-ubl",
  "standard": "EN 16931",
  "profile": "urn:cen.eu:en16931:2017",
  "errors": [],
  "warnings": []
}

Bei ungültiger Rechnung ist die Antwort strukturiert, damit Sie Felder programmatisch korrigieren können:

{
  "valid": false,
  "errors": [
    {
      "rule": "BR-CO-15",
      "path": "/Invoice/LegalMonetaryTotal/TaxInclusiveAmount",
      "message": "Rechnungsbetrag muss Summe der Positionen plus Steuer entsprechen"
    }
  ]
}

Ein gut entworfener Validator liefert sowohl die Regel-ID (aus dem offiziellen Schematron) als auch eine lesbare Meldung. Erstere für Ihre Testsuite; letztere für die Fehleranzeige im UI.

Eine Rechnung versenden

Nach erfolgreicher Validierung reduziert sich der Versand auf eine von zwei Optionen:

E-Mail-Zustellung — XML (oder PDF/A mit eingebettetem XML bei ZUGFeRD) an eine reguläre E-Mail anhängen und senden. Funktioniert für die meisten B2B-Fälle.
Peppol — für grenzüberschreitende EU- oder Behörden-Zustellung. Peppol ist ein geschlossenes Netzwerk von Access Points; Sie veröffentlichen Ihre Empfänger-ID und Käufer senden über ihren eigenen Access Point.

curl -X POST https://api.postscale.io/v1/invoices/send \
  -H "Authorization: Bearer ps_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "format": "zugferd",
    "from": "rechnung@ihrfirma.de",
    "to": "buchhaltung@kunde.de",
    "invoice_xml": "<base64-kodiertes-xml>",
    "pdf_template": "standard"
  }'

Eingehende Rechnungen empfangen und parsen

Das ist die Seite, die die meisten Unternehmen vernachlässigen. Ab 2025-01-01 müssen Sie eingehende E-Rechnungen annehmen. Minimalsetup:

Dedizierter Posteingang, z.B. rechnungen@ihrfirma.de
MX-Eintrag, der diesen Posteingang durch eine Inbound-E-Mail-API leitet
Webhook, der bei jeder Nachricht feuert und parsed-invoice-JSON anhängt
Ihr Buchhaltungssystem liest das JSON und bucht

Mit Postscale:

{
  "id": "in_01HY...",
  "to": "rechnungen@ihrfirma.de",
  "from": "rechnung@lieferant.de",
  "subject": "Rechnung #4421",
  "attachments": [
    {
      "filename": "rechnung-4421.xml",
      "content_type": "application/xml",
      "parsed_invoice": {
        "invoice_number": "4421",
        "issue_date": "2026-04-15",
        "seller": { "name": "Lieferant GmbH", "vat_id": "DE123456789" },
        "buyer": { "name": "Sie GmbH", "vat_id": "DE987654321" },
        "total_net": 1250.00,
        "total_vat": 237.50,
        "total_gross": 1487.50,
        "currency": "EUR",
        "line_items": [...]
      }
    }
  ]
}

Das parsed_invoice-Feld bedeutet: Ihr Kreditoren-Workflow berührt niemals XML direkt — er arbeitet mit JSON und typisierten Feldern.

Was Sie testen sollten

Wenn Sie das heute bauen, sind das die Must-Pass-Testfälle:

Gültige UBL-Rechnung von einem deutschen Lieferanten — Parse erfolgreich, Summen stimmen.
Gültige CII-Rechnung — gleiche Daten, andere Syntax; Ihr Code sollte normalisieren.
ZUGFeRD-PDF mit eingebettetem XML — XML extrahieren, validieren, PDF-Rendering ignorieren.
Rechnung mit Leitweg-ID — Pflichtfeld für Behörden-Empfänger.
Rechnung mit fehlendem Pflichtfeld — Ihr System weist sie sauber zurück, mit korrigierbarem Fehler.
Rechnung mit Reverse-Charge-USt — Edge Case, den naive Parser brechen.
Gutschrift (Rechnungskorrektur) — gleiches Format, negative Beträge.

Diese Fälle gegen Ihre Staging-Umgebung laufen lassen, bevor Sie einen einzigen produktiven Posteingang öffnen.

Wichtigste Erkenntnisse

E-Rechnung ist XML, nicht ein PDF mit XML-Anhang. Auf die strukturierten Daten bauen, nicht auf die Pixel.
Empfangen ist ab 2025 Pflicht; Versenden wird bis 2028 schrittweise ausgerollt. Mit Empfang starten.
XRechnung, ZUGFeRD und Factur-X austauschbar behandeln — gleiches Datenmodell.
Validator verwenden, der strukturierte Fehler liefert, nicht ein generisches "ungültige Rechnung".
Die Leitweg-ID ist das Feld, das alle übersehen.

Wenn Sie das umsetzen, übernimmt unsere Invoices API Validierung, Versand und Inbound-Parsing über einen einzigen, EU-gehosteten Endpoint. Oder lesen Sie die vollständige Invoice-Dokumentation als Referenz.

XRechnung API: Entwickler-Leitfaden zum deutschen E-Rechnungs-Mandat