Oracle sells the same supply chain capability on at least four incompatible counting bases, and the one your rep proposes is rarely the one that is cheapest for your workforce and volume profile. This guide shows how each metric is actually measured, where the compounding traps sit, and how to model the crossover point before you sign.
Oracle sells the same supply chain capability on at least four incompatible counting bases, and the one your rep proposes is rarely the one that is cheapest for your workforce and volume profile. This guide shows how each metric is actually measured, where the compounding traps sit, and how to model the crossover point before you sign.
The metric name printed on your order document, "Hosted Named User," "Hosted Employee," "Hosted 1,000 Order Lines," carries almost no contractual weight on its own. Four separate Oracle documents combine to define what you actually owe, and in 25 years of taking these apart line by line I have rarely met a buyer who has read the one that decides audit outcomes. First, the Oracle Fusion Cloud Service Global Price List (current edition August 6, 2026, with a July 16, 2026 regional edition also live) carries list prices and short metric definitions, and it refreshes roughly monthly. Second, the Fusion Cloud Service Descriptions v071626, effective July 16, 2026 and running 208 pages, holds the glossary that lines up Hosted Named User, Hosted Employee, Hosted 1,000 Order Lines, Hosted 1,000 Records, Hosted 10,000 Records, Hosted Managed Resource, Hosted Named Seat Month, Hosted $M in Application Annual Revenue, and Hosted $M in Freight Under Management as competing bases for overlapping capability. Third, and this is the one that matters in a dispute, Metric Descriptions for Oracle Fusion Offerings (June 12, 2026) converts each metric name into an auditable, SQL-level count. Oracle states plainly that this document is meant to be used together with the Service Descriptions. Fourth, Fusion Retired Service Descriptions (effective June 11, 2026, 361 pages) governs grandfathered part numbers, which keep their original definitions and are frequently cheaper than the current equivalent.
The metric name is marketing; the June 2026 Metric Descriptions document is the thing Oracle will actually measure you against.
The practical move is short and non-negotiable from the buyer side: name each document by title, version, and date inside the ordering document or an amendment, and state that measurement will be performed against those editions for the full subscription term. Without that clause, Oracle can measure a 2026 order against a 2029 definition it wrote unilaterally. Ask for the Metric Descriptions PDF in writing before signature, not after, and read the specific paragraph covering every SKU you are buying. Our Fusion SCM licensing buyer guide walks the same document stack across the wider module set.
Oracle's definition is unambiguous and worth quoting back at any rep who implies otherwise. A Hosted Named User is "an individual authorized by you to access the hosted service, regardless of whether the individual is actively accessing the hosted service at any given time." Authorization is the trigger. Login activity is irrelevant. A warehouse supervisor who left the business in March but whose account was never disabled is fully billable in December, and so is the test account your systems integrator created during CRP2 and forgot. Buyers consistently underestimate this because they benchmark named user against on-premises habits, where inactivity was often tolerated. In Fusion it is not, and it is not measured by interviewing your team.
Measurement is executed as a privilege query against the security tables. The June 2026 Metric Descriptions document names the exact privileges. Oracle Maintenance Cloud Service counts active users assigned MNT_MANAGE_MAINTENANCE_MANAGEMENT_WORK_AREA_PRIV. Global Order Promising User counts active users assigned MSC_MONITOR_ORDER_PROMISING_WORK_AREA_PRIV. Demand Management counts users holding MSC_MONITOR_DEMAND_MANAGEMENT_WORK_AREA_PRIV. Quality Management counts users holding at least one privilege from a defined list, and explicitly counts a user holding several of those privileges only once, which is one of the few genuinely buyer-favorable rules in the ruleset and is worth replicating in role design elsewhere.
Three disciplines follow directly. First, run quarterly privilege sweeps, not annual HR reconciliations, because HR termination data and Fusion privilege assignment drift apart within weeks and the gap is billable. Second, design custom roles so that a qualifying privilege is granted only where the job genuinely requires the work area, since a single over-inclusive inherited role can add hundreds of countable users overnight. Third, keep dated evidence of each sweep, because in a review the burden of showing the count is yours. The same authorization-versus-usage logic drives the named user versus employee decision on the ERP side, and the sweep cadence should cover both estates together.
This is the single most misread definition in Fusion SCM, because the word "employee" in Oracle's metric does not mean what your HR system means by employee. The Metric Descriptions for Oracle Fusion Offerings (June 12, 2026) counts every Person regardless of Person Type tracked in the Fusion service during the month reported, including Employees, Agents, Contractors and Consultants, each counted once. Only workers whose sole Non-Worker person type is "Retiree" or "Not Managed by HR" fall outside the count. Read that carefully: the trigger is being tracked in the service, not being on payroll, not holding a login, not touching a single SCM screen. A warehouse temp loaded into person records for badge access is billable. A contract maintenance technician set up so a work order can be assigned to him is billable. The count is a monthly snapshot of your person master, and in most organizations that master is the least governed table in the estate.
The trigger is being tracked in the service, not being on payroll, not holding a login, not touching a single SCM screen.
Then there is the dependency that quietly kills the cheap option. Oracle's own measurement rule states that measurement of Hosted Employee based Cloud Services requires the presence of at least one Hosted Employee base service from Oracle Cloud HCM. In plain terms, an SCM metric election can pull an entire HCM subscription into scope, because Oracle needs the HCM person model to run the count. Buyers who picked the employee metric on unit price alone have discovered the base HCM SKU arriving as a non-negotiable line item at renewal. If you are considering this route, price the HCM base alongside it and read our breakdown of the three HCM metrics and which one matches headcount before you commit.
The defensive moves are contractual, not technical. Negotiate an express exclusion list beyond Retiree and Not Managed by HR, covering non-worker person types created purely for reference data. Ask for a stated measurement basis (annual average rather than peak month) in the order document, and get the HCM base dependency priced and capped in writing before you sign, not discovered at true-up.
Volume pricing looks like the buyer-friendly option because it decouples cost from headcount, and for lean teams processing high volumes it often is. The cleanest illustration is Oracle selling the same capability on two bases: B81263 Oracle Fusion Order Management Cloud Service is measured in Hosted 1,000 Order Lines, being the number of sales order lines processed during the trailing twelve months in units of 1,000, while B81264 Oracle Fusion Order Management User Cloud Service is measured in Hosted Named User, counted by privilege assignment. Same functional footprint, two entirely different bills. A 40-person order desk pushing 8 million lines a year will pay less on named user. A 6-person desk running 300,000 lines will pay less on volume. Neither answer is obvious until you compute it.
The trap sits in the measurement window. The metric is trailing twelve months, not point-in-time and not annual average. A peak-season spike in month three does not fall out of the billable base until month fifteen. In practice this means a single promotional quarter, a channel-stuffing month, or a one-off migration load of historical orders can hold your reported volume elevated for a full year, and Oracle will measure it at whatever point the renewal or audit lands. The same TTM logic governs the configured-order metric, which counts configured sales order root lines (ATO or PTO models) in thousands over the trailing twelve months, so a product line moving to configure-to-order raises the count on a second axis at the same time.
The second trap is the counting level. Oracle counts lines, not documents, and it is explicit about this. The Accounting Hub records rule is the clearest statement of the principle: Oracle counts thousands of records per month processed via the XlaTrxL.csv interface file, includes all unique transaction lines, and excludes transaction headers and the resulting journal records. Order lines and invoice lines follow the same logic. Your line-to-header ratio is therefore the whole game, and it is a number most buyers cannot quote from memory. A distributor averaging 22 lines per order pays 22 times what a services business averaging one line per order pays for the identical order count. Run the query before you take a per-line basis, and see our wider guide to what actually drives the Fusion SCM bill for how this interacts with adjacent module metrics.
In our negotiation experience, Oracle will concede a defined overage rate more readily than it will change the measurement window, so ask for both and expect to trade one. Never accept a volume tier sized to today's run rate: size it to your modeled peak TTM plus growth, and hold the excess capacity as your buffer rather than paying uplift mid-term.
Put the metric families in one grid and the pricing logic stops being mysterious. Every SCM metric in the Fusion Cloud Service Descriptions v071626 glossary answers three questions: what object gets counted, over what window, and which operating profile pays the penalty. Read the columns, not the rate, because the rate is negotiable and the counting object is not. The measurement window matters as much as the object: monthly-reported metrics reset, trailing-twelve-month metrics do not, and authorization metrics ignore usage entirely. Our Fusion SCM licensing buyer guide maps these back to specific module part numbers.
| Metric | Counting object | Window | Punishes this profile |
|---|---|---|---|
| Hosted Named User | Individual authorized to access, active or dormant, identified by privilege query | Point in time, authorization based | High provisioned-to-active ratio, shared logins, unrevoked leavers |
| Pooled Named User | Authorized individual drawn from a purchased pool | Consumed monthly, refilled retroactively | Flat headcount with no seasonality (pool premium wasted) |
| Hosted Employee | Every Person tracked in Fusion, all Person Types: employees, agents, contractors, consultants, counted once each | Monthly, per reported month | Contract-labor-heavy manufacturing, 3PL, agency warehouse staffing |
| Hosted 1,000 Order Lines | Sales order lines processed, in thousands | Trailing twelve months | Many-line, low-value orders; promotional spikes |
| Hosted 1K Invoice Line | Invoice lines, headers excluded | Trailing twelve months | Poor line-to-header ratio |
| Hosted 1,000 Records / 10,000 Records | Unique transaction or product records, lines only, headers and journals excluded | Monthly | Wide SKU catalogs, high interface file volume |
| Hosted 1,000 Planned Item Locations | Planned items multiplied by planned locations | Monthly | Multi-site distribution networks |
| Hosted Managed Resource | Physical asset (truck, train) plus every user, employee, contractor, partner and entity managed | Per resource | Fleet and field operations |
| Hosted $M in Application Annual Revenue | Revenue in millions attributed to the application | Annual | Growth without matching transaction growth |
| Hosted $M in Freight Under Management | Freight spend in millions passing through the service | Annual | Freight-cost inflation you do not control |
Two landmines deserve naming. First, Planning Central (B85244) is priced on Hosted 1,000 Planned Item Locations, calculated monthly as planned items multiplied by planned locations. Open two more distribution centers against a 40,000-item plan and you have not added a line item, you have multiplied the base. Second, Hosted Managed Resource double-counts by design: Oracle charges for the physical asset and for every individual the service manages, including your contractors and partners. Fleet operators buying transportation capability on this basis should read our Oracle transportation and logistics licensing guide before accepting the quote structure.
Metric selection is arithmetic, not preference, and the arithmetic is not hard. Build a three-year projection for each candidate metric on the same spreadsheet, using peak-month values rather than twelve-month averages, then read off the volume or headcount where the lines cross. Peak matters because trailing-twelve-month metrics like Hosted 1,000 Order Lines carry a spike for a full year after it happens, and Hosted Employee is reported per month, so your November agency surge sets that month's bill. Averages hide both effects and consistently understate the volume metric by our experience of these models.
Treat any rate you find as directional. Oracle does not publish SCM list rates in a form you can rely on: quoting is sales-controlled, and third-party sources reporting figures such as Procurement Cloud from roughly $625 per hosted named user per month are starting points for a sanity check, not truth. What you should hold as fixed is the counting rule from the Metric Descriptions for Oracle Fusion Offerings document dated June 12, 2026, because that is what an audit will apply. Model volumes precisely; model prices as ranges and demand the actual quote in writing.
Model volumes precisely, model prices as ranges, and never accept a metric whose counting rule you have not read.
Three specific moves pay for the modelling effort:
Finish by writing the crossover thresholds into the contract as repricing triggers. If your model shows the order-lines metric wins below 900,000 lines annually, negotiate a conversion right at that boundary rather than discovering the crossover at renewal, when your leverage is gone.
Sequence this work so you hold the numbers before Oracle does. First, run the privilege queries yourself. The Metric Descriptions for Oracle Fusion Offerings (June 12, 2026 edition) names the exact privileges Oracle counts, for example MNT_MANAGE_MAINTENANCE_MANAGEMENT_WORK_AREA_PRIV for Maintenance and MSC_MONITOR_ORDER_PROMISING_WORK_AREA_PRIV for Global Order Promising, so extract active users carrying those privileges from your own environment and reconcile against what you are paying for. Dormant but provisioned accounts are billable under the Hosted Named User definition, and in our audit experience deprovisioning stale accounts before a true-up is the single fastest reduction available. Second, build the full Hosted Employee population, not the payroll list: every Person Type tracked in the service during the reported month, including agents, contractors, and consultants, with only single-type "Retiree" and "Not Managed by HR" excluded. If your contractor ratio pushes that count above your named-user privilege count, the employee metric is not the cheap option, and remember it carries a hard dependency on at least one Hosted Employee base service from Oracle Cloud HCM. Third, model volume metrics on your peak month, not your average, because order lines and records are measured on a trailing twelve months basis and one spike sits in the billable base for a full year. Fourth, insist the order document names the specific edition date of both the Metric Descriptions and Service Descriptions documents, otherwise the counting rules can move under you.
Yes. Hosted Named User is defined as an individual authorized to access the service regardless of whether that individual is actively accessing it at any given time. Oracle measures by querying who holds the qualifying privilege, so a provisioned account nobody has logged into for eighteen months is fully billable. Run privilege sweeps quarterly and deprovision, because the count is authorization, not activity.
No, and this is the most expensive misreading in Fusion SCM. The definition counts every Person regardless of Person Type tracked in the service during the reported month, explicitly including Agents, Contractors and Consultants, each counted once. Only non-workers typed as Retiree or Not Managed by HR are excluded. If you run heavy contract labour, agency warehouse staff, or 3PL personnel inside Fusion, the employee metric can be materially worse than named user.
Generally no. The Metric Descriptions document states that measurement of Hosted Employee based Oracle Cloud Services requires the presence of at least one Hosted Employee base service from Oracle Cloud HCM. Selecting the apparently cheaper employee metric for SCM can therefore drag an HCM subscription into scope, which frequently erases the saving. Price the HCM base into any employee-metric comparison before you conclude it is cheaper.
B81263 Oracle Fusion Order Management Cloud Service is priced on Hosted 1,000 Order Lines, defined as sales order lines processed during the trailing twelve months in units of 1,000. The trailing window is the risk: a peak-season or one-off spike remains inside your billable base for a full year after it happens. Model your peak month, not your average, and check whether B81264 on Hosted Named User is cheaper for your line-to-user ratio.
Pooled Named User licences an authorised individual regardless of active access, pooled for the service period on the order document. You consume as many units as needed each month and buy more only if the pool runs out before period end, with usage monitored retroactively. It is a strong fit for seasonal warehouse, agency, and peak-period staffing where a fixed named-user count would be sized for your busiest eight weeks and idle for the rest of the year.
Planning Central (B85244) is priced on Hosted 1,000 Planned Item Locations, reported monthly and calculated as planned items multiplied by planned locations. Adding a distribution centre does not add a fixed increment, it multiplies your entire planned item catalogue across one more location. Before any network expansion, recalculate the product, and negotiate volume tiers or a cap that anticipates the site roadmap.
PeopleSoft is licensed on authorization, not usage, across four metrics, and Oracle supports it to at least 2036. The metric traps, the support annuity, and the leverage the buyer
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
