67 Days to ZATCA Phase 2: A Real Implementation Timeline

The client received their ZATCA integration notice on a Sunday afternoon. By the time they contacted us on Monday morning, they had 73 days to go live on Phase 2. They went live on Day 67.

This is the account of that implementation — the actual timeline, the obstacles that appeared, and the decisions that determined the outcome. Names and specific identifiers have been omitted. The technical and process details are accurate.

Day 0–5: Discovery and scope

The client was running SAP ECC 6.0 (now EHP 8) at their Saudi Arabia entity. They had been through Phase 1 — simplified e-invoicing — without external help, using a lightweight connector tool purchased from a local vendor. That connector had been generating Phase 1 invoices correctly, but it stored the signing certificate in a shared network folder and had no API integration with Fatoora. For Phase 2, it was not usable without a complete rearchitecture.

The first five days were assessment: mapping the invoice types in scope (standard tax invoices, credit notes, debit notes), identifying the SAP output format in use, confirming the ECC version and patch level, locating the existing Phase 1 private key and certificate (which took two days — it was on a laptop belonging to a member of staff who had left the company), and establishing the ZATCA portal access credentials.

By Day 5 we had a complete scope: 11 document types, two SAP systems (production and quality), one ECC release, and a missing CSID that had to be reapplied for because the previous certificate had lapsed with the staff departure.

Day 6–18: CSID provisioning and key management

Phase 2 requires a ZATCA-issued Cryptographic Stamp Identifier (CSID). To obtain a CSID, the implementation team generates an ECDSA key pair, creates a certificate signing request (CSR) in the exact format ZATCA requires, and submits it to the Fatoora onboarding API. ZATCA returns a compliance CSID after successful completion of their compliance test invoice sequence.

The key pair was generated on the client's SAP application server. The private key was stored in a secure key store managed by the SAP ABAP layer — not in a file system or shared folder. This is the correct architecture for Phase 2: the key never leaves the server that generates invoices.

The CSID provisioning process took longer than expected. ZATCA's compliance API requires submitting a set of test invoices that pass their validation. Three of the initial test invoices failed validation because the client's invoice numeration sequence did not meet ZATCA's uniqueness requirements in the test environment. This took four days to diagnose and resolve.

Compliance CSID received: Day 18.

Day 19–38: Integration development

The core integration work ran for twenty days. The SAP integration layer involved:

• A custom ABAP class extending the existing billing output type to call the signing service before PDF generation
• A UBL 2.1 XML transformation layer converting SAP billing document data to ZATCA's KSA UBL format
• An ECDSA signing function using the CSID private key
• A clearance API client calling the Fatoora production API with retry logic
• Status tracking table in SAP to record clearance results per invoice
• QR code generation and embedding in the printed invoice PDF

The transformation layer was the most technically demanding component. ZATCA's KSA UBL format has specific extensions that are not present in standard UBL 2.1 — tax line items must carry the ZATCA category code, line-level discount structures must follow ZATCA conventions, and the invoice hash chain must be computed correctly across the invoice sequence.

The hash chain implementation is where most Phase 2 implementations encounter their most serious issue. Each invoice must carry a hash of the previous invoice in the sequence. This is not a simple checksum — it is a SHA-256 hash of the canonical XML of the previous cleared invoice, base64-encoded and embedded in the current invoice XML before signing. If the chain breaks, ZATCA's validation rejects the invoice. Getting the chain implementation correct in the SAP environment, where billing documents can be posted in parallel across multiple application servers, required careful sequencing logic.

Day 39–52: Quality environment testing

The integration was tested in the SAP quality system against ZATCA's simulation environment. The simulation environment replicates production validation behaviour and returns the same error codes and rejection messages as production.

Phase 1 of testing revealed two issues. The first was a character encoding problem: Arabic invoice descriptions were being submitted with incorrect UTF-8 encoding due to a code page mismatch in the SAP RFC layer. The second was a tax amount rounding discrepancy: the client's SAP pricing procedure calculated VAT using an intermediate rounding that produced a one-halala difference in tax amounts on certain invoice configurations, causing ZATCA's validation to reject those invoices.

Both issues were resolved during the quality environment testing phase. The encoding issue required a change to the RFC layer output. The rounding issue required a change to the tax calculation sequence in the ABAP UBL transformation.

Second-phase testing: clean pass on all 11 document types across 400 test invoices.

Day 53–60: Production CSID and parallel run

The compliance CSID obtained on Day 18 is used for testing against ZATCA's compliance environment. For production clearance, a separate production CSID is required. The production CSID is obtained through the same provisioning process, but using the production Fatoora API endpoint.

Production CSID provisioned: Day 53.

From Day 54 to Day 60, the integration ran in shadow mode: every invoice posted in production was also run through the clearance integration in a non-blocking mode, with the clearance result logged but not used to control invoice release. This allowed the team to confirm that production invoice volumes and formats were behaving identically to the quality environment tests.

Shadow mode results: 1,847 invoices processed, 1,847 cleared successfully, zero rejections.

Day 61–67: Go-live

On Day 61, the integration was switched from shadow mode to enforcement mode: invoice release is now contingent on a successful clearance response from Fatoora. Invoices that receive a rejection are held in a pending queue and flagged for review.

Between Day 61 and Day 67, one invoice was rejected — a credit note where the reference invoice number had been entered incorrectly by a billing clerk. The credit note was corrected and resubmitted. It cleared on the second attempt.

By Day 67, the client was fully live on Phase 2. No penalty exposure. The implementation was completed six days ahead of the mandate deadline.

What determined the outcome

A 67-day implementation from a standing start is achievable on SAP ECC with experienced practitioners. Three factors made the difference in this case:

Key management was done correctly from Day 1. The decision to store the ECDSA private key in the SAP application server's key store, rather than in a file system or external service, meant the signing infrastructure was architecturally sound. This also meant the key survived the quality-to-production migration without incident.

The hash chain was treated as a first-class requirement. Many Phase 2 implementations underestimate the complexity of the invoice hash chain in a multi-server SAP environment. Addressing it explicitly in the design phase — before development started — avoided the most common Phase 2 implementation failure mode.

Shadow mode was not skipped. Seven days of shadow mode processing 1,847 production invoices gave the team and the client confidence that the go-live would be clean. The temptation to go directly from quality testing to live enforcement was present — the timeline was tight. Shadow mode was not skipped. It is never skipped on our projects.