ZATCA E-Rechnung QR (Saudi FATOORA)
ZATCA (Zakat-, Steuer- und Zollbehörde) Saudi-Arabiens schreibt einen QR auf jeder im Königreich ausgestellten Steuerrechnung vor. Phase 1 ist vereinfachtes TLV; Phase 2 fügt kryptografische Versiegelung durch Integration mit der FATOORA-Plattform hinzu. Nicht konforme Rechnungen werden von der Buchhaltungssoftware des Käufers abgelehnt und sind für die Vorsteuererstattung ungültig.
Offizielle Spezifikation:ZATCA E-Invoicing-Beschluss und Durchführungsbestimmungen, gültig bis 2026.
Phase 1 (Erstellung): in Kraft seit 4. Dezember 2021. Alle mehrwertsteuerlich registrierten Unternehmen müssen digitale Rechnungen mit QR ausstellen.
Phase 2 (Integration): rollout in Wellen nach Unternehmensgröße seit 1. Januar 2023. Fügt digitale Signatur + ZATCA-Freigabe für Standardrechnungen und Echtzeit-Reporting für vereinfachte Rechnungen hinzu.
Phase 1 (Erstellung): in Kraft seit 4. Dezember 2021. Alle mehrwertsteuerlich registrierten Unternehmen müssen digitale Rechnungen mit QR ausstellen.
Phase 2 (Integration): rollout in Wellen nach Unternehmensgröße seit 1. Januar 2023. Fügt digitale Signatur + ZATCA-Freigabe für Standardrechnungen und Echtzeit-Reporting für vereinfachte Rechnungen hinzu.
Was es ist
Der QR kodiert einen Base64-String. Base64 dekodieren ergibt eine binäre TLV-Sequenz mit 5 Pflichtfeldern in fester Reihenfolge:
| Tag | Feld | Typ | Hinweise |
|---|---|---|---|
01 | Verkäufername | UTF-8-String | Handelsname des Verkäufers. Arabisch und Latein beide akzeptiert. |
02 | USt-IdNr. | 15 Ziffern | Beginnt mit 3 für saudi-arabische Einheiten. Format: 3XXXXXXXXXXXXX3. |
03 | Rechnungszeitstempel | ISO 8601 | Z.B. 2026-04-18T10:30:00Z. Muss Zeitzone enthalten. |
04 | Rechnungsbetrag (inkl. MwSt.) | Dezimalstring | Z.B. 115.00. Währung ist implizit SAR. |
05 | MwSt.-Betrag | Dezimalstring | Z.B. 15.00. Aktuell 15 % Standardsatz. |
06 | Rechnungs-Hash (Phase 2) | Base64 SHA-256 | SHA-256 des kanonischen Rechnungs-XML. |
07 | Digitale Signatur (Phase 2) | Base64 | ECDSA über den Rechnungs-Hash mit dem CSID-Zertifikat des Verkäufers. |
08 | Öffentlicher Schlüssel (Phase 2) | Base64 X.509 | ECDSA-Öffentlicher-Schlüssel des Verkäufers (aus dem CSID). |
09 | ZATCA-Stempel (Phase 2) | Base64 | Gegensignatur von ZATCA. Vorhanden nur nach ZATCA-Freigabe. |
Jeder TLV-Datensatz ist 1 Tag-Byte + 1 Längen-Byte + <Länge> Wert-Bytes. Die gesamte Sequenz wird dann Base64-kodiert, um den QR-Payload zu werden.
Phase 1 (vereinfacht) vs. Phase 2 (Integration)
| Aspekt | Phase 1 | Phase 2 |
|---|---|---|
| QR-Inhalt | Nur Tags 01–05 | Tags 01–05 plus 06, 07, 08, optional 09 |
| ZATCA-Integration | Keine, offline | Echtzeit-API für vereinfachte Rechnungen, Freigabe-Flow für Standardrechnungen |
| Erforderliche Zertifikate | Nein | Ja, CSID (Kryptografischer Stempel-Identifikator) von ZATCA ausgestellt |
| Wirksamkeitsdatum | 2021-12-04 (alle Unternehmen) | 2023-01-01 (schrittweise Wellen nach Umsatz) |
| Rechnungsumfang | B2C (vereinfacht) + B2B (Standard) | B2C vereinfacht: Echtzeit-Meldung. B2B Standard: Freigabe (Vorab-Validierung) vor Ausstellung. |
Kanonische Testvektoren
Beispiel-TLV (vor Base64):
01 0A "Acme Saudi" 02 0F "300000000000003" 03 14 "2026-04-18T10:30:00Z" 04 06 "115.00" 05 05 "15.00"Nach Base64-Kodierung:
AQpBY21lIFNhdWRpAg8zMDAwMDAwMDAwMDAwMDMDFDIwMjYtMDQtMThUMTA6MzA6MDBaBAYxMTUuMDAFBTE1LjAw| Fall | Eingaben | Base64-Präfix |
|---|---|---|
| Phase 1, minimales vereinfachtes | seller=Acme Saudi | AQpBY21lIFNhdWRp... |
| Arabischer Verkäufername | seller=شركة أكمي | Verkäufername UTF-8-kodiert innerhalb TLV vor Base64. |
| Phase 2 Standardrechnung | Alles oben plus hash=<SHA-256 Base64> | Viel längeres Base64. Decoder müssen zusätzliche Tags jenseits 05 tolerieren. |
Häufige Fallstricke
- USt-IdNr.-Länge. ZATCA-USt-IdNrn. sind genau 15 Ziffern, beginnen und enden mit
3. Alles andere schlägt bei der Validierung beim Rechnungseingang fehl. - Zeitstempel ohne Zeitzone. Die Spezifikation erfordert ISO 8601 mit expliziter Zone (
Zoder+03:00). Lokale Zeitstempel ohne Zone werden abgelehnt. - Kodierungsreihenfolge. TLV-Felder müssen in Tag-Nummernreihenfolge erscheinen (01, 02, 03, 04, 05, …). Umordnung lässt den QR korrekt dekodieren, aber einige Validatoren markieren ihn als nicht kanonisch.
- Dezimalformatierung. Rechnungsbetrag und MwSt.-Betrag verwenden Punkt-Dezimal (
115.00), nicht Komma-Dezimal (115,00). Auch keine Tausendertrennzeichen. - Währung ist implizit SAR. Fremdwährungsrechnungen werden trotzdem in SAR für das QR-Feld umgerechnet. Der zugrunde liegende XML kann die Originalwährung tragen; der QR nicht.
- Phase-2-Freigabe-Fehler. Eine an ZATCAs Freigabe-API übermittelte Standardrechnung kann abgelehnt werden (falsches CSID, fehlerhaftes XML, falsche Steuerberechnung). Die Rechnung ist rechtlich ungültig bis zur Freigabe. Implementieren Sie eine Wiederholungsschleife mit exponentiellem Backoff; stellen Sie die Rechnung erst nach erfolgreicher Freigabe aus.
- CSID-Zertifikatsrotation. Phase-2-CSIDs laufen ab (typischerweise 1 Jahr). Bauen Sie eine Erneuerungsprüfung in Ihren E-Invoicing-Stack ein, sonst können Sie plötzlich keine Rechnungen mehr ausstellen.
Scanner-Kompatibilität
| Leser | Unterstützung | Hinweise |
|---|---|---|
| ZATCA FATOORA-App | Nativ | Offizielle Ministeriums-App; verifiziert Phase-2-Signaturen gegen ZATCAs PKI. |
| Saudi-arabische Buchhaltungssoftware (SAP B1, Oracle, Microsoft Dynamics) | Nativ (nach 2023) | Lokalisierte saudi-arabische Builds haben ZATCA-Parsing in der AP-Pipeline. |
| iOS-Kamera | Rohes Base64 | Nicht als Steuerrechnung erkannt. Benutzer muss die FATOORA-App öffnen. |
| Android-Kamera / Google Lens | Rohes Base64 | Gleich, kein natives Parsing. |
| Drittanbieter-Audit-Tools (PwC, KPMG, Deloitte Saudi-Einheiten) | Nativ | Audit-Technologie-Suiten parsen und verifizieren Phase-2-Signaturen. |
Siehe auch
- /zatca-saudi-einvoice-qr-code/, der Generator.
- /standards/, zurück zum Standards-Index.
- ZATCA-Entwicklerportal, offizielle Ressourcen und die FATOORA-Sandbox.