Saudi Arabia’s mandatory e-invoicing program has entered its most commercially impactful stage. Under Phase 2 (Integration Phase), businesses are now required to connect their ERP and billing systems directly to the FATOORA platform operated by Zakat, Tax and Customs Authority (ZATCA).
For finance leaders, this is no longer a regulatory checkbox. Phase 2 introduces real-time invoice clearance, XML-based reporting, cryptographic stamping, and audit-ready data retention — all of which directly affect cash flow, VAT deductibility, and operational continuity.
This guide is written specifically for SAP customers in Saudi Arabia — including SAP S/4HANA and SAP Business One environments — who need a clear, practical understanding of ZATCA Phase 2 requirements, current enforcement waves, and what technical readiness actually looks like before the 2026 deadlines, supported by an expereienced SAP consulting firm in saudi Arabia.
This applies to SAP S/4HANA (utilizing SAP DRC), SAP ECC, and SAP Business One. The strategy differs by environment: while S/4HANA leverages the Standard Document and Reporting Compliance (DRC) framework, ECC and B1 often require specialized connectors or middleware to handle the real-time “handshake” with the Fatoora portal.
ZATCA Phase 2 Rollout: Wave 23 & Wave 24 Deadlines
Saudi Arabia continues the phased rollout of mandatory e-invoicing under the Integration Phase, requiring businesses to connect their systems directly with the FATOORA platform operated by the Zakat, Tax and Customs Authority (ZATCA).
In July 2025, ZATCA confirmed Wave 23, targeting taxpayers with annual VAT-subject revenues exceeding SAR 750,000 during 2022, 2023, or 2024. Affected businesses must complete Phase 2 integration no later than 31 March 2026.
In October 2025, ZATCA announced Wave 24, extending Phase 2 requirements to taxpayers with revenues above SAR 375,000 during the same assessment period. The compliance window for Wave 24 runs from 1 April 2026, with a final enforcement deadline of 30 June 2026, as confirmed by ZATCA’s official implementation decision.
ZATCA formally notifies each affected taxpayer ahead of their enforcement window. Businesses are expected to complete technical integration, testing, and go-live within the notified period to avoid compliance breaches. For official requirements, formats, and integration rules, refer to the ZATCA E-Invoicing Detailed Guideline,
What ZATCA Phase 2 (Integration Phase) Requires from Businesses
ZATCA Phase 2 goes beyond generating electronic invoices. It introduces a continuous transaction control (CTC) model, where invoices must be validated, stamped, and either cleared or reported through the FATOORA platform using standardized technical protocols.
At a high level, Phase 2 requires SAP environments to:
-
- Generate Bilingual XMLs: All invoices and associated Credit/Debit Notes must be generated in UBL 2.1 XML (or PDF/A-3) with mandatory Arabic fields.
- Note Chaining: Ensure all Credit/Debit notes are cryptographically linked to the original SAP invoice hash.
- Cryptographic Stamping: Apply a unique UUID and Digital Signature (CSID) per device.
- Standard vs. Simplified Flow: Transmit Standard Tax Invoices (B2B) for real-time clearance and Simplified Tax Invoices (B2C) for 24-hour reporting.
- Master Data Validation: Enforce Saudi National Address and VAT ID accuracy directly within the SAP “Business Partner” master.
The exact flow differs depending on whether the transaction is B2B (clearance model) or B2C (near-real-time reporting) — a distinction that has direct implications for ERP configuration and system performance.
B2B vs B2C E-Invoicing in ZATCA Phase 2: Clearance vs Reporting Explained
Under ZATCA Phase 2, not all invoices follow the same compliance flow. The Integration Phase introduces two distinct models depending on the transaction type: Clearance (B2B) and Near Real-Time Reporting (B2C).
Understanding this distinction is critical, because SAP must be configured differently for each flow, and errors here are one of the most common causes of failed Phase 2 audits.
B2B Transactions — Clearance Model
Standard Tax Invoices (B2B) — The Clearance Model For Business-to-Business (B2B) and Business-to-Government (B2G) transactions, the “Clearance” model applies. In this flow, the invoice is legally invalid until ZATCA returns a cleared XML with a cryptographic stamp.
How it works:
- SAP generates the invoice in structured XML format
- The invoice is cryptographically signed
- The invoice is transmitted to ZATCA’s FATOORA platform via API
- ZATCA validates and returns a clearance response
- Only cleared invoices can be shared with the customer and posted for VAT
Critical implication for SAP users:
If clearance fails, the invoice cannot be issued, revenue recognition is delayed, and VAT deductibility may be impacted.
B2C Transactions — Near Real-Time Reporting Model
Simplified Tax Invoices (B2C) — The Reporting Model For Business-to-Consumer (B2C) transactions, the “Reporting” model allows for immediate issuance. However, the SAP system must be configured to batch or transmit these to ZATCA within 24 hours of the timestamp.
How it works:
- SAP issues the invoice or receipt
- Cryptographic stamping is applied
- Invoice data is reported to ZATCA within the mandated time window
- ZATCA acknowledgment is stored for audit purposes
Critical implication for SAP users:
High-volume retail environments must ensure system performance and queue stability, or reporting backlogs can create compliance exposure.
Why This Matters for SAP Architecture
Many SAP projects fail ZATCA Phase 2 not because the ERP is wrong — but because:
- B2B and B2C flows are treated identically
- Clearance latency is not accounted for in order-to-cash design
- Error handling and retry logic are missing
- Reporting queues are not monitored
In SAP environments, this directly affects:
- Sales posting logic
- VAT reporting accuracy
- Cash flow timing
- Audit readiness
This is why ZATCA compliance cannot be handled as a “billing add-on” — it must be architected into the SAP transaction lifecycle.
SAP S/4HANA vs SAP Business One for ZATCA Phase 2: What Saudi Businesses Must Know
ZATCA Phase 2 compliance is not solution-agnostic.
While both SAP S/4HANA and SAP Business One (B1) can support e-invoicing integration, their readiness models, risks, and scalability profiles differ significantly.
Choosing the wrong SAP platform — or underestimating its limitations — is a leading cause of integration delays, failed testing cycles, and post–go-live penalties in Saudi Arabia. If you need local delivery ownership, work with an SAP partner in Saudi Arabia that can design B2B clearance vs B2C reporting correctly in your SAP landscape.
SAP S/4HANA — Enterprise-Grade ZATCA Architecture
SAP S/4HANA is designed to support high-volume, real-time clearance and reporting scenarios across complex organizational structures.
Strengths for ZATCA Phase 2:
- Native support for structured XML invoice generation
- Scalable API orchestration for clearance and reporting
- Advanced error handling and retry logic
- Better performance under clearance latency (B2B)
- Easier separation of B2B clearance vs B2C reporting flows
- Strong audit traceability for VAT and compliance reviews
Best suited for:
- Enterprises with multiple entities or VAT registrations
- High B2B invoice volumes
- Complex order-to-cash processes
- Organizations already planning RISE or cloud migration
Primary risk (if mismanaged):
Over-engineering the solution without aligning it to Saudi compliance workflows, resulting in unnecessary cost and complexity.
SAP Business One — SME-Focused ZATCA Enablement
SAP Business One can support ZATCA Phase 2 compliance, but with tighter architectural boundaries.
Strengths for ZATCA Phase 2:
- Faster deployment for SMEs
- Lower implementation cost
- Suitable for lower invoice volumes
- Simpler operational model
Limitations that must be managed carefully:
- Dependency on add-ons or middleware for API orchestration
- Limited native error-handling sophistication
- Performance sensitivity in high-volume retail or hybrid B2B/B2C models
- Less flexibility for future regulatory expansion
Best suited for:
- Single-entity businesses
- Moderate invoice volumes
- SMEs newly entering Phase 2 thresholds (Wave 23 / Wave 24)
Primary risk (if ignored):
Treating Business One like an enterprise platform and pushing it beyond its intended compliance envelope.
The Saudi Reality: Platform ≠ Compliance
ZATCA Phase 2 failures are rarely caused by SAP itself.
They occur when businesses assume:
- “Any SAP system is automatically compliant”
- “Add-ons will handle everything”
- “Compliance can be retrofitted later”
In reality, ZATCA compliance is an architectural decision, not just a functional one.
The correct question is not:
“Can this SAP system integrate with ZATCA?”
But:
“Is this SAP system aligned with our Saudi transaction volumes, audit exposure, and growth horizon?”
ZATCA Phase 2 Technical Architecture: How SAP Integrates with the FATOORA Platform
ZATCA Phase 2 is not a reporting upgrade.
It is a real-time system integration mandate that fundamentally changes how invoices are created, validated, cleared, and stored inside SAP.
At a technical level, Phase 2 requires SAP systems to connect directly with the national FATOORA platform operated by Zakat, Tax and Customs Authority, exchanging structured invoice data through secure APIs before (or immediately after) invoice issuance.
The Core ZATCA Phase 2 Architecture (SAP View)
At a minimum, every compliant SAP architecture in Saudi Arabia must support five mandatory technical layers:
|
Layer |
Purpose |
Why ZATCA Cares |
|
Invoice Generation |
Create structured XML invoices |
Ensures standardized data |
|
Cryptographic Signing |
Hashing & digital signatures |
Prevents invoice tampering |
|
API Connectivity |
Secure system-to-system exchange |
Enables real-time validation |
|
Clearance / Reporting |
ZATCA approval or notification |
Legal enforceability |
|
Audit & Archiving |
Long-term invoice traceability |
VAT audits & penalties |
If any one layer fails, the invoice becomes non-compliant, regardless of SAP version.
Clearance vs Reporting: Two Integration Models (Mandatory)
ZATCA Phase 2 enforces two different technical workflows, depending on transaction type.
B2B Transactions — Clearance Model
For B2B invoices:
- SAP generates XML invoice
- Invoice is cryptographically signed
- SAP sends invoice to ZATCA via API
- ZATCA validates and clears invoice
- Cleared invoice is returned with approval
- Only approved invoices may be shared with customers
Key risk:
If clearance fails, the invoice is legally invalid.
B2C Transactions — Reporting Model
For B2C invoices:
- SAP generates and signs invoice
- Invoice is issued immediately to customer
- Invoice is reported to ZATCA within the defined timeframe
Key risk:
Late or missing reporting triggers penalties and audit flags.
SAP Integration Flow (End-to-End)
A compliant SAP ZATCA flow typically follows this sequence:
- Transactional Event: Sales invoice created in SAP
- Compliance Layer Trigger: ZATCA logic determines B2B vs B2C path
- XML Generation: Invoice transformed into ZATCA-mandated XML structure
- Cryptographic Controls: Hash, UUID, and digital signature applied
- API Communication: Invoice transmitted to FATOORA endpoints
- Response Handling: Clearance approval, warning, or rejection
- SAP Status Update: Invoice status locked or released
- Archiving & Audit Trail: XML, QR, and response stored securely
This flow must operate without manual intervention to pass compliance audits.
Common Architecture Failure Points (Saudi Reality)
Based on real Phase 2 audits, the most common failures include:
- Incorrect XML schemas
- Missing cryptographic fields
- Improper handling of clearance rejections
- Invoice issuance before clearance
- Weak error-handling and retry logic
- Poor segregation of B2B vs B2C flows
These failures almost always stem from implementation shortcuts, not SAP limitations.
Why Add-Ons Alone Are Not Enough
Many businesses assume:
“Installing a ZATCA add-on = compliance”
This is incorrect.
Add-ons may handle:
- XML formatting
- API calls
But they do not replace:
- Proper SAP process design
- Transaction flow governance
- Audit-grade archiving
- Saudi-specific business logic
ZATCA evaluates the entire system behavior, not just the connector.
Architecture Must Match Saudi Business Reality
ZATCA Phase 2 architecture must align with:
- Invoice volumes
- Entity structures
- VAT registrations
- Retail vs enterprise models
- Growth into future ZATCA waves
This is why architecture decisions made today directly impact compliance risk in 2026 and beyond.
ZATCA Phase 2 Testing, Certification & Go-Live Readiness Checklist (SAP)
ZATCA Phase 2 compliance is not achieved at integration — it is achieved at successful testing, certification, and controlled go-live.
Many Saudi businesses fail after building the integration because they underestimate ZATCA’s validation rigor, timeline discipline, and audit expectations enforced by Zakat, Tax and Customs Authority.
This section defines the exact readiness framework SAP systems must pass before invoices can legally flow in production.
Phase 1: Pre-Testing Readiness (Internal SAP Controls)
Before engaging ZATCA’s test environment, SAP must demonstrate internal technical readiness.
Mandatory Internal Checks
|
Area |
Validation Requirement |
|
Invoice Scenarios |
All B2B & B2C cases covered |
|
XML Schema |
100% compliant with ZATCA format |
|
Cryptography |
Hash, UUID, and digital signature verified |
|
Error Handling |
Automatic rejection capture & retry |
|
Invoice Locking |
No posting before clearance (B2B) |
|
Audit Logging |
Immutable storage of XML & responses |
If these fail internally, ZATCA testing will fail repeatedly, delaying go-live.
Phase 2: ZATCA Sandbox Testing (Mandatory)
ZATCA requires all businesses to validate integration using official sandbox endpoints before production approval.
What Happens in Sandbox Testing
- SAP submits sample invoices
- ZATCA validates:
- Structure
- Cryptography
- Business rules
- Structure
- ZATCA returns:
- Approval
- Warning
- Rejection with error codes
- Approval
Critical Requirement
SAP must correctly interpret and handle every response type, not just approvals.
Hidden Risk:
Ignoring warning responses leads to audit exposure later.
Phase 3: Production Readiness & Certification
After sandbox approval, businesses must prepare for production certification.
Go-Live Prerequisites
- Valid Production API credentials
- Certificate lifecycle management
- Failover & retry logic
- Monitoring dashboards
- Invoice volume stress testing
- Archival policy aligned with VAT law
ZATCA does not allow phased go-live by department. Once live, all invoices must comply.
Phase 4: Post Go-Live Monitoring (Most Missed Step)
ZATCA Phase 2 is not “set and forget.”
Post go-live controls must include:
- Daily clearance success monitoring
- Rejection trend analysis
- Certificate expiry tracking
- Regulatory update readiness
- Quarterly internal compliance audits
Most penalties occur after go-live — not during onboarding.
Common Go-Live Failure Patterns (Saudi Audits)
|
Failure |
Impact |
|
Clearance delays |
Cash flow disruption |
|
XML version mismatch |
Invoice rejection |
|
Missing archive |
VAT audit penalties |
|
Certificate expiry |
System-wide invoice halt |
|
Poor monitoring |
Undetected non-compliance |
These failures are operational, not technical — and fully preventable.
Executive Readiness Test (Boardroom Lens)
Before approving go-live, leadership should answer YES to all:
- Can we prove compliance in an audit today?
- Can we stop invoice issuance automatically if ZATCA is unavailable?
- Do we have internal ownership of ZATCA monitoring?
- Are we prepared for future waves without rework?
If not — go-live is a liability, not a milestone.
This is why Saudi organizations increasingly rely on a SAP partner in Saudi Arabia with proven Phase 2 delivery experience and local compliance ownership — if you want Business Line to assess your SAP landscape for Wave 23/24 readiness,