Oracle Fusion Cloud ERP is a SaaS suite covering financials, procurement, projects and supply chain on one data model. Implementation is mostly configuration rather than code: you map your chart of accounts, business units and approval rules onto Oracle's structures. Most delivery risk sits in enterprise structure design, data migration and integrations, not in the application itself.
Implementations succeed or fail on three things: enterprise structure designed early, migrated balances that reconcile, and integrations scoped before build. We deliver against those, not against a module checklist.
What problem does this solve?
Fusion projects rarely fail on functionality. They fail because the chart of accounts and enterprise structure were designed late, because legacy balances were migrated without reconciliation evidence, or because approval hierarchies were rebuilt to mirror an old system rather than the current organisation.
The second failure is integration scope. Teams budget for the ERP, then discover that banking, payroll, warehouse and reporting interfaces all need building, testing and long-term support.
Quarterly updates are the third surprise. Oracle updates your environment on its own schedule, so anything built outside supported extension points becomes recurring regression work rather than a one-off build.
How the solution works
We treat enterprise structure and chart of accounts as the first signed deliverable, not a workshop output to revisit later, because changing ledgers, legal entities or business units after go-live is expensive and disruptive.
Migration is run as a reconciliation exercise. Every balance and open transaction loaded is proved back to the source system and the evidence is retained, so the first close after go-live starts from a defensible position.
- 1Agree scope by module and legal entity, and state explicitly which processes will not move into Fusion.
- 2Ledgers, legal entities, business units, departments and the accounting flexfield, signed off before configuration starts.
- 3Configure each module against a numbered requirement so every setup can be traced to a decision and an owner.
- 4Banking, payroll, warehouse and reporting interfaces, with error handling and reprocessing defined before build.
- 5Master data, then open transactions, then balances — reconciling and signing off at each stage.
- 6Run a conference room pilot using real data and the actual approvers, not sample data and project staff.
- 7Cut over in a defined window with a documented rollback position, then run hypercare against a defect log.
Reference architecture
A Fusion programme has four moving parts. Treating them as one workstream is why scope is missed.
| Layer | What it contains |
|---|---|
| Enterprise structure | Ledgers, legal entities, business units, departments and the accounting flexfield. Designed once, signed before configuration, and expensive to change afterwards. |
| Functional configuration | Module setup driven by numbered requirements, so every setup decision traces to an owner and a reason rather than to a workshop memory. |
| Data migration | Master data, open transactions and balances loaded through FBDI or ADFdi, each stage reconciled to the source and evidenced for audit. |
| Integration layer | Banking, payroll, warehouse and reporting interfaces, normally via Oracle Integration Cloud, with error handling and reprocessing designed before build starts. |
Key capabilities
Enterprise structure design
Ledger, legal entity and chart of accounts structure agreed and signed before any configuration begins.
availableModule configuration
Financials, Procurement, Projects and SCM configured against numbered, traceable requirements.
availableData migration with reconciliation
Balances and open items loaded and proved back to the source, with the evidence retained.
availableIntegration build
Banking, payroll and warehouse interfaces built on Oracle Integration Cloud with monitored error handling.
availableReporting and close pack
OTBI and BI Publisher reporting delivered against the close process people actually run.
availableUpdate regression testing
A regression pack maintained against Oracle's quarterly update cadence.
availablePost-go-live managed support
Local UAE support covering configuration, integration errors and period close.
availableIntegrations
Fusion rarely runs alone. These are the interfaces that most often get discovered late and then dominate the schedule.
| System | Integration point & data exchanged | Direction |
|---|---|---|
| Banking and payments | Payment file generation in bank-specific formats plus statement import for reconciliation. Formats change, so they need an owner after go-live. | bi-directional |
| Payroll | Payroll results posted to General Ledger on an agreed accounting calendar, with reconciliation between the payroll register and the ledger. | inbound |
| Warehouse / WMS | Stock movements, receipts and issues exchanged with the warehouse system so inventory valuation in Fusion matches physical stock. | bi-directional |
| RFID and RTLS asset data | Location and custody events filtered into business events before they reach Fusion, never raw position data. | inbound |
| Reporting and BI | Extracts to a reporting store where analysis spans systems or needs history that was deliberately not migrated. | outbound |
| Document management | Invoice images and supporting documents linked to Fusion transactions while the document system stays the record of evidence. | bi-directional |
Industry use cases
Government entities
Budgetary control, commitment accounting and procurement compliance, with approval hierarchies that mirror delegation of authority rather than an old system.
Construction and contracting
Project costing, subcontractor certification and retention handling across long-running contracts and multiple entities.
Logistics and distribution
Order to cash and procure to pay with warehouse integration, where inventory accuracy drives the financial position.
Oil, gas and energy services
Multi-entity, multi-currency financials with heavy project accounting and joint-venture reporting requirements.
Facilities and services groups
Shared services finance across several legal entities on one ledger structure with intercompany balancing.
UAE & GCC considerations
UAE entities carry VAT and, increasingly, corporate tax obligations that must be configured rather than assumed, with rounding and recovery rules proved against real transactions before go-live. E-invoicing requirements across the GCC are moving, so treat the invoicing interface as something that will change rather than a one-time build. Multi-entity groups spanning UAE, KSA and other GCC states usually need separate ledgers with different calendars and tax rules, which makes enterprise structure design the single most consequential early decision. Arabic reporting and bilingual document output should be tested with real data early, because retrofitting them after go-live is disruptive.
Implementation approach
- 1Scope and structure (weeks 1-4) Agree module and entity scope, then design and sign the enterprise structure and chart of accounts. Nothing else starts until this is fixed.
- 2Requirement capture Number every requirement and map it to a configuration decision or an explicit gap with an agreed workaround.
- 3Configuration and unit proof Configure module by module, proving each setup against its requirement rather than deferring all testing to a single phase.
- 4Integration build Build and test interfaces with real files and real failure cases, including how errors are found and reprocessed.
- 5Migration rehearsals Run at least two full migration rehearsals with reconciliation sign-off, not a single load close to cutover.
- 6Conference room pilot Run the business processes end to end with real data and the actual approvers, and log defects formally.
- 7Cutover Execute against a timed runbook with a documented rollback position and named decision owner.
- 8Hypercare and handover Support the first full period close, then hand over to a named internal owner with the regression pack.
Security & deployment
Fusion runs in Oracle's cloud, so your security work is about access rather than infrastructure. Role design is the main control: segregation of duties between requisitioning, approval, payment and master data maintenance has to be designed deliberately, because default roles are broad and will not satisfy an auditor. Data residency and the region your pod runs in should be confirmed in writing where UAE government data classification rules apply. Integration credentials need to be managed as secrets with rotation, not embedded in interface definitions. Because Oracle updates quarterly, the security review is recurring: new features can introduce new privileges, so role assignments should be re-tested against the regression pack after each update rather than assumed stable.
Limitations & prerequisites
- Fusion is SaaS on Oracle's update cadence. You do not control when updates land, so regression testing is a permanent operating cost rather than a project task.
- Extension is limited to supported points. Requirements needing genuine code change are usually met by process change or an external application instead.
- Migration quality is bounded by the source system. Where legacy balances were never reconciled, migration exposes the problem rather than solving it.
- Environment counts and licensing are set by Oracle, and the number of test environments you have directly limits how much parallel testing is possible.
- Go-live timing is constrained by your financial calendar. Mid-period cutovers create reconciliation work that rarely justifies the schedule saving.
Fusion Cloud ERP vs staying on EBS vs a mid-market suite
All three are defensible. The decision usually turns on customisation depth, internal capability and appetite for a vendor-controlled update cycle.
| Criterion | Oracle Fusion Cloud | Oracle EBS (retained) | Mid-market suite |
|---|---|---|---|
| Update control | Oracle's quarterly cadence, adoption mandatory | You choose when to patch and upgrade | Vendor cadence, usually lighter |
| Customisation | Supported extension points only | Deep customisation possible | Limited, configuration-led |
| Infrastructure effort | None — Oracle operates it | You run and patch the stack | None to minimal |
| Fit for complex multi-entity finance | Strong | Strong | Varies, often weaker |
| Ongoing internal skill needed | Config, integration and regression testing | DBA, apps DBA and functional | Configuration only |
| Cost profile | Subscription plus integration support | Licence maintenance plus infrastructure | Lower subscription, narrower scope |
FAQ
For single-country finance and procurement with clean data, plan in months rather than weeks. Multi-entity, multi-currency or supply chain scope extends it. The pace is rarely set by configuration speed — it is set by data readiness, integration count, and how quickly the business can make and hold design decisions.
EBS is on-premise or hosted software you run, patch and upgrade on your own schedule, with deep customisation possible. Fusion is SaaS: Oracle runs and updates it, customisation is restricted to supported extension points, and you adopt updates on Oracle's cadence. The functional overlap is large; the operating model is completely different.
The normal pattern is to migrate open items and balances into Fusion, and keep full transactional history in a read-only archive or reporting store. Loading years of closed history into Fusion is expensive and seldom earns its cost. Decide early what history must be queryable in Fusion versus merely retained.
Not automatically. You remove infrastructure and upgrade projects, but add subscription cost, integration support and continuous regression testing. Build the comparison over several years including internal effort, not on licence cost alone.
Yes, and it is often sensible — financials and procurement first, projects or supply chain later. The constraint is shared setup: enterprise structure and chart of accounts must be designed once, for the full eventual scope, or you rework them at every phase.
At minimum: someone who owns setup and approval rules, someone who can read integration errors and reprocess, and a reporting owner. Without those, every routine change becomes a support ticket and the update cycle becomes a risk.
Tell us the module, the release and the exact symptom.
Send the module in scope, your Fusion release or EBS version, and the exact error text or symptom with a screenshot where you have one. We reply with a written assessment: the likely cause, what we would check first, and whether it is a configuration fix, a data fix, or a defect that needs an Oracle service request. When Swedish Technology can help, we scope the remediation with effort and sequence before you commit to anything.
Request an Oracle AssessmentSources & evidence
- Oracle Help Center — Cloud Applications documentation — module setup, subledger accounting and period-close reference
- Oracle Help Center — all product documentation — database, middleware and infrastructure reference used for error diagnosis
- My Oracle Support — patches, known-issue notes and service requests; Oracle account required
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.