ERP implementations produce custom development objects on every project. The moment your fit-gap workshops start and your team starts identifying gaps between what the system does out of the box and what your business needs, the list begins.
SAP consultants call them RICEFWs. Oracle consultants call them RICE or CEMLI. Microsoft Dynamics teams call them extensions. NetSuite teams call them SuiteScripts and custom records.
Different acronyms. Identical problem.
Each one needs to be scoped, estimated, approved, built, tested, and maintained through every future upgrade. Most teams track all of this in a spreadsheet. By go-live, that spreadsheet is out of date, split across multiple versions, and nobody fully trusts it.
This post explains how each major ERP platform categorizes custom development objects, why they all share the same lifecycle management problem, and what actually needs to happen to keep them under control.
Why custom objects exist in every ERP implementation
No ERP system covers 100% of any organization's requirements out of the box — not SAP, not Oracle, not Dynamics, not anyone. The gap between what the platform does natively and what the business actually needs has to go somewhere. That somewhere is custom development.
The size of that gap varies by implementation. A company that runs a clean, vanilla process and is willing to adapt how it works can get away with fewer custom objects. A company with complex business rules, unique integrations, or regulatory requirements in specific markets will generate significantly more.
The volume of custom objects on a project is one of the strongest predictors of cost, timeline, and risk. More custom objects means more development effort, more testing cycles, more potential failure points at go-live, and more ongoing maintenance overhead with every platform upgrade.
This is why managing them isn't optional. It's the backbone of your implementation's build stream.
SAP: RICEFW (and WRICEF)
SAP implementations use RICEFW to categorize the six types of custom development objects that fall outside standard functionality:
- R — Reports: Custom reports and analytics SAP standard doesn't cover
- I — Interfaces: Data flows between SAP and external systems (Salesforce, third-party logistics, legacy systems)
- C — Conversions: One-time data migrations from legacy systems into SAP
- E — Enhancements: Extensions to standard SAP behavior via user exits, BAdIs, or enhancement spots
- F — Forms: Custom output documents — invoices, purchase orders, delivery notes
- W — Workflows: Approval and routing processes beyond SAP standard workflow
You'll also see WRICEF — the same six categories, just rearranged (Workflows first). Some firms prefer one, some prefer the other. The underlying objects are identical.
A mid-size S/4HANA implementation typically generates 80–150 RICEFW objects. Enterprise-scale programs can run into the hundreds. Each one flows through a lifecycle: identified in fit-gap workshops → estimated and approved → functional spec authored → technical spec built → developed → tested (FUT → SIT → UAT) → deployed.
The standard tracking approach is an Excel register. The standard outcome is version chaos.
Oracle: RICE and CEMLI
Oracle has two related acronyms that together cover the same ground as RICEFW.
RICE is the classic Oracle EBS framework:
- R — Reports: Custom BI Publisher reports, OTBI reports, custom SQL queries
- I — Interfaces: Inbound and outbound integrations with external systems
- C — Conversions: Data migrations from legacy systems (vendor masters, GL balances, open transactions)
- E — Extensions: Customizations to standard Oracle application behavior
CEMLI extends this with additional object types specific to the Oracle EBS world:
- C — Customizations: Direct modifications to Oracle standard objects
- E — Extensions: New functionality built on top of standard objects
- M — Modifications: Changes to standard Oracle reports or programs
- L — Localizations: Country-specific compliance requirements
- I — Integrations: Connections to third-party or external systems
Oracle Fusion Cloud ERP has moved away from the heavy customization model of EBS — the platform is designed to be configured rather than customized. But integrations remain the dominant custom workstream, and a typical Oracle Cloud implementation still generates 15–40 integrations using Oracle Integration Cloud, dozens of BIP and OTBI reports, and significant data conversion effort.
Microsoft Dynamics 365: Extensions and Integrations
Microsoft Dynamics 365 Finance & Operations doesn't use an acronym for its custom development objects, but the categories map closely to RICEFW:
- Extensions: X++ code extensions that modify or add to standard D365 behavior (the equivalent of SAP Enhancements)
- Integrations: Connections to other Microsoft systems (Power Platform, Azure services) and third-party applications
- Reports: Custom SSRS reports and Power BI dashboards beyond the standard reporting suite
- Data migrations: One-time migrations from legacy systems
- Power Automate flows: Automated business process flows that extend standard D365 behavior
Microsoft sealed the D365 code base in 2018, which means all customizations must go through a formal extensions model — every custom object is identifiable and needs lifecycle tracking. A significant D365 F&O implementation might generate 50–150 extensions and integrations combined.
NetSuite: SuiteScripts, Custom Records, and Flows
NetSuite's customization model is built around its SuiteCloud platform:
- SuiteScripts: JavaScript-based customizations — SuiteScript 2.x user event scripts, Restlets, scheduled scripts, portlets
- Custom records: New data objects beyond NetSuite's standard transaction and entity records
- SuiteFlow workflows: Visual workflow builder for approval routing and process automation
- Saved searches: Custom searches and reports used as reporting or operational views
- Integrations: Connections to external systems via SuiteTalk (SOAP/REST APIs) or third-party iPaaS platforms
A mid-market NetSuite implementation typically generates 30–80 custom objects across these categories.
The universal lifecycle problem
Across SAP, Oracle, Dynamics, and NetSuite, every custom development object goes through the same lifecycle stages:
- Identified — gap discovered in a fit-gap workshop
- Scoped — effort estimated, object typed and described
- Approved — cost and priority confirmed by PMO or steering committee
- Designed — functional specification authored by functional consultant
- Built — technical specification and development by technical team
- Tested — unit test → system integration test → user acceptance test
- Defects resolved — issues found in testing linked back to the object
- Deployed — promoted to production at go-live
- Maintained — managed through future platform upgrades and change requests
The fundamental tracking problem is that each of these stages typically lives in a different tool:
- Fit-gap workshops happen in meeting transcripts and workshop slides
- The object register lives in an Excel spreadsheet
- Specs live in SharePoint or Confluence
- Development tasks live in Jira or Azure DevOps
- Test scripts live in another spreadsheet
- Defects live in yet another Jira project
- Approvals happen in email chains
By the time you reach go-live, nobody has a complete picture. The PMO is manually consolidating status from five sources before every steering committee. When something fails in UAT, tracing it back to the original gap decision is a two-hour archaeological dig.
What good custom object management looks like
The consulting firms that consistently deliver on time share one practice: they treat the custom object register as a living, connected artifact — not a static spreadsheet.
That means each object links back to the specific gap identified in a fit-gap workshop, and forward to its functional spec, technical spec, test scripts, and any defects raised during testing. One version. Always current. With approval decisions captured and timestamps recorded.
The terminology doesn't matter. RICEFW, RICE/CEMLI, extensions, SuiteScripts — the management discipline is identical.
Axia gives implementation teams a connected platform for tracking every custom development object from fit-gap workshop to go-live — regardless of which ERP platform you're implementing.