Eingang prüfen, bevor er gebucht wird

Drei Prüfungen vor der Buchung — und eine klare Aussage darüber, was geprüft wurde.

„Prüfen“ heißt bei einer E-Rechnung drei verschiedene Dinge, und sie werden gern verwechselt. Erstens: Ist die Datei lesbar und in einem bekannten Format? Zweitens: Stimmen die Zahlen in sich — Positionen, Steuerbeträge, Summen? Drittens: Passt die Rechnung zu deiner Bestellung? Die API deckt die ersten beiden Fragen ab; die dritte beantwortet dein System. Diese Seite sagt, welcher Aufruf welche Frage beantwortet, damit niemand eine Zusage liest, die nicht drinsteht.

Integration anfragen Kostenlos starten

Was reinkommt

Die eingegangene Datei: XRechnung-XML oder ZUGFeRD-PDF

Die daraus ausgelesenen Rechnungsdaten als JSON

Deine Bestellung oder der Vertrag als Vergleichsmaßstab

Das Land des Absenders, weil die Regeln daran hängen

Was das löst

Lesbar und erkannt

Der Parse-Endpoint sagt, ob sich die eingegangene Datei als E-Rechnung lesen lässt. Scheitert das, ist der Fall geklärt, bevor jemand Zahlen abtippt.

Rechnerisch in sich stimmig

Über die ausgelesenen Felder beantwortet der Validate-Endpoint die Frage: Ergäben diese Rechnungsdaten eine konforme Rechnung? Die Antwort trägt valid sowie errors und warnings mit Regel-Code und Feld.

Was der Validate-Endpoint nicht beurteilt

Er urteilt über Rechnungsdaten, nicht über die Bytes der fremden Datei — und formal konform heißt nicht sachlich richtig. Ob der Betrag stimmt, sagt deine Bestellung, nicht die Norm.

Der Abgleich mit der Bestellung bleibt bei dir

Lieferantennummer, Bestellbezug, vereinbarter Preis, Steuersatz: Diesen Vergleich kann nur dein System führen. Die API liefert dafür die Felder — in derselben Struktur wie beim Erzeugen.

Ein echtes Beispiel

Ausschnitt aus dem Rezept „Bestehende Rechnung prüfen“ — die Daten, über die der Validate-Endpoint urteilt.

json

{
  "invoice": {
    "invoiceNumber": "RE-2025-003",
    "countrySpecific": {
      "countryCode": "DE",
      "leitwegId": "991-12345-67"
    },
    "taxSummary": [
      {
        "taxRate": 19,
        "netAmount": 1500,
        "taxAmount": 285
      }
    ],
    "subtotal": 1500,
    "total": 1785
  }
}

POST /api/v1/invoice/DE/validate

Antwort: valid sowie errors und warnings mit Regel-Code und betroffenem Feld. Für dieses Beispiel: 1.500,00 € netto, 285,00 € Steuer, 1.785,00 € Gesamtbetrag — rechnerisch geschlossen und mit Leitweg-ID, also ohne BR-DE-15.

Das vollständige Rezept

Die beteiligten Endpoints

Parser
POST /api/v1/invoice/parse
Live
Validator
POST /api/v1/invoice/{countryCode}/validate
Live

Gegenüber der Alternative

Die Alternative ist: Es fällt in der Buchhaltung oder der Kanzlei auf. Dann ist die Rechnung gebucht, der Monat abgeschlossen und die Korrektur teurer als die Prüfung gewesen wäre.

Zum Vergleich

So läuft es

1
Eingang auslesen: POST /api/v1/invoice/parse liefert die Felder.
2
POST /api/v1/invoice/DE/validate über die ausgelesenen Daten — Regel-Code und Feld statt „irgendwas stimmt nicht“.
3
Fachlich abgleichen: Bestellbezug, Preis und Steuersatz gegen deine Bestellung, dann buchen oder zurückweisen.

Was es bei diesem Umfang kostet

Rund 1.000 Rechnungen im Monat liegen im Tarif Starter bei 23 € pro Monat.

Alle Preise netto, zzgl. USt. · 20 % Rabatt bei Jahreszahlung · Free-Tier ohne Kreditkarte

Alle Tarife

Grenzen

Der Validate-Endpoint beurteilt Rechnungsdaten, nicht das eingegangene Dokument selbst. Für eine Aussage über die fremde Datei ist das Auslesen der erste und der aussagekräftige Schritt.
Formale Konformität ist keine sachliche Richtigkeit: Die Regeln der Norm sagen nichts über deine Beträge.
Der Endpoint verlangt einen Bearer-Key; bei erschöpftem Kontingent wird auch eine reine Prüfung abgelehnt (429).

Weiterführend

Rezept: bestehende Rechnung prüfen

n8n-Template: Prüf-Formular für das Team

Validator-Endpoint

Fehlerreferenz mit den Regel-Codes

Häufige Fragen

Kann ich eine fremde XRechnung hochladen und prüfen lassen?

Du liest sie zuerst mit dem Parse-Endpoint aus und prüfst dann die ausgelesenen Daten. Der Validate-Endpoint nimmt Rechnungsdaten als JSON entgegen, keine Datei.

Was heißt valid in der Antwort?

Dass die übergebenen Rechnungsdaten die geprüften Regeln erfüllen; errors und warnings nennen im Zweifel Regel-Code und Feld. Eine Aussage darüber, ob die Beträge zu deiner Bestellung passen, ist es nicht.

Zählt eine Prüfung gegen mein Kontingent?

Eine Prüfung erzeugt nichts und wird nicht als Erzeugung gezählt. Sie braucht trotzdem einen gültigen Schlüssel, und bei erschöpftem Kontingent antwortet die API mit 429.

Prüfen, bevor gebucht wird — mit einer klaren Aussage darüber, was geprüft wurde.

Integration anfragen Kostenlos starten