If you've worked on a SAP implementation, you know RICEFW — the acronym for the six types of custom development objects every SAP project produces. Oracle ERP has an equivalent, and if you're running an Oracle EBS or Oracle Fusion Cloud implementation, you need to understand it.
Oracle uses two related frameworks: RICE and CEMLI. Together, they categorize the custom development objects your implementation will generate — the integrations, reports, data conversions, and extensions that sit outside standard Oracle functionality.
This post explains both frameworks, how they apply to Oracle EBS versus Oracle Fusion Cloud, and what managing them effectively actually looks like.
RICE: The core Oracle framework
RICE is Oracle's foundational acronym for custom development objects, introduced through Oracle's AIM (Application Implementation Methodology) framework:
R — Reports Custom reports and analytics that Oracle standard reporting doesn't cover. In Oracle EBS, typically built using Oracle Reports, BI Publisher, or custom SQL. In Fusion Cloud, custom reports are built in Oracle Transactional Business Intelligence (OTBI) or Business Intelligence Publisher (BIP).
I — Interfaces Inbound and outbound data flows between Oracle and external systems. Interfaces are often the most complex and highest-risk custom objects because they have external dependencies — if the external system changes its API or data format, the interface breaks.
Examples: A daily sync of customer master data between Oracle ERP and Salesforce. An inbound order feed from an e-commerce platform. An outbound payment file to a banking system in a country-specific format.
C — Conversions One-time data migrations from legacy systems into Oracle. Each data stream — vendor masters, customer masters, open purchase orders, GL account balances, fixed assets, historical transactions — is a separate conversion object with its own mapping rules, validation logic, and reconciliation process.
Conversions are consistently underestimated. Data quality in legacy systems is almost always worse than expected, and mapping to Oracle data structures requires careful analysis. Data migration budget overruns are one of the most common Oracle implementation failure patterns.
E — Extensions Customizations to standard Oracle application behavior. In Oracle EBS, these range from simple form personalizations to significant modifications of standard programs. In Oracle Fusion Cloud, extensions are built through Application Composer, Page Composer, or the Fusion Extensibility Framework.
CEMLI: The extended framework
CEMLI expands on RICE with additional object types particularly relevant in Oracle EBS:
- C — Customizations: Direct modifications to Oracle standard code
- E — Extensions: New functionality built on top of standard objects without modifying the originals
- M — Modifications: Changes to standard Oracle-delivered reports or concurrent programs
- L — Localizations: Country-specific compliance requirements — tax regulations, statutory reporting formats, local banking file formats
- I — Integrations: Same as RICE's I
The distinction between Customizations and Extensions matters in Oracle EBS: a Customization modifies an existing object, an Extension adds new behavior without changing the original.
How RICE/CEMLI applies to Oracle Fusion Cloud vs. EBS
The Oracle landscape has an important split that affects how you think about custom development objects.
Oracle EBS supports extensive customization. A large EBS implementation can produce hundreds of RICE/CEMLI objects. EBS 12.2 premier support runs through 2031, but Oracle is no longer selling new EBS licenses — most of the Oracle EBS customer base is now planning or running a migration to Fusion Cloud.
Oracle Fusion Cloud ERP follows a "configure, don't customize" philosophy. This means:
- The M (Modifications) category is essentially eliminated
- The C (Customizations) category shrinks dramatically
- Integrations become even more significant — Fusion Cloud integrates via Oracle Integration Cloud, REST APIs, and FBDI for bulk data loads
- Reports are built within Oracle's tools rather than via custom SQL
A typical Oracle Fusion Cloud financials implementation generates 10–30 integrations, 20–50 custom reports, 3–8 data conversion streams, and a smaller number of Extensions. Total object count is lower than comparable EBS implementations, but integration complexity has increased.
For EBS-to-Fusion migrations, one of the most important early activities is auditing the existing EBS CEMLI inventory — identifying which customizations can be retired, which need to be rebuilt as Fusion-native extensions, and which need to be re-platformed as integrations.
How RICE/CEMLI objects are identified
RICE/CEMLI objects emerge from the fit-gap process — the systematic comparison of business requirements against Oracle standard functionality. In Oracle implementations, this typically happens through Conference Room Pilots (CRPs) — sessions where consultants demonstrate the Oracle standard process to business stakeholders and identify gaps.
Oracle's Soar methodology (for cloud migrations) and OUM (Oracle Unified Method) both provide frameworks for this process. But the actual gap tracking almost universally happens in Excel.
The lifecycle that matters
Each RICE/CEMLI object goes through a full development lifecycle:
- Identified — gap confirmed in a CRP or fit-gap workshop
- Scoped — object type, effort estimate, priority agreed
- Approved — PMO or steering committee approves scope and cost
- Designed — Functional Design Document (FDD) authored
- Built — Technical Design Document (TDD) and development
- Tested — unit test → SIT → UAT
- Deployed — promoted to production
- Maintained — managed through Oracle quarterly patch cycles (Fusion) or EBS upgrades
The quarterly mandatory update cycle in Oracle Fusion Cloud is a specific challenge. Oracle releases a quarterly update that all Fusion Cloud customers must apply. Every Extension built in Application Composer needs regression testing with each update. The more extensions you have, the higher your quarterly testing overhead — one of the strongest arguments for minimizing custom extensions in Fusion Cloud and tracking every one you do build.
Why tracking breaks down
By the time a large Oracle implementation reaches UAT, the RICE/CEMLI register typically has: objects that were descoped but never removed; objects that grew in scope but kept their original estimates; status fields weeks out of date; design documents in SharePoint with no link to the register row; and defects in Jira with no traceability back to the CEMLI object that caused them.
The PMO's view of where the project stands is always slightly behind, always manually assembled from multiple sources before every steering committee meeting.
What effective RICE/CEMLI management looks like
The firms that run tightest Oracle implementations maintain the RICE/CEMLI register as a connected, live artifact. Each object links to its functional design document, technical design document, test scripts, and any defects. Status reflects actual current state. Approval decisions are captured with timestamps. When a defect comes up in UAT, the team can trace it to the original business requirement in 30 seconds.
Axia gives Oracle ERP implementation teams a connected platform for RICE/CEMLI tracking, fit-gap analysis, test execution, and PMO visibility — whether you're running EBS, Oracle Fusion Cloud, or managing a migration between them.