Technical Integration Guide · 2026
Oracle to Zycus. What the integration actually involves.
Most integration conversations collapse into vague promises or premature complexity. This guide lays out the architecture plainly: what connects, how it connects, what your team owns, and what Zycus owns, across E-Business Suite, Fusion Cloud ERP, and every state in between.
Request the integration design workshop →Request the integration guide
Oracle is now the largest ERP vendor by revenue, ahead of SAP (2024)
Fusion Cloud ERP enterprise customers
EBS 12.2 Premier Support runs to at least 2037. No forced migration
Typical EBS to Fusion programme length for complex estates
Sources: Apps Run The World (2024 ERP applications revenue); Oracle E-Business Suite Support roadmap; ERP Research (EBS-to-Fusion migration). Premier Support for EBS 12.2 runs to at least 2037, with no forced migration to Fusion Cloud.
Why this matters now
There is no cliff. That is exactly why the conversation is different.
SAP customers are racing a 2027 deadline. Oracle customers are not, Premier Support for E-Business Suite 12.2 runs to at least 2037 with no forced migration. So the integration question is not "beat the clock." It is "how do we add modern procurement now, while EBS and Fusion run side by side for years."
The frozen feature line
Innovation ships to Fusion only. EBS stays supported, but new AI, embedded analytics and quarterly capability updates land in Fusion Cloud, not EBS. The procurement value gap widens every release you stay put, and S2P is where that gap is most visible.
The talent line
The EBS skill pool is ageing out. Forms/Reports, PL/SQL and EBS DBA expertise is increasingly scarce and expensive. Integrations that lean on hand-built EBS extensions inherit that risk. The less custom EBS code an integration needs, the safer it ages.
The migration line
Most estates run EBS and Fusion in parallel. A full migration takes 3–5+ years and is gated by CEMLI customization debt. During that window, business units sit on different ERPs at once, so the integration layer has to serve both from a single design.
Architecture
The Zycus and Oracle connection, laid out plainly
Four nodes. Two directions. One consistent pattern, whether you are on E-Business Suite, already live on Fusion Cloud, or running both in parallel during a phased migration.
Your ERP
Oracle EBS · Fusion · OCI
Financial system of record. Suppliers, ledgers, receiving, payables, payments.
Optional
Middleware
OIC · MuleSoft · Boomi · SOA Suite. Transport layer, optional not required.
Mapping brain
Zycus iSaaS
API gateway · surface orchestration · GenAI Mapper. Transformation and monitoring.
S2P apps
Zycus S2P
Intake → Sourcing → P2P → eInvoice. Ends at PO and pre-validated invoice.
Oracle is not one API. iSaaS orchestrates the right surface per ERP and operation.
Fusion REST
Fusion Cloud record writes and reads: suppliers, POs, invoices. JSON, OAuth 2.0.
Fusion CloudFBDI
Bulk file loads: Supplier Import, Payables Invoice Import. High volume.
EBS + FusionOpen Interface
EBS record loads: PO Open Interface, Payables Invoice Import, PL/SQL APIs.
EBSSOA / legacy SOAP
EBS web services where unavoidable. Contained, not the default path.
EBS legacyYour integration COE provides the transport tunnel. Zycus iSaaS owns all mapping logic and field transformation. The middleware never needs to understand Oracle supplier or PO semantics.
No middleware COE. Zycus iSaaS connects directly, REST for Fusion Cloud, or FBDI / Open Interface / PL-SQL APIs for EBS, handling both transport and transformation. Fewer moving parts, works well for greenfield Fusion.
Integration touchpoints
Every module. Every Oracle object. Every direction.
| Module | Direction | What moves | Oracle objects · EBS / Fusion |
|---|---|---|---|
| Supplier Master | ↓ Inbound | Oracle supplier to Zycus supplier golden record. Operating unit / business unit carried as attributes. | AP_SUPPLIERS · sites (EBS) · POZ_SUPPLIERS · TCA party (Fusion) |
| User Master / SSO | ↓ Inbound | User identity sync and single sign-on. Approval hierarchy optionally from HCM Cloud. | SAML 2.0 · OCI IAM · Entra ID · Oracle HCM |
| Org Structure | ↓ Inbound | Ledgers, legal entities, business units, cost centres, GL accounts for routing, coding, validation. | Operating units · Accounting Flexfield (EBS) · BU · COA segments (Fusion) |
| Intake Management | Internal | Guided intake, smart routing, workflow approval. Zycus-internal only, no Oracle integration at this layer. | No Oracle touchpoint |
| Sourcing | ↑ Outbound | New supplier from a sourcing event pushed to Oracle. Sync keeps both in step. | Supplier Import (FBDI) · Supplier REST · create / update |
| Contracting | ↑ Outbound | Executed contracts pushed to Oracle as agreements for release. | Blanket / Contract PA · PO_HEADERS · Procurement Contracts |
| Supplier & Risk Mgmt | ⇄ Bi-directional | Supplier onboarding (KYC, risk scores) and the Oracle supplier record stay synchronised. Risk flags update Zycus. | AP_SUPPLIERS / POZ_SUPPLIERS · risk-status fields |
| eProcurement / P2P ★ | ↑ Outbound | Requisition to approval to PO creation, the last Zycus step. Receiving, match and payment remain in Oracle. | PO Open Interface · Purchase Order REST · RCV · AP match |
| eInvoice, Invoice Post NEW | ↑ Outbound | Invoice validated in Zycus, 3-way matched, then posted to Oracle pre-validated. Fewer hold failures. | Payables Invoice Import · AP_INVOICES · Invoice REST |
| eInvoice, Payment Status NEW | ↓ Inbound | After the Payment Process Request, payment confirmation and date feed back into the Zycus Supplier Network. Suppliers see lifecycle. | Oracle Payments · Payment Process Request · payment advice |
| Spend Analysis | ↓ Inbound | AP spend, GL actuals, cost-centre feeds pulled into Zycus for AI UNSPSC classification and analytics. | Subledger Accounting · GL · CO actuals · AP extracts |
| PO Status Feedback | ↓ Inbound | Receipt confirmation, invoice status, payment completion fed back so suppliers see PO lifecycle. | RCV (receipt) · AP match · Oracle Payments |
★ PO creation is the last Zycus step. Receiving, invoice matching and payment are handled in Oracle. Oracle stays the system of record throughout.
Integration models
Two models. The difference is who owns the mapping.
Both run on the same Zycus iSaaS gateway. The only question is whether Zycus or your Oracle Integration COE builds and maintains the field-mapping logic.
Model A
Integration as a Service (iSaaS-led)
Zycus builds and maintains the mapping logic inside iSaaS. Works with or without existing middleware.
- Mapping logic
- Zycus iSaaS, our responsibility and SLA
- Middleware role
- Transport only, no transformation
- Your team's effort
- Oracle enablement, connectivity, UAT
- AI Mapper
- Live field-mapping session, signed off
- Best when
- Speed matters or COE bandwidth is constrained
Model B
Customer-Owned Integration
Your OIC, MuleSoft, or Boomi COE builds and maintains all mapping logic.
- Mapping logic
- Your OIC / MuleSoft / Boomi COE
- iSaaS role
- API gateway and error monitoring only
- Your team's effort
- Majority, COE builds all mapping
- AI Mapper
- Available as reference, Zycus does not run it
- Best when
- COE ownership is a hard governance requirement
Effort split, Model A (iSaaS-led) · illustrative, confirmed at design workshop
Zycus: mapping, logic, AI session, monitoring.
Your team: Oracle enablement (FBDI / Open Interface / REST), connectivity, payload validation, UAT.
Model B inverts this ratio.
The differentiator
Where integration projects lose weeks, and why we don't
An Oracle supplier is not one record. It is a header plus sites, site assignments per operating unit or business unit, bank accounts, and, in Fusion, a TCA party underneath. Competitors map that in offline spreadsheet exchanges over weeks. We do it live, in one session, with AI confidence scoring.
Live mapping session
Load your Oracle source payload and the Zycus target schema. The AI maps field-to-field on screen, in the room. What used to take weeks takes an afternoon.
Oracle-native intelligence
The mapper knows AP_SUPPLIERS, supplier sites, PO_HEADERS, FBDI templates and the Fusion REST resource models from real Oracle integration experience embedded in the model.
Confidence scoring
Each mapping carries a confidence score. Edge cases are flagged, not silently wrong. Logic is described in plain English for business and technical reviewers.
Load schemas
Upload Oracle source (FBDI, REST JSON, XSD) and the Zycus target schema. Any format.
AI auto-maps
GenAI generates field-to-field mappings with plain-English transformation rules.
Review + adjust
Review mappings against confidence scores. Adjust edge cases. Lock and sign off.
Live transform
Run against a real Oracle test payload. See the Zycus output. Validate before SIT.
Master data design
The supplier problem, and the correct pattern
In Oracle, the same legal entity becomes many records, supplier sites per operating unit in EBS, site assignments per procurement business unit in Fusion. Designed wrong, you inherit duplicates and orphaned sites. Designed right, Zycus is the layer that cleans it up.
In Oracle
- EBS: a supplier carries sites per operating unit; the same entity equals multiple site records across OUs.
- Fusion: the supplier is a TCA party with sites and site assignments per procurement BU.
- EBS to Fusion migration changes the supplier model, a change in Oracle, not in Zycus.
- Risk: duplicates, orphaned sites, sync errors if the dedup key is not designed up front.
In Zycus
- One supplier equals one golden record, deduplicated on a primary key you define.
- Operating units and business units carried as attributes, not separate records.
- Site / location views held as sub-records, same entity, different scope.
- The sync engine writes back to Oracle in the correct per-OU / per-BU format automatically.
- Dynamic workflow per business unit, region or risk tier, not hardcoded to Oracle.
Worked example: one supplier across three business units
Business units and ledgers carried as org attributes. Auto-sync, no manual translation.
| Business unit / ledger | Payment terms | Local tax ID | Status |
|---|---|---|---|
| US-OPS (US ledger) | NET 30 | 12-3456789 | ACTIVE |
| US-MFG (US ledger) | NET 45 | 12-3456789 | DEACTIVATED |
| EU-OPS (EUR ledger) | NET 60 | DE-123456789 | ACTIVE |
golden record in Zycus
Three business units, one deduplicated supplier. The sync engine writes back the correct per-BU site automatically, no manual translation.
Scope boundary
What the standard offer covers, and what it doesn't
Scope ambiguity is what turns an 8-month integration into an 18-month one. This is the standard boundary. Every item is confirmed or classified before design begins.
Included in the standard offer
- ✓Integration-as-a-Service via iSaaS (mapping, logic, monitoring, AI session)
- ✓Onsite design workshops and solution configuration for agreed scope
- ✓TPRM connectors via App Extend (EcoVadis, D&B, Moody's, Trustpair)
- ✓eInvoice integration, outbound posting to Payables and payment-status feed
- ✓Data migration templates (FBDI loads) and load support
- ✓Go-Value workshop(s), mandatory pre-go-live
- ✓Train-the-Trainer enablement via Zycus University
- ✓UAT support and go-live hypercare (4 weeks pilot, 2 weeks per wave)
Treated as a change item
- △Modules or business units beyond the signed scope
- △Integration touchpoints not in the agreed inventory
- △Customer-owned build effort in middleware (if Model B)
- △Direct materials or bespoke custom development
- △Third-party TPRM licences, customer-owned
- △End-user training beyond Train-the-Trainer
- △Change management on the customer's side
- △Oracle-side custom development (CEMLI extensions, custom DFFs, PL/SQL)
Field intelligence · real conversations
Integration objections Oracle teams raise, and direct answers
"EBS is supported to 2037. Why integrate a new S2P now instead of waiting for our Fusion migration?"
Because integration is decoupled from the ERP migration. Zycus connects to EBS today and to Fusion later, the S2P configuration does not change. You capture sourcing, intake and eInvoice value years before Fusion, and the supplier golden record becomes the clean source you migrate into Fusion. That reduces migration risk rather than adding to it.
"We're mid-migration, some BUs on EBS, some on Fusion. Do we need two Zycus instances?"
No. Single instance is the proven pattern. During a phased migration, iSaaS routing directs requisitions, POs and invoices to the correct ERP backend by business unit and migration wave. Users see one Zycus UI throughout. A second instance doubles configuration and change-management cost for no technical gain.
"Our OIC COE wants to own the integration logic. Can Zycus work that way?"
Yes, that is Model B. Zycus exposes clean, versioned APIs, runs the iSaaS gateway, and monitors error responses. Your COE builds and maintains all mapping. The trade-off is honest: COE bandwidth becomes the critical path. If ownership is a hard governance requirement, Model B is the right call.
"When we move EBS to Fusion, does the Zycus integration have to be redone?"
No. The Zycus S2P configuration does not change. The supplier and PO schema shift (AP_SUPPLIERS → POZ_SUPPLIERS, FBDI → REST) is handled at the iSaaS or middleware mapping layer, a contained, scoped update. Your team updates extraction and field mapping, tests in a sandbox, and cuts over.
"We have 40+ operating units across many ledgers. Won't Zycus make the supplier mess worse?"
It solves it, not amplifies it. In Zycus, one supplier equals one golden record, deduplicated on a key you define. Operating units and business units are carried as attributes, and the sync engine writes back the correct per-OU site automatically. The dedup key, sync ownership and write-back rules are confirmed in the master-data design session, not assumed.
"Mixing goods and services on POs keeps causing receipt and match failures."
Zycus enforces category segregation at the requisition stage, before the PO is created. Business rules prevent a cart mixing goods and service lines, so the user corrects it at point of entry. What reaches Oracle Purchasing is always a cleanly-typed PO. The rules are configurable and set in the design workshop.
"Who owns what after PO creation? We don't want Zycus touching our Payables."
For procurement, PO creation is the last Zycus step. After it posts via the PO Open Interface or Purchase Order REST, everything that follows is Oracle: receiving, AP match, and Oracle Payments. For eInvoice, Zycus 3-way matches then posts a pre-validated invoice; what flows back after the payment run is payment status only, a read-only feed. Oracle stays the system of record.
"Our EBS has years of CEMLI customization and custom supplier DFFs. Will those break the integration?"
Not by default, but they must be surfaced before go-live. We run an Oracle-side integration health check as part of the design workshop, catalogue every custom flexfield and DFF in scope, classify each Oracle-side or Zycus-side, assign an owner, and set a resolution milestone before SIT. Included under Model A, not an extra.
Where we go from here
Three decisions that unlock the design
None require a long lead time. They can be resolved in one working session with the right people: your Oracle functional lead, your integration COE contact, and your procurement architect.
Choose the integration model
Model A (iSaaS-led) or Model B (COE-owned). Determines who builds the mapping, who runs the AI session, and your resource commitment.
Unlocks: effort estimate + timeline
Confirm the touchpoint inventory
Walk each touchpoint: EBS / Fusion scope, identity provider, eInvoice scope, HCM hierarchy, TPRM providers. Each gets a yes or no. Anything unconfirmed is a change item.
Unlocks: scope boundary + baseline
Run the integration design workshop
One day. Oracle team, Zycus team, COE if applicable. Run the GenAI mapping session live. Exit with a signed-off integration design document.
Unlocks: build can start
Ready to lock the design?
One working session. The right people. A signed-off integration design document.
