Oracle's Agile PLM audit findings are built from installation footprints and account lists, not from what your contract actually entitles or what your users actually did. This playbook shows you which artifacts to pull, in what order, and how each one converts a line item on Oracle's spreadsheet into a withdrawn or repriced claim.
How to Prepare for Your Oracle SaaS Negotiation
The 90-day renewal proposal with a 9 to 12 percent uplift is the bill for not preparing. The ARR compensation game, the utilization audit that finds 30 to 50 percent shelfware, benchmarks targeting 0 to 3 percent, one costed alternative, and sequencing toward May 31.
Oracle's Agile PLM audit findings are built from installation footprints and account lists, not from what your contract actually entitles or what your users actually did. This playbook shows you which artifacts to pull, in what order, and how each one converts a line item on Oracle's spreadsheet into a withdrawn or repriced claim.
The opening package from Oracle's audit team (LMS, now GLAS) is not a finding. It is a measurement request bundled with a self-declaration spreadsheet, and the spreadsheet is engineered to accept whatever numbers you type into it without ever testing them against your ordering document. The standard request set is predictable: a user list exported from the Agile License Console, module enablement status, the database deployment map (which is a second audit hiding inside the first, see the restricted-use limits on the Oracle Database under Agile PLM), and a roster of integration accounts touching Agile SDK, AIS, ACS, or the ERP connector. None of that arrives with a price attached. Oracle attaches the price later, after you have populated its cells.
The gap you should exploit sits between what GLAS asks for and what your audit clause actually obliges you to hand over. The clause commits you to reasonable cooperation in measuring use of the licensed programs. It does not commit you to producing an Active Directory dump, an HR headcount, or a corporate org chart. In 25 years of these engagements, volunteering raw AD or HR headcount is the single most expensive mistake a customer makes, because Oracle's contractual definitions are authorized-access based (the Global Price List counts individuals authorized to use the programs whether or not they actively use them), so every disabled, duplicated, or service account in that dump becomes a billable line. With a 20-user minimum per Agile module and historic list prices near $3,380 per Application User for Product Collaboration, a careless export inflates the claim by six figures before anyone has read a contract.
The 30 day response window in most Oracle audit letters is an internal service target, not a contractual deadline. Treat it as negotiable and sequence your reply deliberately: a scope letter first (which entities, which programs, which metric, which contract), an entitlement extract second, and no usage data at all until Oracle has agreed the entitlement baseline in writing.
Oracle attaches the price later, after you have populated its cells.
Your strongest single artifact is Oracle's own telemetry, not your assertion about it. Inside the product, Server Settings > Licenses exposes three tabs: General Information, Modules, and History. The General Information tab tabulates User Licenses as the Agile administrator assigned them, split across the three types the product itself recognizes: Named (formerly Power), Concurrent, and Restricted. That distinction is not cosmetic and it is not a customer opinion. Oracle's Administrator Guide states that Named licenses are not applied against concurrency counts, so a Named user can log in at any time, while every user who is neither Named nor Restricted is subject to concurrency counts and can be locked out when the limit is reached. Runtime lockout is enforcement, and enforcement is evidence. If your Concurrent population was capped and occasionally locked out, the system was policing your entitlement for you, and Oracle cannot simultaneously claim the cap was fictional. The cost consequences of each type are set out in our comparison of Named User versus Concurrent metrics in Agile PLM.
The History tab is the artifact most customers never open and the one that most often kills a claim. It timestamps license configuration changes, which means it can prove the date a module was toggled to Yes, the date a user type changed from Restricted to Concurrent, and, just as usefully, that a module Oracle claims was in use was never enabled at all.
Remediating before you preserve destroys the only contemporaneous record of what you were actually running. Preserve first, argue second, remediate last.
This is the single highest-value defense in an Agile PLM audit, and Oracle's own documentation hands it to you. Agile PLM is licensed module by module, and Oracle's auditors will typically score a module as "in use" because the binaries shipped with the installation and the schema objects exist. That is installation, not entitlement consumption. Chapter 35 of the Oracle Agile PLM Administrator Guide describes a two-step gate: for Recipe and Material Workspace, the administrator must set the relevant fields under Licenses > Modules (Recipe Management, Material and Equipment Management) to Yes, and even then, further steps including running pharma.sql against the Agile PLM database are required before any user can access the solution. If step two never ran, no user could have touched the module regardless of what the installer dropped on disk. Oracle wrote that sentence; make Oracle live with it.
Document the absence of the enabling step with four artifacts, in this order: (1) DBA script execution history or change-ticket records showing pharma.sql and its module equivalents were never run; (2) object counts from the module's business object tables returning zero rows; (3) the Licenses node screenshots showing the module flag set to No, with the History tab confirming no prior toggle to Yes and back; and (4) the role and privilege extract showing zero users assigned any role carrying that module's privileges. Any one of these is arguable. All four together make the finding indefensible.
The economics justify the effort. Agile PLM part numbers historically carried a 20 Application User minimum per module (per the archived Oracle price list, deprecated and directional only, with Product Collaboration at $3,380 per user and Product Cost Management at $2,414). Killing one false module claim removes a 20-user floor plus support; reclassifying a dozen individual users usually does not. Sequence your defense accordingly, and see how add-on modules surface in Agile PLM audit findings for the specific ones Oracle tends to over-score.
Oracle's own administrator guide says users cannot access the module until a database script runs, so prove the script never ran.
Agile PLM ships three user license types inside the product: Named (formerly Power), Concurrent, and Restricted. Oracle's Administrator Guide defines Restricted users as people outside your company, such as distributors and suppliers, given limited access. Oracle's Integration Guide goes further and names the mechanism: the out-of-the-box (Restricted) Material Provider role grants privileges to create and modify declarations plus read access on other PG&C objects, and is documented as the role typically assigned to supplier users with restricted access. The PG&C Supplier Guide is blunter still, telling the supplier directly that "you as a supplier are a Restricted user." In practice, audit spreadsheets still price those same accounts at full Named or Application User rates, because the extract Oracle pulls counts accounts, not privilege scope. In our experience that single reclassification is often the second largest line-item reduction after a killed module claim, particularly at manufacturers with large declaration-collection supplier bases.
Build a per-account evidence table and hand Oracle nothing narrative. One row per external account, five columns, sourced from the role and privilege extract rather than a spreadsheet you typed. Then invert the burden: Oracle must identify, per account, a specific granted privilege that exceeds the documented Restricted role. Absent that, the account prices as Restricted.
| Column | Source artifact | What it proves |
|---|---|---|
| Account ID and company | Agile user table, company field | External party, not employee |
| Assigned roles | Roles tab per user | Mapped to (Restricted) Material Provider or equivalent |
| Privilege mask | Privilege extract per role | No create/modify beyond declarations |
| Objects actually touched | Object history and audit trail | Read-only footprint on non-declaration objects |
| Oracle's assigned metric | Audit workbook line | The gap you are disputing |
Two cautions. First, if a supplier account also carries a Change Analyst or Component Engineer role, that account is genuinely above Restricted and should be conceded early to preserve credibility on the rest. Second, the metric on your ordering document governs the price, so check whether Restricted Use pricing exists in your contract before you argue the classification; the interaction between metrics is covered in the Named User versus Concurrent metric comparison. Concede the handful, fight the hundreds.
The clause Oracle's auditors reach for sits in the definitions block of the EBS Applications Global Price List: a non-human operated device is counted as a Named User Plus in addition to all individuals authorized to use the programs if such devices can access the programs, and where multiplexing hardware or software (a TP monitor or web server, for example) is used, the number must be measured at the multiplexing front end. Read literally by an auditor, every Agile service account becomes both a license of its own and a doorway to the entire population sitting behind it. The exposure vectors are predictable: Agile SDK scripts, Agile Integration Services (AIS), Agile Content Service (ACS), ERP connectors into E-Business Suite or SAP, middleware queues, and report schedulers that write extracts on a cron. In our audit-defense work, integration accounts are routinely the single largest inflation factor in a first-draft Agile finding, because each one gets grossed up to the full human population of the connected ERP.
The same sentence carries your counter, and it is in Oracle's own text: automated batching of data from computer to computer is permitted. A scheduled file drop, a JMS queue consumer, or an AIS job that runs at 02:00 against a staged payload has no interactive front end and therefore no multiplexed user population to measure. Build the inventory before you answer anything: every service account, its authentication type, its invocation pattern (interactive, API called on behalf of a named human, or scheduled batch), the calling system, and the human population, if any, standing behind it. Then concede front-end counting only where a human genuinely initiates the transaction in real time, for example a supplier portal screen that proxies through a single Agile account. For anything scheduled or queue-driven, cite the batching language and require Oracle to rebut it. Pair this evidence with your Named User versus Concurrent metric analysis, because a conceded interactive front end is far cheaper counted against concurrency than against named seats.
Usage evidence wins arguments about who should be counted; entitlement sets the ceiling, and the ceiling is what caps the bill. The metric printed on your ordering document governs, and it governs over any adviser blog, any Oracle sales deck, and any auditor spreadsheet header. Watch for the commonly repeated authorized-user formula (200 employees plus 50 suppliers equals 250 licenses regardless of frequency, per Reveal Compliance's November 2024 commentary). That is third-party interpretation, not contract text, and adopting it as your own baseline hands Oracle a 250-seat starting number you were never obliged to concede. Watch harder for Employee User, defined in Oracle's price list as an individual authorized to use the programs installed on one or multiple servers regardless of whether that individual is actively using them. In legacy Agile paperwork that metric quietly converts a 40-person engineering team into a headcount-wide liability, and it is the one line worth a lawyer's hour before you send anything back.
| Metric on ordering document | What it actually counts | Audit exposure behavior |
|---|---|---|
| Application User (Min 20 per module) | Authorized individuals per licensed module | 20-seat floor per module drives module-sprawl claims |
| Named User Plus | Authorized humans plus non-human devices | Integration accounts inflate the count unless batching applies |
| Restricted Use | External parties, limited privileges | Lowest-cost landing zone for supplier reclassification |
| Employee User | Every authorized individual, active or not | Scales with headcount, not usage; highest exposure |
Assemble the map from primary paper only: every ordering document and amendment, migration or transition agreements (Agile-to-Oracle and any subsequent consolidation), the CSI records, and every support renewal quote, which restates quantities and metrics annually and is therefore an admission Oracle authored. Add the license key issuance history from Oracle License Codes Support, since Agile PLM keys are obtained by contacting that team, meaning Oracle holds corroborating evidence of what you were enabled to run and cannot credibly dispute it. Reconcile that stack against the Licenses console before you answer the auditor, and use the Agile PLM metrics and modules reference to confirm each part number maps to the module Oracle is claiming. Any finding above your mapped entitlement is a sales proposal, not a compliance gap.
A valid shortfall is not a valid number. Oracle's audit letter prices findings at current list against the price list, then adds 22 percent support, often backdated. Your ordering document, not the price list, is the commercial reference point, and in 25 years of these negotiations I have never seen an enterprise buy Agile at list. The historic per Application User anchors (deprecated Oracle price list archive, verify against your own ordering document) show how fast a single disputed module compounds: Product Collaboration around $3,380, Product Cost Management around $2,414, Product Governance and Compliance around $1,930, Product Quality Management around $1,447, each carrying a 20 user minimum. That minimum is the real mechanism. If Oracle asserts that three quality engineers touched PQM, the floor is 20 licenses, not three, so a three person finding is priced as roughly $28,940 before support. Push back on two fronts at once: the license count (see the module sprawl audit findings breakdown) and the unit price.
| Disputed module (per App User list anchor) | Oracle claim at 20 user floor | At 50 percent historical discount | At 70 percent historical discount |
|---|---|---|---|
| Product Collaboration ($3,380) | $67,600 | $33,800 | $20,280 |
| Product Cost Management ($2,414) | $48,280 | $24,140 | $14,484 |
| Product Governance and Compliance ($1,930) | $38,600 | $19,300 | $11,580 |
| Product Quality Management ($1,447) | $28,940 | $14,470 | $8,682 |
Enterprise discounts on Agile in our practice fall in the 40 to 70 percent band, so insist the settlement is priced at your own historical realized discount, evidenced from prior ordering documents, not at list less a goodwill gesture. Then add the roadmap argument. Oracle removed 9.3.7 from the roadmap in October 2023, leaving 9.3.6 terminal. You are being asked to buy perpetual licenses, plus 22 percent annual support, for a product with no forward release. Finally, frame against the cloud comparator: Agile PLM Cloud entry packages have been quoted around $13,800 per year (third party aggregator figures, GoEngineer and SelectHub). If a compliant subscription costs five figures annually, a six figure perpetual backfill on a terminal release is not a defensible settlement shape.
You are being asked to buy perpetual licenses, plus 22 percent annual support, for a product with no forward release.
Sequence matters more than content. Do these five things inside 30 days, and do not answer a usage question before step three is finished.
Treat every line on Oracle's spreadsheet as a priced hypothesis that Oracle must be made to prove: which contract, which clause, which account, which date, which discount. Findings that survive that test are usually a fraction of the opening claim.
Oracle's letters typically name a 30 day window, but that date is Oracle's preference, not a contractual deadline in most audit clauses. Acknowledge in writing quickly, then negotiate the timeline against your own readiness to assemble console exports and ordering documents. A four to eight week extension is routinely granted when you show a credible work plan, and it costs far less than submitting unverified numbers on Oracle's schedule.
Not on its own. Oracle's own administrator documentation shows module access requires the administrator to set the module to Yes under Licenses > Modules and, for solutions like Recipe and Material Workspace, to run additional database steps such as pharma.sql before any user can reach it. If the enabling steps were never completed and no user holds the module privileges, you have a documented basis to reject the finding rather than pay a 20 user minimum for a dormant module.
Yes, and Oracle's documentation supports it. The out of the box (Restricted) Material Provider role in Product Governance and Compliance grants only declaration create and modify plus read access on other PG&C objects, and Oracle's PG&C Supplier Guide states plainly that a supplier is a Restricted user. Produce a per account mapping of role to privilege to objects touched, and require Oracle to identify a specific excess privilege before it prices any external account above Restricted.
Sometimes, and the distinction is in the wording. Oracle's terms count a non-human operated device as a named user plus if it can access the programs, and require counting at the multiplexing front end where multiplexing software is used, but the same language permits automated batching of data from computer to computer. Scheduled, non interactive file or queue transfers fall into the batching carve-out, while an API account that brokers live requests from a human population generally does not.
No. Oracle prices audit findings against the price list, not against the discount on your original order, which is why a claim can look several times larger than what the same licenses would cost in a normal purchase. Enterprise customers typically settle 40 to 70 percent below list, so resetting the price basis is a separate negotiation from disputing the quantities. Do both, in that order: kill the invalid quantities first, then reprice what remains.
It helps materially. Oracle removed 9.3.7 from the roadmap in October 2023, making 9.3.6 the terminal release, so any backfill purchase buys perpetual licenses plus roughly 22 percent annual support on a product with no forward feature path. Use that to push the settlement toward a credit against Fusion Cloud PLM subscription, or to justify an exit to third party support if you are not migrating on Oracle's timeline.
The strategic approach for Oracle audit defense across LMS, license verification, and contractual response. Beyond the tactical playbook.
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.
