Für Rechnungssoftware · XRechnung · ZUGFeRD · Peppol

E-Rechnung API für Rechnungssoftware

Aus einfachem JSON eine geprüfte XRechnung erzeugen, vorhandene XRechnung- und ZUGFeRD-Dateien gegen die offiziellen KoSIT- und CEN-Regeln prüfen und über Peppol senden, wenn der Empfänger dort erreichbar ist. Dieselbe Seite auf English.

Keine Karte nötig. Schlüssel selbst erzeugen und rotieren unter api.wsystem.dev/account. Sandbox für jeden Endpunkt.

Kurz: POST https://api.wsystem.dev/einvoice/create macht aus JSON eine UBL-2.1-XRechnung und prüft sie sofort. POST /einvoice/validate prüft Ihre eigenen Dateien — UBL, CII oder ein ZUGFeRD/Factur-X-PDF — gegen XML-Schema, CEN EN 16931 und die KoSIT-Konfiguration XRechnung 3.0.2. POST /einvoice/send führt denselben Ablauf in der Sandbox aus (Übertragung nur simuliert, signierter Beleg). Der Live-Versand über Peppol wird pro Unternehmen nach Mandat und KYC-Prüfung freigeschaltet.

Was die API heute tut

  • Erzeugen. POST /einvoice/create erzeugt aus JSON eine UBL-2.1-Rechnung im Format xrechnung, en16931 oder peppol-bis3. Summen und die USt-Aufschlüsselung berechnet die API. ZUGFeRD-PDFs erzeugt sie derzeit nicht.
  • Prüfen (KoSIT und EN 16931). POST /einvoice/validate prüft UBL, UN/CEFACT CII und ZUGFeRD/Factur-X-PDFs. Bei einer XRechnung laufen die offiziellen KoSIT-Regeln XRechnung 3.0.2 (Konfiguration vom 31. August 2026) und EN 16931 1.3.15, unverändert. Jeder Fehler nennt Regel-ID, Meldung, XPath und Korrekturhinweis. Das Feld checked sagt, welche Regelwerke gelaufen sind. Peppol-BIS-3-spezifische Regeln (PEPPOL-EN16931-*) laufen noch nicht. Vorhandene Dateien können Sie ohne Code im Browser-Validator prüfen oder mit POST /einvoice/parse als JSON lesen.
  • Empfänger vor dem Versand. GET /einvoice/route?id=… prüft die USt-IdNr. in VIES und, ob der Empfänger im Peppol-Verzeichnis oder per SML/SMP erreichbar ist. POST /einvoice/preflight ergänzt Sanktionslisten und die Rechnungsprüfung, ohne etwas zu senden. Mehr dazu (Englisch): Check if the buyer is on Peppol.
  • Senden. In der Sandbox läuft der ganze Ablauf, die Übertragung wird nur simuliert. Live über Peppol (mode=live) geht durch unseren zertifizierten Access-Point-Partner, pro Unternehmen nach Peppol-Mandat und unserer KYC-Prüfung.

Deutsche B2B-Rechnungen müssen nicht über Peppol. Ein gültiges EN-16931-Format (XRechnung oder ZUGFeRD/Factur-X) reicht, der Kanal ist frei vereinbar, auch E-Mail. Quelle: BMF, FAQ E-Rechnung. Fristen: Empfang seit 1. Januar 2025, Ausstellung ab 1. Januar 2027 über 800.000 € Vorjahresumsatz und ab 1. Januar 2028 für alle. Details: Germany e-invoicing deadlines.

Beispiel: erzeugen und gegen KoSIT prüfen

Die Beispielrechnung ist eine deutsche XRechnung in unserem JSON-Format. Ihre Software bildet ihre eigenen Felder darauf ab. $KEY ist Ihr API-Schlüssel (gratis, keine Karte).

shell
# 1. Beispielrechnung holen (kein Schlüssel nötig)
curl -s https://api.wsystem.dev/einvoice/sample > invoice.json

# 2. XRechnung erzeugen und gegen die offiziellen KoSIT- und CEN-Regeln prüfen
curl -s -X POST https://api.wsystem.dev/einvoice/create \
  -H "X-API-Key: $KEY" -H 'Content-Type: application/json' \
  -d @invoice.json \
  | jq -r .xml > INV-2026-001.xml

curl -s -X POST https://api.wsystem.dev/einvoice/validate \
  -H "X-API-Key: $KEY" -H 'Content-Type: application/xml' \
  --data-binary @INV-2026-001.xml

Antwort (gekürzt, aus einem echten Lauf am 2026-11-12, API 0.3.97): Erzeugen.

{
  "valid": true,
  "format": "xrechnung",
  "syntax": "UBL 2.1",
  "checked": {
    "xsd": true,
    "EN16931": true,
    "XRechnung": true,
    "PeppolBIS3": false,
    "SK_national": false,
    "NO_national": false
  },
  "totals": {
    "currency": "EUR",
    "line_total": "980.98",
    "vat_total": "183.27",
    "total_with_vat": "1164.25",
    "payable": "1164.25"
  }
}

Prüfen derselben Datei: valid true, Profil XRechnung, KoSIT XRechnung 3.0.2 und EN 16931 sind gelaufen.

{
  "valid": true,
  "profile": "XRechnung",
  "checked": {
    "xsd": true,
    "EN16931": true,
    "XRechnung": true,
    "PeppolBIS3": false,
    "SK_national": false,
    "NO_national": false
  },
  "rule_versions": {
    "EN16931": "1.3.15+ via KoSIT config",
    "XRechnung": "3.0.2 config 2026-08-31"
  },
  "error_count": 0
}

Eine fehlerhafte Datei ohne Schlüssel prüfen:

shell
curl -s https://wsystem.dev/examples/broken-xrechnung.xml | curl -s -X POST https://api.wsystem.dev/einvoice/validate -H 'Content-Type: application/xml' --data-binary @-

Dieselbe Prüfung mit der öffentlichen Beispieldatei broken-xrechnung.xml: valid false, Regel BR-CO-16.

{
  "valid": false,
  "profile": "XRechnung",
  "error_count": 1,
  "errors": [
    {
      "rule_id": "BR-CO-16",
      "message": "Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).",
      "fix": "Amount due must be total with VAT minus prepaid amount plus rounding."
    }
  ]
}

Über Peppol senden (zuerst Sandbox)

Ein Aufruf prüft Empfänger und Rechnung, erzeugt die XRechnung und gibt einen signierten Beleg (Ed25519 JWS) zurück. In der Sandbox wird nichts an einen echten Empfänger übertragen. Für den Live-Versand setzen Sie später mode=live und recipient_check=strict: ist der Empfänger nicht auf Peppol, antwortet die API mit HTTP 422 recipient_not_on_peppol, bevor etwas gesendet wird.

shell
# Sandbox: dieselben Prüfungen wie beim Live-Versand, Übertragung nur simuliert, signierter Beleg
jq '{invoice: ., mode: "sandbox", transport: "mock"}' invoice.json \
  | curl -s -X POST https://api.wsystem.dev/einvoice/send \
      -H "X-API-Key: $KEY" -H 'Content-Type: application/json' -d @-

Antwort (gekürzt, aus einem echten Lauf am 2026-11-12, API 0.3.97):

{
  "status": "simulated",
  "receipt_id": "ev_4fa8f6b525f64315b868976a77eddc1e",
  "transmission": {
    "transport": "mock",
    "status": "simulated",
    "transmitted": false,
    "note": "Mock transport: no network transmission happened."
  },
  "preflight": {
    "verdict": "warn",
    "warnings": [
      "peppol"
    ]
  }
}

Preis

Gratis-Sandbox-Schlüssel, danach der Platform-Plan für Rechnungssoftware mit vielen Mandanten: 149 € pro Monat inklusive 10 aktiver Firmen und 1.000 geprüfter Rechnungen. Einzelheiten und der Peppol-Dokumentpreis stehen auf der Preisseite. Design-Partner erhalten den ersten Monat gratis.

Fragen und Antworten

Ist das eine Zertifizierung?

Nein. Die API führt die offiziellen Prüfartefakte unverändert aus — die KoSIT-Konfiguration XRechnung 3.0.2 (Stand 31. August 2026) und die CEN-Artefakte EN 16931 — und nennt in jeder Antwort, welche Regelwerke gelaufen sind. Das ist keine Zertifizierung und keine Rechts- oder Steuerberatung.

Erzeugt die API auch ZUGFeRD-PDFs?

Derzeit nicht. POST /einvoice/create erzeugt aus JSON eine UBL-2.1-Rechnung im Format xrechnung, en16931 oder peppol-bis3. Vorhandene ZUGFeRD- und Factur-X-Dateien (PDF oder das eingebettete XML) können Sie mit POST /einvoice/validate prüfen und mit POST /einvoice/parse als JSON lesen.

Müssen deutsche Rechnungen über Peppol?

Nein. Im inländischen B2B-Verkehr in Deutschland ist ein gültiges EN-16931-Format (XRechnung oder ZUGFeRD/Factur-X) Pflicht; der Kanal ist frei vereinbar, auch E-Mail. Peppol ist ein Kanal, in Belgien ist er Pflicht. Wenn der Empfänger nicht auf Peppol registriert ist, erzeugt und prüft die API die Datei, und Ihre Software stellt sie über den üblichen Kanal zu.

Wann können wir live über Peppol senden?

Die Sandbox läuft ab dem ersten Tag mit einem kostenlosen Schlüssel. Der Live-Versand über Peppol (mode=live) wird pro Unternehmen freigeschaltet, nach einem Peppol-Mandat und unserer KYC-Prüfung, mit einem Peppol- oder Platform-Tarif.

Was kostet es?

Die ersten 20 Aufrufe pro Tag und IP sind ohne Schlüssel frei (gut zum Ausprobieren von /einvoice/validate und /einvoice/route). Der kostenlose API-Schlüssel (nur geschäftliche E-Mail, keine Karte) enthält 500 Einheiten pro Monat: eine Prüfung kostet 3 Einheiten, Erzeugen oder Senden 8, eine Vorprüfung 5, eine Peppol-Abfrage 1. Für Rechnungssoftware mit vielen Mandanten ist der Platform-Plan gedacht: 149 € pro Monat inklusive 10 aktiver Firmen und 1.000 geprüfter Rechnungen.

Weiter

Technische Prüfung, keine Rechts- oder Steuerberatung.