What is in an Oracle audit findings report?
The Oracle audit findings report is the formal output of the measurement phase, and it has a consistent structure. For each program in scope it states the deployment Oracle measured, expressed in the contractual metric, the entitlement Oracle credited you with, and the resulting position, surplus or shortfall. Shortfalls are then priced, typically at list, with back support frequently added for the period Oracle argues the licences should have been held. The total is presented as the cost of compliance.
What the report does not show is its own workings in full. The deployment figures rest on the script output and on interpretive choices Oracle made: which cores to count, how to treat each feature usage flag, which accounts qualify as Named User Plus, how to handle virtualization. Those choices are where the report can be challenged, but they are rarely spelled out, which is why a customer must reconstruct them rather than accept the totals. The broader context for this sits in the audit defence pillar.
The report's tone of finality is itself a negotiating device. Presented as a settled calculation, it invites the customer to argue about price rather than about the calculation. The customer who treats it instead as a draft to be audited in turn keeps the more valuable argument, the one about whether the numbers are right at all, firmly open.
Where audit reports routinely overstate exposure
Audit findings reports overstate exposure in predictable ways, and knowing the patterns lets you target the review. Core counting is the most common: the report may count all physical cores on a host when the database is constrained to fewer, may apply the wrong core factor, or may count cores in environments that should not be in scope. Each overcounted core is priced at full list, so core errors are both frequent and expensive.
| Overstatement | How it appears in the report | The challenge |
|---|---|---|
| Core miscount | All host cores counted at full | Apply correct core factor and actual constrained cores |
| Incidental option flag | Option licensable on all processors | Establish the usage was incidental or ceased |
| Migrated licences ignored | Entitlement understated | Produce migration records to restore entitlement |
| Service accounts as NUP | User count inflated | Separate human users from batch and service accounts |
| Back support added | Penalty inflated by historical support | Contest the period and the contractual basis |
Entitlement understatement is the mirror image and just as common. Oracle credits the entitlement it can readily see, and licences acquired through migrations, acquisitions, or older agreements are easily missed, depressing your credited position and inflating the shortfall. This is exactly the gap an effective licensing position closes, because your own reconciliation already holds the entitlement Oracle overlooked.
Reconciling and challenging line by line
Challenging the report is a reconciliation exercise, not an argument. You take each line and compare Oracle's figure against your own data: your core counts, your entitlement records, your interpretation of each option flag and user account. Where they agree, you accept. Where they differ, you identify the specific cause and assemble the evidence, a configuration record showing constrained cores, a migration document restoring entitlement, an account list distinguishing service accounts from named users.
A findings report is a hypothesis priced at list. Reconcile it line by line and the defensible number is almost always lower, often dramatically.
This is where holding your own data before the report arrives transforms the position. A customer with a current effective licensing position can complete the reconciliation in days and respond with a corrected position rather than a plea. The corrected, defensible number then becomes the real starting point for any negotiation, and an independent firm running the audit defence service will produce that line by line challenge as a matter of course.
How should you respond when the report arrives?
The first response to a findings report is to slow down. The report is engineered to create urgency, but nothing is owed until a position is agreed, and a considered, evidenced response serves the customer far better than a fast one. Acknowledge receipt, state that you will review and respond substantively, and avoid any language that concedes the figures while you reconcile them.
The substantive response then sets out, line by line, where you agree and where you do not, with evidence attached to each disputed item. This converts the conversation from Oracle's monologue into a documented exchange in which Oracle must defend its choices. The full sequence from report to settled position is mapped in the audit defence white paper, and the report itself should always be read against the scripts that produced it, as set out in the audit scripts guide.
Building a line by line written response
A strong response to a findings report is a structured document that mirrors the report's own format, line by line, so that Oracle cannot dismiss it as a general objection. For each program, the response states Oracle's figure, the customer's figure, the difference, and the specific evidence for the customer's position. This format forces both sides onto the same terms and makes each disagreement concrete rather than rhetorical.
The evidence attached to each line is what gives the response force. A core counting dispute is supported by a configuration record showing the constrained core count and the correct core factor. An entitlement dispute is supported by the ordering or migration document Oracle overlooked. A user metric dispute is supported by an account classification distinguishing humans from service accounts, the same analysis covered in the Named User Plus audit guide. Each piece of evidence converts an assertion into a fact Oracle must rebut.
Tone matters as much as substance. The response is cooperative and factual, accepting the lines where Oracle is right and contesting only what the evidence supports, which builds credibility for the contested points. A response that disputes everything indiscriminately is easy to dismiss; one that concedes the clear points and documents the rest is hard to ignore. This is the same disciplined posture that runs through the audit defence method.
The written response also becomes the record for any subsequent negotiation, because it establishes the defensible figure from which commercial discussion proceeds. A customer that has documented its corrected position in writing negotiates from a number it can defend, not from Oracle's headline, which is why the response document is worth the effort it takes to build.
The buyer side view
The findings report looks like the end of the audit, but for a prepared customer it is the start of the real conversation. Customers who settle small read the report as a draft, reconciled every line against their own data, and responded with a corrected position backed by evidence. Customers who settle large accepted the report as a verdict and moved straight to negotiating a discount on a number that was overstated to begin with.
Treat the report as a hypothesis to be tested, not a bill to be paid, and reconcile before you respond. Hold your own numbers with the effective licensing position, carry the corrected figure into the negotiation, and anchor the whole approach in the audit defence pillar.
Oracle audit findings report: frequently asked questions
Is an Oracle audit findings report final?
No. The findings report is a draft conclusion priced at list, not a final bill or a legal judgement. It rests on interpretive choices Oracle made about cores, options, and accounts, and those choices can be reconciled against your own data and challenged before any position is agreed.
How long do you have to respond to an audit findings report?
Oracle usually proposes a response window, but nothing is owed until a position is agreed, so the priority is a considered, evidenced response rather than a fast one. Acknowledge receipt, decline to concede the figures while you reconcile, and respond substantively line by line once your review is complete.
What is the most common error in an Oracle audit report?
Core counting and overlooked entitlement. Reports frequently count all host cores at full when a database is constrained to fewer, apply the wrong core factor, and credit only the entitlement Oracle can readily see, missing licences acquired through migrations or acquisitions. Both inflate the priced shortfall.