Rechnungsvalidator für ZATCA Phase 2
Fügen Sie das XML einer saudischen E-Rechnung ein oder laden Sie es hoch und sehen Sie, was die ZATCA voraussichtlich ablehnen würde: BR-KSA-Regeln, USt-Identifikationsnummer, Summen, QR-Code und Rechnungs-Hash – mit Feldpfad und Lösung für jeden Fehler.
Tool
Läuft in Ihrem Browser. Die Datei wird nie hochgeladen.
Dieses Tool im Vergleich zum offiziellen SDK und Developer Portal der ZATCA
Nutzen Sie diese Seite für eine schnelle Vorprüfung während der Entwicklung oder Fehlersuche. Für die maßgebliche Prüfung vor dem Onboarding verwenden Sie die Tools der ZATCA.
| Dieser Validator (Kodenova) | ZATCA Compliance and Enablement Toolbox SDK | |
|---|---|---|
| Was geprüft wird | UBL-2.1-Struktur, BR-KSA-Geschäftsregeln, USt-Nummern, Summen und Rundung, der QR-Code und der Rechnungs-Hash nach BR-KSA-27. Die ECDSA-Signatur und die Zertifikatskette werden nicht verifiziert. | Laut ZATCA prüft das SDK, ob erzeugte E-Rechnungen, Gutschriften und Belastungsanzeigen der E-Invoicing-Verordnung entsprechen. |
| Wo es läuft | In Ihrem Browser. Das XML wird nirgendwohin hochgeladen. | Download von zatca.gov.sa, Ausführung auf Ihrem eigenen Rechner, mit Benutzerhandbuch. |
| Wann Sie es nutzen | Schnelle Prüfung einzelner XML-Dateien, während Sie Felder in SAP Business One oder Ihrem ERP zuordnen. | Der offizielle Prüfschritt vor dem Onboarding. Die ZATCA weist darauf hin, dass ein bestandener Test nicht bedeutet, dass sie die Rechnungen genehmigt hat. |
Quelle: ZATCA, Compliance and Enablement Toolbox: Download SDK. Für Systementwickler nennt die ZATCA außerdem ein E-Invoicing Developer Portal. Stand: Oktober 2026.
Häufige Fehler und wie Sie sie beheben
Zehn Ablehnungsgründe, die sich direkt aus den Regeln des ZATCA XML Implementation Standard v1.2 ergeben – jeweils mit der Lösung.
| Regel | Was schiefgeht | So beheben Sie es |
|---|---|---|
| BR-KSA-40 | Die USt-Nummer des Verkäufers hat nicht 15 Ziffern oder beginnt bzw. endet nicht mit 3. | Übernehmen Sie die USt-Nummer exakt aus der Registrierungsbescheinigung, ohne Leerzeichen. |
| BR-KSA-27 | Das XML wurde nach dem Signieren bearbeitet, neu eingerückt oder neu gespeichert; der Hash passt nicht mehr zum signierten Digest und zum QR-Code. | Signieren Sie das endgültige XML und senden Sie es Byte für Byte unverändert. Nach dem Signieren nichts mehr ändern. |
| BR-KSA-26 / 61 | Der Hash der vorherigen Rechnung (PIH) fehlt oder ist nicht der Hash der vorherigen Rechnung derselben EGS-Einheit. | Speichern Sie den Hash jeder gesendeten Rechnung und verwenden Sie ihn als PIH der nächsten. |
| BR-KSA-33 / 34 | Der Rechnungszähler (ICV) fehlt, ist nicht numerisch oder wurde zurückgesetzt. | Führen Sie pro EGS-Einheit einen fortlaufenden Zähler und verwenden Sie keinen Wert doppelt. |
| BR-KSA-37 / 66 | Die Gebäudenummer des Verkäufers hat nicht 4 Ziffern oder die Postleitzahl nicht 5 Ziffern. | Pflegen Sie die Felder der saudischen nationalen Adresse in den Firmenstammdaten. |
| BR-KSA-63 | Standardrechnung an einen saudischen Käufer ohne vollständige Käuferadresse (Straße, Gebäude, Postleitzahl, Stadt, Bezirk). | Vervollständigen Sie die nationale Adresse des Geschäftspartners vor der Fakturierung. |
| BR-KSA-06 | InvoiceTypeCode/@name ist kein 7-stelliger Transaktionscode wie 0100000 oder 0200000. | Ordnen Sie jeder Belegart den richtigen Code zu und setzen Sie nur die zutreffenden Flags. |
| BR-KSA-68 | TaxCurrencyCode fehlt, oder es gibt kein TaxTotal mit der MwSt. in SAR. | Senden Sie immer TaxCurrencyCode SAR und ein TaxTotal, das nur den MwSt.-Betrag in SAR enthält. |
| BR-KSA-23 / 24 / 69 | Nullsatz-, steuerbefreite oder nicht steuerbare Positionen ohne VATEX-SA-Befreiungscode. | Ergänzen Sie TaxExemptionReasonCode und TaxExemptionReason in jeder Aufschlüsselung der Kategorien Z, E oder O. |
| BR-KSA-51 / BR-CO-15 | Positionsbetrag inkl. MwSt. oder Belegsummen gehen nach der Rundung nicht auf. | Runden Sie die MwSt. jeder Position auf 2 Nachkommastellen und summieren Sie dann die Positionen zu den Kopfsummen. |
Spezifikationen, gegen die dieses Tool prüft
- ZATCA Electronic Invoice XML Implementation Standard v1.2 (Regeln BR-KSA, BR-DEC und BR-CO, Hash nach BR-KSA-27)
https://zatca.gov.sa/ar/E-Invoicing/SystemsDevelopers/Documents/20230519_ZATCA_Electronic_Invoice_XML_Implementation_Standard_%20vF.pdf - OASIS UBL 2.1 Invoice Schema (UBL-Invoice-2.1.xsd)
https://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/maindoc/UBL-Invoice-2.1.xsd - W3C Canonical XML 1.1 (C14N 1.1), verwendet für den Rechnungs-Hash
https://www.w3.org/TR/xml-c14n11/
Kopien dieser Dateien liegen mit ihren SHA-256-Prüfsummen beim Quellcode des Tools. Das Tool prüft gegen die veröffentlichten ZATCA-Spezifikationen; es ist weder von der ZATCA zertifiziert noch ein offizieller Validator.
Drei Schritte, ohne Anmeldung
XML einfügen oder hochladen
Verwenden Sie das signierte XML einer Standardrechnung (B2B), einer vereinfachten Rechnung (B2C), einer Gutschrift oder einer Belastungsanzeige – oder laden Sie ein Beispiel.
Bericht lesen
Fehler, Warnungen und Hinweise werden gruppiert, jeweils mit der offiziellen Regel-ID (BR-KSA-…), dem XML-Pfad und der passenden Korrektur.
Korrigieren, bevor die ZATCA ablehnt
Korrigieren Sie das Feld in SAP Business One oder Ihrem ERP, erzeugen Sie das XML neu und prüfen Sie erneut. Laden Sie das PDF für Ihr Team herunter.
Fragen zu diesem Tool
Was prüft dieser ZATCA-Validator?
Die UBL-2.1-Struktur und die saudischen Geschäftsregeln des ZATCA XML Implementation Standard v1.2: Rechnungsart und Transaktionscode (KSA-2), UUID, Ausstellungsdatum und -uhrzeit, Rechnungszähler (ICV) und Hash der vorherigen Rechnung (PIH), USt-Nummern von Verkäufer und Käufer, Felder der nationalen Adresse, Lieferdatum, Codes für Befreiungsgründe, Positions-MwSt. und Rundung, MwSt.-Aufschlüsselungen, Belegsummen mit Rundung auf 2 Nachkommastellen, den QR-Code und den Rechnungs-Hash nach BR-KSA-27.
Wie wird der Rechnungs-Hash berechnet?
So, wie BR-KSA-27 es beschreibt: ext:UBLExtensions, die cac:AdditionalDocumentReference mit der ID QR und cac:Signature entfernen, den Rest mit C14N 1.1 kanonisieren, mit SHA-256 hashen und das Ergebnis Base64-kodieren. Das Tool vergleicht den Wert mit dem Digest in der Signatur und mit QR-Tag 6.
Prüft das Tool die kryptografische Signatur?
Nein. Es prüft, ob der Stempel vorhanden und formal korrekt ist (SignedInfo, SignatureValue, Zertifikat und Signed Properties) und ob der signierte Digest zur Rechnung passt. Die ECDSA-Signatur und die Zertifikatskette werden nicht verifiziert. Ein PASS hier ist also kein Clearance- oder Reporting-Ergebnis der ZATCA.
Was ist der Unterschied zwischen einer Standard- und einer vereinfachten Steuerrechnung?
Der Transaktionscode in InvoiceTypeCode/@name beginnt mit 01 bei einer Standardsteuerrechnung (B2B), die die ZATCA in Echtzeit freigibt (Clearance), und mit 02 bei einer vereinfachten Rechnung (B2C), die den kryptografischen Stempel und den QR-Code tragen muss und innerhalb von 24 Stunden gemeldet wird.
Ist das ein offizieller ZATCA-Validator?
Nein. Es ist ein unabhängiges Tool; Kodenova ist nicht mit der ZATCA verbunden. Geprüft wird gegen die veröffentlichten ZATCA-Spezifikationen. Die maßgebliche Konformitätsprüfung sind das Compliance and Enablement Toolbox SDK der ZATCA und ihr E-Invoicing Developer Portal; die endgültige Antwort kommt immer von der Fatoora-Plattform.
Wird meine Rechnung irgendwohin hochgeladen?
Nein. Das XML wird von Ihrem eigenen Browser gelesen und geprüft, und auch der PDF-Bericht entsteht dort. Nichts wird an Kodenova oder Dritte gesendet.
Für SAP-Business-One-Teams entwickelt
ZATCA Phase 2 aus SAP Business One?
Wir binden SAP B1 an die ZATCA an: XML, Hash-Kette, Signatur, QR-Code, Clearance und Reporting, mit Protokollen und Wiederholungen. Festpreis, meist innerhalb von 24 Stunden angeboten.
