ZATCA E-Invoicing with Oracle Fusion: A Practical Integration Blueprint for Saudi Arabia
Saudi Arabia's e-invoicing programme is not simply a change to the invoice layout. For businesses using Oracle Fusion Cloud ERP, it creates an operational integration between finance, tax, customer master data and the Zakat, Tax and Customs Authority (ZATCA).
An invoice can be complete in Oracle Fusion and still fail ZATCA validation because of missing tax data, an incorrect identifier, an invalid XML rule, a security problem or a mismatch in the calculated totals. A successful design must therefore cover the complete invoice lifecycle—not only XML generation.
This article explains a practical architecture for connecting Oracle Fusion Receivables to ZATCA's Fatoora platform, with the controls required for clearance, reporting, status tracking and audit readiness.
Core principle: A compliant invoice is an end-to-end business outcome—not simply a valid XML file.
What is ZATCA e-invoicing?
ZATCA e-invoicing, also called FATOORA, requires Saudi VAT taxpayers to issue invoices in a structured electronic format. Under Phase 2, selected taxpayers must integrate their e-invoicing solution with ZATCA systems for invoice clearance or reporting, based on invoice type and their notified integration wave.
ZATCA Phase 2 requirements for Oracle Cloud ERP
ZATCA introduced e-invoicing in two phases. Phase 1, effective from 4 December 2021, required taxpayers to generate and store electronic invoices using compliant systems. Phase 2, which started on 1 January 2023 and has been introduced in waves, adds integration with ZATCA's systems. The official scope and rollout remain available on ZATCA's rollout phases page.
The two main document flows are:
- Standard tax invoices, commonly used for business-to-business transactions, follow the clearance route. The invoice is submitted to ZATCA before it is issued to the buyer.
- Simplified tax invoices, commonly used for business-to-consumer transactions, follow the reporting route.
These flows have different operational behaviour, but they should use the same controlled foundation: reliable source data, compliant XML, secure communication, status persistence and reconciliation.
Clear with ZATCA before releasing the invoice to the buyer.
Report through the applicable ZATCA route and retain the response.
How Oracle Fusion integrates with the FATOORA platform
Oracle Fusion Receivables is the financial system of record. It holds the transaction, customer, tax, accounting and payment information. Oracle also supports electronic invoice processing and UBL 2.1 data elements.
However, ZATCA compliance requires more than exporting a generic UBL invoice. The solution must apply the Saudi-specific XML structure and validation rules, manage cryptographic and onboarding requirements, call the correct Fatoora endpoint, interpret the response and update the business process in Oracle Fusion.
A robust design normally contains the following layers:
- Oracle Fusion Receivables as the source of the legal and financial transaction.
- Oracle Integration Cloud (OIC) to orchestrate extraction, transformation, API calls, callbacks, exceptions and status updates.
- A compliance transformation service to create and validate the ZATCA invoice XML, generate required security elements and apply document-specific logic.
- ZATCA Fatoora APIs for onboarding, compliance testing, clearance and reporting.
- An operational dashboard and audit store for requests, responses, timestamps, errors, retries and reconciliations.
This separation is important. Oracle Fusion should remain the financial source of truth, while the compliance service handles the fast-changing technical rules of the tax platform.
The end-to-end invoice flow
1. Complete the source transaction
The process starts when an invoice or credit memo reaches the agreed status in Oracle Fusion. The integration can be initiated by a business event, a scheduled process or a controlled combination of both. Oracle documents supported integration events in the Oracle ERP Cloud Adapter capabilities.
Before extraction, the solution should check whether the document is within scope and identify its flow. Useful decision inputs include transaction type, customer class, establishment, legal entity, tax registration, business unit and document reason.
2. Extract a canonical invoice payload
OIC retrieves the required header, line, tax, party, address, reference and payment data. The payload should be normalized into an internal canonical model before it is transformed into ZATCA XML.
The canonical model makes the design easier to support. Oracle fields can change, new business units can be added and ZATCA rules can evolve without tightly coupling every source field to a single XML node.
3. Validate business data before XML generation
The least expensive failure is the one prevented before submission. Pre-validation should detect issues such as:
- missing or malformed seller and buyer identifiers
- incomplete addresses
- incorrect tax categories or exemption reasons
- inconsistent line, allowance, charge, tax and document totals
- duplicate invoice references
- missing credit-note references
- unsupported unit-of-measure or currency codes
- incorrect classification as a standard or simplified document
These checks should return a business-readable message. “Buyer tax registration number is missing” is more useful to finance than a raw XML path or HTTP error.
4. Generate and validate the ZATCA XML
The transformation service converts the canonical payload into the required XML. It should apply the current ZATCA data dictionary, XML implementation standard and security requirements published through the official e-invoicing portal.
Validation should occur locally before an API call. It should cover schema validation, business rules, calculations, mandatory elements, codes and security controls. Local validation reduces unnecessary calls and shortens the time needed to resolve issues.
5. Submit for clearance or reporting
The integration calls the appropriate Fatoora API. ZATCA's official Fatoora Portal User Manual describes onboarding, compliance, production CSID, clearance and reporting services.
For a standard invoice, the customer-facing document should only be released after a successful clearance response. For a simplified invoice, the solution follows the reporting process and stores the authority response against the transaction.
Every submission should have an idempotency strategy. A timeout must not cause the same business document to be created or processed twice. The application should first establish whether the earlier call succeeded before attempting a controlled retry.
6. Persist the result in Oracle Fusion
The result should be visible to finance users without requiring them to open an integration console. Depending on the customer's design, the integration can update descriptive flexfields, attachments, references or a connected compliance repository.
At minimum, retain:
- Oracle transaction number and internal identifier
- invoice UUID and document type
- submission route and timestamp
- clearance or reporting status
- ZATCA request and response identifiers
- accepted XML and customer-facing output
- warnings and errors
- retry and correction history
Oracle's Receivables Invoices REST resources can form part of the controlled read/write design, subject to the customer's release and security policies.
7. Deliver the invoice and reconcile
After the relevant success response, the invoice can be delivered through the agreed customer channel. The process is not finished until the document is reconciled across Oracle Fusion, the integration platform and ZATCA.
A daily control should identify:
- completed Oracle transactions not submitted
- submitted documents without a final response
- rejected documents awaiting correction
- transactions retried more than the approved limit
- differences between Oracle and XML totals
- cleared documents not delivered to the customer
Master data is the real starting point
Many e-invoicing programmes focus first on APIs. In practice, master data causes a large share of production exceptions.
The readiness assessment should cover legal entities, tax registrations, business units, customer accounts, customer sites, address formats, transaction types, tax rates, exemption reasons, units of measure, currencies and payment methods. It should also establish field ownership: who creates the value, who approves it and who corrects it when an invoice fails?
Where one Oracle field is used for several business purposes, avoid hidden assumptions in the transformation. Define the rule explicitly and maintain it as configuration wherever possible.
Security and certificate lifecycle
ZATCA integration includes device or solution-unit onboarding, compliance checks and production credentials. These are operational assets, not one-time implementation tasks.
The production design should include:
- secure storage of secrets, certificates and private keys
- separate credentials and endpoints for development, simulation and production
- controlled renewal and revocation procedures
- least-privilege access
- masking of sensitive data in logs
- audit trails for configuration changes
- alerts before certificate or credential expiry
ZATCA provides official technical material for systems developers, which should be checked when implementing or updating these controls.
Operational safeguard: Treat certificates, credentials and renewal dates as monitored production assets.
Exception handling that finance teams can operate
Failures should be separated into clear categories:
- Source-data error: correct the customer, tax or transaction data in Oracle Fusion.
- Validation error: correct the mapping or document data before resubmission.
- Authority rejection: interpret the ZATCA rule and follow the approved correction process.
- Technical error: retry safely after a network or platform failure.
- Security error: stop processing and escalate credential, certificate or signature issues.
The dashboard should show the owner, age, severity and next action for every exception. Automated retries should be limited to transient technical failures; a business rejection should not loop without correction.
Testing strategy
A successful test programme covers more than a few normal invoices. It should include:
- standard and simplified invoices
- credit and debit scenarios where applicable
- taxable, zero-rated and exempt treatments used by the business
- discounts, charges, rounding and foreign currency
- multiple lines and units of measure
- missing or invalid buyer data
- duplicate submissions and timeouts
- high-volume and peak-period performance
- certificate renewal and endpoint failure
- reconciliation between Oracle, XML and ZATCA responses
Business users should approve both the financial result and the operational recovery process.
Implementation checklist
- Confirm the taxpayer's Phase 2 wave and in-scope legal entities.
- Classify every relevant transaction type as standard or simplified.
- Complete the Oracle-to-ZATCA field mapping.
- Clean customer, address, tax and unit-of-measure data.
- Define pre-validation and calculation controls.
- Complete onboarding and compliance testing.
- Design idempotent submission and safe retry behaviour.
- Persist XML, responses and statuses for audit.
- Give finance users a business-readable exception dashboard.
- Reconcile Oracle Fusion, the integration layer and ZATCA daily.
- Document security, certificate renewal and support ownership.
- Retest after Oracle, OIC or ZATCA specification changes.
Build compliance into the transaction lifecycle
ZATCA e-invoicing works best when compliance is part of the Oracle Fusion transaction lifecycle, not an isolated interface added after invoicing. The right architecture gives tax teams control, finance teams visibility and IT teams a supportable integration.
Innovage Cloud designs Oracle Fusion and OIC solutions that connect financial transactions with country-specific e-invoicing requirements. Our approach covers source-data assessment, XML transformation, API integration, status tracking, exception management and reconciliation. Explore our Oracle ERP services and Oracle Integration Cloud and API integration services. For UAE requirements, read our UAE e-invoicing readiness for Oracle Fusion guide.
ZATCA e-invoicing FAQs
What is ZATCA Phase 2 e-invoicing?
ZATCA Phase 2 is the integration phase, requiring notified taxpayers to connect compliant e-invoicing solutions to the FATOORA platform.
Does Oracle Fusion integrate directly with FATOORA?
Oracle Fusion typically requires an integration layer, such as Oracle Integration Cloud, to transform, validate, submit and track invoice data.
What is the difference between ZATCA clearance and reporting?
Standard tax invoices generally follow clearance before delivery, while simplified tax invoices are reported to FATOORA after issuance according to ZATCA rules.
How quickly must simplified invoices be reported to ZATCA?
ZATCA guidance states that simplified tax invoices must be reported within 24 hours of generation.
How do businesses know their ZATCA Phase 2 deadline?
ZATCA notifies targeted taxpayers by rollout wave, generally at least six months before the required integration date.
