Saudi finance teams have been living under ZATCA's Phase 2 e-invoicing obligations since 2023, and a recurring confusion shows up in nearly every implementation: ZATCA's cryptographic invoice stamping is being treated as if it were the same thing as an electronic signature under the Saudi Electronic Transactions Law (ETL). They are not. They are different cryptographic objects, regulated by different authorities, serving different legal purposes — and conflating them creates real compliance gaps in both directions. The two frameworks do intersect, but at specific operational points that procurement, tax, and legal teams need to understand together. Here is how the two systems actually fit, where they overlap, and what changes for the contracts that sit upstream of every invoice.
ZATCA e-invoicing Phase 1 (Generation Phase, December 2021) and Phase 2 (Integration Phase, January 2023) — Phase 2 introduced the structured XML invoice format, cryptographic stamp, QR codes, and real-time integration with ZATCA's FATOORA platform
ZATCA — Zakat, Tax and Customs Authority
Phase 2 technical stack: UBL 2.1 XML invoice format, cryptographic stamp identifier (CSID) issued per taxpayer, ECDSA/RSA-signed XML, TLV-encoded QR code, real-time API integration for B2B and B2G invoices
ZATCA Technical Specifications for E-Invoicing, 2023
of taxpayer onboarding into Phase 2 ZATCA integration since 2023 — sized down progressively from the largest VAT-registered businesses to small and medium enterprises. The smallest taxpayer tiers are still being phased in
ZATCA Wave Announcements, 2023–2026
The fundamental distinction: stamp vs signature
The ZATCA cryptographic stamp and an electronic signature under Saudi ETL look similar at a technical level — both involve cryptographic operations on a digital document — but they are legally and operationally different objects. The distinction matters because confusing them creates compliance gaps in both directions: assuming ZATCA stamping satisfies ETL signing obligations (it doesn't), or assuming an ETL e-signature satisfies ZATCA invoicing obligations (it doesn't).
ZATCA cryptographic stamp vs Saudi ETL electronic signature — the technical and legal distinctions that matter operationally.
| Jurisdiction | Law | Cross-border transfer rule | Intensity |
|---|---|---|---|
| Legal basis | ZATCA stamp | Issued under VAT Implementing Regulations + ZATCA e-invoicing technical regulation. A tax-integrity instrument, not a contract instrument. | Moderate |
| Legal basis | ETL e-signature | Issued under Saudi ETL (Royal Decree M/18 of 1428H). A contract-execution instrument carrying evidentiary weight in commercial disputes. | Moderate |
| What it binds | ZATCA stamp | Binds the invoice XML to the issuing taxpayer's cryptographic stamp identifier (CSID). Proves invoice integrity and origin for tax purposes. | Moderate |
| What it binds | ETL e-signature | Binds a signed document to a specific natural-person or legal-entity signer at a specific time. Proves intent to be bound. | Moderate |
| Issuing authority | ZATCA stamp | CSID issued by ZATCA via the FATOORA platform onboarding flow; uses ZATCA-managed PKI. | Moderate |
| Issuing authority | ETL e-signature | Self-managed cryptographic material (AES) or CST-licensed certification service provider (QES); separate PKI from ZATCA. | Moderate |
| Required by | ZATCA stamp | Every VAT-registered taxpayer in Phase 2 scope must apply the stamp to every B2B and B2G invoice. Failure carries tax penalties. | Strict |
| Required by | ETL e-signature | Required for the signed document itself (the contract giving rise to the invoice), not for the invoice. Different documents, different requirements. | Moderate |
ZATCA stamping is mandatory for the invoice. ETL signing is the natural mechanism for the contract that generates the invoice. Neither substitutes for the other. A sales contract with an ETL-compliant electronic signature still requires every invoice issued under it to carry a ZATCA stamp; a properly stamped ZATCA invoice does not retroactively make the underlying agreement a legally signed contract.
— The point most teams miss until audit
Where the two frameworks actually intersect
The distinction above does not mean the two worlds are sealed off from each other. There are four operational intersections where signing and stamping decisions need to be made together, not separately:
The four signing-stamping intersection points
- Master service agreements that determine invoice terms
The MSA between buyer and supplier is signed under ETL — it establishes the legal basis, pricing, payment terms, and tax treatment that every downstream invoice operationalises. A poorly signed MSA undermines the legal weight of every invoice issued under it, regardless of how perfectly stamped each invoice is.
- Sales contracts triggering invoice generation
When a contract execution triggers automatic invoice generation (common in subscription, recurring-revenue, and project-based businesses), the contract signing event needs to flow data cleanly into the invoicing system. Misalignment between signed contract terms and stamped invoice line items is the most common audit finding.
- PKI and certificate management infrastructure
Both ZATCA stamping and ETL AES/QES signing rely on cryptographic key management at the organisation level. Keys must be protected, rotated, audited, and recovered against the same operational standards even though they serve different frameworks. Most mature organisations centralise this in a single PKI governance function.
- Audit trail and record-keeping alignment
Both frameworks require long-term retention of cryptographic artefacts (the stamped invoice for ZATCA, the signed contract and audit trail for ETL). Retention schedules should be designed together — the signed contract typically needs longer retention than the invoices it generated, because the contract evidences the legal relationship while the invoice only evidences a specific tax event.
The end-to-end flow — contract to invoice to compliance
Here is what the integrated flow looks like for a typical Saudi B2B transaction subject to both ETL signing obligations and ZATCA Phase 2 invoicing obligations:
MSA or sales contract signed under Saudi ETL
Buyer and supplier execute the master agreement or sales contract via an ETL-compliant electronic signature (AES sufficient for most commercial agreements). The signed contract establishes pricing, tax treatment, payment terms, and the legal relationship that authorises invoicing.
Goods or services delivered; invoice triggered
Delivery (or service performance, or milestone achievement) triggers invoice generation per the signed contract terms. The contract content drives invoice content — line items, pricing, tax category.
Invoice generated in ZATCA UBL 2.1 format
The invoicing system produces the invoice in the structured XML format ZATCA mandates. The invoice carries the supplier's VAT registration number, the buyer's details (B2B), line items, tax breakdown, and total — all in the prescribed XML structure.
Cryptographic stamp applied using the supplier's CSID
The supplier's e-invoicing solution applies the cryptographic stamp using the CSID issued by ZATCA during Phase 2 onboarding. The stamp cryptographically binds the invoice content to the supplier's identity.
Real-time integration with ZATCA FATOORA
For B2B and B2G invoices, the stamped XML is transmitted to ZATCA's FATOORA platform in real time via the integration API. ZATCA acknowledges; the invoice is then valid for issuance to the buyer. A TLV-encoded QR code is generated and printed on the visual invoice.
What changes for the upstream contract
The most important compliance shift Phase 2 introduced is not technical — it is the operational pressure it puts on the contracts that sit upstream of every invoice. When invoice generation is real-time, structured, and cryptographically bound, the contract that authorises the invoice has to be at least as defensible as the invoice itself.
What Phase 2 forces upstream contract management to do
- Capture invoice-relevant data structurally at signing
Contracts that drive automated invoicing need structured data capture at signing — VAT registration numbers of both parties, agreed pricing per SKU/service, applicable tax categories, payment terms. PDF-only contracts with free-text pricing are now an operational bottleneck.
- Bind the signed contract to a specific signer identity
AES (or QES for QES-required documents) under Saudi ETL — the contract signer must be cryptographically identified so that audit trails can trace any invoice line item back to the contract clause that authorised it, and to the person who signed that contract.
- Retain signed contracts alongside stamped invoices
A ZATCA audit may ask not just for the stamped invoices but for the contract authorising them. Signed contracts should be retained in the same archival system as the stamped invoices, with cross-references between them.
- Handle amendments and addenda as signed documents
Mid-contract price adjustments, scope changes, and addenda all need to be signed under ETL with the same rigour as the original contract — because they change the basis for downstream invoices and the audit needs to follow that chain.
- Align PDPL data flows for both signing and invoicing
Both the contract signing and the invoice issuance process personal data (signer identifiers, contact details, sometimes individual buyer information for B2C). Saudi PDPL (Royal Decree M/19 of 1443H) applies to both flows; the PDPL compliance post covers the data-protection mechanics in detail.
Compliant vs sloppy — what the difference looks like in practice
Integrated contract + invoice posture
What a Saudi B2B operation looks like with the two frameworks aligned.
- Contracts signed via AES under Saudi ETL; signer identity cryptographically bound to the agreement
- Structured pricing/tax/payment data captured at signing, feeds the invoicing system directly
- Invoice generated in ZATCA UBL 2.1 format with CSID-based cryptographic stamp; real-time FATOORA integration
- Cross-references between signed contracts and stamped invoices maintained in a unified archive
- Amendments and addenda signed with the same ETL rigour as the original contract
- PDPL-compliant data handling across both signing and invoicing flows; in-region hosting
- Audit can trace any invoice line back to the contract clause and signer that authorised it
Stamped invoices, sloppy contracts
The most common Phase 2 implementation pattern — invoicing solved, contracts left behind.
- Invoices perfectly stamped and integrated with FATOORA
- Underlying contracts still printed, signed by hand, scanned, filed in disparate locations
- No structured data flow from contracts to invoices; finance team manually translates terms each cycle
- Contract amendments handled by email; invoices issued under unclear contractual basis
- Audit can verify invoice integrity but cannot reliably link invoices back to signed contracts
- PDPL exposure on the contract side because signing platforms host outside the region
- VAT disputes harder to defend because the contractual basis for tax treatment is in a paper file somewhere
The takeaway
ZATCA Phase 2 solved invoicing. It did not solve contracts. For Saudi B2B teams, the integrated compliance posture requires both — ETL-compliant electronic signing for the contracts that drive invoicing, and ZATCA-compliant cryptographic stamping for the invoices themselves. The two frameworks are technically and legally distinct but operationally inseparable. Treating them as a single integrated workflow (rather than two parallel projects) is what distinguishes the organisations that pass ZATCA audits cleanly from those that get stuck in remediation cycles.
ETL electronic signing covers the contracts; ZATCA cryptographic stamping covers the invoices those contracts authorise. Mature Saudi B2B operations treat them as a single integrated compliance workflow with shared PKI governance, aligned retention schedules, and cross-referenced archives — not as two separate projects run by tax and legal teams in different rooms.
SahlSign Saudi customer integration patterns, 2026
Related reading
- AES vs QES with Nafath: Why Most Saudi Business Signing Doesn't Need Qualified — the Saudi-specific tier-selection argument for contracts that sit upstream of every ZATCA-stamped invoice.
- PDPL and PDPPL Compliance in E-Signing — Saudi PDPL applies to both signing and invoicing data flows; the joint-controllership and cross-border-transfer mechanics matter for both.
- Why Regional Hosting Matters for Sensitive Documents — contract data and invoice data carry the same residency considerations; hosting decisions should cover both.
Sources
- ZATCA — Zakat, Tax and Customs Authority
- ZATCA E-Invoicing (Fatoorah) regulations and technical specifications
- ZATCA FATOORA Platform
- Saudi Electronic Transactions Law — Royal Decree No. M/18 of 1428H
- Saudi VAT Implementing Regulations
- Saudi Personal Data Protection Law — Royal Decree M/19 of 1443H
- Communications, Space and Technology Commission (CST) — PKI regulator
- SDAIA — Saudi Data and AI Authority