Beispiel: drei Rechnungen aus einer CSV, mit den Prüfregeln dieses Werkzeugs geprüft

Diese Seite zeigt einen Beispiellauf der öffentlichen Prüfregeln: eine kleine CSV-Datei mit drei frei erfundenen Rechnungen und die Meldungen dazu, wie sie ein Skript erzeugt hat. Es ist nicht der Bericht der Stapelverarbeitung im Werkzeug; was diese mit genau dieser Datei tut, steht weiter unten.

Die Beispiel-CSV ist erfunden

Alle Namen, Straßen und Nummern sind frei erfunden. Die Datei steht hier vollständig, so wie das Skript sie schreibt. Die Spalte buyer_email ist vorhanden, ihre Zellen sind leer, weil diese Website keine E-Mail-Adressen zeigt. Die Käuferreferenz der zweiten Rechnung ist absichtlich leer gelassen. Spalten zu Konto und Zahlung enthält die Datei nicht. Den Aufbau echter Dateien beschreibt die Seite XRechnung aus CSV erstellen.

invoice_number;issue_date;due_date;delivery_date;buyer_reference;buyer_name;buyer_street;buyer_postcode;buyer_city;buyer_country;buyer_email;item_name;item_description;quantity;unit;unit_price;vat_rate;note
BSP-001;05.10.2026;19.10.2026;30.09.2026;KD-BEISPIEL-1;Beispiel Kunde Eins GmbH;Beispielstraße 1;10115;Berlin;DE;;Beispiel-Leistung A;Beispielposition;"2,5";HUR;"80,00";0;"Beispielrechnung, frei erfunden."
BSP-002;05.10.2026;19.10.2026;30.09.2026;;Beispiel Kunde Zwei GmbH;Beispielweg 2;20095;Hamburg;DE;;Beispiel-Leistung B;;3;HUR;"75,00";0;
BSP-003;05.10.2026;19.10.2026;30.09.2026;KD-BEISPIEL-3;Beispiel Kunde Drei GmbH;Beispielplatz 3;80331;München;DE;;Beispiel-Leistung C;;4;HUR;"50,00";0;

So entstand der Beispiellauf

Ein Skript hat die Datei mit der Funktion parseCsvBatch gelesen. Weil die Spalte buyer_email leer ist, trug es für die drei Käufer Beispieladressen im Speicher ein; sie stehen nicht in der Datei. Dann baute es im Kleinunternehmer-Modus UBL-Dateien und prüfte jede mit der Funktion check aus erechnung-core.js, demselben Kern, den diese Website im Browser nutzt. Weil der Kern eine Rechnung ohne Käuferreferenz gar nicht erst baut, setzte das Skript bei Rechnung 2 einen Platzhalter ein und entfernte das Element danach aus der XML-Datei. Bei Rechnung 3 erhöhte es die Summe der Positionsnettobeträge in der XML-Datei um 10,00. Die Fehler sind also vom Skript absichtlich erzeugt, damit die Prüfung etwas zu melden hat. Geprüft wurde nur ein Teil der Regeln von EN 16931 und XRechnung, nicht der KoSIT-Prüfer.

Die Meldungen des Beispiellaufs

Rechnung 1 (BSP-001): 0 Fehler

Das Skript hat sie aus der Zeile gebaut und nicht verändert. Keine der geprüften Regeln ist verletzt. Das heißt nicht, dass jede denkbare Regel erfüllt wäre; es heißt nur, dass diese Teilmenge keine Meldung auslöst.

Rechnung 2 (BSP-002): 1 Fehler

BR-DE-15 meldet, dass die Käuferreferenz (BT-10) fehlt. Mit dieser Angabe ordnet der Empfänger die Rechnung bei sich zu, bei Behörden ist es die Leitweg-ID. Mehr zu dieser Regel steht auf der Seite BR-DE-15: Käuferreferenz fehlt.

Rechnung 3 (BSP-003): 2 Fehler

BR-CO-10 meldet, dass BT-106 nicht die Summe der Positionsnettobeträge (BT-131) ist, weil das Skript die Summe um 10,00 erhöht hat. BR-CO-13 ist die Folgemeldung: BT-109 ist nicht BT-106 minus BT-107 plus BT-108. Beide Fehler haben dieselbe Ursache. Ähnliche Summenfehler erklärt die Seite Summenfehler beheben.

Was die Stapelverarbeitung mit dieser Datei tut

Aus dem Programmcode: Die Stapelverarbeitung liest die Zeilen mit parseCsvBatch und ruft für jede Rechnung zuerst validateInvoice auf. Fehlen Pflichtangaben, baut sie für diese Zeile keine XML-Datei und führt check nicht aus. In der Ergebnistabelle steht die Zeile dann als „nicht erstellt“ mit den fehlenden Angaben; die übrigen Zeilen werden trotzdem verarbeitet.

Die E-Mail-Adresse des Käufers ist eine Pflichtangabe, und die Spalte buyer_email der Datei ist leer. Die folgenden Angaben setzen voraus, dass der Abschnitt „Verkäufer (Sie)“ vollständig ausgefüllt und der Kleinunternehmer-Haken gesetzt ist, wie es das Skript angenommen hat; ohne den Haken fehlt zusätzlich der Steuersatz, und ein unvollständiger Verkäufer ergänzt weitere fehlende Angaben. Lädt man die Datei so, wie sie oben steht, in die Stapelverarbeitung, erscheinen deshalb alle drei Rechnungen als „nicht erstellt“: bei BSP-001 und BSP-003 fehlt „Käufer: E-Mail (elektronische Adresse)“, bei BSP-002 zusätzlich „Käuferreferenz / Leitweg-ID“. Mit ausgefüllten Adressen würden BSP-001 und BSP-003 gebaut, und zwar ohne Fehler, denn die Summen berechnet das Werkzeug selbst aus den Positionen; die falsche Summe gibt es nur in der vom Skript veränderten XML-Datei. BSP-002 bliebe auch dann „nicht erstellt“ und erschiene nicht mit der Meldung BR-DE-15.

Ein Test dieser Website liest die CSV aus dem Kasten oben, vergleicht sie mit der Beispieldatei und wiederholt den Lauf mit einem erfundenen, vollständigen Verkäufer und denselben Funktionen (parseCsvBatch, validateInvoice, buildUBL, check). Er vergleicht Rechnungsnummern, Fehlerzahlen und Regelnummern der Tabelle mit dem Ergebnis und prüft, welche Angaben validateInvoice für jede Zeile als fehlend meldet.

Lizenzschlüssel

Der Schlüssel schaltet die Stapelverarbeitung frei. Zum Freischalten wird nur der Schlüssel an diese Website gesendet, keine Rechnungsdaten. Eine einzelne Rechnung erstellen und prüfen Sie weiterhin ohne Schlüssel im kostenlosen Werkzeug.

Lizenzschlüssel bei Gumroad kaufen Preis: 19 US-Dollar. Gumroad ist Verkäufer und Vertragspartner für den Kauf und rechnet die Umsatzsteuer hinzu, wo sie anfällt; den Endpreis zeigt Gumroad im Bestellvorgang. Werkzeug, keine Steuer- oder Rechtsberatung; keine Garantie für Konformität; Prüfung durch Steuerberater/Empfänger empfohlen.