The Core Distinction
Clearance applies to Tax Invoices (B2B): ZATCA must validate and stamp the invoice before it can legally be shared with the buyer. Reporting applies to Simplified Tax Invoices (B2C): the invoice is shared with the customer immediately after generation, then transmitted to FATOORA within 24 hours.
| Feature | Clearance (Tax Invoice) | Reporting (Simplified Invoice) |
|---|---|---|
| When FATOORA is involved | Before sharing with buyer | After sharing with customer (within 24 hours) |
| Invoice validity without FATOORA response | Invalid — cannot be shared | Valid for customer immediately; reporting fulfils compliance |
| ZATCA stamp applied | By FATOORA after clearance — embedded in returned XML | By EGS (using CSID) before sharing |
| Submission format to FATOORA | XML only (not PDF/A-3) | XML only (not PDF/A-3) |
| Format shared with buyer | Cleared XML or PDF/A-3 with embedded cleared XML | Printed copy, electronic format, or any human-readable format |
| Credit/debit notes | Tax Invoice notes go through clearance | Simplified Invoice notes go through reporting |
Clearance — The Step-by-Step Process
Your EGS generates the invoice in XML (UBL 2.1), assigns a UUID, calculates and embeds the Previous Invoice Hash (SHA-256), applies your CSID-backed cryptographic stamp, and transmits the complete XML to FATOORA via API. FATOORA runs multi-layer validation. If it passes, FATOORA applies ZATCA’s own cryptographic stamp, updates the QR code, and returns the cleared XML. You then deliver the cleared document to the buyer — as XML or as a PDF/A-3 with the cleared XML embedded.
Every invoice incorporates the hash of the previous invoice — creating a tamper-evident chain. Even a rejected invoice that is never corrected or resent still occupies a position in the chain. Its hash must appear as the Previous Invoice Hash in the next invoice you generate. A system that skips rejected invoices breaks the chain — and ZATCA audits can detect the break mathematically. Confirm your EGS handles this correctly during sandbox testing.
Reporting — The 24-Hour Obligation
Your EGS generates the invoice, assigns a UUID, embeds the Previous Invoice Hash, and applies your cryptographic stamp. The invoice is immediately shared with the customer — printed, emailed, or in any human-readable format. Within 24 hours of the invoice’s generation timestamp, the XML must be submitted to FATOORA. FATOORA validates it and returns a confirmation. If validation fails, the submission must be corrected and resubmitted before the window closes.
A Jeddah supermarket chain generates approximately 4,500 Simplified Tax Invoices per day across three branches. Its POS system transmits invoices to FATOORA in rolling batches every two hours. By 2am, all invoices from the previous trading day have been reported and confirmed. Retry logic catches any connectivity issues automatically. The 24-hour window is met consistently through automated process design — not through manual vigilance.
Rejection Handling
| Response | Tax Invoice Action | Simplified Invoice Action |
|---|---|---|
| Accepted | Share cleared invoice with buyer | Reporting obligation fulfilled |
| Accepted with Warnings | Share cleared invoice; investigate warning for future invoices | Reporting fulfilled; investigate warning |
| Rejected | Do NOT modify original. Generate new corrected invoice with new UUID. Use rejected invoice hash as PIH in new invoice. | Correct data issue; resubmit before 24-hour window expires |
| No connectivity | Retry every 5 min; share uncleared invoice temporarily if no response after ~5 min; retry every 15 min | Queue for retry; 24-hour window still runs |
What FATOORA Validates
| Validation Layer | What It Checks |
|---|---|
| XML schema conformance | Invoice structure matches UBL 2.1 as defined in ZATCA’s XML Implementation Standard |
| Mandatory field presence | All mandatory fields for the invoice type and phase are populated |
| VAT calculation accuracy | VAT amounts at line and document level are mathematically consistent |
| Cryptographic stamp validity | EGS-applied stamp verifiable against the registered CSID |
| UUID uniqueness | UUID has not been used in a previously submitted invoice |
| Invoice counter sequence | Counter value is consistent with the sequence of prior invoices from that EGS unit |
| Previous Invoice Hash | PIH matches the hash of the last accepted invoice from that EGS unit |
| Seller VAT registration | Seller VAT number matches the registered taxpayer profile |
When ZATCA’s Systems Are Unavailable
Tax Invoice during FATOORA outage
Retry clearance every five minutes. After approximately five minutes of failed attempts, you may share the uncleared invoice with the buyer as a temporary measure — ZATCA acknowledges the operational reality. Continue retrying every 15 minutes. Once clearance succeeds, provide the buyer with the cleared version. Retain detailed logs of all retry attempts and timestamps.
Simplified Tax Invoice during FATOORA outage
Share the invoice with the customer immediately as normal. The 24-hour reporting window continues running — it does not pause for FATOORA outages. Queue the invoice for submission and retry automatically until the report is accepted. Log all retry attempts as evidence if the deadline is missed due to a prolonged outage.
Frequently Asked Questions
- Clearance is a legal prerequisite for Tax Invoices — it must happen before the invoice leaves your system. An uncleared Tax Invoice is not a valid VAT document, regardless of content accuracy.
- The 24-hour reporting window for Simplified Tax Invoices is absolute — it does not reset at midnight, pause for weekends, or extend during outages. Automated reporting with fault-tolerant retry logic is the only reliable solution at any transaction volume.
- Rejected invoices retain their identity in the hash chain. Do not modify or drop a rejected Tax Invoice — it must remain in your system, and its hash must appear as the PIH in the next invoice you generate.
- Clearance confirms technical compliance — not correct VAT treatment. ZATCA can still audit the substantive tax position of any cleared invoice.
- Keep detailed logs of all clearance attempts, responses, and retries. Evidence of good-faith compliance during a FATOORA outage substantially changes how a missed window or temporary uncleared invoice is assessed.
Also in this series
This article reflects ZATCA’s E-Invoicing Regulation (December 2020) and the Controls, Requirements, Technical Specifications and Procedural Rules Resolution (May 2023). For informational purposes only — not legal or tax advice. Confirm with zatca.gov.sa or a qualified Saudi tax advisor. dariba.co is an independent platform.