Defending a Hyperion Audit: Proving Which Options and Users Actually Count

Oracle's Hyperion audit findings are built on two assumptions: that every provisioned account is a licensable user, and that every installed component is a licensed option. This playbook shows you the evidence that dismantles both, and the sequence in which to present it.

What Oracle Actually Measures in a Hyperion Audit

Start from an uncomfortable truth for Oracle: there is no Hyperion equivalent of the Database LMS collection scripts. There is no options_packs_usage_statistics view, no feature-usage table with first and last use timestamps, no measurement layer at all for most of the estate. What LMS actually collects is a Shared Services provisioning export, an installed-component inventory from the deployment report, a hardware list, and interview notes from whoever answered the questionnaire. Every one of those is inference, not measurement. Provisioning a group is not usage of a product. Laying binaries on a filesystem is not deployment of an option. That distinction is the whole of your defense, and it is worth saying out loud in the first call with the audit team, because once Oracle's spreadsheet circulates internally the numbers acquire a false authority they never earned.

Nearly all the money in a Hyperion finding comes from four claim categories. First, named user counts derived from Shared Services groups, including terminated staff, service accounts, and nested groups nobody has reviewed since 2014. Second, the 25 Named User Plus per processor minimum applied to core-factored hardware, which on an 8-core Intel box at a 0.5 core factor produces a floor of 100 users regardless of how few people log in. Third, restricted-use components treated as full-use: the Essbase engine embedded with Planning, WebLogic Server Standard Edition, Oracle Internet Directory, and the ODI standalone agent. Fourth, separately-priced modules assumed to be in scope, such as Tax Governance at $4,500 per Application User, Data Relationship Steward, and individual FDMEE adapters. Under most ordering documents the burden of proving the more expensive interpretation sits with Oracle, and our advice on Hyperion named users, options, and scope is to make them carry it line by line.

Provisioning is not usage, installation is not deployment, and Oracle owns the burden of proving otherwise.

Pull the Contract First: Old SKUs, Old Prices, Old Metrics

The highest-leverage hour of the entire engagement is spent reading your original ordering documents, not the audit output. Hyperion estates are typically 10 to 20 years old and frequently carry pre-acquisition or early-Oracle SKUs whose metric definitions and unit prices differ materially from today's list. Oracle will price any claimed shortfall at current list unless you force the conversation back to the ordering document's own definitions, its stated minimums, and any price-hold or capped-uplift language. The gap is not marginal. Compare a legacy Planning System 9 entitlement against the current Planning Plus part, and the per-seat delta alone changes a 400-user finding by more than half a million dollars before support is layered on.

Treat the archived figures as directional and verify them against your own paper, because they come from a public archived list rather than your contract. Then make one procedural demand and repeat it until it is met: Oracle must cite the specific ordering document, dated, and the specific section underpinning every claimed breach. A spreadsheet row saying "Essbase Plus, 240 users, unlicensed" is not a claim, it is an assertion. If the ordering document defines Application User by reference to a 2009 metric with a 25-user minimum, that definition governs, not the current price list. Where the contract lets you switch counting basis, our comparison of Named User Plus versus Processor for EPM estates shows where the remedy is cheaper than the finding.

Building the User Evidence Pack: Provisioning Is Not the Answer

Oracle's opening user number in a Hyperion audit is almost always a Shared Services provisioning export: every account holding a role in Planning, HFM, Financial Reporting, or Essbase, deduplicated only by login string. In our audit-defense work that export routinely overstates the licensable population by 30 to 60 percent, and the causes are predictable: leavers whose native directory accounts were never deprovisioned, service and integration accounts running FDMEE or batch jobs, the same human appearing once as a native user and again as an LDAP or Active Directory identity, and read-only viewers provisioned during a rollout who never logged in again. None of those are arguments Oracle will make for you. The reconciliation is yours to build, and it has to be defensible line by line, because the counter-evidence you skip becomes the seat Oracle keeps. Note that Application User and Named User Plus are the same counting exercise here, and HFM has no concurrent-user metric, so there is no pooling argument available: every dispute is about a specific named individual.

Build the roster as a join, not a filter. Start with Shared Services group membership, join to HR active-employee data on a stable identifier, join to authentication logs for a defined lookback (12 months is the window we defend most often), and then join to Smart View and Excel add-in session evidence. That last join matters because Smart View users count as named users even if they never touch a web interface, and shared or generic accounts do not help you: Oracle counts the actual humans behind them, so an account used by six analysts is six licenses, not one. Contractors and external auditors need deliberate documentation too, since they must either sit on one of your licensed accounts or be licensed in their own right.

Shared accounts do not shrink the count, they expand it, because Oracle licenses the humans behind the credential.

The deliverable is one reconciled roster with a written inclusion rule attached: who counts, on what evidence, over what window, with named exceptions. Hand Oracle the rule before the number, because a number without a rule invites the auditor to substitute their own.

The 25-Per-Processor Minimum and Why Hardware Evidence Beats User Evidence

In mid-size Hyperion estates the finding is often not driven by headcount at all. Named User Plus carries a minimum of 25 users per processor, and once your reconciled roster falls below that floor, every additional seat Oracle claims is arithmetic on your hardware, not on your people. Ten planners on a two-processor Planning server still cost 50 NUP. That inverts the defense priority: the fastest route to a smaller number is CPU model evidence mapped to the Oracle Core Factor Table, not another week of provisioning cleanup.

That $350,000 swing on a single server turns on paperwork you either have or do not. If you cannot produce the CPU model, physical core count, and the matching core factor entry, the auditor will apply the less favorable factor and you will be arguing from the back foot. Virtualised and oversized hosts compound it, because Oracle's default position on soft partitioning is to count the whole host. Three artefacts close the gap: a server inventory with hostnames, CPU model strings pulled from the systems themselves, and a role map showing which hosts actually run licensable Hyperion services versus web tier, workspace, or utility functions that carry no separate metric. Where the floor still dominates your reconciled headcount, run the comparison in the named user versus processor metric analysis before you concede, because a Processor licence on a small documented host is sometimes cheaper than the NUP minimum it triggers.

Restricted-Use Components: Where Oracle Overreaches Most Often

The enabled-options portion of a Hyperion audit finding is the most winnable, and buyers routinely surrender it because they treat it as a technical argument rather than a documentary one. It is documentary. Oracle wrote the restrictions down itself, in the EPM 11.2 "Included Products and Components" documentation, and the restrictions are narrow, specific, and testable. Your job is not to argue about intent. It is to produce evidence that the deployment stayed inside boundaries Oracle already published. In 25 years of these disputes, the pattern is consistent: the auditor asserts a full-use claim because a binary exists on disk or a service is running, not because anyone verified how it was used. That gap is where you take the money back.

There are four recurring claims and each has a defined proof. First, the embedded Essbase inside Planning Plus is restricted to Planning application data, so your defense is a cube-by-cube inventory showing every application shares Planning metadata rather than existing as an independent analytic application. Any cube built for standalone ad hoc reporting converts to a full standalone Essbase license claim, and note the entitlement does not run in reverse either: standalone Essbase licenses do not cover Planning Plus, and Planning Plus does not cover standalone Essbase. Second, restricted-use Essbase Plus under Financial Close Suite requires each Aggregate Storage Option application to share data and metadata with a deployed HFM Plus instance, so produce the ASO application list mapped to its HFM source. Third, restricted-use WebLogic Server Standard Edition and Oracle Internet Directory may only run Hyperion Java logic and store Hyperion user information, so a single co-deployed application or a non-Hyperion directory branch converts both into full-use claims (the buried WebLogic and database exposure is where the largest single-line findings surface). Fourth, running ODI scenarios in batch mode with the stand-alone agent triggers a full-use ODI Enterprise Edition requirement, so pull your agent configuration and scheduler logs before anyone else does.

Oracle published the restrictions itself, which means the enabled-options fight is a documentation exercise, not a debate.

Sequence matters. Present the restriction language from Oracle's own documentation first, then the deployment evidence proving compliance, then invite the auditor to identify which specific application or service falls outside it. That inverts the burden and stops the conversation drifting into installed-binary theory.

The Modules Oracle Assumes Are In Scope But Often Are Not

Suite SKUs create a false impression of coverage in both directions, and buyers lose money on both. Planning Plus and Financial Close Suite package several components under one part number, but the component quantities still have to reconcile, so Oracle can and does claim a shortfall on an included module while your team assumes the suite covered it. Running the other way, several products that sit inside the same environment are separately priced Application User SKUs that nobody bought and nobody consciously turned on. Hyperion Tax Governance lists at $4,500 per Application User with $990 annual support. Data Relationship Steward and Data Relationship Management for Financial Close Suite are distinct line items, not the restricted DRM bundled into EPM. FDMEE adapters are individually licensed: the SAP ERP source adapter, the HFM adapter, and the Adapter Suite each appear separately. The database under HFM is never bundled and must be licensed separately, whether Oracle Database or SQL Server, which is a cost line that belongs in your own Hyperion entitlement baseline long before an auditor asks.

Do this now. Build a three-column inventory: what is installed, what is configured, and what has recorded production activity in the last 12 months. Anything installed but never configured is a non-issue you should be able to prove in an afternoon. Anything with 12 months of genuine activity, you license and stop arguing. The middle category, configured but unused, is the whole game: disable it, document the date and the change ticket, and capture the pre-change usage extract before you respond. Do that after the audit letter lands and it looks like concealment. Do it as documented housekeeping with evidence retained, and it is a defensible reduction in scope.

Indirect Access and Downstream Reporting: The Argument to Prepare Early

Indirect access is the least settled area of Hyperion licensing, which is precisely why it rewards documented architecture and punishes improvised explanation. Oracle's position, as reflected in current guidance, is that if Hyperion data feeds another tool that people access, those individuals may still count as users depending on how the access is structured. The word "may" is your opening. The defensible line, in 25 years of arguing this with Oracle LMS and their successor teams, runs between two architectures: a scheduled batch extract that lands data in an independent store the reporting layer owns, versus a live query, ODBC pass-through, or drill-through that hits the Hyperion engine at runtime. The first is a data copy. The second is use of the software. If your Power BI or Tableau layer issues a query that reaches Essbase or HFM while a human waits for the result, expect Oracle to count that human, and expect them to be right. If your warehouse holds its own copy, refreshed nightly by FDMEE or ODI, with no runtime dependency, you have an argument worth several hundred seats at $3,500 to $5,200 list apiece.

• Integration diagrams showing every data path in and out of Hyperion, with direction and trigger (scheduled versus user-initiated).
• ETL job schedules and run logs proving refresh is time-based, not query-based.
• Database connection evidence from the reporting layer showing it targets the warehouse, not the Essbase or HFM instance.
• Screenshots or configuration files proving drill-through to source is disabled where you claim it is.
• A written architecture statement signed off by your integration lead, dated before the audit letter where possible.

Build this pack before Oracle asks. A diagram produced two weeks after an engineer said something loose in an interview is worth a fraction of the same diagram produced unprompted. Data warehouse layers, Power BI, and Tableau are the usual triggers, and the on-premise Hyperion licensing rules for named users and options are the frame Oracle will apply.

What to Do First: The 30-Day Response Sequence

Work the sequence in order. Week one: acknowledge the audit letter in writing without agreeing scope, entity list, or date range, and say so explicitly. Retrieve every ordering document, amendment, migration agreement, and support renewal quote going back to the original purchase, because legacy Application User SKUs carried materially lower prices and, sometimes, different metric definitions. Appoint one named response owner and instruct in writing that no engineer, DBA, or administrator answers Oracle directly or runs an Oracle-supplied script without review. Week two: build the reconciled user roster (Shared Services provisioning cross-checked against actual login and Smart View session activity, deduplicated for shared and service accounts) and the hardware pack (CPU model, socket and core counts, core factor evidence, virtualization boundaries). The named user versus processor comparison tells you which side of the 25-per-processor minimum each server falls on. Week three: run the restricted-use component review, focusing on bundled Essbase used outside Planning data, ODI stand-alone agent batch scenarios, WebLogic hosting non-Hyperion applications, and Internet Directory scope. Disable anything unlicensed and unused, and keep dated change records showing what was turned off and when. Week four: respond with your numbers, your contract citations, and a written position on each claim category. Do not accept Oracle's spreadsheet as the baseline.

Do not accept Oracle's spreadsheet as the baseline; make them argue against your reconciled numbers, not the other way around.

Name the leverage honestly. Oracle's real objective is backdated support at 22% of list plus a forward commitment, not a license true-up in isolation. Your counterweights are timing and alternatives: sustaining support economics, the third-party support option, and your EPM Cloud migration schedule. Test every settlement number against those three before signing anything.

Related advisory: the full topic guide.

Frequently asked questions

Does every person with a Hyperion login need a licence?

Every individual authorised to access the software needs a named user licence, including read-only viewers and anyone using the Smart View Excel add-in. However, an authorisation that was provisioned and never used, or that belongs to a leaver or a service account, is not a licensable human. Your defense is a reconciled roster joining Shared Services provisioning to HR active-employee data and authentication logs, not the raw provisioning export Oracle will ask for.

Can Oracle count concurrent users instead of named users for HFM?

No. There is no concurrent user metric for Hyperion Financial Management, so every count argument is a named-individual argument. Shared or generic accounts do not help because Oracle will count the actual people behind them. External auditors and consultants who need occasional access must either use one of your licensed accounts or be licensed separately.

Is the Essbase engine included with Hyperion Planning a full Essbase licence?

No. The Essbase engine bundled with Planning Plus is restricted-use and scoped to the Planning application's data only. Building separate Essbase cubes or applications unrelated to Planning falls outside that scope and requires a full standalone Essbase licence, and Oracle auditors check for exactly this. Planning Plus entitlements do not convert to standalone Essbase and vice versa.

How does the 25 Named User Plus per processor minimum inflate a Hyperion audit finding?

The minimum applies per processor after the core factor is applied, so hardware size drives the licence floor regardless of actual headcount. An 8-core Intel server at core factor 0.5 equals 4 processors and a 100 NUP minimum, while the same server assumed at factor 1.0 produces a 200 NUP minimum. If you cannot evidence the CPU model and core factor, Oracle will assume the less favourable one.

What does a Hyperion licence shortfall actually cost at list price?

Hyperion Planning Plus lists at $3,500 per Application User with $770 annual support, and HFM Plus at $5,200 with $1,144 support, both support figures being 22% of licence. Oracle's real objective in most Hyperion audits is backdated support on the claimed shortfall, which compounds across the years since deployment. That is why reducing the claimed user count and the option scope matters more than negotiating the discount.

Should we disable unused Hyperion modules before responding to the audit?

Yes, if they are genuinely unused, and you should document the change with dated records. Modules such as Tax Governance, Data Relationship Steward, and individual FDMEE adapters are separately priced Application User SKUs that are often enabled but lightly used. Decommissioning before you respond removes them from the forward-looking scope, though it does not erase historic usage, so pair it with evidence of what was and was not actually run.