Ob eine XRechnung aus SAP oder einem anderen ERP-System gültig ist, entscheiden die Prüfregeln der KoSIT — die Geschäftsregeln der EN 16931 plus die deutschen Zusatzregeln (BR-DE-…). Per API beantworten Sie die Frage in Sekunden: Datei an POST /validate schicken, Befund mit Regel-IDs zurückbekommen — ohne dass die Datei gespeichert wird.

Ihr System — SAP, ein anderes ERP oder eine Fakturierungslösung — hat eine XRechnung erzeugt. Der Empfänger weist sie ab, oder Sie wollen vor dem Versand sicher sein. Die Frage ist in beiden Fällen dieselbe: Besteht diese Datei die Prüfung, die deutsche Eingangssysteme tatsächlich fahren?

Dieser Beitrag zeigt, wie Sie genau das in Sekunden beantworten — für die Datei, die Ihr System wirklich erzeugt hat. Wie die Datei in Ihrem System entsteht, ist Sache Ihres Systems und Ihrer Dienstleister; hier geht es um das Ergebnis.

Wogegen geprüft wird: die KoSIT-Regeln

Eine XRechnung ist erst dann „gültig”, wenn sie die Prüfregeln der KoSIT besteht — die Geschäftsregeln der EN 16931 plus die deutschen Zusatzregeln (BR-DE-…). Dieselben Regeln fahren die Eingangsportale des Bundes und vieler Länder sowie strenge B2B-Empfänger. Ein PDF-Viewer, ein XML-Editor oder „es sieht richtig aus” beantworten diese Frage nicht — die Prüfung ist maschinell, regelnummerngenau und versioniert.

Typische Befunde bei Dateien aus ERP-Ausgabestrecken:

  • BR-DE-15 — die Käuferreferenz (BT-10) fehlt. In der XRechnung ein Pflichtfeld, auch im B2B. → Leitweg-ID und BT-10
  • BR-DE-2, BR-DE-5 bis BR-DE-7 — Kontaktangaben des Verkäufers unvollständig.
  • Falsche oder veraltete Profilversion — geprüft wird gegen einen konkreten Versionsstand; produktiv gilt derzeit XRechnung 3.0.2.
  • Syntax-Verwechslung — XRechnung existiert in zwei Syntaxen (UBL und CII); der Empfänger muss beide können, Ihr Validator muss die richtige erkennen.

Die Prüfung per API: Datei hinschicken, Befund zurück

POST /validate nimmt Ihre strukturierte Rechnung (XRechnung-XML, UBL oder CII) entgegen und liefert den Befund — dieselbe Prüfstrecke, mit der Fortlauf eigene Belege vor der Ausstellung prüft, mit Regel-IDs zum Nachschlagen:

Bash
curl -X POST "$FORTLAUF_API_URL/validate?profile=3.0.2" \
  -H "Authorization: Bearer $FORTLAUF_API_KEY" \
  -H "Content-Type: application/xml" \
  --data-binary @rechnung.xml

Auch bei einem Durchfaller ist die Antwort 200. Ein fail ist ein erfolgreicher Prüfbefund, kein HTTP-Fehler; ein 4xx gibt es nur, wenn die Anfrage selbst nicht verarbeitbar ist (etwa eine unbekannte Profilversion):

JSON
{
  "verdict": "fail",
  "profile": "3.0.2",
  "reports": [
    {
      "format": "xrechnung-ubl",
      "formatVersion": "3.0.2",
      "verdict": "fail",
      "findings": [
        {
          "ruleId": "BR-DE-15",
          "severity": "error",
          "message": "Das Element \"Buyer reference\" (BT-10) muss übermittelt werden.",
          "location": "/ubl:Invoice"
        }
      ]
    }
  ]
}

Drei Eigenschaften, die für Produktionsdaten entscheidend sind:

  • Es wird nichts gespeichert. Die Datei wird geprüft und verworfen — kein Beleg wird angelegt, kein Bericht aufbewahrt, nichts gezählt. Sie können also auch echte Ausgangsrechnungen prüfen, ohne dass sie ein fremdes System betreten und dort liegen bleiben.
  • Der Versionsstand ist explizit. Sie geben die Profilversion an (?profile=3.0.2), und die Antwort nennt sie zurück — der Befund ist aus sich heraus nachvollziehbar.
  • Es ist dieselbe Prüfung wie beim Ausstellen. Der Befund kann nicht von dem abweichen, was eine über Fortlauf ausgestellte Rechnung passieren muss — es ist ein und dieselbe Prüfstrecke.

Was ein „pass” bedeutet — und was nicht

Ein bestandener KoSIT-Befund heißt: Die Datei ist formal gültig gegen den geprüften Regelstand. Er heißt nicht, dass die Rechnung inhaltlich vollständig oder richtig ist — ob etwa alle Pflichtangaben des §14 UStG sachlich stimmen, prüft keine Schematron-Regel der Welt. → Pflichtangaben nach §14 UStG · → KoSIT-Validierung im Detail

Wenn Sie regelmäßig prüfen (oder gleich sauber ausstellen) wollen

Wer die Prüfung dauerhaft in den eigenen Ausgangsprozess einbaut, ruft denselben Endpoint aus der eigenen Strecke auf. Und wer feststellt, dass die eigene Ausgabestrecke die eigentliche Fehlerquelle ist, kann die Erzeugung ganz delegieren: Fortlauf stellt XRechnung und ZUGFeRD/Factur-X aus einem geprüften Datenmodell aus. → E-Rechnung per API

Sie wollen Ihre Ausgangsstrecke durchsprechen? Im Gespräch klären →