Gültiges XML ist nicht dasselbe wie eine akzeptierte Rechnung. Lernen Sie die drei Ebenen der E-Rechnungs-Validierung kennen — Schema, Geschäftsregeln und Empfängerprüfungen — und wie Sie Ihre Datei in weniger als einer Minute testen können.
Eine E-Rechnung kann ein technisch einwandfreies XML sein, jede Schema-Prüfung bestehen und dennoch abgelehnt werden. Diese Lücke – zwischen „technisch korrekt“ und „tatsächlich akzeptiert“ – ist der Punkt, an dem die meisten E-Rechnungsprojekte Zeit verlieren, und es handelt sich dabei fast immer um ein Problem der Business-Validierung und nicht um ein technisches.
So sind die Ebenen tatsächlich aufgebaut und so prüfen Sie Ihre eigene Rechnung in etwa einer Minute.
Ist die Datei strukturell eine UBL-Rechnung (Invoice) oder eine UN/CEFACT Cross Industry Invoice? Sind die Elemente in der richtigen Reihenfolge und haben die Datentypen das richtige Format? Diese Ebene fängt defekte Dateien ab, aber fast nichts anderes. Ein bestandener Test sagt hier noch sehr wenig aus.
Das ist die Ebene, die wirklich zählt. Der europäische Standard EN 16931 definiert mehrere hundert Regeln – die Familien BR-* und BR-CO-* –, die prüfen, ob der Inhalt der Rechnung Sinn ergibt. Darüber liegen nationale Regeln (BR-DE-* für XRechnung) und Netzwerkregeln (PEPPOL-EN16931-* für Peppol BIS Billing). Eine Datei kann ein makelloses XML sein und dennoch zwanzig Geschäftsregeln verletzen.
Die Ebene, die kein Validator für Sie testen kann. Gehört die Leitweg-ID tatsächlich zu der Behörde, die Sie abrechnen? Ist die Bestellnummer diejenige, die das System des Käufers erwartet? Stimmt die Umsatzsteuerbehandlung mit der Transaktion überein? Ihre Rechnung kann jeden öffentlichen Validator passieren und dennoch vom Buchhaltungssystem des Empfängers abgelehnt werden.
Fast alle Ablehnungen in der Praxis häufen sich in einer Handvoll von Bereichen:
BR-CO-10, BR-CO-13, BR-CO-15 und BR-CO-16 prüfen die arithmetische Kette. Eine einzige Rundungsentscheidung in Ihrem ERP-System kann diese Kette unterbrechen.
In Deutschland macht BR-DE-15 die Käuferreferenz (BT-10) zur Pflicht – hier kommt die Leitweg-ID hinein. Dies ist der mit Abstand häufigste Grund, warum eine B2G-Rechnung abgewiesen wird.
Jede Zeile der Umsatzsteueraufschlüsselung muss mit den auf den Rechnungspositionen verwendeten Kategoriencodes übereinstimmen, und für Steuerbefreiungen wird ein Befreiungsgrund oder -code benötigt.
Fehlende IBAN oder ein Zahlungsmittel-Code, der nicht zu den angegebenen Zahlungsinformationen passt.
Die meisten Validatoren stufen Funde als fatale Fehler, Fehler und Warnungen ein. Es ist verlockend, alles zu versenden, das nur Warnungen produziert – aber eine Warnung bedeutet: „Dies ist ungewöhnlich und der Empfänger kann damit möglicherweise nicht umgehen“. Öffentliche Portale sind insbesondere strenger, als es der Mindeststandard erfordert. Behandeln Sie Warnungen als Fragen, die es zu klären gilt, und nicht als Rauschen, das ignoriert werden kann.
Unser E-Rechnungs-Validator ist kostenlos und läuft direkt im Browser. Er umfasst:
Erhalten Sie sofortigen Zugriff auf unseren kostenlosen E-Rechnungs-Validator. Prüfen Sie XRechnung, Peppol BIS und ZUGFeRD vor dem Versand auf Fehler in den Geschäftsregeln.
Kostenloses Validierungstool • Keine Registrierung erforderlich • Sofortige Ergebnisse
Hier erhalten die meisten Leute ein verwirrendes Ergebnis. Drei kurze Regeln:
Extrahieren Sie zuerst den XML-Anhang aus der PDF/A-3-Datei und validieren Sie dann das XML – in der Regel als ZUGFeRD 2.2 EN 16931.
Schauen Sie sich den Rechnungstyp-Code an: 380 ist eine Rechnung, 381 ist eine Gutschrift. UBL verwendet für beides ein unterschiedliches Wurzelelement (Root Element). Die Wahl der falschen Variante führt zu Fehlern, die nichts mit Ihren eigentlichen Daten zu tun haben.
Prüfen Sie das öffnende Tag des XML. urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 bedeutet UBL; urn:un:unece:uncefact:standard:CrossIndustryInvoice:100 bedeutet CII.
Verwenden Sie für Peppol den Peppol Participant ID Checker, um vor dem Versand zu überprüfen, ob der Empfänger erreichbar ist.
Validierung ist günstig; eine Ablehnung ist es nicht. Eine Datei, die an Ihrem Schreibtisch fehlschlägt, kostet eine Minute. Dieselbe Datei, die drei Wochen später in der Buchhaltungswarteschlange eines Kunden fehlschlägt, kostet einen gesamten Zahlungszyklus – und in Ländern mit E-Rechnungspflicht kann sie eine Meldefrist kosten.
Testen Sie die Datei, bevor sie Ihr System verlässt. Jedes Mal.
Mit Invoice Portal können Sie XRechnung-, Peppol BIS- und ZUGFeRD-Rechnungen an einem Ort validieren, Fehler in den Geschäftsregeln vor der Übertragung abfangen und konforme Dateien direkt an Ihre Kunden weiterleiten.
Die Schema-Validierung prüft, ob die XML-Datei strukturell korrekt ist. Die Validierung von Geschäftsregeln prüft, ob der Rechnungsinhalt Sinn ergibt, zum Beispiel ob die Summen stimmen und obligatorische Käuferreferenzen vorhanden sind.
Die häufigsten Ablehnungen werden durch nicht übereinstimmende Summen, fehlende Käuferreferenzen (wie die deutsche Leitweg-ID), inkonsistente Umsatzsteuer-Kategorien sowie fehlende oder falsche Zahlungsdetails verursacht.
Warnungen sollten nicht ignoriert werden. Eine Warnung bedeutet, dass der Inhalt ungewöhnlich ist und der Empfänger möglicherweise nicht damit umgehen kann. Öffentliche Portale sind oft strenger, als es der Mindeststandard vorschreibt.
Prüfen Sie das öffnende Tag des XML. Eine UBL-Rechnung beginnt mit urn:oasis:names:specification:ubl:schema:xsd:Invoice-2, während eine UN/CEFACT CII-Rechnung mit urn:un:unece:uncefact:standard:CrossIndustryInvoice:100 beginnt.
