Oracle ERP Integration · Saudi Arabia

Oracle on ZATCA.

ZATCA Phase 2 on Oracle E-Business Suite and Oracle Fusion Cloud Financials. This page covers the parts that actually cause slipped go-lives — certificate lifecycle, who holds the private key, and the document hash chain — rather than a feature list. Written for the people who will operate it after we leave.

Wave 25 Latest announced wave — SAR 187,500 threshold, integrate by 1 February 2027
6 months ZATCA's stated minimum notice before a wave's integration date — that is the whole project window
2 certificates Compliance CSID then Production CSID — different issuers, different failure modes
Keys yours Private key custody stays with the taxpayer, not with the implementer
The first decision

EBS and Fusion are two different projects wearing the same word.

Most Oracle content treats "Oracle" as one platform. For ZATCA Phase 2 it is not. The invoice data model, the extension mechanism, the release cadence and the support position all differ, and the two need separate plans.

Oracle E-Business Suite 12.x. No native cryptographic stamping, no CSID lifecycle management, no clearance client. Phase 2 on EBS is an integration project by construction: AR and AP data is extracted into UBL 2.1, and stamping, chaining and submission happen in a component that lives outside EBS. The advantage is that you control every step. The cost is that you own every step — including the parts that have to keep working at 2am on a wave deadline.

Oracle Fusion Cloud Financials. A managed, quarterly-update platform with far less freedom to customise, which for compliance work is usually a benefit. The harder questions here are release-cadence risk — an update landing mid-UAT — and precisely where in the flow the cryptographic stamp is applied, because that determines who ends up holding your private key.

Groups running both — common after a partial migration — have a third problem. Each Oracle instance that issues invoices is its own e-invoice generation unit, so each needs its own certificate and its own document chain. Two Oracle systems do not share one CSID.

Decide these before design
  • Where the stamp is applied: inside your boundary or on a provider's platform — this decides key custody
  • One unit or many: per legal entity, per branch, per Oracle instance — each needs its own certificate and chain
  • Where chain state lives: the last document hash and counter must survive a restart, a failover and a refresh
  • Archive location: the cleared XML is the legal record, not the Oracle print output
  • Who holds the OTP: onboarding needs a named person with Fatoora portal access, on the day
Where implementations actually fail

Four mechanisms. Almost every incident is one of them.

01 · Certificates

The CSID lifecycle

Onboarding produces two certificates, not one, and they come from different issuers. The Compliance CSID is self-signed by the e-invoicing platform so you can run the compliance checks; only once those pass does ZATCA's CA issue the Production CSID that the live APIs accept.

  • Onboarding starts with a one-time password generated in the Fatoora portal — there is no API for it, and ZATCA states OTPs are currently valid for one hour
  • Renewal is not a refresh: ZATCA revokes the existing certificate, then issues a new one
  • A failed compliance check sends you back to a new OTP and a new signing request
  • VAT-group changes, deregistration or suspension can trigger automatic revocation — which means re-onboarding every affected unit
02 · Key custody

Who actually holds the stamp

The Production CSID is issued against your VAT registration. Whoever holds the private key holds your ability to issue a valid tax invoice. This is a commercial question wearing technical clothing, and it is far easier to settle before signing than at exit.

  • Keys generated and held in infrastructure you control, with the provider granted use rather than possession
  • Stamping is ECDSA with SHA-256 under XAdES B-B, as an enveloped signature
  • ZATCA's technical guideline and developer manual both specify the secp256k1 curve — while its certificate-profile document lists P-256. That is an inconsistency in ZATCA's own documents; implementations resolve it in favour of secp256k1, which is what the CA and compliance checker accept
  • Revocation lists are valid seven days, so a unit can run offline for that window — plan the failure mode beyond it
03 · The chain

Previous Document Hash

Every document carries the hash of the one before it, in a single sequence per generation unit covering both standard and simplified documents. This is the mechanism nobody explains, and the one that turns a small incident into a stopped invoice run.

  • Rejected documents stay in the chain — ZATCA records the hash of rejected submissions, so the next document references the rejected one, not the last accepted one
  • Invoice counter values and UUIDs are never reused, including after a rejection
  • Generation does not wait on clearance: ZATCA is explicit that the clearance stamp is not part of the hash
  • The chain is state. Lost in a refresh, restore or failover, it cannot be reconstructed by guessing
04 · Recovery

When the chain breaks anyway

The scenario no vendor page covers: a non-production refresh overwrites chain state, a failover replays a counter, or a batch is submitted twice. What matters is whether you planned for it while the system was calm.

  • Treat chain state as production data with its own backup and a tested restore, not as application scratch
  • Never restore chain state from a lower environment into production
  • Keep an operational record of the last document hash and counter per unit, independent of the application database
  • Rehearse the recovery once during UAT — the single highest-value test in the plan
Prerequisites

What has to be true before integration starts.

Most delays we see are not integration delays. They are master-data and organisational readiness problems discovered during integration, when they are expensive.

ZATCA validates in layers: XML well-formedness and UBL schema first, then content rules derived from EN 16931, then Saudi-specific rules. Where those conflict, EN 16931 overrides UBL and the Saudi rules override EN 16931. A document with a single fatal error is rejected in full — errors and warnings are not the same thing, and only warnings survive submission.

That layering is why master data decides your rejection rate. Tax categories, registration numbers, unit codes and party identifiers are where the fatal errors live, and they are fixed in Oracle, not papered over in the integration layer.

Readiness checklist
  • VAT registration data accurate and matching ZATCA's records for every entity and branch
  • Tax determination mapping cleanly to standard, zero-rated, exempt and out-of-scope treatments
  • Customer master carrying the identifiers standard invoices require
  • Item and unit codes aligned to the accepted code lists
  • Document types — invoices, credit notes, debit notes — behaving correctly in Oracle first
  • Fatoora portal access assigned to named people, not a shared mailbox
  • Environment parity, so UAT results mean something in production
Two flows, not one

Clearance and reporting behave differently when they fail.

Standard (B2B) documents must be cleared by ZATCA before they are given to the buyer — a standard document is only valid once it carries ZATCA's clearance stamp. Simplified (B2C) documents are issued to the customer first and reported afterwards, and ZATCA does not stamp them.

The operational consequence sits in the failure path. If clearance fails on a B2B document you correct the error and submit again, because the buyer has not received a valid invoice yet. If reporting fails on a B2C document the customer already holds it, so you correct the underlying problem and account for the transaction in the VAT return rather than reissuing.

Design exception handling around that asymmetry. A queue that treats both the same will either block a till or quietly lose a tax invoice.

One planning note worth flagging: ZATCA's own documents describe the simplified submission window as within 24 hours of, variously, the transaction being completed, of generation, and of issuance. Those are not identical triggers. Build to the tightest reading and cite the document you are relying on.

ZATCA Phase 2 in detail →
What the QR code carries
  • Phase 1: five fields — seller name, VAT number, timestamp, invoice total with VAT, VAT total
  • Phase 2: nine — adding the XML hash, the ECDSA signature, the public key, and for simplified documents ZATCA's signature over that key
  • Encoding: base64 of a tag-length-value structure
  • Common defect: encoding the hash field as text rather than as its raw bytes
  • Where it goes wrong in Oracle: the print layout, long after the XML is correct
Testing, UAT and cutover

The sequence, and where it usually slips.

01

Data and mapping

Fix master data in Oracle before generating a single document. Every hour spent here removes rejections later, and rejections inside a wave window are expensive in a way they are not beforehand.

02

Compliance checks

Onboard with the OTP, obtain the Compliance CSID, and pass ZATCA's checks across your real document mix — invoices, credit notes, debit notes, standard and simplified. Failures restart the OTP cycle, so batch the fixes rather than trickling them.

03

End-to-end UAT

Run production-shaped volume, then deliberately break things: reject a document and confirm the chain continues correctly, take clearance offline and confirm invoicing continues, and rehearse chain-state recovery.

04

Cutover and hypercare

Obtain the Production CSID, cut over per unit rather than all at once where the structure allows, and watch rejection reasons daily for the first weeks — early rejections cluster into a small number of master-data defects.

What drives cost: the number of generation units and legal entities, EBS customisation depth, how far master data sits from ZATCA's rules, the spread of document types, and whether both standard and simplified flows are in scope. We do not publish a rate card, because those five factors move the number far more than any list price would tell you. What we commit to is directional pricing on the first call and a written fixed-fee quote within 24 hours.

Vendor neutrality

When a custom Oracle integration is the wrong answer.

We operate our own Peppol-certified Access Point, so we have an obvious interest in recommending an integration. Here is when we would tell you not to build one.

Low volume on a standard configuration. If you issue modest volumes from a largely vanilla Oracle instance with one legal entity, a packaged connector will be cheaper and faster than anything bespoke, and the difference will not repay the engineering.

A migration already scheduled. If EBS is moving to Fusion inside twelve months, deep EBS extensions mean paying twice. Bridge the wave deadline with the lightest compliant option and do the real integration on the target platform.

No appetite to own the key. Custody carries real operational weight — renewal, revocation, storage, access control. An organisation that will not staff that is better served by a managed arrangement, provided the exit terms are agreed in writing at the start rather than negotiated under pressure later.

What does not change our advice is whose network the invoices travel over. Whether it is ours or someone else's, the certificate, the chain and the master data are yours.

Where the wave line sits
  • Wave 24: VAT-subject revenues above SAR 375,000 in 2022, 2023 or 2024 — integrate by 30 June 2026
  • Wave 25: above SAR 187,500 in 2022, 2023, 2024 or 2025 — integrate by 1 February 2027, announced 24 July 2026
  • Later waves: none announced as at 28 July 2026
  • Notice: ZATCA states it notifies each wave directly at least six months before its integration date

Verified against ZATCA's Wave 25 announcement and its published technical guidelines and implementation standards. Last checked 28 July 2026.

Questions we actually get

Asked on most Oracle discovery calls.

Does Oracle EBS support ZATCA Phase 2 out of the box?

No. EBS 12.x has no native cryptographic stamping, no CSID lifecycle management and no clearance client. Phase 2 on EBS is an integration project by definition — the only real question is where the stamping and chaining component sits and who operates it. Fusion Cloud Financials is a different conversation, but "out of the box" overstates it there too.

What actually happens to the chain when ZATCA rejects an invoice?

The rejected document stays in the chain. ZATCA records the hash of rejected submissions, so the next document must reference the rejected document's hash rather than the last accepted one. Its counter value and UUID are burned and must never be reused. Implementations that "roll back" to the last successful document produce a broken chain and a rejection cascade — the most common serious defect we are called in to fix.

What is the Previous Document Hash for the very first invoice?

There is no prior document, so the field is seeded with a fixed value — and this is worth being careful about, because ZATCA has not published that seed in any normative standard. The value used in ZATCA's own SDK sample invoices is the base64 encoding of the hexadecimal string representation of the SHA-256 hash of "0", which is not the same as base64 of the raw hash bytes. Implementations that pick the wrong one fail their first submission. Anyone stating this as a specification requirement is overstating what ZATCA has actually published. Note too that ZATCA's normative flow documentation calls this the Previous Document Hash; "PIH" is community shorthand.

Can we keep invoicing if ZATCA's platform is unavailable?

Yes, for generation. ZATCA is explicit that there is no dependency on clearance for generating the next invoice, because the clearance stamp is not part of the hash. What you cannot do is hand a buyer a standard invoice that has not been cleared. The design consequence is a durable queue with retry and an operational view of what is pending — plus a decision, made in advance, about what the business does if an outage runs long.

Who should hold the private key — us or you?

You. The Production CSID is issued against your VAT registration, and whoever holds the key holds your ability to issue valid tax invoices. Our position is that keys live in infrastructure you control and we are granted use rather than possession. If you prefer a managed arrangement, agree the exit terms — how the key and the chain state come back to you — in the contract, not at exit.

How long does an Oracle ZATCA implementation take?

It depends on the five cost factors above, and honestly on master-data condition more than anything else. What we will say plainly: ZATCA's stated six-month wave notice is the entire window, and it has to absorb data remediation, onboarding, compliance checks, UAT and cutover — while every other taxpayer in your wave competes for the same implementation capacity. Organisations that start when the letter arrives are already tight.

Other ERPs

We integrate on your ERP — we don't replace it.

Each mandate lands differently on each platform. These are the ones we implement most often in the GCC.

SAP Dynamics 365 Zoho Tally Odoo

Mandate Monitor

Deadlines move. We will tell you when.

Short, source-checked notes when a GCC mandate actually changes — a wave announced, a specification revised, a date moved. Written by the people doing the implementations. No sequence, and you can leave in one click.

We use it to send mandate updates and nothing else. See our privacy policy.

Start with thirty minutes.

Tell us which Oracle you run, how many entities issue invoices, and which wave you are in. We will tell you what has to be true before integration starts, where your rejections will come from, and what it will cost — with a written fixed-fee quote within 24 hours.

Book a consultation → Read the ZATCA Phase 2 briefing Free · Senior practitioner · Quote in 24 hours