What Oracle ERP Cloud modules really cost in 2026. What the base subscription includes, how add ons lift the effective cost per real user, and why the metric on each line matters more than the rate.
Oracle Fusion Cloud ERP is sold as a base subscription plus add on modules, and the pricing impact depends on which base you start from, which modules you layer on top, and which metric each line is counted on. The base is rarely enough. The add ons and the metric mix are where the budget moves.
This guide is for finance and procurement leaders sizing Oracle ERP Cloud in 2026. Read it with the ERP Cloud licensing models guide, the ERP Cloud negotiation playbook and the Oracle Knowledge Hub.
The base subscription buys the core financials backbone. Everything that turns that backbone into a working business system is licensed separately, module by module, on its own metric.
Oracle describes the suite on its ERP Cloud pages and publishes the applications price lists from its corporate pricing page. Read the per user per month rate off the dated PDF and record the date, exactly as you would with a technology price list.
Core financials and standard reporting, and very little beyond that. Anything that touches a second business function usually needs its own line.
Oracle documents the financials capability set in detail. Use that page to settle in house arguments about what the base actually covers before the implementation partner scopes around it.
Three, and they are the ones missing from most first drafts of the business case. None of them appear when you compare module rates.
Price all three before signature. Discovering them during implementation removes every piece of leverage you had.
They sit on top of core financials and add sector specific capability, priced as add ons. Confirm the sector module is genuinely required rather than merely recommended.
The test is whether a named statutory or contractual requirement fails without it. If the answer is that the module would be nice for reporting, it is a phase two decision, not a signature decision.
Per Hosted Employee or per Hosted Named User, depending on the module, and Oracle chooses which. The metric mix matters more than the rate, because the two metrics count fundamentally different populations.
Far more people than use the software. This is the single most expensive misunderstanding on a Fusion quote, and it is settled entirely by the definitions in your ordering document.
Oracle publishes its cloud service definitions and contract documents on its cloud contracts page. Pull the definition that applies to your order and read it word by word before you accept a headcount number.
The two metrics, and who lands inside each count
| Population | Hosted Employee | Hosted Named User |
|---|---|---|
| Full time employees who use the module | Counted | Counted |
| Full time employees who never log in | Counted | Not counted |
| Part time and temporary staff | Counted | Only if authorized |
| Contractors, agents and consultants | Counted | Only if authorized |
| Staff at acquired entities, post close | Counted | Only if authorized |
| Authorized users who left last month | Not counted | Counted until deauthorized |
Read this against the definitions in your own ordering document, which govern. The pattern holds across the Fusion orders we have reviewed, but the wording is what binds.
Two practical consequences follow, and both belong in the quote review.
The rate you negotiate is a number. The metric you accept is a formula, and the formula outlives the negotiation.
They raise the effective per user cost by 25 to 50 percent in the deployments we have costed. Each module layered on top adds its own charge, so the base rate systematically understates a working deployment.
Work it as an effective rate rather than a list of lines. Take your quoted base rate, add every module rate at its own count, then divide by the number of people who will actually use the system.
Effective cost per real user, worked on a 10,000 employee organization with 800 active finance and procurement users
| Line | Metric | Billable count | Assumed negotiated rate per month | Annual cost |
|---|---|---|---|---|
| Base financials | Hosted Employee | 10,000 | 12 | 1,440,000 |
| Procurement | Hosted Named User | 450 | 60 | 324,000 |
| Project portfolio management | Hosted Named User | 200 | 75 | 180,000 |
| Risk management and advanced controls | Hosted Employee | 10,000 | 2 | 240,000 |
| Total | Mixed | 800 real users | 227 per real user per month | 2,184,000 |
Rates are placeholders. Substitute the rates on your own quote and read the effective figure in the last row: 2,184,000 divided by 800 users divided by 12 months. The structure, not the rate, is what makes the base line misleading.
The base line in that model is 12 dollars per month. The number a CFO should be shown is 227. Both are true, and only one of them describes the decision.
Whenever a module that only a small team uses is priced per Hosted Employee. In the model above, risk management costs 240,000 dollars a year to serve a controls team of perhaps 15 people.
That is not an argument against the module. It is an argument for pricing it honestly against the alternative, and for asking whether a Hosted Named User line exists for it.
It raises the discount and deepens the dependency, in that order. Bundling ERP with EPM or HCM commonly moves the discount by 10 to 20 percent, and it makes any future partial exit considerably harder.
Quantify both sides. The discount is a number on this order. The switching cost is a number you will only discover in year five, so estimate it now while you still have a choice.
In three places, none of which is the module rate you spent the negotiation on. Every one of them is fixable in the ordering document and almost impossible to fix afterward.
Oracle frequently prices year one low and steps the fee up across the term. The pitch compares year one against your incumbent cost, which is the least representative year in the deal.
A five year ramp against a flat deal, same average discount on paper
| Year | Ramped deal | Flat deal | Difference |
|---|---|---|---|
| 1 | 1,200,000 | 2,000,000 | 800,000 in your favor |
| 2 | 1,800,000 | 2,000,000 | 200,000 in your favor |
| 3 | 2,200,000 | 2,000,000 | 200,000 against you |
| 4 | 2,400,000 | 2,000,000 | 400,000 against you |
| 5 | 2,400,000 | 2,000,000 | 400,000 against you |
| Total | 10,000,000 | 10,000,000 | Identical |
Both deals cost the same across five years. Only one of them sets your renewal baseline at 2,400,000 dollars instead of 2,000,000. The ramp is not a discount. It is a starting point for the next negotiation.
That last line is the whole point. Renewal quotes are built from the final year of the prior term, so a ramp quietly hands Oracle a 20 percent higher anchor at no cost to Oracle.
Your negotiated rate applies to the initial term. Unless the ordering document says otherwise, the renewal is a fresh commercial conversation and the rate can drift back toward list.
Ask for three things in writing, and ask before the term is agreed.
Point three is the one Oracle resists hardest, which tells you what it is worth.
On Hosted Employee lines your bill tracks your payroll, not your usage. Organic growth, an acquisition or the insourcing of a contractor population all raise the count automatically.
The standard advice is to license the full module stack up front because the bundle discount is better. We disagree, and the engagement data points the other way.
Unused add ons showed up in 30 to 50 percent of the estates we reviewed, and they were almost never removable mid term. The bundle discount was real, and it was paid for by modules nobody switched on.
The better sequence is to license what will be live in phase one, secure a written price hold on the phase two modules at the same discount for a defined window, and buy them when the process owner asks for them. You keep the discount and you stop funding shelfware.
Oracle will tell you the price hold is unnecessary because the discount will be there later. If that is true, writing it down costs Oracle nothing.
Source: Redress Compliance advisory engagement file, 2024 to 2025. Observed ranges across ERP Cloud reviews, not Oracle published rates.
By starting from the process and its owner, not from the module list. A module earns its line when a named person owns a named process that fails without it.
The scoping test, one row per candidate module
| Question | Evidence that counts | If the answer is weak |
|---|---|---|
| Which process fails without it? | A named process with a named owner | Move to phase two with a price hold |
| Who uses it, and how many? | A headcount from the process owner | The metric is probably wrong for you |
| What does it replace? | A retiring system and its cost | You are adding cost, not moving it |
| When does it go live? | A date inside the implementation plan | Buy it when the date is real |
| What is the exit? | A reduction right at renewal | Negotiate one before signature |
Run every candidate module through those five rows in one workshop with the process owners in the room. Modules that survive get licensed. Modules that do not get a price hold and a date.
White Paper · Oracle
Oracle Fusion ERP Negotiation Playbook
How to price, scope and cap a Fusion ERP subscription. Read it free.
For the wider commercial picture, read the Oracle Cloud ERP pricing guide. If perpetual Oracle technology sits alongside your Fusion estate, the Oracle Technology Price List guide covers how that side is priced and where the two negotiations meet.
As a base subscription plus add on modules. The base covers core financials, and modules such as procurement and project management are licensed separately, per Hosted Employee or per Hosted Named User depending on the module. Each line carries its own metric, count and minimum.
Core financials and standard reporting: general ledger, payables, receivables, cash management, fixed assets and expenses. Capabilities beyond core financials, including procurement, projects and risk management, generally require separate add on modules.
By 25 to 50 percent over the base subscription across the deployments in our engagement file, depending on the modules selected. That is why the base rate understates a working deployment, and why the number to model is cost per real user rather than the quoted base rate.
Hosted Employee counts your workforce whether or not those people use the module, and typically includes contractors and agents. Hosted Named User counts individuals you authorize. A module used by 15 people can still be billed against 10,000 employees if it sits on the employee metric.
Usually yes. The definitions Oracle applies to hosted employee metrics commonly capture contractors, agents and consultants alongside full time and part time staff. Read the definition in your own ordering document, because that wording governs, and reconcile the count against your contractor register before you accept it.
Additional non production environments, integration tooling and storage above the included allowance. None of them appear when you compare module rates, and all three tend to surface during implementation when your negotiating leverage has already gone.
Only after pricing both sides. Bundling commonly moves the discount by 10 to 20 percent and simplifies integration, but it deepens dependency on the Fusion suite and makes a partial exit harder. Estimate the switching cost while you still have a choice.
Not necessarily, and it usually costs money later. A ramp can carry the same five year total as a flat deal while setting a materially higher final year figure, and renewal quotes are built from that final year. Rebuild every ramped proposal as a flat equivalent before comparing.
It is renegotiated unless you wrote the terms down. The discount applies to the initial term, so ask for a stated maximum renewal uplift, per line renewal rates and a defined reduction right before the term is agreed.
Map every add on to a named process with a named owner and a go live date before signing, then review adoption at each renewal. Take phase two modules as a written price hold rather than a purchase, so you keep the discount without funding shelfware.
Hosted named user versus hosted employee metrics, module pricing, and the negotiation levers on Oracle ERP Cloud.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The base subscription is the floor, not the price. The add on modules are where the ERP Cloud budget actually moves, so scope them against real business processes before you sign.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One short note on Oracle licensing moves, price list mechanics, audit posture, and the buyer side levers we are running in client engagements. No noise.
