How do you integrate Oracle with ZATCA? The Phase 2 working sequence

An Oracle ZATCA integration is not one project — it is a family of them, and Wave 25 has just widened who has to run one. On 24 July 2026 ZATCA set the Wave 25 criteria: VAT-taxable revenue above SAR 187,500 in any year from 2022 to 2025, with e-invoicing solutions integrated with the Fatoora platform by 1 February 2027. That is half the Wave 24 threshold of SAR 375,000, whose deadline passed on 30 June 2026. The question we now hear weekly from Oracle shops — EBS 12.x, Fusion Cloud, sometimes both — is the same one: what does the integration actually involve, and how long do we have to get it wrong once?

What Wave 25 changes, precisely

The facts, verified against ZATCA's announcement on the day this was written. Wave 25 covers taxpayers whose revenues subject to VAT exceeded SAR 187,500 during 2022, 2023, 2024 or 2025 — one qualifying year is enough. ZATCA will notify targeted taxpayers directly, and its stated practice is at least six months' notice before the integration date. The integration deadline is 1 February 2027. Phase 1 (the Generation phase) has applied since 4 December 2021; Phase 2 adds the Fatoora integration, a specific invoice format, and additional invoice fields.

At SAR 187,500 — roughly half the VAT registration threshold used as the previous floor — Wave 25 reaches businesses that never considered themselves "enterprise" e-invoicing candidates. Plenty run Oracle. If you are unsure of your wave, the Saudi Arabia compliance page tracks the wave table, and the penalties note covers what non-compliance costs across the GCC.

What "integration" means when the ERP is Oracle

Phase 2 splits your invoices into two flows with different rules. Standard tax invoices — your B2B and B2G documents — go to ZATCA for clearance: the invoice is only valid once it carries ZATCA's clearance stamp, and it cannot be given to the buyer before that. Simplified invoices — broadly, B2C — are issued to the customer at the point of sale and reported to ZATCA within 24 hours. Both flows require invoices in ZATCA's UBL 2.1 XML format with KSA-specific fields, a cryptographic stamp, a QR code, an invoice counter value and a hash chain linking each document to the previous one.

None of that is native Oracle behaviour. EBS 12.x has no cryptographic stamping, no CSID lifecycle management and no clearance client; the XML is generated from EBS data, and stamping, chaining and clearance happen in a component outside EBS. Fusion Cloud gives you cleaner extraction paths — BI Publisher extracts, REST services, Oracle Integration Cloud as the transport — but the ZATCA-facing mechanics still sit in an e-invoicing component you add, whether built or bought. We keep a full technical treatment of both on the Oracle integration page: CSID lifecycle, stamp custody, the Previous Document Hash chain and how to recover it. This note is the sequence — what to do, in what order.

The six-stage sequence

1. Scope: which entities, which wave, which Oracle. List every VAT registration in the group, its qualifying revenue years, and which system issues its invoices. EBS and Fusion are different projects wearing the same word — different extraction, different patching cadence, different test cycles. A group running both should plan two workstreams under one programme, not one workstream with a footnote.

2. Audit the data before touching the architecture. The XML is validated field by field, and the fields come from your master data: seller records that match the VAT registration exactly, structured addresses, buyer VAT numbers where required, tax category per line rather than inferred from the customer. In our implementation experience the critical path of an Oracle Phase 2 project runs through this remediation, not through middleware. Every rejection later is a master data defect surfacing with a timestamp — the rejection log is a data audit you didn't order.

3. Make the architecture decision deliberately. The realistic options: build the ZATCA component on your own integration layer (OIC or equivalent), or connect Oracle to an existing e-invoicing platform and keep the mapping under your control. The build path buys control and costs maintenance — every ZATCA specification revision becomes your patch. The buy path moves that burden but raises custody questions: the Production CSID is issued against your VAT registration, and whoever holds the key holds your ability to issue valid tax invoices. Our view on when a custom Oracle integration is the wrong answer is published; either way, decide with the trade-offs on the table, not by default.

4. Onboard with Fatoora — and respect the OTP. 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, so a named person with portal access must be available on the day. The Compliance CSID comes first, ZATCA's compliance checks run against it, and only when they pass does ZATCA's CA issue the Production CSID. A failed check sends you back to a new OTP and a new signing request — batch your fixes rather than trickling them through.

5. UAT with production-shaped data, including the ugly documents. Clean standard invoices pass first time almost everywhere. Validation failures concentrate in the awkward flows: credit notes referencing originals, prepayments, foreign-currency invoices, self-billing, inter-company charges. Test those, test the hash chain across a rejection, and test what happens when clearance is slow — generation does not wait on clearance, but a standard invoice cannot go to the buyer until it is cleared, so your despatch process needs a defined holding state.

6. Cut over, then run it as an operation. Cut over per entity or per unit rather than all at once where structure allows. Then staff the run state: a named owner for rejections who fixes root causes in master data, a diarised CSID renewal, and monitoring on the reporting flow's 24-hour clock. Phase 2 is not a go-live; it is a permanent operating condition.

Where Oracle projects slip

Three patterns repeat. First, multiple invoice sources behind one registration — EBS for contracts, a POS for retail, a spreadsheet a branch still uses — each needing a route into the compliant flow and a consistent counter and hash chain story. Second, customised AR: years of EBS invoice customisation mean the "standard" extract isn't, and every custom field needs an explicit mapping decision. Third, the B2C split discovered late: teams scope the clearance flow, then find mid-project that their simplified invoices need the separate reporting path with its own timing rules.

How long does this take?

We have published a week-by-week account of a ZATCA Phase 2 implementation done in 67 days. That pace is achievable when the data is clean and decisions are made on time. An Oracle estate with dirty master data, heavy customisation and no named decision-maker takes multiples of it. Counting back from 1 February 2027 with UAT and remediation in the plan, a Wave 25 Oracle shop starting in the autumn of 2026 is not early — it is on time, with no slack for a second attempt at onboarding.

If you want the scoping done properly, the readiness assessment is the structured version of stages one and two — and that conversation is free, with a senior practitioner. The data remediation itself is the data practice's bread and butter, and the integration work is described plainly on the e-invoicing practice page.

Wave criteria and deadlines were verified against ZATCA's published announcements on 25 August 2026. ZATCA revises specifications and announces new waves; check the authority's primary publications before relying on any date or threshold here.