Defending a Fusion SCM Cloud Audit: What Oracle Examines in Your Subscription Usage

Oracle does not need a script to audit your Fusion SCM tenancy, because it already meters it monthly and holds the reports that decide the number. This guide shows exactly which artifacts Oracle reads, where its first-pass count is usually wrong, and how to rebut it inside the 30-day remediation window.

Why a SaaS Audit Is Not an On-Prem Audit

Everything you learned defending an on-prem Database or E-Business Suite review is dead weight here. In an on-prem audit, the fight is over data collection: whether the LMS script runs, on which hosts, in which window, and whether Oracle's interpretation of DBA_FEATURE_USAGE_STATISTICS reflects real deployment. In Fusion SCM, Oracle already has the data. Oracle operates the tenancy, installs and schedules the metering job itself ("Generate Metrics for Oracle Fusion SCM Services", running monthly under the RCS_CAPTURE_SCM_SAAS_USAGE_METRICS_PRIV privilege, typically completing in under ten minutes), and stores the resulting SaaS Service Usage Metrics Report and Hosted Named User Usage Drill Through Report on its own side of the fence. The 45-day written notice and the once-every-twelve-months cap in the Cloud Services Agreement are real, but they protect a process that Oracle has already completed before the letter lands. Your duty is to cooperate and provide reasonable assistance, and the CSA is explicit that Oracle bears none of your costs, so budget advisor and internal analyst hours as a real line item from day one.

Two clauses still work in your favor. The nondisclosure section covers the performance of the audit and the non-public data obtained during it, including findings and reports, which is your basis for insisting that the compliance conversation stays separate from the renewal conversation and that the account team does not receive a scorecard to negotiate against. And because Oracle controls collection, the only remaining battleground is definitional: what counts as an active user, what counts as a planned item location, what falls inside the trailing twelve months. That is where the difference between named user, employee, and volume metrics stops being academic and starts being money.

Your leverage is not in controlling data collection, because Oracle already ran the job: it is in the definitions and the arithmetic applied to the output.

The Clause That Decides the Price: Overage as Scope Change

Read the CSA again and note which sentence actually sets the invoice. It is not the audit clause. It is this: any usage in excess of Your rights under the applicable order(s) shall be considered a change to the scope of services, and You shall be responsible for paying the additional fees. That single reframing is worth more to Oracle than the audit right itself. A breach would trigger cure rights, termination mechanics, and a dispute posture. A scope change triggers a purchase order. Commercially, Oracle is not accusing you of anything: it is telling you that you bought more service, and the price of service you did not negotiate for is current list, not the 60 percent or 70 percent discount you fought for at signature. In our experience the delta between contracted rate and list on a Fusion SCM true-up commonly runs two to three times the number you would have paid had the same volume been ordered up front.

The Subscription Services Agreement variant compresses the window further: remedy, which may include payment of fees for additional Cloud Services, within 30 days of written notification. Thirty days is not enough time to rebuild your privilege inventory from scratch, which is why the evidence work belongs before the letter, not after it.

The negotiation move is structural and it belongs in the contract, not in the audit response. Pre-agree true-up pricing at your contracted discount, with any incremental subscription co-termed to the existing end date so you do not create a stub term that Oracle can reprice separately. Add a written statement that overage is remediated by ordering additional quantity at the ordering-document rate card, and cap the uplift on that rate card for the term. That language is cheapest to obtain at renewal, when Oracle wants your signature, which is exactly the argument set out in our guidance on right-sizing modules and capping uplift at an SCM renewal. Buy the protection while you still have something Oracle wants.

The Four Artifacts Oracle Actually Reads

The good news in a Fusion SCM review is that the evidence set is small, published, and sitting inside your own tenancy. Oracle is not going to surprise you with a proprietary script the way it does in a database audit. Four artifacts carry the entire commercial argument. First, the Generate Metrics for Oracle Fusion SCM Services scheduled process, which Oracle installs and runs monthly on your instance to gather licensing data; Oracle's own documentation instructs you not to modify the process or alter the schedule, it executes under the RCS_CAPTURE_SCM_SAAS_USAGE_METRICS_PRIV privilege, and it typically completes in under ten minutes. Second, the SaaS Service Usage Metrics Report (PDF), generated daily, containing the current month plus the prior three, which shows what you licensed, how much you licensed, how much you are consuming, and whether you are using a product you never bought. Third, the Hosted Named User Usage Drill Through Report (XLS), generated monthly, exposing raw HNU data with roles and privileges assigned at the individual user level. Fourth, and most often neglected, the Import User and Role Application Security Data ESS job, which feeds the drill-through and should be scheduled daily. If that job has not run in six weeks, the rebuttal file you hand Oracle is as stale as the claim you are disputing.

Pulling these yourself requires an OCI cross-tenancy policy setup: endorse and allow statements covering usage-report, subscriptions, and organizations-subscriptions, then navigation through Environments, Subscriptions, Usage to download the PDF. In our audit-defense practice, most SCM teams have never once retrieved their own numbers, which means Oracle quotes the report back to them and they have no independent baseline to test it against. Fix that before the notice letter, not after. Assign named ownership, because IT will assume Procurement owns it and Procurement will assume IT does. Pair the artifact set with the entitlement side of the equation from your Fusion SCM licensing and metric baseline so you are comparing measured usage against ordered quantities in the same units.

Active-User Counting Is Privilege-Based, Not Login-Based

Here is the misconception that costs clients the most money. Oracle's own metric language for Fusion services counts active users assigned a named privilege, for example "the count of active users assigned the WLF_LEARNING_COMMON_PRIV privilege." Nothing in that sentence mentions logging in. A warehouse supervisor who left in March, a finance analyst who has never opened an SCM page, a contractor provisioned for a go-live that slipped: all of them count if the privilege is still attached. Every defense built on sign-in logs collapses the moment Oracle produces the Hosted Named User drill-through, because that file lists privileges, not sessions. The related trap is role inheritance. A custom role copied from a seeded job role silently carries the underlying SCM privileges, so an IT or finance role cloned for convenience quietly manufactures licensed SCM users at scale. Read the drill-through by privilege, trace each one back to its granting role hierarchy, and you will usually find two or three cloned roles generating hundreds of countable users nobody intended to license.

A user who has never once signed in still counts if the privilege is attached, and no login log will save you.

The remediation move is timing, not argument. Revoke the privilege before the measurement month closes, because a revocation in month thirteen does nothing for a claim built on month eleven. Separately, enable the FND_TRACK_USER_ACTIVITY profile option and use the User System Usage OTBI subject area with the Last Activity Date column to build a documented dormancy case. That data is not retroactive: if you switch it on the week the audit letter arrives, you will have no history to show. Turn it on now as standing hygiene. Then confirm which metric actually governs each SKU before you argue about users at all, using the distinctions in named user versus employee versus volume metrics, and check external parties separately against the rules on whether supplier users count toward your license. In practice, privilege hygiene run quarterly removes more exposure than any negotiation posture you can adopt after the fact.

Module Activation: The Unlicensed Product Flag

The SaaS Service Usage Metrics Report does something no on-prem script does: it states, in one artifact, what you licensed, how much you licensed, how much you are using, and whether you are using a product you did not license. There is no discovery effort, no deployment mapping, no interview cycle. An activated module is a self-reporting finding, and Oracle's account team can read it before it ever sends you a notice. The uncomfortable part is that activation almost never follows a purchase decision. In our experience the four recurring causes are: an implementation partner enabling an entire offering because it was faster than enabling functional areas selectively, seeded functional area setup that switches on adjacent capability by default, a sandbox or test configuration promoted into production with its offerings intact, and opt-in features accepted during a quarterly update by an administrator who read the release note as a bug fix. None of those is a commercial act, but all of them produce the same flag.

The defensible distinction is between an enabled offering and actual transactional use, and Oracle will not draw that line for you. An enabled offering with zero transactions is a configuration error; an enabled offering with posted transactions is consumption you will pay for. Argument does not move this finding. Evidence does: documented deactivation with a change ticket and date stamp, plus a transaction extract showing zero records in the relevant business object across the full metering window. Pull that evidence before you respond, not after. The modules that most often light up sit adjacent to what you actually bought, so review the dependency map between Fusion Inventory and Manufacturing to see which neighbors are likely already switched on in your tenancy.

Transaction Volume: Trailing Twelve Months and Multiplicative Metrics

Volume metrics, not users, produce the largest SCM findings, because the counting windows are unforgiving in ways that user counts are not. B81263, Oracle Fusion Order Management Cloud Service Hosted 1,000 Order Lines, is defined as the number of sales order lines processed during the trailing twelve (12) months, in units of 1,000. That means a single peak quarter, a seasonal promotion, a one-time channel load, or a migration cutover that reprocessed historical lines, inflates your reported count for a full year after the event has passed. B85244, Planning Central Hosted 1000 Planned Item Locations, is worse in structure: it is reported monthly and defined as the number of Planned Items multiplied by the number of Planned Locations. Five new distribution centers do not add to the count, they multiply it. A 40,000 item master across 10 locations is 400 units; the same master across 15 locations is 600. Nothing about your business grew by fifty percent.

Five new distribution centers do not add to your Planning count, they multiply it.

Audit the exclusions in your own favor before you accept a number. Oracle's own metric text excludes auto-configured items from Planned Item Locations, and further excludes non-planned items, item configurations, organization assignments, and revisions or versions of the same item. First-pass claims routinely count all four. Where you hold a pooled SKU, 10,000 Pooled Order Lines is pooled across the Services Period stated on the Order Document, typically a three-year term, with consumption varying month to month. That is a genuine defense against a single bad month, and it is the reason pooled structures are worth negotiating at renewal rather than after a finding. For how the line-count arithmetic behaves across tiers, see our breakdown of how Order Management order-line volume pricing actually works.

Do this now: extract 24 months of order line and planning counts yourself, strip the documented exclusions, and hold that reconciliation before Oracle sends a number to rebut.

Where Oracle's First-Pass Number Is Usually Wrong

Oracle's opening claim is a gross count pulled from the SaaS Service Usage Metrics Report and the Hosted Named User Usage Drill Through Report, and it is almost never the defensible number. In our audit-defense practice the first pass typically carries three or four categories of over-count that come off before a single commercial argument is made. The reports show privilege holders, not people, so duplicate person records, users disabled in Fusion but never stripped of their SCM roles, and terminated employees whose role assignments survived offboarding all land in the count. Integration and service accounts are a second bucket: an account created to run an inbound order feed holds a licensable privilege and is counted as a named user unless you can show it is a system identity, not a human. A third bucket is tenancy scope, because test and non-production environment data sometimes gets folded into a production figure. On the volume side, cancelled and error-status order lines routinely appear as processed lines even though they never completed, and planning counts frequently ignore Oracle's own published exclusions.

Those exclusions are written into the metric definitions and are worth citing verbatim. For Planned Item Locations, auto-configured items are excluded, as are non-planned items, item configurations, organization assignments, and revisions or versions of the same item. Because the metric is multiplicative, (number of Planned Items) multiplied by (number of Planned Locations), each excluded item propagates across every location and the correction compounds. The related trap is version control. Match the Fusion Cloud Service Descriptions edition and the Metric Descriptions edition in force at your order date, not the current June 12, 2026 edition, because definitions change and the order-date version governs your entitlement. Our comparison of named user, employee, and volume metrics sets out which definition applies where. With SCM list pricing running roughly $300 to $450 per user per month for Supply Chain Planning, $200 to $300 for Order Management, and $280 to $400 for Manufacturing, every removed unit is worth documenting line by line.

What to Do First: A 30-Day Response Plan

The remediation clock in the Subscription Services Agreement is 30 days from written notification, so sequence matters more than volume of effort. On day one, acknowledge receipt only. Confirm in writing the scope, the contract version and order date that governs, and the exact measurement period, and concede no number. State that the audit occurs under the 45-day notice and once-per-twelve-months limit, and that findings fall under the nondisclosure section, which constrains what circulates to the account team. Between days one and five, pull your own evidence rather than waiting for Oracle's. Set up the OCI cross-tenancy policy, download the SaaS Service Usage Metrics Report (daily, current month plus prior three) and the Hosted Named User Drill Through Report (monthly, with roles and privileges at user level), and confirm the Import User and Role Application Security Data job is scheduled daily. If it is stale, your rebuttal is stale.

Days five to fifteen are reconciliation. Match every privilege holder to HR status, revoke dormant and terminated assignments, tag integration accounts, document the date and scope of any module deactivation, and apply the published volume exclusions to planning and order-line counts. Days fifteen to thirty: present a reconciled counter-position with the underlying report extracts attached, then negotiate any residual gap as a co-termed subscription increase at your contracted discount, never as a list-price true-up under the scope-change clause. Our guidance on right-sizing modules and capping renewal uplift covers how to fold the settlement into the renewal instead of paying it separately.

Three fixes are worth making now even if no letter has arrived, and they cost almost nothing:

• Enable the FND_TRACK_USER_ACTIVITY profile option so the User System Usage subject area records Last Activity Date. Without it, you cannot prove dormancy retrospectively.
• Assign a named owner for the RCS_CAPTURE_SCM_SAAS_USAGE_METRICS_PRIV privilege and the two commercial reports, so somebody sees the numbers before Oracle quotes them back.
• Run a quarterly self-check against the metric definitions in force at your order date, and keep the extracts. The baseline in our Fusion SCM licensing buyer guide is the right reference point.

Related advisory: the full topic guide.

Frequently asked questions

How much notice does Oracle have to give before a Fusion SCM Cloud audit?

The Cloud Services Agreement requires 45 days written notice and limits Oracle to no more than one audit every twelve months. In practice the notice period is less protective than it looks, because Oracle already holds the metering data from your tenancy and does not need the 45 days to collect it. Use the window to pull and reconcile your own usage reports, not to prepare a data submission.

Do users who never log in still count toward my Fusion SCM license?

Yes. Oracle counts active users assigned the relevant privilege, not users who logged in during the period. A terminated employee, an integration account, or a finance user who inherited SCM privileges through a copied job role all count until the privilege is revoked. Revoking after the measurement month does not retroactively reduce the reported figure.

What happens if Oracle finds an unlicensed module activated in my SCM tenancy?

The SaaS Service Usage Metrics Report explicitly flags products you are using but did not license, so there is no discovery burden on Oracle. Treat it as a commercial event rather than a compliance breach: the CSA reframes excess usage as a change to the scope of services with additional fees payable. Your defense is documented deactivation plus evidence of zero transactional use, negotiated as a subscription adjustment at your contracted discount rather than a list-price true-up.

Can a single peak quarter inflate my order line count for a whole year?

Yes, under the trailing twelve month metrics such as B81263 Order Management Hosted 1,000 Order Lines. A seasonal peak stays inside the counting window for twelve months and will drive your reported figure for that entire period. Pooled order line SKUs, where consumption is pooled across the services period, are the structural fix and should be negotiated at renewal.

How long do I have to remediate a Fusion SCM audit finding?

The Subscription Services Agreement variant requires the customer to remedy non-compliance, including payment of fees for additional cloud services, within 30 days of written notification. That is short for a full reconciliation, which is why you should pull your own usage reports quarterly rather than starting from zero when the letter arrives. Confirm which agreement version governs your order before assuming the timeline.

Which contract version governs the metric definitions in my audit?

The Fusion Cloud Service Descriptions and Metric Descriptions edition in force at your order date, not the current published version. Definitions change between editions, including exclusions such as auto-configured items in Planned Item Locations. Always request that Oracle cite the version applicable to your ordering document and check it yourself before accepting a count.