What Phase 2 actually requires
ZATCA Phase 1 required businesses to generate structured PDF invoices. Phase 2 is a different category of obligation entirely. Under Phase 2 — the clearance model — every B2B and B2G invoice must be submitted to the Fatoorah API in real time, cleared by ZATCA, and returned with a cryptographic stamp before it can be issued to the buyer.
The technical requirements are specific. Each invoice must be generated as a UBL 2.1 XML document. It must carry a UUID assigned at the point of creation. A cryptographic hash is computed over the invoice data and signed using an ECDSA key pair registered with ZATCA. A QR code is generated and embedded in the invoice. The counter field — a sequential number — must increment correctly across all invoices from that device. The cleared invoice and its metadata must be archived for five years.
Phase 1 compliance — generating a PDF report — does not prepare your systems for any of this. The gap between the two is not a configuration change. It is an architectural one.
Where most ERPs fail
The most common failure mode is the bolt-on connector. A third-party tool receives an export from your ERP, generates the ZATCA XML separately, submits it, and returns a status code. The ERP itself never touches the Fatoorah API.
This architecture introduces compounding risks. First, field mapping: the connector must correctly interpret every field from your ERP export — buyer TIN, item code, VAT category, discount treatment. Any mismatch produces a rejection at the Fatoorah API that your finance team may not see until the invoice is already late.
Second, timezone handling. ZATCA timestamps must be in the correct format and timezone. Systems that generate timestamps from a server in a different region or that apply DST incorrectly produce submission errors that are non-obvious to diagnose.
Third, the retry problem. Fatoorah API downtime is real. When the clearance API is unavailable, invoices must queue and retry without creating duplicates. Bolt-on tools frequently lack this logic, leading to either duplicate submissions or invoices stranded in a limbo state — issued to the customer but not cleared by ZATCA.
Fourth, disconnected error surfacing. When a clearance fails, the error should appear in the workflow where the invoice was created — not in a separate compliance dashboard that your finance team checks separately, or not at all.
What a native implementation looks like
In a natively integrated system, the clearance flow begins the moment an invoice is posted. The platform generates the UBL XML, computes the counter and UUID, signs the document server-side using the registered ECDSA key, and submits to the Fatoorah API — all within the same transaction.
If the submission succeeds, the cleared XML and ZATCA stamp are stored against the invoice record. The QR code is generated from the cleared document. The invoice is marked as compliant and available for dispatch to the buyer.
If the submission encounters a transient error — API timeout, rate limit, 503 — the invoice enters a retry queue with exponential backoff. The submitting user sees a pending status. No invoice is dispatched until clearance is confirmed. Duplicate prevention is enforced at the UUID level.
Errors that require human review — field rejections, schema violations, key expiry warnings — surface as workflow items, not log files. The finance team sees what failed, why it failed, and what action is required. They do not need access to a separate tool to find this.
Questions to ask your ERP vendor
Before accepting a vendor's claim of ZATCA Phase 2 compliance, ask these six questions directly:
1. Does the cryptographic hash and ECDSA signature happen inside the ERP, or in a third-party connector? If the answer is "connector," ask to see the error handling and retry architecture.
2. How does the system handle the invoice counter field? The counter must be per-device and sequential without gaps. Ask how the vendor prevents counter drift in multi-user environments.
3. What happens when the Fatoorah API returns a 503? Walk through the exact retry mechanism. Ask whether a timed-out submission can create a duplicate if retried.
4. Where does the archived cleared XML live? ZATCA requires five-year retention of cleared documents. Ask whether that storage is within the ERP database, and whether it is immutable.
5. How does the platform handle ECDSA key expiry and renewal? ZATCA requires periodic renewal of the cryptographic key pair. Ask whether the renewal process requires downtime or manual intervention.
6. Can you see the error log from a failed clearance in the same screen where the invoice was created? Ask for a demo of the failure state — not just the happy path.