API

Zwei Endpunkte, kein SDK nötig. Der Prüf-Endpunkt ist offen und ohne Schlüssel nutzbar.

POST /api/v1/validate

Nimmt eine E-Rechnung im Request-Body entgegen und liefert das Prüfergebnis als JSON. Angenommen wird XML (UBL oder CII) oder eine ZUGFeRD-/Factur-X-PDF; im zweiten Fall wird der eingebettete XML-Anhang gelesen und geprüft. Maximal 4 MB pro Aufruf.

curl -X POST https://erechnung.dev/api/v1/validate \
  -H "Content-Type: application/xml" \
  --data-binary @rechnung.xml

curl -X POST https://erechnung.dev/api/v1/validate \
  -H "Content-Type: application/pdf" \
  --data-binary @rechnung.pdf

Antwort:

{
  "valid": false,
  "syntax": "UBL",
  "profile": "urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0",
  "checkedRules": 31,
  "source": { "container": "pdf", "attachment": "factur-x.xml" },
  "findings": [
    {
      "rule": "BR-DE-15",
      "severity": "error",
      "term": "BT-10",
      "message": "Es fehlt die Leitweg-ID bzw. Käuferreferenz (BT-10) …"
    }
  ]
}

severity ist error oder warning. valid ist genau dann true, wenn kein Fund die Stufe error hat. Warnungen blockieren nicht. source.container ist xml oder pdf und sagt, woher die geprüfte XML kam.

Erkannt wird an den ersten Bytes der Datei, nicht am Content-Type — eine PDF wird also auch dann als solche behandelt, wenn sie als application/octet-stream ankommt. Enthält die PDF keinen Rechnungsanhang, antwortet der Endpunkt mit 422 und einer Begründung, nicht mit einem Parserfehler.

POST /api/v1/create

Nimmt flaches JSON und liefert eine XRechnung 3.0 als UBL-XML zurück. Mit dem Header Accept: application/json kommt stattdessen ein Objekt aus xml und validation — das erzeugte Dokument wird immer gegen die eigene Prüfung gefahren, bevor es das Haus verlässt.

Pflichtfelder

Feld	Business Term	Beschreibung
`invoiceNumber`	BT-1	Rechnungsnummer
`issueDate`	BT-2	Rechnungsdatum als YYYY-MM-DD
`seller`	BG-4	Name, Anschrift und Kontakt. Für die XRechnung sind `contact.name`, `contact.phone` und `contact.email` Pflicht (BR-DE-5 bis BR-DE-7).
`buyer`	BG-7	Name und Anschrift des Rechnungsempfängers
`lines[]`	BG-25	Mindestens eine Position mit `name`, `quantity`, `netPrice` und `vatRate`
`buyerReference`	BT-10	Leitweg-ID. Ohne sie weisen öffentliche Auftraggeber die Rechnung zurück (BR-DE-15).

Was automatisch gesetzt wird

Summen (BT-106, BT-109, BT-112, BT-115) und die Umsatzsteuer-Aufschlüsselung (BG-23) werden gerechnet, nicht übernommen.
Gerundet wird je Position und danach je Steuersatz — nicht erst am Ende. Genau daran scheitert BR-CO-10 bei vielen Eigenbauten.
Vorbelegt: typeCode 380, currency EUR, unitCode C62 (Stück), Zahlungsart 58 (SEPA-Überweisung).

Grenzen, offen benannt

Erzeugt wird derzeit UBL. ZUGFeRD als PDF/A-3 mit eingebettetem CII folgt.
Gelesen werden UBL und CII. Gutschriften (CreditNote) noch nicht.
Nachlässe und Zuschläge auf Kopf- und Positionsebene (BG-20/BG-21) fehlen noch.
Die Prüfung ist eine Teilmenge der Regeln, kein Ersatz für den KoSIT-Referenzvalidator.