Module 7 opens on the third licensing world, and it shares almost no mechanics with the first two. No perpetual, no BYOL, no core factor, just a subscription priced on a metric, and the metric is the entire deal. This session maps the Fusion pillars and NetSuite, names the metrics each is sold on, hosted named user, employee, transaction, and shows where they inflate: the employee metric set on Fusion Financials that charges for 6,000 staff when 300 use it, a 20x overcount worth millions a year; the NetSuite warehouse users over tiered to full licenses; the friendly bundle whose free modules compound at every renewal. It closes with one Fusion estate metered honestly, the right metric per module, the renewal capped at signature.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the 6,000 employee company sold Fusion Financials on the employee metric for 300 actual users, a 20x overcount; the 200 NetSuite warehouse staff assigned full user licenses when a limited tier fits; and the attractive bundle whose three unused modules compound at every renewal. It closes with one Fusion estate metered to reality, HCM on the employee metric correctly, Financials re metered to named users, the bundle rejected on renewal math.
The full narration of this session, section by section, for reading and reference.
Welcome back, session thirty one of forty, and module seven opens on a genuinely new world. For thirty sessions you've worked in two licensing models: perpetual licenses with the core factor and the support annuity, and cloud consumption with credits and commits. Today the rulebook changes a third time, to software as a service, and almost none of the old mechanics come with us. No perpetual licenses. No core factor. No BYOL. No processors to count. Instead there's a subscription, priced on a metric, and the metric, who or what gets counted, is the entire deal. Get the metric right and a SaaS subscription is fair and predictable. Get it wrong, and you overpay for the whole term, and the term after that, and the one after that, because the mistake renews. This is Oracle's applications business now: Fusion Cloud Applications, the flagship suite, and NetSuite, the mid market ERP Oracle acquired, both sold as subscriptions with their own metrics and their own renewal behavior. Today we map the portfolio and, above all, the metrics: hosted named user, the employee metric, transaction and document counts, and where each one applies, because the same company pays wildly different amounts depending on which metric prices which module. The negotiation discipline from module four still applies. The mechanics are new. Let's learn the third rulebook.
Five takeaways. One, you'll map the portfolio: the Fusion pillars, ERP, HCM, SCM, and CX, plus NetSuite, and what each is actually sold as, because Fusion is a catalog bought module by module, not a single product. Two, you'll name the metrics: hosted named user, the employee metric, transaction and document volumes, contact and send counts, and the enterprise metrics, and, crucially, which metric fits which kind of application. Three, you'll count honestly: sizing a subscription to the real user population and real transaction volume, not to the headcount or the org chart that sales will happily default to. Four, you'll read the economics: what the subscription model gives, operational relief, and what it takes, ownership, plus the uplift that returns at renewal exactly as support did. And five, you'll spot the metric traps before signing: the employee metric on a departmental app, over tiered users, bundled shelfware, and the uncapped renewal, each one a recurring overpayment set in the first contract. One sentence to carry through the whole module: in SaaS, the metric is the deal, and matching the metric to actual use is the entire skill. The stakes, next.
Four numbers. Three: the licensing worlds you now know. Perpetual with support, cloud consumption, and, from today, SaaS subscription. This third one shares almost no mechanics with the first two, which is why it gets its own module rather than a footnote. Zero: perpetual licenses in SaaS. Nothing to own, nothing on the balance sheet, no BYOL bridge from your existing licenses, no walk away that keeps the software running. You rent access by a metric, and when you stop paying, access stops, which reshapes the whole leverage picture from module four. One: the metric that decides the deal. Everything in a SaaS negotiation flows from which metric prices which module, and a wrong metric is not a one time overpayment, it's a permanent one, renewed every term. And three to eight percent: the renewal uplift, back again. Module four's support annuity has a SaaS cousin, the subscription uplift, compounding across renewals on the same fiscal calendar, and the same discipline of capping it at signature applies. Module seven runs five sessions: the portfolio and metrics today, reading the subscription contract next, then negotiating a Fusion deal, then NetSuite specifically, and finally SaaS renewals and shelfware. Every one of them starts from the metric, so that's where we start. The portfolio, first.
Oracle Fusion Cloud Applications, the flagship SaaS suite, sold as pillars, each a family of modules with its own metrics and its own buyers. Five cards. Fusion ERP: financials, procurement, project management, the finance department's suite, sold largely on hosted named user, with some modules on transaction or document volume. Fusion HCM: core HR, payroll, talent, and here's the important one for today's metric lesson, priced per employee, because in HR the whole workforce genuinely is the user base, so the employee metric fits. Fusion SCM: supply chain, manufacturing, logistics, a mix of user and transaction metrics, order lines and shipments among the things counted. Fusion CX: sales, service, and marketing, user based for sales and service, but marketing often priced on contact or send volume, an entirely different meter that scales with your audience, not your staff. And the module reality, the card that governs every Fusion deal: Fusion is bought module by module, each module with its own metric and its own price, so the suite is a catalog, not a single SKU, and the modules add up fast. The first job in any Fusion conversation is knowing exactly which pillar, which modules within it, and which metric each module carries, because, as the next slides show, the metrics are not uniform and the differences are enormous. The metrics themselves, next.
The SaaS metrics that price the deal, five of them in one table. Hosted Named User: counts the individuals authorized to use the service, and it prices much of Fusion ERP, SCM, and CX, the applications a defined population uses. This is session two's named user idea, reborn as a subscription. The employee metric: counts your total employees, users or not, and it prices Fusion HCM and some enterprise agreements. It's simple and it fits HR, where everyone is a user, and it's ruinous anywhere else, which is the whole of the next knowledge check. Transaction or document: counts volume, orders, invoices, records processed, and it prices SCM modules, some ERP, and usage heavy services. This one scales with business activity rather than people, so it needs a forecast, not a headcount. Contact or send: counts marketing audience or message volume, pricing CX marketing and engagement services, a meter that can grow independently of everything else you buy. And enterprise metrics: revenue bands, spend bands, or headcount bands, pricing the large all you can eat style Fusion agreements. The line to hold from this table: the metric is not cosmetic. The same five thousand person company pays wildly different amounts under named user versus employee versus transaction pricing, so choosing the metric, module by module, is the deal itself, not a detail of it. The most expensive metric mistake, tested. Knowledge check one.
Knowledge check one. A six thousand employee company wants Fusion Financials, which perhaps three hundred finance staff will actually use. The sales team proposes the employee metric, for simplicity. Sound? A, yes, the employee metric is simplest, and simplest is cheapest. B, no: Financials is a named user application used by three hundred people, and priced per employee it charges for six thousand, a twentyfold overcount, so insist on the hosted named user metric. C, yes, employee pricing always costs less than named user. Or D, it doesn't matter, the price is the same either way. Pause here. How many people use Financials, and how many would the employee metric charge for?
The answer is B, and you do the arithmetic the simplicity pitch is designed to skip. Fusion Financials is used by the finance function, three hundred people here. On hosted named user, you subscribe roughly three hundred, plus perhaps a handful of occasional approvers. On the employee metric, you pay for all six thousand employees, whether they ever open the application or not, a twentyfold overcount, and at Financials per user rates that gap runs to millions of dollars a year, every year of the term, and it renews. Here's why the trap works: the employee metric genuinely is simpler, no user counting, no access reviews, no true ups, and that administrative convenience is exactly the wrapping that makes it the expensive default sales offers on applications only a department uses. The metric isn't evil, it has a correct home, HCM, where the entire workforce really is the user base, which is next session's contrast and the reason the metric exists at all. But bolting the employee metric onto a departmental application is the single most expensive metric error in Fusion, and it's proposed constantly, always under the banner of keeping things simple. B is the discipline: the metric follows who actually uses the module, and for Financials that's named users. A confuses simple with cheap, which in SaaS are frequently opposites. C is false, employee pricing wins only when nearly everyone is a user and loses badly otherwise. D ignores the twentyfold difference the whole question is built on. The permanent rule: name the actual user population of every module before accepting any metric, because the metric charges for its count whether or not that count ever logs in. NetSuite, next.
NetSuite, the other Oracle SaaS, and a genuinely different animal. It's Oracle's mid market ERP, acquired whole, run as its own business inside Oracle, with its own product, its own rulebook, and its own commercial rhythm. Five facts. The model: a base platform subscription, plus modules, plus user licenses. Three layers, each priced separately, and the base plus modules often cost more than the users, which surprises buyers who focus only on seat count. User types: full users, employee self service, and limited access tiers, priced very differently, so assigning the right tier to each person is real, recurring money, the subject of the next check. The SuiteSuccess bundles: industry packaged editions bundling modules for a given vertical, convenient, and a classic place for unused modules to hide inside a single tidy price. The discount and renewal pattern, and this one is well documented: deep initial discounts to win the deal, then aggressive renewal uplifts once you're embedded, a rhythm session thirty four teaches you to plan for from day one rather than discover in year two. And bought whole, sold hard: NetSuite runs its own sales motion with its own tactics, distinct from Fusion's, though the buyer discipline you bring is identical. NetSuite gets its own full session, thirty four. Today's point is just this: it's a distinct product with distinct metrics and distinct renewal behavior, not a flavor of Fusion, and it must be sized on its own terms. The tiering discipline, tested. Knowledge check two.
Knowledge check two. A NetSuite proposal assigns full user licenses to two hundred warehouse staff who only confirm shipments. What should the buyer check? A, nothing, all users need full licenses. B, the user tiers: shipment confirmation likely fits a limited access or employee self service tier at a fraction of the full user price, so re tier the two hundred and cut the cost. C, whether to buy a second NetSuite account instead. Or D, nothing, user tiers cannot be changed after the proposal. Pause here. What do those two hundred people actually do in the system?
The answer is B. NetSuite sells access in tiers priced far apart, and the gap between a full user and a limited access user is large, frequently several fold. Two hundred warehouse staff who only confirm shipments are doing precisely the narrow, transactional work the lower tiers exist for, and assigning them full user licenses pays full price for capability they never touch, across two hundred people, for the entire life of the subscription. B is the check every NetSuite proposal deserves: walk the user list role by role, and match each person to the thinnest tier that covers what they actually do. Full users for the finance and operations people who live in the system all day; self service or limited tiers for the confirm a shipment, submit a timesheet, approve a request population that touches it briefly. This is session two's named user discipline reborn in a subscription, the same principle that you buy the capability used, not the capability available. A is exactly the assumption the default proposal counts on, because over tiering is revenue, so proposals arrive over tiered by default. C overreacts: the fix is re tiering within the one account, not opening a second, which would just multiply base platform costs for nothing. D is false, tiers are the most negotiable line in a NetSuite deal before signature and remain adjustable at renewal. And the general SaaS rule, holding across both Fusion and NetSuite: the metric or tier must match actual use, person by person and module by module, because the subscription bills the assignment, not the usage, and the assignment is the one thing entirely in your control. Counting honestly, next.
Sizing a SaaS subscription to reality, because the counting discipline from module one comes back, aimed at a new target: real users and real volumes, never defaults. Five habits. Count the real users, per module: who genuinely needs access, at what tier, from the access list, not the headcount and not the org chart's aspiration for who might someday use it. Forecast the volume honestly: for transaction metrics, real order lines and document counts with a defensible growth curve, exactly session twenty six's forecast discipline transplanted from cloud consumption to SaaS transactions. Separate the pillars: HCM's employee metric and ERP's named user metric count completely different populations, so never let one module's metric bleed into another module's pricing, which is how the knowledge check one disaster happens. Plan for growth deliberately: subscriptions grow mid term by adding users at the contracted rate, so size to today's real need, with price holds locked for tomorrow's growth, per session thirty three, rather than pre buying seats against a forecast. And record it: the subscription counts, users by module and tier, volumes by service, join the entitlement library from session twenty five, because SaaS belongs in the license position too. One warning that surprises people: SaaS feels like it needs no license management, because there's nothing to install and nothing to audit in the old sense. But the subscription counts still drift as people join and leave, still inflate as modules get added, and still deserve the records, because every uncounted seat is a line you keep paying. The economics, next.
The subscription model, honestly, what it gives and what it takes, against the two worlds you already know. What you gain: no infrastructure, no upgrades, no patching, no version management. Oracle runs it, and the whole operational burden from modules one and five, the deployment baseline, the patching, much of the audit surface, largely disappears. That's a real benefit, and for many applications it's the right trade. What you give up: ownership. No perpetual license, no asset on the balance sheet, and, importantly for leverage, no walk away that keeps the software running. Stop paying and access stops, which is a fundamentally weaker negotiating position than the perpetual world where you could run unsupported, and it's why the SaaS renewal deserves such care. The uplift returns: SaaS renewals carry uplift just as support did, three to eight percent, compounding across terms, module four's annuity lesson wearing subscription clothes. No BYOL bridge: your perpetual licenses do not convert into SaaS, the database BYOL from session twenty seven has no applications equivalent, so SaaS is always a fresh subscription, never a migration of assets you own. And the lock in shape: your data and your configuration live in Oracle's cloud, and the switching cost, the migration of both, is the real lock in, far more than any contract term, which is exactly why the exit and data retrieval clauses in session thirty two matter as much as they do. SaaS trades ownership and control for operational relief, a fair trade for many applications, but a trade, and the renewal is where its price becomes visible. The traps, next.
The metric traps, five of them, every one set before you sign and paid for every term after. One, the employee metric on a departmental app: knowledge check one's trap, paying for the whole company to run a finance system, the most expensive SaaS error there is, and the most common, because it arrives dressed as simplicity. Two, over tiered users: knowledge check two's trap, full licenses for self service work, so tier everyone to actual use or pay the gap forever, across every over tiered seat. Three, bundled shelfware: SuiteSuccess and Fusion bundles carry modules you won't use, and the tidy bundle price hides the unused, module two's shelfware lesson wrapped in a discount, with the twist that it also inflates the renewal base. Four, optimistic user counts: sized to the org chart rather than the access list, and every phantom user is a full subscription line, renewed every term, for a person who never logs in. And five, the uncapped renewal: no renewal cap negotiated at signature means the uplift runs free later, and session thirty three's fix, the cap, has to be set at signature, because that's the only moment you hold leverage, before Oracle has your data and your dependency. Notice the shape all five share: each is a recurring overpayment locked into the first contract, invisible in year one, compounding every year after. The subscription's danger isn't a one time overspend, it's a permanent one, which is why the metric decisions today are worth more than any single renewal negotiation later. The bundle trap, tested. Knowledge check three.
Knowledge check three. A Fusion bundle is offered at an attractive price, including four modules the team will use and three it won't. The rep says the extras are essentially free. Do you buy it? A, yes, free modules can't hurt. B, scrutinize it: bundled modules are never free, they inflate the renewal base and the metric counts, so price the four module deal separately and compare. C, yes, and deploy all seven to get the value. Or D, no, bundles are never worth considering. Pause here. What is the renewal priced on, and what did the bundle just set?
The answer is B, and you get there by following the money past year one, which is exactly where essentially free doesn't want you to look. The bundle's attractive price is a first term number. The renewal, per this session's economics and module four's annuity lesson, is an uplift on the whole subscription base, including the three modules nobody uses, so the extras that were free in year one carry a compounding uplift in every year after, and they set the base that every future negotiation starts from. Worse, some of those unused modules carry their own metrics, employee counts or transaction volumes, that quietly enlarge the counted footprint and the compliance surface even while sitting idle, module two's shelfware and module five's audit exposure arriving together inside a friendly bundle. B is the discipline: price the four module deal you actually want on its own, then compare it honestly to the bundle, renewal math included, and if the bundle genuinely wins on the modules you'll use with a capped renewal, take it, but as a decision, not a reflex. Sometimes bundles do win, which is why D overcorrects; a bundle that beats the standalone price of the modules you need, capped, is a fine buy. A is the pitch itself, false the moment the first renewal lands. And C is the worst answer: deploying unneeded modules to justify the purchase manufactures usage nobody needed and cost nobody planned, session twenty four's shelfware conversion trap in SaaS clothing. The rule that closes the session: in subscriptions, free is a first term word, and the renewal is where every free thing is finally priced. The full estate, metered honestly, next.
One Fusion estate, metered to reality, the session in six rows. Fusion HCM: six thousand employees, and the employee metric fits, because in HR all staff genuinely are users, so this line is correct as proposed, the metric matches the population. Fusion Financials: three hundred ten hosted named users, not six thousand employees. Re metered from the default proposal, this removes the twentyfold overcount from knowledge check one, and on Financials rates that single correction saves millions a year, every year. Fusion SCM: a transaction metric sized to real order line volume with a defensible forecast, not a round number, session twenty six's forecast discipline applied to SaaS transactions. The offered bundle: three unused modules dropped, the four module deal priced standalone, and the bundle rejected on the renewal math per knowledge check three. Renewal protection: a cap negotiated at signature, bounding the three to eight percent uplift before it compounds across terms, the only moment the leverage exists. And the estate, the bottom row: the right metric on every module, every user tiered to actual use, the bundle declined, and the renewal capped, a subscription sized to use rather than to headcount. Look at what happened across those rows: HCM's employee metric was exactly right, Financials' was catastrophically wrong, and the bundle was a renewal trap. Same suite, three completely different judgments, one honest count behind each. That's the whole skill of SaaS licensing in one table. Recap, next.
Session thirty one in three sentences. One, SaaS is the third licensing world, no perpetual, no BYOL, no core factor, just a subscription priced on a metric, and the metric, named user, employee, transaction, contact, is the entire deal rather than a detail of it. Two, the metric must match who actually uses each module, department by department: the employee metric fits HCM because everyone is a user and ruins Financials because only finance is, and every individual user gets tiered to what they actually do, especially in NetSuite. Three, the subscription trades ownership for operational relief, the uplift returns at renewal and compounds, nothing bundled is ever free once you follow it past year one, and the SaaS counts belong in the session twenty five records like every other license, because they drift and inflate exactly the same way. Next session goes inside the paper: reading a SaaS subscription contract. The subscription terms and service descriptions, the difference between Oracle's marketing pledges and the actual contract commitments, the data retrieval rights that decide whether you can ever leave, and the termination mechanics. The contract is where the metric you chose today either gets protected or gets exposed. Homework first.
Homework, about an hour, and it builds the SaaS half of your license position. One, map your SaaS estate: every Oracle SaaS subscription you hold, which pillar, which modules, which metric, and how many units of each. Most estates have a detailed on premises inventory and have never once listed their SaaS the same way. Two, check one metric against use: pick a named user or employee metric module and count the actual users against the subscribed quantity. Does it match, or are you carrying an overcount? Three, tier a user list: take one NetSuite or Fusion module and put every user against the thinnest tier that fits their role, and note the re tiering saving, because it's usually larger than expected. Four, find the bundles: any SuiteSuccess or Fusion bundle, list the modules actually deployed against the modules purchased, and the unused ones are your renewal exposure, sitting quietly in the base. And five, find the renewal dates: every SaaS renewal date and its current uplift, into the session twenty five calendar right beside the support renewals and the cloud commits, because they're all the same negotiation season now. That's the hour. See you in session thirty two, inside the subscription contract.
Five reads, all free on redress compliance dot com. First, the Oracle Fusion Cloud Applications guide: the pillars, the modules, and the metrics, at reference depth, today's portfolio as a full map. Second, the Oracle Fusion modules list: the entire catalog module by module, with the metric each one carries, the document to have open during any Fusion scoping conversation. Third, the Oracle Cloud ERP pricing guide: how the ERP pillar is priced, metric by metric, the numbers behind today's arithmetic. Fourth, the Oracle NetSuite licensing guide: the base platform, the modules, and the user tiers, your preparation for session thirty four. And fifth, FinOps for SaaS licensing: managing subscription spend as a standing discipline, the SaaS equivalent of the cost management this course has taught throughout. That's session thirty one. The third rulebook is open: no ownership, no core factor, just subscriptions priced on metrics, where the metric is the deal, the metric must match actual use, and everything bundled gets priced at the renewal. Next session we read the contract that holds it all together, and find out whether the metric you chose is actually protected on paper. See you there.