Oracle's communications audit concentrates 70 to 80 percent of findings in two places: database options inherited across every processor under BRM, and a Subscriber count that includes lines your CRM never bills
Oracle's GLAS team runs three scripts and then goes past DBA_FEATURE_USAGE_STATISTICS into the object catalog, where a single partitioned rated-event table on a 16-processor BRM database creates a full 16-processor Partitioning claim at $47,500 list each. The second concentration is the Subscriber definition, which counts working telephone numbers, activated handsets, cable drops and connected utility meters, not billable customers. Decide now which denominator you will defend, because the script output arrives before the argument does.
Prepared by Redress Compliance · August 21, 2026 · Oracle advisory. Communications audit defense engagements 2024 to 2026.
Executive summary
The single largest line item in a communications audit is almost never an application module, it is a database option inherited across every processor beneath it: an option touched once on a 16-processor BRM database is claimed for all 16 processors at $47,500 per Processor list.
Or $760,000 before support.
Partitioning on a rated-event schema, Advanced Compression on archived CDR tables and Diagnostics Pack from a single AWR snapshot are the three recurring triggers, and each one attaches 22 percent annual support at $10,450 per processor on top.
Oracle's contractual Subscriber definition is device and line based, so a carrier with 8 million billable customers can be audited against 11 to 13 million countable Subscribers once IoT SIMs, M2M lines, spare MSISDNs, suspended-but-active numbers and connected utility meters are added.
The definition aggregates working telephone numbers, activated handsets and paging devices, residential cable drops and live connected meters, which means the CRM customer count you report internally is the wrong denominator to hand an auditor.
The CDR path crosses at least three separately licensed products before a bill is produced, and orchestration pulls in two more, so a single revenue flow generates five concurrent audit scope boundaries.
Offline Mediation Controller normalizes the CDR, ECE rates it, BRM writes the balance, OSM coordinates fulfilment with UIM and ASAP, and the WebLogic and SOA Suite layers underneath list at $45,000 and $57,500 per Processor respectively.
Oracle publishes no list price for the BRM stack, so there is no public anchor for the application layer, but the technology layer is fully published and that asymmetry decides where you fight.
Push the argument onto the priced technology lines where net bands are observable at $33,000 to $40,000 per Processor for Enterprise Edition, and refuse to negotiate the unpriced application layer against a number Oracle invented for the audit letter.
The three scripts, the views they read, and what each one can and cannot prove
Oracle's collection package arrives as three artifacts, and each one proves a different thing with a different degree of authority. lms_cpuq.sh is a shell-level utility that reads processor model, physical core count and thread configuration off the operating system.
It is not a licensing calculation, it is raw hardware inventory, and it says nothing about the core factor table, hard partitioning, or whether the host is even in your licensed scope.
The Database Options and Packs script queries DBA_FEATURE_USAGE_STATISTICS and its related views to enumerate every licensable option and management pack that has ever recorded usage. The user script enumerates every database account and maps that population against Named User Plus.
Two points matter before you run anything. First, the options script Oracle sends is functionally the same query set as ReviewLite.sql and options_packs_usage_statistics.sql, which Oracle publishes for customer self-service under MOS Doc ID 1317265.1.
You can run that yourself, on your own timeline, before the audit clock starts. Second, and this is the point most carriers miss, the feature usage view records first and last usage timestamps and a detected-usage flag. It records that something ran.
It does not record whether it ran deliberately, whether it ran once during a vendor-led upgrade, or whether the schema in question belongs to a restricted-use database bundled beneath a Communications application.
| Script | Artifact produced | BSS/OSS products it touches | Defensible counter-position |
|---|---|---|---|
| lms_cpuq.sh | Processor model, physical cores, thread config per host | BRM database tier, ECE grid nodes, OSM/UIM WebLogic hosts | Raw core count is not licensable count. Apply the Oracle Core Factor Table, exclude approved hard-partitioned or non-production hosts, and require Oracle to show which contract line covers each host before it enters the calculation. |
| Options and Packs (ReviewLite.sql / options_packs_usage_statistics.sql, MOS 1317265.1) | Feature-level usage history from DBA_FEATURE_USAGE_STATISTICS | BRM rated-event and CDR schemas, ECE persistence, PDC design-time repositories | Detected usage is not licensable usage. Separate one-off usage during Oracle-led upgrades, installer defaults, and restricted-use ASFU schemas from genuine production consumption. |
| User enumeration script | All database accounts, mapped to Named User Plus | Billing Care, PDC, Business Operations Center, service accounts | Application service accounts and multiplexed connections are not the NUP population. At $950 NUP against $47,500 Processor list, the crossover is 50 real users per processor, and the 25-NUP-per-processor floor sets the smallest defensible position at $23,750. |
The table hides the sequencing problem. Oracle almost never disputes lms_cpuq.sh output, because hardware inventory is objective and rarely contested. The battleground is the options script, and Oracle's advantage there is that the output lands in the audit file before your explanation does.
Once a finding sits in a spreadsheet with a first-usage date and a processor count, you are arguing to reduce a number that already exists rather than arguing about whether it should exist.
Run MOS Doc ID 1317265.1 yourself, quarterly, and keep the output. A carrier that can show two years of self-collected feature usage, with annotations explaining each detected flag, is negotiating from an evidence position.
A carrier seeing the output for the first time in Oracle's deck is negotiating from a deficit.
Past the feature view: the object catalog queries auditors run on BRM and ECE schemas
Treating DBA_FEATURE_USAGE_STATISTICS as the whole exercise is the most common and most expensive misread in a communications audit. The feature view is the entry point.
The LMS scripts go on to query the object catalog directly, notably DBA_PART_TABLES and DBA_PART_INDEXES, which enumerate every partitioned object in every schema regardless of whether the feature view flagged Partitioning as used. This distinction decides the settlement.
The feature view can be argued about, because a detected flag has context. A row in DBA_PART_TABLES is a static structural fact: the object is partitioned, today, in production. There is no usage narrative to construct around it.
This is precisely where BRM concentrates risk. Rated-event tables and CDR archive schemas in BRM are partitioned by design, because that is how you keep bill runs and event purges viable at telecom volume.
Oracle's own reference architecture assumes it, and the implementation partner who built your stack did it deliberately. But options inherit the full processor count of the database beneath them.
An option present on a 16-processor BRM database must be licensed for all 16 processors whether or not the partitioned objects touch every core. At $47,500 list per processor, one partitioned rated-event table produces a $760,000 list claim plus $167,200 a year in support at 22 percent.
A design decision made in an implementation workshop becomes a seven-figure line item.
Two adjacent triggers behave the same way. Advanced Compression is routinely applied to archived event tables, because compressing dormant CDR history is obvious housekeeping.
And it is separately licensable at full processor count. Diagnostics Pack and Tuning Pack require nothing more than a single AWR snapshot or one ADDM run, and any performance investigation during a bill-run incident, including one conducted by Oracle Support, leaves that trace permanently.
Inventory every partitioned object, every compressed segment and every AWR retention setting across the BRM and ECE estate now, and understand the boundary between your restricted-use application entitlements and full-use database rights before Oracle draws it for you.
Reading the Oracle Audit: What the LMS Scripts Collect
Oracle GLAS and LMS measure a database by reading its own feature-usage views. What the scripts collect, how to read true positive from false positive, and how to meet a measuremen
Get the white paper →The Subscriber count Oracle will build, and the one your CRM reports
The word Subscriber in your ordering document is not a commercial concept, it is a device inventory.
Oracle's Applications Global Price List defines it in four limbs: a working telephone number for all wireline devices, a portable handset or paging device activated for wireless communications and paging, a residential drop or a nonresidential device serviced by a cable provider.
And a live connected utility meter.
The definition then closes with the sentence that does the damage: the total equals the aggregate of all types. There is no netting, no exclusion for zero-revenue lines, and no reference anywhere to an account, a customer, or an invoice.
In twenty-five years of counting these estates, the gap between the number a carrier's CRM reports as billable customers and the number the four limbs produce runs 25 to 40 percent on a converged operator, and higher where an IoT or smart-metering business has been bolted on.
The inflation comes from predictable places: M2M and IoT SIMs sitting on a flat wholesale rate, spare MSISDN pools that were activated in the HLR/HSS for testing and never deactivated, suspended-but-active lines still holding a working telephone number, secondary SIMs on shared plans.
And meter endpoints that are live and connected but billed to a utility rather than to a person.
Our full treatment of the metric mechanics sits in how the BRM Subscriber metric really counts, but the operational point is narrower: whoever produces the first number sets the anchor, and the auditor's extract will not arrive with your caveats attached.
| What the auditor will request | Where it comes from | What you exclude, and on what ground |
|---|---|---|
| Active account and service instance counts | BRM ACCOUNT_T, SERVICE_T, SERVICE_TELCO_GSM_T | Closed and cancelled service states: no working telephone number, no activated handset |
| MSISDN and IMSI inventory extract | Number inventory / HLR-HSS provisioning export | Unassigned pool ranges, quarantine and aging numbers: not activated for wireless communications |
| Device and SIM activation register | Provisioning or SIM lifecycle system | Test, staff and lab SIMs, spare secondary SIMs never activated |
| Cable subscriber records | Drop and CPE inventory | Nonresidential devices already counted once under a drop: aggregate rule counts the type, not both |
| Metering endpoints | Head-end or MDM export | Meters not live and not connected (installed, unpaired, disconnected) |
| Suspended and dunning-state lines | BRM account status history | Contested: cite the specific limb wording, do not concede the whole category |
Practical instruction: do not send raw SQL output. Build the count yourself, limb by limb, with the exclusion logic documented against the contract text, and hand Oracle a reconciled figure with a written basis.
A defensible number you produced beats a defensible argument against a number Oracle produced, because the second conversation starts from their spreadsheet.
Why the priced technology layer, not the unpriced application layer, decides the settlement
Oracle does not publish a list price for Billing and Revenue Management. That is confirmed on the vendor side, licensing is sized to enterprise and CSP requirements, and there is no public document a buyer can hold up in a meeting.
Now put that next to the technology stack sitting underneath the same estate, where the Technology Global Price List states Database Enterprise Edition at $47,500 per Processor, WebLogic Suite at $45,000, and SOA Suite at $57,500. One layer is a published number.
The other layer is whatever the audit letter says it is. That asymmetry is not an accident of Oracle's pricing history, it is the structural leverage in every communications settlement I have worked on, and it dictates which layer you should be arguing about.
Consider what each side of that line does to a negotiation. On the technology lines, both parties can check the same document.
A dispute about 40 Partitioning processors is a dispute about a countable quantity multiplied by a public rate.
And the discount conversation then runs against observable comparables: net pricing across 2026 deals in the $50,000 to $500,000 tier lands at roughly $33,000 to $40,000 per Processor for Enterprise Edition.
You can argue quantity, you can argue discount, and every step is testable. On the application lines, there is nothing to test.
The auditor's valuation of an additional 3 million Subscribers rests on your own prior ordering documents, which were themselves negotiated under different conditions, at a different scale, possibly by people who have left. You are quoting yourself back at yourself and calling it a benchmark.
This is precisely why Oracle's teams prefer to run the settlement through the application layer. An unpriced line can absorb an arbitrary valuation without ever looking unreasonable, because there is no reasonable to compare it against.
A Subscriber shortfall stated as a single dollar figure is not a price, it is an assertion, and assertions that cannot be falsified tend to survive contact with procurement committees.
The audit narrative reinforces it: the application overage is presented as the primary compliance failure and the technology exposure as a technical footnote, which is the inverse of the pricing transparency.
So invert the sequence deliberately. Concede structurally where the exposure is measurable.
If Partitioning, Advanced Compression, Diagnostics and Tuning Pack are genuinely lit across the BRM processors, do not spend six months on a metadata argument you will lose, buy the position at a real discount and take a certified, documented baseline in exchange.
That concession has a defined ceiling, it is checkable, and it converts an open finding into a closed number. Then refuse to price the application layer against anything but the terms of the existing agreement.
If Oracle wants a new Subscriber tier, it is asking for a new commercial transaction, and a new transaction is negotiated on forward value, not on an audit finding.
The same discipline that works on challenging audit findings generally applies with sharper edges here: separate the compliance claim from the commercial ask, and never let them be settled in one number.
The reason this ordering matters more in telecom than in most estates is the support tail. Support has held at 55 to 70 percent of total Oracle spend across a term, and the technology line carries 22 percent annually, which is $10,450 per Enterprise Edition Processor at list.
A settlement signed today is not a one-time payment, it is a ten-year annuity with no published cap on the annual uplift. Ten wrongly conceded Processors at net pricing are roughly $350,000 up front and another $770,000 in support over a decade before any increases.
Pricing the wrong layer, or pricing the right layer badly, compounds for the entire life of the contract.
Whichever way the settlement lands, insist that the paper reflects the structure: quantities, metrics and definitions written down for the technology lines, and a separate instrument, priced on future value, for anything the application layer needs.
Do not let a compliance credit and a new licence purchase collapse into a single unallocated figure. That figure is unauditable in three years, which is exactly when the next cycle starts.
The mediation bus problem: 25 Kafka topics equal one Processor
The Oracle Technology Global Price List (USA, dated 3 August 2026) carries a conversion rule for GoldenGate for Distributed Applications and Analytics that almost no telecom licensing team has read: only processors running the source databases from which you capture data are counted.
And for any messaging system from which you capture data, every 25 queues or topics count as one Processor.
Read that against a modern mediation bus. A carrier that has decomposed CDR ingest, enrichment, deduplication, error queues, and per-partner rating feeds into topics will run a few hundred of them without anyone deciding to. Three hundred topics is twelve Processors. Six hundred is twenty-four.
At WebLogic Suite and Database EE list ranges, a double-digit Processor claim built entirely out of Kafka topic names is a seven-figure conversation, and there is not one server in the arithmetic.
The reason this lands so hard is structural: your CMDB counts hosts, your VMware inventory counts vCPUs, your CCB counts change tickets, and none of them count topics. Topic creation is a developer action inside a namespace, not a procurement action.
Every infrastructure inventory the licensing team maintains is blind to the unit of measure Oracle will use.
If any part of your Oracle Communications BSS/OSS estate uses GoldenGate to capture change data into or out of the messaging layer, the topic count is a licensable quantity and it grows every sprint.
The defensible position is narrow but real: the rule counts topics from which you capture data, not topics that exist. A three-hundred-topic bus where GoldenGate subscribes to eleven is an eleven-topic claim, not a twelve-Processor one. Oracle will not draw that line for you.
Produce the connector configuration, the subscription list, and a dated export showing which topics are actually in a capture path, and hold that evidence separately from any general Kafka inventory you hand over.
In our experience, the topic count on a live mediation bus moves 15 to 40 percent per year without any licensing review.
Freeze a baseline now, put topic creation behind a naming convention that flags capture-eligible topics, and you convert an uncontrolled metric into a governed one before the script arrives.
Evidence base: where the findings actually land across communications audits
Options inheritance across every processor under BRM and the Subscriber denominator together account for the large majority of claimed value in communications audits we have defended.
The 25 NUP per Processor minimum at $950 each sets the smallest Processor-equivalent position, which is what a single unlicensed PDC design-time or UAT database costs before anyone argues usage.
| Rank | Finding | Mechanism | Typical exposure driver |
|---|---|---|---|
| 1 | Database option inheritance | An option touched anywhere on a 16-processor BRM database licenses all 16 processors at $47,500 list each | Partitioning on rated-event tables, Diagnostics Pack on any monitored instance |
| 2 | Subscriber denominator | Oracle counts working telephone numbers, activated handsets, cable drops, live utility meters, not billable customers | IoT and M2M SIMs, spare MSISDNs, suspended-but-active lines |
| 3 | Restricted-use boundary breach | The bundled database is licensed only for the application schema it ships with | Reporting joins, data warehouse extracts, third-party writes into the BRM schema |
| 4 | Middleware under the application layer | WebLogic Suite at $45,000 and SOA Suite at $57,500 per Processor beneath PDC, Billing Care, Business Operations Center | Full-use WebLogic features enabled on restricted-use images |
| 5 | Non-production and UAT | Test, DR, and design-time nodes carry the same metrics as production | NUP floor of $23,750 per node, SE2 two-socket cap cannot carry the option stack |
Three patterns recur often enough to plan around. First, the option finding is almost never a licensing decision; it is a DBA convenience or an installer default, which means the mitigation is technical remediation plus a documented cessation date, not a purchase.
Second, the Subscriber dispute is winnable only if you fixed the denominator before the script ran, because Oracle's contractual definition is unambiguous and the argument has to be about what your ordering document actually says, not about fairness.
Read how the Subscriber metric really counts before you concede a number. Third, on remedy: Oracle publishes no discount schedule and no cap on annual support uplift, and Support Rewards at 25 or 33 cents per OCI dollar is the only published mechanism that reduces a technology support bill.
Every other reduction you get is negotiated, undocumented, and therefore only as good as the pressure you bring.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Run the options script yourself before any letter arrives, pulling options_packs_usage_statistics.sql per Doc ID 1317265.1 against every BRM, ECE, PDC and OSM database so you see the Partitioning, Advanced Compression and Diagnostics Pack flags in your own timeframe rather than Oracle's.
- Build your own Subscriber count against the four contractual limbs, separately tallying working telephone numbers, activated handsets and pagers, cable drops, and live connected utility meters, then documenting in writing why suspended, spare and test MSISDNs sit outside each limb, using the Subscriber metric breakdown as the reference definition.
- Map every partitioned object on BRM and ECE schemas with a named business justification, because an option on a 16-processor database is claimed at all 16 processors, and a single rated-event partition you cannot explain costs $760,000 at $47,500 list.
- Price your own technology exposure before Oracle proposes a number, anchoring against $47,500 per Processor for Database EE, $45,000 for WebLogic Suite, $57,500 for SOA Suite, and 22 percent support at $10,450 per EE processor per year, so the first figure in the room is yours.
- Quote Oracle's own script header back at the auditor, which states usage statistics are informational only and do not represent any license entitlement or requirement, then insist every finding be traced to an ordering document clause rather than a view, as covered in challenging Oracle audit findings.
The sequence matters more than any single move. Steps one through three are internal and privileged; run them before the audit letter creates a disclosure obligation.
In 25 years of these negotiations, the carriers that settle at 20 to 30 percent of the opening claim are the ones that walked in with their own script output, their own Subscriber denominator, and a per-partition justification memo already written.
Oracle's script data is not a license position, it is a telemetry dump. The gap between "feature used" and "feature licensed" is the entire negotiation, and it closes in whoever's favor arrives with documentation first.
Frequently asked questions
Which scripts does Oracle run in a communications audit?
Three artifacts dominate: lms_cpuq.sh at the shell level to capture processor model, core count and thread configuration, the Database Options and Packs script that reads DBA_FEATURE_USAGE_STATISTICS and related views.
And the user script that enumerates database accounts against Named User Plus metrics.
The collection tool is now branded under GLAS, Oracle's Global Licensing and Advisory Services. The options script output (ReviewLite.sql) is substantially the same as the publicly available options_packs_usage_statistics.sql, so you can generate it yourself first.
Does a row in DBA_FEATURE_USAGE_STATISTICS mean I owe a license?
No. Oracle's own script header, distributed under My Oracle Support Doc ID 1317265.1, states that the usage statistics are for informational purposes only and do not represent any license entitlement or requirement.
That sentence is the single strongest defense line you have, because it means each row is a question about how a feature was invoked, not an invoice. Many rows come from installation defaults, one-off diagnostic runs or Oracle-delivered scripts.
How does Oracle define Subscriber for Communications products?
The Applications Global Price List defines Subscriber as the aggregate of: a working telephone number for wireline devices, a portable handset or paging device activated for wireless or paging, a residential drop or nonresidential device serviced by a cable provider.
And a live connected utility meter.
It is device and line based, not customer based. That means IoT SIMs, M2M lines, suspended-but-active numbers and meter endpoints all count, and your CRM billable-customer figure is systematically lower than the auditable number.
Why does one database option touch create a claim across all processors?
Database options are licensed against the full processor count of the database they run on, not the subset of cores that used the feature. An option installed on a 16-processor database must be licensed for all 16 processors.
At $47,500 per Processor list for Enterprise Edition-class pricing, a single Partitioning trigger on a BRM rated-event schema becomes a seven-figure line before the 22 percent annual support at $10,450 per processor is added.
What does Oracle's BRM stack list at?
Oracle does not publish list pricing for Billing and Revenue Management. Licensing and deployment are sized to enterprise and CSP requirements, which means there is no public anchor to negotiate against on the application layer.
Your only comparables are your own prior ordering documents and peer benchmarks. This is why buyers should push the quantified argument onto the published technology lines where Enterprise Edition, WebLogic Suite at $45,000 and SOA Suite at $57,500 per Processor are checkable.
Can Kafka topics generate an Oracle license claim?
Yes, under the GoldenGate for Distributed Applications and Analytics terms. Only processors running the source databases from which you capture data are counted, but for messaging systems from which you capture data, every 25 queues or topics counts as one Processor.
A carrier running a few hundred topics on the mediation bus can produce a double-digit processor claim with no physical server in the calculation, which is why topic sprawl never appears in a standard infrastructure inventory.
Is Standard Edition 2 a viable way to reduce BSS/OSS exposure?
Only in narrow cases. SE2 is licensed per socket and capped at two sockets per server, and it cannot run most option packs, which rules it out for any BRM or ECE tier that depends on Partitioning or Advanced Compression. It can be defensible for peripheral reporting or small ancillary databases.
For design-time and test nodes, the alternative worth pricing is Named User Plus, where the 25-NUP-per-Processor minimum sets a floor of $23,750, roughly half of Processor list.
