ZATCA Phase 2 invoice validator
Paste or upload a Saudi e-invoice XML and see what ZATCA would likely reject: BR-KSA rules, VAT number, totals, the QR code and the invoice hash, with the field path and the fix for each issue.
Tool
Runs in your browser. The file is never uploaded.
Common errors and how to fix them
Ten causes of rejection that come straight from the rules of the ZATCA XML Implementation Standard v1.2, with the fix for each.
| Rule | What goes wrong | How to fix it |
|---|---|---|
| BR-KSA-40 | Seller VAT number is not 15 digits starting and ending with 3. | Copy the VAT number exactly from the VAT registration certificate, with no spaces. |
| BR-KSA-27 | The XML was edited, re-indented or re-saved after signing, so the hash no longer matches the signed digest and the QR. | Sign the final XML and send it byte for byte. Change nothing after signing. |
| BR-KSA-26 / 61 | Previous invoice hash (PIH) is missing or not the hash of the previous invoice of the same EGS unit. | Store the hash of each invoice you send and use it as the PIH of the next one. |
| BR-KSA-33 / 34 | Invoice counter (ICV) is missing, not numeric, or reset. | Keep one running counter per EGS unit and never reuse a value. |
| BR-KSA-37 / 66 | Seller building number is not 4 digits or the postal code is not 5 digits. | Fill the Saudi national address fields in the company master data. |
| BR-KSA-63 | Standard invoice to a Saudi buyer without the full buyer address (street, building, postal code, city, district). | Complete the national address of the business partner before invoicing. |
| BR-KSA-06 | InvoiceTypeCode/@name is not a 7-digit transaction code such as 0100000 or 0200000. | Map each document type to the right code and set only the flags that apply. |
| BR-KSA-68 | TaxCurrencyCode is missing, or there is no TaxTotal with the VAT in SAR. | Always send TaxCurrencyCode SAR and a TaxTotal holding only the VAT amount in SAR. |
| BR-KSA-23 / 24 / 69 | Zero-rated, exempt or out-of-scope lines without a VATEX-SA exemption reason code. | Add TaxExemptionReasonCode and TaxExemptionReason to each Z, E or O breakdown. |
| BR-KSA-51 / BR-CO-15 | Line amount with VAT or document totals do not add up after rounding. | Round each line VAT to 2 decimals, then sum lines to the header totals. |
Specifications this tool checks against
- ZATCA Electronic Invoice XML Implementation Standard v1.2 (BR-KSA, BR-DEC and BR-CO rules, BR-KSA-27 hashing)
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), used for the invoice hash
https://www.w3.org/TR/xml-c14n11/
Copies of these files, with their SHA-256 checksums, are kept with the tool source. This tool checks against the published ZATCA specifications; it is not ZATCA certified and not an official validator.
Three steps, no signup
Paste or upload the XML
Use the signed XML of a standard (B2B) or simplified (B2C) invoice, credit note or debit note, or load a sample.
Read the report
Errors, warnings and info are grouped, each with the official rule ID (BR-KSA-…), the XML path and how to fix it.
Fix it before ZATCA does
Correct the field in SAP Business One or your ERP, regenerate the XML and check again. Download the PDF for your team.
Questions about this tool
What does this ZATCA validator check?
The UBL 2.1 structure and the KSA business rules of the ZATCA XML Implementation Standard v1.2: invoice type and transaction code (KSA-2), UUID, issue date and time, ICV counter and previous invoice hash (PIH), seller and buyer VAT numbers, national address fields, supply date, exemption reason codes, line VAT and rounding, VAT breakdowns, document totals with 2-decimal rounding, the QR code and the BR-KSA-27 invoice hash.
How is the invoice hash calculated?
As BR-KSA-27 describes: remove ext:UBLExtensions, the cac:AdditionalDocumentReference with ID QR and cac:Signature, canonicalise the rest with C14N 1.1, hash it with SHA-256 and Base64-encode the result. The tool compares it with the digest in the signature and with QR tag 6.
Does it verify the cryptographic signature?
No. It checks that the stamp is present and well formed (SignedInfo, SignatureValue, certificate and signed properties) and that the signed digest matches the invoice. It does not verify the ECDSA signature or the certificate chain, so a PASS here is not a ZATCA clearance or reporting result.
What is the difference between a standard and a simplified tax invoice?
The transaction code in InvoiceTypeCode/@name starts with 01 for a standard (B2B) tax invoice, which ZATCA clears in real time, and 02 for a simplified (B2C) invoice, which must carry the cryptographic stamp and QR code and is reported within 24 hours.
Is this an official ZATCA tool?
No. Kodenova is not affiliated with ZATCA. The tool checks against the published ZATCA specifications; the official answer always comes from the Fatoora platform.
Is my invoice uploaded anywhere?
No. The XML is read and checked by your own browser, and the PDF report is created there too. Nothing is sent to Kodenova or anyone else.
Built for SAP Business One teams
ZATCA Phase 2 from SAP Business One?
We connect SAP B1 to ZATCA: XML, hash chain, signing, QR, clearance and reporting, with logs and retries. Fixed price, usually quoted within 24 hours.