Oracle Fusion Integration with Complyance for ZATCA E-Invoicing in Saudi Arabia

Updated on Nov 3, 2026

Learn how to integrate Oracle Fusion Cloud ERP with Complyance for Saudi Arabia’s ZATCA e-invoicing requirements, including XML generation, clearance, reporting, status tracking, and reconciliation.

Oracle Fusion Integration with Complyance for ZATCA E-Invoicing in Saudi Arabia

Table of Contents

Introduction

Businesses using Oracle Fusion Cloud ERP in Saudi Arabia need an integration process that connects invoice data from their ERP with the requirements of the Zakat, Tax and Customs Authority (ZATCA). The integration must do more than transmit invoice fields: it must support the required Saudi invoice format, the applicable clearance or reporting process, responses from the e-invoicing service, and traceable records of each document’s outcome.

Complyance provides the Unify API for submitting invoice data and retrieving document status. The exact implementation depends on the Oracle Fusion modules in use, the organisation’s integration architecture, its invoice types, and its ZATCA onboarding status.

This guide explains the main integration responsibilities and the architecture options to evaluate. It is a technical planning guide, not a claim that a pre-built Oracle Fusion–Complyance connector is available.

1. What Oracle Fusion must provide

The integration starts with reliable invoice data from Oracle Fusion. Identify the source objects and supported interfaces for the Oracle Fusion products and modules used by your organisation. Depending on the implementation, the required data may include:

Seller legal and tax registration details.
Buyer identification and address details where required.
Invoice number, issue date, currency, and document references.
Line descriptions, quantities, unit prices, discounts, tax categories, tax rates, and totals.
References to original invoices for credit notes and debit notes.
Payment and delivery details where relevant to the document type.

Use Oracle-supported integration interfaces, such as documented REST APIs, business events, or an Oracle integration adapter where appropriate. Avoid direct database writes to Oracle Fusion application tables.

Before building the flow, agree on the source of truth for invoice numbering, tax calculation, customer and item data, and document corrections. These decisions affect mapping, duplicate prevention, reconciliation, and auditability.

Choosing third-party API applications

Not every e-invoicing project needs a separate API for tax calculation, digital signatures, or another specialist function. First establish which responsibilities are already covered by Oracle Fusion, the selected e-invoicing platform, and the organisation’s existing tax and integration systems. Add another provider only when there is a defined requirement and the responsibilities between systems are clear.

Before selecting a third-party API, evaluate the following:

Saudi-specific coverage: Confirm support for the relevant ZATCA document types, required invoice data, XML and security requirements, and the clearance or reporting workflow. Do not rely on a general claim of “e-invoicing support” without checking the Saudi requirements.
Documented API contract: Review supported endpoints, authentication, request and response schemas, error responses, rate limits, versioning, and status-retrieval behaviour. Use the current provider documentation rather than assuming a particular endpoint or authentication method.
Lifecycle visibility: Check how the integration identifies submitted documents, exposes processing outcomes, and supports investigation of rejected or pending documents. A submission response alone may not represent the final ZATCA outcome.
Security and operations: Assess credential storage and rotation, access controls, encrypted transport, audit logging, incident handling, service availability commitments, and the provider’s support process.
Testing and change management: Confirm the availability of a suitable sandbox or test workflow, representative test cases, release notes, and a process for assessing API or regulatory changes before production deployment.
Clear division of responsibility: Decide which system owns tax calculations, invoice numbering, XML generation, validation, submission, status tracking, and record retention. Avoid duplicate processing or conflicting calculations across multiple services.

Tax calculation engines or signature-related services may be relevant in some architectures, but they should not be assumed to be standalone requirements for every Oracle Fusion integration. Verify the applicable ZATCA requirements and the selected e-invoicing platform’s responsibilities before adding them.

For a Complyance implementation, review the current Unify API documentation and Saudi Arabia country guide to confirm the available interfaces and Saudi-specific requirements.

2. What the e-invoicing integration must do

The integration architecture should assign clear responsibilities for the full document lifecycle:

Extract or receive invoice data from Oracle Fusion through a supported interface.
Map the data to the fields required for the relevant Saudi document type. Confirm the mapping against the current Complyance Saudi Arabia field reference and validation rules.
Validate the payload and resolve missing or inconsistent data before production submission.
Generate the required Saudi e-invoice XML and apply the applicable ZATCA technical and security requirements through the configured e-invoicing workflow.
Submit the document for the correct ZATCA process—clearance for standard tax invoices and associated notes, or reporting for simplified tax invoices and associated notes.
Retrieve and record the outcome, including the document status and any validation or authority response.
Update or reconcile the ERP-side record where the integration design and supported Oracle interfaces allow it.
Retain audit evidence, including source references, submission identifiers, timestamps, responses, and correction history.

The exact sequence and status names depend on the chosen integration design and the responses available through the connected systems. Do not treat an initial API response as proof that ZATCA has accepted the invoice.

3. ZATCA Phase 2 workflow: clearance and reporting

Saudi Arabia’s Phase 2 e-invoicing requirements distinguish between standard and simplified tax invoices.

Standard tax invoices and associated notes

Standard tax invoices and their associated notes must be submitted to FATOORA for clearance before they are shared with the buyer. The integration should wait for and record the relevant clearance outcome before treating the document as cleared for the applicable business process.

Simplified tax invoices and associated notes

Simplified tax invoices and their associated notes are generated and shared with the buyer under the applicable rules, then submitted to FATOORA for reporting within 24 hours of issuance. The integration should track the reporting deadline and identify documents that have not reached a final status in time.

For both paths, the implementation needs to distinguish local validation from the final authority outcome. It should also retain the original Oracle transaction reference and the e-invoicing document identifier so finance and tax teams can trace the result back to the ERP.

Refer to ZATCA’s Detailed E-Invoicing Guideline for the official requirements.

4. Integration architecture options

Choose the architecture based on your existing Oracle estate, operational ownership, expected volume, and support model. These are implementation patterns—not a statement that a specific Complyance connector is available.

Option A: Oracle Integration Cloud (OIC)

OIC is a practical option when the organisation wants a managed integration layer between Oracle Fusion and an external API. Oracle documents the use of the ERP Cloud Adapter for the Oracle Fusion side and the REST Adapter for external REST endpoints.

A typical design is:

Configure an ERP Cloud Adapter connection for the relevant Oracle Fusion interface or event, where supported by the use case.
Create a REST Adapter connection for the Complyance Unify API using the current API documentation, including the endpoint, authentication, request schema, and expected response.
Define the integration flow and map the required Oracle invoice data to the payload expected by the configured Complyance source mapping.
Submit documents using the appropriate Saudi document type and environment.
Store the returned document identifier and retrieve the document status using the documented status endpoint.
Handle errors and route unresolved cases to an operational queue or support process.
Update Oracle Fusion through a supported interface if that update is part of the approved design.

Review Oracle’s OIC configuration guidance and the Complyance Unify API documentation. Endpoint names, authentication, request fields, and status behaviour should be confirmed from the current documentation rather than assumed.

Option B: Oracle SOA Suite

Oracle SOA Suite may be suitable for organisations that already operate and support it as part of their integration architecture. It can be used to design service-oriented workflows, with technologies such as BPEL available for orchestration where appropriate.

The design should define how Oracle Fusion data reaches the integration workflow, how the external API is called, how results are persisted, and how exceptions are handled. Oracle Service Bus may be relevant in an existing deployment, but do not assume it is included in every SOA Suite environment or that BPEL is mandatory.

This option is generally most relevant where SOA Suite is already an established, supported platform. Evaluate the maintenance and operational overhead before adopting it for a new Oracle Fusion Cloud integration.

Option C: Custom integration service

A custom service can call the supported Oracle Fusion interfaces and the Complyance Unify API when the organisation needs more control over orchestration, data mapping, or monitoring. The service may be implemented in a suitable language and hosting environment, provided it follows the relevant Oracle and Complyance API contracts.

The implementation should include:

Secure storage of API credentials and a process for credential rotation.
TLS-protected communication and access controls.
Schema and business-rule validation before submission.
Idempotency and duplicate prevention, especially when a request times out and the final outcome is not yet known.
Durable logs and audit records that avoid exposing secrets or unnecessary sensitive invoice data.
Status retrieval, exception handling, alerting, and reconciliation with Oracle Fusion.
A documented process for correcting rejected documents without creating unintended duplicate invoices.

Prefer supported Oracle APIs and integration interfaces over direct database writes. Custom development provides flexibility but makes the organisation responsible for operating, securing, testing, and maintaining the service.

Optional: API Gateway for security and governance

An API gateway can be used as an optional security and governance layer in front of an integration service or published API. Depending on the gateway product and configuration, it may support controls such as authentication, request limits, routing, and request validation.

It should not be treated as the default end-to-end workflow engine for the Oracle-to-e-invoicing process. Data mapping, orchestration, durable status tracking, retries, and reconciliation belong in the integration platform or service designed to perform those tasks. Oracle’s API Gateway documentation describes gateway capabilities and controls.

5. Error handling, retries, and reconciliation

A production integration must account for more than successful requests. Define how the system responds to:

Missing mandatory fields or invalid Saudi tax data.
XML-generation or validation errors.
Authentication, permission, and configuration errors.
Network timeouts or interrupted connections.
Duplicate document numbers or repeated submissions.
ZATCA clearance or reporting rejections.
Documents that remain in a processing state longer than expected.
Differences between Oracle Fusion records and the final e-invoicing outcome.

Do not automatically resend a document after a timeout without first checking whether the original request was stored or processed. A retry policy must account for the API’s duplicate rules and the document’s current status. Follow the current Complyance documentation for error responses, duplicate handling, and status retrieval.

Reconciliation should compare the relevant Oracle invoice population with e-invoicing records and their final outcomes. Reports should make it possible to identify documents that are missing, rejected, pending, or require correction. Assign responsibility for resolving each exception to a named operational team.

Useful implementation references include Complyance’s Submit and Retrieve guide, Documents and Status reference, and Unify error reference.

6. Testing and go-live

Test the complete lifecycle using representative Saudi documents before moving to production. The test plan should include:

Standard tax invoices and simplified tax invoices.
Credit notes and debit notes, including required original-document references.
Tax calculations, rounding, discounts, and invoice totals.
Missing mandatory fields and invalid tax or party data.
XML and validation failures.
Clearance and reporting responses, including rejected documents.
Timeouts, repeated requests, and duplicate document numbers.
Status retrieval and reconciliation back to Oracle Fusion.
Monitoring, alerts, access permissions, and audit-log review.

Use the appropriate Complyance sandbox workflow and ZATCA test resources for development and validation. A successful sandbox test does not replace production onboarding or prove that the company’s production EGS setup is complete.

Before go-live, confirm that the company is onboarded in the correct environment, production credentials and source configuration are in place, required Saudi mapping test cases have passed, and operational owners understand how to monitor and correct documents. Follow the current Complyance Saudi Arabia go-live checklist and Saudi onboarding guide.

7. Compliance responsibilities

Integration can improve consistency, visibility, and control across the invoice lifecycle. It cannot, by itself, ensure tax compliance.

The organisation remains responsible for accurate source data, correct VAT treatment, appropriate invoice classification, complete ZATCA onboarding, compliant invoice content and XML/security controls, timely clearance or reporting, and recordkeeping. Finance, tax, IT, and integration teams should agree on ownership for configuration changes, regulatory updates, exception handling, and periodic testing.

Complyance documentation should be used to confirm current API contracts, Saudi field requirements, validation rules, submission behaviour, and status-retrieval details. Start with the Complyance Unify API reference and the Saudi Arabia country guide.

Conclusion

Integrating Oracle Fusion with Complyance for ZATCA e-invoicing requires a defined connection between ERP invoice data, Saudi-specific mapping and XML requirements, the correct clearance or reporting path, and reliable status tracking. OIC, an existing SOA Suite environment, or a custom integration service may provide the orchestration layer; an API gateway can add controls where appropriate.

The right design is the one that fits the organisation’s Oracle environment, uses documented interfaces, protects credentials and invoice data, prevents duplicate submissions, and gives finance and tax teams a traceable view of each document’s outcome. Validate the implementation against the latest Oracle, Complyance, and ZATCA documentation before production deployment.

References

Official Oracle documentation

Official ZATCA documentation

Complyance documentation

Frequently Asked Questions

The integration can be designed to call the Unify API through a supported REST interface. For OIC, Oracle documents using a REST Adapter for an external API and an ERP Cloud Adapter for the Oracle Fusion side where appropriate. Confirm the current endpoint, authentication, payload, and response details in the Unify API documentation. This guide does not claim that a pre-built Complyance connector for Oracle Fusion is available.

No. Standard tax invoices and associated notes follow the clearance process before being shared with the buyer. Simplified tax invoices and associated notes are reported to FATOORA within 24 hours of issuance. The integration must classify each document correctly and apply the relevant workflow.

Not necessarily. The initial response may indicate that the payload passed an initial validation stage and was stored for further processing. The integration should retain the document identifier and retrieve the status until the applicable final outcome is available.

Not usually. A gateway can provide an API security or governance layer, but the end-to-end solution also needs mapping, workflow orchestration, durable status tracking, error handling, and reconciliation. Those responsibilities should be implemented in OIC, another suitable integration platform, or a custom service.

No. Sandbox testing helps validate the integration and document flows. Production use requires the relevant production onboarding, credentials, configuration, and readiness checks to be completed separately.

About the Author

Ajith Kumar

Im a skilled content writer and SEO expert crafting engaging articles that rank. Passionate about making complex topics clear, discoverable, and valuable to readers.Dedicated to driving organic growth through high-quality, search-optimized content

Connect on LinkedIn