ERP, EPM, SCM, HCM, CX, and NetSuite: what you are actually buying, and where the definitions hide the money. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session sixteen of thirty, and a new world. For fifteen sessions we counted infrastructure: OCPUs, vCPUs, credits, egress. Module four moves to Oracle SaaS, the Fusion applications and NetSuite, and the counting changes character completely, because now we count people, and people are harder. They join, they leave, they contract, they go seasonal, they approve a workflow once a quarter, and every one of those behaviors lands differently depending on a definition buried in a service description you have probably never read. Today is the foundation session: the portfolio map, the three metric families, the definitions that surprise buyers, and the floors you pay whether or not anyone logs in. By the end you will have the three questions that every SaaS line item must answer before it goes on an order. Let's meet the family.
Five takeaways. One, the map: six product families, Fusion ERP, EPM, SCM, HCM, CX, and NetSuite, what each covers and which metric family each bills on, because the metric tells you more about the commercial behavior than the product name does. Two, the metrics themselves: Hosted Named User, Hosted Employee, and the transaction metrics, three fundamentally different machines for turning your organization into a number. Three, the definitions: why what you owe comes from the service description's words, not from your usage, and the five specific definitions that catch buyers. Four, the floors: module minimums and packaging, the quantities that bill with zero logins. And five, the discipline: three questions, which metric, whose definition, what floor, asked before signature, every time, in writing. That ritual, applied consistently, is worth more than any discount percentage in this module.
The portfolio map, six families. Fusion ERP: financials, procurement, projects, risk, the general ledger heart of the suite, priced mostly per Hosted Named User with per module minimums. Fusion EPM: planning, consolidation and close, account reconciliation, the CFO's analytical layer, also named user, per module. Fusion SCM: inventory, order management, manufacturing, logistics, named users plus transaction metrics where volume is the real driver, order lines and shipments. Fusion HCM: core HR, talent, payroll, workforce management, and here the metric flips to Hosted Employee, the whole workforce, which is a different animal entirely and gets session nineteen to itself. Fusion CX: sales, service, marketing, users for the humans, records and interactions for the marketing engines. And NetSuite: the mid market suite, same corporation, completely separate commercial machine, its own paper, its own ladder, its own sales team. Everything Fusion rides the CSA and service description stack from module one, which means everything you learned about precedence and definitions applies here, with more zeros attached. One map, six families, and every family reduces, commercially, to a metric definition. So let's do the metrics properly.
Three metric families, three different machines. Hosted Named User: a specific individual authorized to use the service. The operative word is authorized, not active, a named user counts from the day the account is provisioned to the day it is deprovisioned, and logging in is irrelevant. This metric grows with authorization, which means you control it: provisioning discipline and a monthly deprovisioning ritual are, in SaaS, exactly what the counting disciplines were in OCI, a licensing control wearing an operations costume. Hosted Employee: everyone in your workforce as the service description defines it, and the standard definition is broad, full time, part time, temporary employees, plus contractors and agents in scope. It grows with headcount, and you control almost nothing about it after signature except that you signed the definition. And the transaction metrics: expense reports, order lines, invoice lines, records, revenue bands. These grow with business volume, which sounds scary and is actually the most negotiable of the three, because the forecast comes from your own operational data, and you know your volumes better than any seller does. Three families, three negotiations: named user deals argue about scoping, employee deals argue about the definition, transaction deals argue about the forecast. Know which argument you are in before you start arguing. First check.
First check. An HCM module is priced per Hosted Employee. Your organization: eight thousand employees, fifteen hundred long term contractors, nine hundred seasonal workers who work two months a year. Only six hundred HR staff will ever actually log in. The count you typically pay for is: A, six hundred, the people who use the system. B, eight thousand, employees means employees. C, roughly ten thousand four hundred: employees, contractors, and seasonal workers, as the service description defines the workforce, regardless of who logs in. Or D, whatever you declare at signature, Oracle cannot verify headcount. Pause here. The metric is Hosted Employee, not hosted user. Whose definition of employee applies?
The answer is C, roughly ten thousand four hundred, the workforce as defined, not the users as observed. Hosted Employee is a whole workforce metric by design: the standard definition sweeps in full time, part time, and temporary employees, plus the contractors and agents in scope for the service, and the nine thousand eight hundred people who will never touch the system count exactly like the six hundred who live in it. That is not a trick, it is the metric's architecture, it makes the bill track your headcount instead of your adoption, which Oracle quite reasonably prefers. A is the named user intuition applied to the wrong family, and it is the single most expensive habit in SaaS buying, because the gap between users and workforce is routinely ten to one. And D deserves a moment, because it is a trap with a delay: your declared count is contractual, and Oracle prices your renewal against your public filings, your LinkedIn footprint, and eventually your own HCM data, the system you are buying is literally the system of record for the metric that bills it. An understated workforce does not save money, it defers a true up conversation to the moment you have least leverage. If the definition is the number, then the definition is the negotiation. Which is exactly where we go next.
Where the definitions hide the money, five specifics. One, Hosted Employee, just covered: contractors, temps, and seasonal staff count, and some descriptions sweep affiliate headcount too, so scope the population in writing before anyone prices anything. Two, Hosted Named User: authorized, not active, dormant accounts bill until someone deprovisions them, so the leaver process is a licensing control with a monthly cash value. Three, the self service modules, and this one is sneaky: expense management or self service procurement can price on the workforce metric even though your mental model says a few hundred finance users, because the metric counts everyone who could file, not everyone who does. Check which family a module actually uses before assuming. Four, approvers and viewers: the executive who approves one workflow a quarter, the analyst who consumes one report, service descriptions differ on whether they need full subscriptions, and the casual user line is worth establishing in writing at the order. And five, affiliate scope: which legal entities may use the service and whose headcount counts, a definition that sleeps peacefully until an acquisition or a divestiture wakes it, module six will pick that thread up. None of these five are hidden. They are all sitting in the service description, in plain language, which is exactly why nobody reads them until the renewal makes them expensive. The money moves at signature, while the definition is still negotiable. Let's hear what that looks like when it goes wrong.
Guest analyst The deal that taught me to read definitions out loud was an HCM subscription for a retail group, signed three years before I saw it. At signature the customer counted eight thousand two hundred hosted employees, their permanent headcount, clean number, everyone agreed. What nobody read closely was the definition, which included temporary and seasonal workers engaged in the operation of the business. This was a retailer. Every November they onboarded six thousand seasonal staff for ten weeks, ran them through the workforce management module for scheduling, and offboarded them in January. Oracle's renewal team did read the definition, and they read the seasonal payroll too, because the customer processed it through the same system. The renewal quote arrived priced at fourteen thousand hosted employees, a seventy percent increase, and contractually they were right. We salvaged what we could: we negotiated a seasonal worker band at a reduced rate, and a definition amendment that priced short tenure workers differently, but we were negotiating for mercy, not for position, and mercy is expensive. Here is the lesson I now apply everywhere. At every SaaS deal review, someone reads the metric definition aloud, the actual sentence from the service description, and then we ask: is there any month of the year when our real population does not match this sentence? If the answer makes anyone in the room look at their shoes, the deal is not ready to sign.
Read the definition aloud, then ask whether any month of the year breaks it. A seventy percent renewal increase, fully contractual, built on one sentence about seasonal workers that nobody read at signature. The definition is the deal. Second check.
Check two, the family collision. An expense management module is being added for the three hundred people in finance who process expense reports. The line arrives on the quote priced per Hosted Employee, across your nine thousand five hundred person workforce. The right response: A, sign it, expenses is cheap per employee and everyone files one eventually. B, recognize the family mismatch as the negotiation: self service modules on workforce metrics price on everyone who could file, so either accept that knowingly, negotiate the population scope, or ask for a named user alternative, before signature. C, sign it but only provision the three hundred finance users. Or D, refuse workforce metrics on principle, Oracle always has a per user price. Pause here. Who could file an expense report? And does provisioning change the count?
The answer is B, and the reasoning matters more than the letter. Self service modules are where the two metric families collide head on: your mental model says three hundred processors, the metric counts nine thousand five hundred potential filers, and both readings are honest, they are just different machines. Now look at C, because it is the classic error and I want it dead: provisioning controls a Hosted Named User count, it does nothing whatsoever to a Hosted Employee count. Deploy to three hundred people, bill for nine thousand five hundred, the metric does not care about your rollout plan. D overcorrects into religion: sometimes the workforce metric genuinely is cheaper per head than named user pricing once adoption spreads, workforce metrics exist because they suit some deployments, the point is to run both calculations against your actual population and your actual adoption curve, not to have a policy. And A signs a thirty to one population multiplier without doing the multiplication. The discipline is the one from the slide: when a module's metric family does not match your mental model of who uses it, that mismatch is not a detail, it is the negotiation, and it is only negotiable before you sign. After signature, the family is the family.
The floors, five of them, the quantities that bill with nobody logged in. One, module minimums: most named user modules carry a minimum order quantity, and a small team pays the floor, not the headcount. The floor is per module, so a five module footprint multiplies it, that arithmetic shows up in the third check. Two, workforce floors: Hosted Employee modules commonly carry a minimum employee count, and a four hundred person subsidiary buying at a one thousand employee floor pays for six hundred ghosts, forever. Three, bundles and bases: Fusion sells base modules with add ons that require the base, and the dependency chain is part of the price, the add on you want quietly carries the base you did not. Ask what requires what before comparing quotes. Four, co termination: modules added mid term typically co term with the original order, which means a stub period billed at full annual rates, so the timing of module additions is real money, add at renewal when you can. And five, the meta rule of this whole session: floors, like definitions, are negotiable exactly once, at the first signature, while the deal is competitive and Oracle is selling. At renewal, the floors are your installed base, and installed bases do not negotiate, they escalate. Everything in this session compounds into the same sentence: the first order is where the money moves.
Three edges of the portfolio worth flagging before the checks close out. First, NetSuite, properly: same corporation, genuinely separate commercial machine. User packs instead of per module named users, module tiers, its own contract paper, its own sales organization with its own quarter end behavior. Fusion discount benchmarks do not read across, Fusion negotiation norms do not read across, and if your estate runs both, you run two playbooks and you never let one team's assumptions price the other's renewal. Second, Fusion CX: the human facing modules, sales and service, price per user like you would expect, but the marketing and data products price on records, contacts, and interactions, volumes that grow while your headcount stands still. Forecast those from your own CRM and marketing automation data, the seller's sizing is aspiration dressed as arithmetic. And third, the AI layer, which is arriving fast: agentic features and AI assistants are shipping as new SKUs with new metric names on top of the families you now know. The rule for every new metric name in a quote is the rule of this whole session: it is unread fine print, and the definition game we just played on Hosted Employee gets replayed on every one of them. The common thread across all three edges: every product in this portfolio, however novel, eventually reduces commercially to a metric definition in a service description. Read the definition and you know the product. Last check.
Last check. Fusion Financials for a sixty person finance team, quoted at one hundred users, because the module minimum is one hundred. The quote also carries two add on modules, each with the same one hundred user floor, and the team needs those add ons for fifteen specialists each. What is the exposure, and what do you challenge? A, nothing, minimums are policy and policy does not move. B, three hundred subscriptions for at most ninety real seats: challenge the floors at signature, price the add ons at their real population or inside the base bundle, because floors are negotiable exactly once. C, buy the add ons on a separate order later, to reset the minimum. Or D, accept it, unused subscriptions become credit at renewal. Pause here. Sixty people, ninety seats, three hundred billed. When does that ratio get fixed?
The answer is B, and the arithmetic is the whole argument: sixty people, ninety module seats across the three modules, three hundred billed subscriptions, a three point three to one ratio manufactured entirely by per module floors. Floors are pricing policy, not physics. At the initial signature, with a competitive evaluation still warm on the table, they get waived, halved, or absorbed into bundle pricing routinely, you just have to ask with the ratio written down, sellers concede to arithmetic faster than to adjectives. A confuses the rate card with the contract, the rate card is where negotiations start, not where they end. C actually makes it worse: a separate later order re triggers the same floor, adds a co term stub at full rates, and prices in a vacuum, after your competitive leverage went home. And D, the renewal credit myth, needs a stake through it: unused SaaS subscriptions are not credit, they are evidence, Oracle reads three hundred paid seats as your demonstrated budget, and the renewal opens from there. Shelfware anchors renewals, that is session twenty three's entire subject, and the anchor gets set today, at signature, by the ratio you agree to. Sign ratios close to one, or know exactly why you did not.
The discipline, three questions, and they are the session folded into a ritual. Question one: which metric family? Named user, workforce, or transaction. The family tells you what grows the bill, what you can control, and which negotiation you are in, and a module whose family surprises you is by definition a module you have not scoped. Question two: whose definition? Pull the service description, the actual document, and read the metric definition aloud in the deal review, Tom's rule. Who counts, which legal entities, which contractor categories, which month of the year breaks the sentence. If the definition and your org chart disagree, that disagreement will be priced, the only question is whether it is priced by you at signature or by Oracle at renewal. Question three: what floor? Per module minimums, workforce floors, base module dependencies, co term stubs. Compute billed quantity against real population before signature and challenge every ratio above one, with the arithmetic on paper. Three questions, in writing, every line item, every order. Sessions seventeen, eighteen, and nineteen are, honestly, these three questions applied with increasing ferocity: next week the full order anatomy, then ERP in depth, then HCM and its workforce metric at scale. The ritual starts now.
Session sixteen, three sentences. One: six product families, ERP, EPM, SCM, HCM, CX, and NetSuite, and every one of them reduces commercially to a metric definition in a service description, read the definition and you know the product. Two: three metric families, named user, workforce, and transaction, and the family decides everything, what grows the bill, what you can control, and whether you are negotiating scoping, definitions, or forecasts. Three: definitions and floors move exactly once, at the first signature, so the discipline is three questions asked before you sign, which metric, whose definition, what floor, and a ratio of billed to real kept as close to one as you can get it. Next session we take everything from today and walk a real order form line by line: the products, the quantities, the service description references, the environments, the fine print, reading a SaaS order the way an analyst reads it, before it becomes binding. See you there.
Homework, about an hour, and it produces the document module four builds on. One, pull the orders: every Oracle SaaS order in force, Fusion, NetSuite, anything with a subscription term, the order forms themselves, not the invoices, the invoices hide the structure. Two, build the metric map: one row per line item, module, metric name, metric family, billed quantity, and the floor if you can see one on the order. Three, find the definitions: for every workforce metric in the map, retrieve the service description and copy the actual definition of employee into the map, word for word, and note what it sweeps in, contractors, temps, affiliates. Four, compute the ratios: billed against real for every line, named users against active users from your identity system, hosted employees against HR headcount, floors against need. And five, star everything above one point two, because each of those is a right sizing candidate at the next renewal, and the map you just built is page one of the renewal file that session twenty three will teach you to run all year. An hour of reading orders, and your SaaS estate stops being a stack of invoices and becomes a position.
Five reads before next session, all free on redress compliance dot com. First, the Oracle Fusion Cloud applications guide, the portfolio map from today in reference form, family by family. Second, Hosted Named User versus Hosted Employee, the two big metric families compared with worked numbers, the arithmetic behind both of today's first two checks. Third, the Oracle Fusion modules list, the catalog of what exists and what requires what, useful when you hit the base and add on dependency chains. Fourth, the Oracle HCM Cloud licensing guide, the workforce metric in its home territory, and the preview for session nineteen. And fifth, the Oracle NetSuite licensing guide, the separate ladder, because if you run NetSuite alongside Fusion you are running two commercial worlds and both deserve a playbook. That's session sixteen. The portfolio is mapped, the metrics are named, and the three questions are yours now: which metric, whose definition, what floor. Next week, we read an order. See you then.