Proving a Legitimate Oracle License Transfer at Audit: The Evidence You Need

Oracle's master agreements prohibit transfer by default, which means every legitimate move you have made exists only as a documented exception. This page sets out exactly which documents Oracle's auditors accept, where buyers lose the file, and how to rebuild an evidence pack before a preliminary report hardens into a claim.

Transfer Is Prohibited by Default, So the Paper Is the Entitlement

Start from the clause, not from what your integration team assumed. Oracle's Master Agreement General Terms Section 15 says you may not assign the Master Agreement or give or transfer the Programs, Operating System, Integrated Software and/or any Service Offerings, or an interest in them, to another individual or entity. Schedule P Section 3.3 re-applies that same bar to every Program licensed under it, with a single carve-out: except to the extent the prohibition is rendered unenforceable under applicable law. That escape hatch is an EU exhaustion argument, not a US one, and no auditor will volunteer it. If your estate predates the OMA, the legacy OLSA v053012 carries near-identical wording, so a 2007 acquisition does not inherit whatever transfer language your 2019 negotiation won. The practical consequence is the part buyers keep missing. Because prohibition is the default position, the auditor is not obliged to prove that a breach occurred. They observe Oracle software running under a legal entity name that does not match the contracting party on the ordering document, and that observation alone is a finding. You then carry the burden of producing the exception: the specific instrument, executed by Oracle, that moved those licenses to the entity now using them. No instrument, no exception. The absence of paper is treated as the absence of the right, and it is treated that way inside the 30-day payment clock the audit clause imposes. Read our broader guide to what you can actually move, sell, or reassign before you assume a past move was covered.

The auditor does not have to prove a breach occurred; you have to prove Oracle consented, in writing, at the time.

The Four Documents Oracle Actually Accepts as Proof

Oracle's audit teams work from a recognizable stack, and they accept four artefacts as evidence that a transfer was legitimate. First, the Oracle License Assignment Document, the named instrument that moves licenses between legal entities. Second, Oracle's written consent letter, effective at closing, naming the new or combined entity by exact legal name and confirming continued use across it. Third, the Ordering Document that references the correct governing agreement, because an order citing an OLSA while your consent letter cites an OMA is an argument you will lose the day it is noticed. Fourth, the Software Update License and Support renewal showing the transferred CSI is actively supported and invoiced to the receiving entity. That last one does more work than buyers expect: in 25 years of these disputes, a clean unbroken SULS renewal history in the acquiring entity's name has repeatedly been the difference between a conversation and a claim, because it evidences that Oracle itself recognised the new party. Name the instrument correctly. An assignment transfers rights under the existing contract, leaving the original obligations partly intact. A novation substitutes a new party entirely, extinguishing the old contract. Filing a novation and calling it an assignment invites Oracle to argue that the original licensee still exists and the receiving entity holds nothing. Where the move was between affiliates rather than across a sale, check what your contract already permits under our affiliate and subsidiary sharing analysis before commissioning new paper.

Store all four together, per transaction, indexed by CSI and legal entity name. Split files across the deal team, the SAM tool, and an ex-employee's mailbox and you have no evidence pack, only fragments you will be reassembling under a 45-day notice.

Entity Naming, Change of Control, and the Traps Inside the Consent Letter

A consent letter in your file is not the end of the argument. It is the beginning of one, and in my experience most letters fail on their own terms rather than on Oracle's. The reason is structural: every Oracle agreement defines the authorized customer as one named corporation plus its majority-owned subsidiaries, so when Company A acquires Company B, B's licenses stay legally usable only by B as originally defined until Oracle formally adds the entity to the contract. A parent's OMA does not stretch to cover a newly acquired subsidiary by gravity. So read the consent letter as a scope document, not a permission slip: does it name the surviving legal entity exactly as registered, does it name the entity that will actually run the software (often a different shared-services subsidiary), and does it enumerate the CSI numbers being carried across? Then read it against the deployment inventory. Four traps recur. First, the competitor exclusion, which lets Oracle refuse or void consent where the receiving entity competes with Oracle, an increasingly wide net as Oracle acquires into vertical applications and cloud. Second, the no-expansion-of-scope condition: the transferee inherits the original quantities, metrics, and territories, so a 200 Processor entitlement does not become an enterprise-wide right because the acquirer is larger. Third, the change of control notification deadline written into the negotiated agreement, commonly 30 days from closing, which deal teams miss because legal closes the transaction and licensing paperwork follows in the next quarter. Fourth, limited-use and application-specific licenses, which breach the moment the receiving entity runs them for a workload outside the named application. Reconcile letter to CSI list to inventory, and see the rules on sharing licenses across affiliates and subsidiaries before you assume the group is one customer.

A parent's master agreement does not stretch to cover a newly acquired subsidiary by gravity.

Hardware, Engineered Systems, and Integrated Software Need Their Own File

Exadata, ZFS, SuperCluster, and the appliance estate fail audits on a completely different clause set, and program consent will not save them. Schedule H of the OMA describes Operating System and Integrated Software or Integrated Software Options rights as "limited, non-exclusive, royalty free, non-transferable and non-assignable," and ties those rights to the specific hardware they shipped on. That wording is stronger than the general Section 15 assignment bar because there is nothing to assign: the right lives with the box, not with you. Worse, hardware warranty and entitlement terms can be void where title to the hardware passes to a third party, which means a divestiture that moves racks to the buyer can strip support coverage from equipment that is otherwise functioning perfectly. So build a second file, parallel to the program assignment, and keep it as long as the asset lives:

• Hardware title transfer evidence: bill of sale, asset schedule from the purchase agreement, and the date title actually passed, not the closing date of the corporate transaction.
• Serial numbers and rack identifiers for every chassis, storage cell, and switch, mapped to the Integrated Software Options actually enabled (partitioning, storage indexes, hybrid columnar compression, and similar).
• Support contract reassignment paper from Oracle, referencing the hardware serials and the receiving entity, separate from any program CSI reassignment.
• The original ordering document for the engineered system, showing which Integrated Software Options were purchased versus merely installed and available.

Auditors probe the appliance estate precisely because the paper is usually thinner there, and because installed-but-unlicensed options are trivially discoverable in the collected configuration data. Pair this file with the broader restrictions in our Oracle license transfer and assignment guide before you sign any asset schedule.

How the Audit Process Converts a Missing Document Into a Cash Demand

The mechanics are unforgiving because the clock, the burden, and the tooling all sit on Oracle's side of the table. Oracle audits on 45 days' written notice, you must cooperate and provide access to deployment information, and you must pay within 30 days of written notification any fees applicable to use in excess of your license rights. Non-payment permits Oracle to terminate technical support, the licenses, or the agreement itself, and Oracle bears none of your cooperation costs. Read that sequence carefully: nothing in it requires Oracle to prove your transfer was invalid. It requires you to prove, inside a 30-day payment window, that the entity now running the software was contractually entitled to. If the assignment letter is missing, the default contractual position, that transfer is prohibited, fills the gap and the deployment becomes unlicensed use.

The process runs in a predictable order, and each stage is an evidence checkpoint. First comes the notification letter citing the audit clause. Then a questionnaire covering products, environments, hardware, and users, which is where entity names first appear in writing and where a legacy subsidiary name can quietly become a finding. Then Oracle's scripts collect installation and configuration data. Treat that tooling as an interested party's instrument, not a neutral measurement: it reports what is installed, not what you are entitled to, and it has no view of your assignment paper. Your counterweight is independent SAM data from Flexera, Snow, or ServiceNow SAM reconciled against a maintained License Position Document that maps every entitlement to the legal entity holding it and the ordering document that created it. Present that reconciliation at the preliminary report stage, which is often just a workbook asking you to confirm contents and identify errors. That workbook is the last cheap moment to inject a transfer file. After it hardens into findings, you are negotiating a number rather than correcting a record.

One boundary works in your favor: no action arising out of the agreement may be brought more than two years after the cause of action accrued. That does not stop Oracle raising old transfers in a commercial conversation, but it constrains how far back a claim can be litigated, and it is worth stating early when an auditor reaches for a 2011 divestiture. Establish the entity chain in your first written response to the audit notice, not in month four.

What an Unproven Transfer Actually Costs

The number is not theoretical. In one documented acquisition, the buyer discovered post-close that the target's licenses could not be transferred, needed 20 additional processors of Database and Middleware, and was refused a move by Oracle. The acquirer bought 20 new processor licenses at roughly $950,000 in license fees plus approximately $209,000 annually in support. That support line is the part buyers underweight: it is a permanent addition to the run rate, indexed upward at renewal, and it compounds across every year the estate stays on Oracle. Priced over five years, that single missing consent letter cost north of $1.9 million.

The second failure mode is quieter and more common in my experience: two merged entities simply start sharing licenses because everyone assumes the movement is internal. Oracle treats it as a transfer, because neither the combined entity nor the acquired subsidiary was named in the original contract. Parent licenses do not cover a newly acquired subsidiary until Oracle formally adds that entity, a point covered in detail in our guide to sharing Oracle licenses across affiliates and subsidiaries. Nobody signed anything, nobody moved a server, and the finding still lands.

A missing consent letter is not an administrative gap, it is a permanent addition to your annual support run rate.

Read the table as a decision rule. Leverage collapses the moment findings are formalized, so every hour spent reconstructing the file before the preliminary report is worth multiples of the same hour spent after. Where evidence is genuinely gone, the fallback is to trade the cleanup paper into a broader negotiation rather than pay list for a document you once had.

Reconstructing the File When the Documents Are Gone

The normal post-M&A case is not a clean contract set; it is three OMAs, a legacy OLSA nobody can date, ordering documents referencing agreements that were never scanned, and a CSI list inherited from a target whose IT team left eighteen months ago. Oracle will tell you that you can request copies of your contracts from Oracle, and Rimini Street's audit guidance confirms that route exists. Use it last, not first. Asking Oracle to reconstruct your entitlement record hands the vendor editorial control over the document set you will later argue from, and Oracle's copy will contain what Oracle's LMS repository holds, not what your closing set proves. Exhaust internal sources first: purchase orders and purchase confirmation emails, accounts payable records showing who paid whom for which line item, CSI histories and support renewal invoices (the Software Update License and Support renewal is the layer that shows which licenses were actively supported and under whose name), and the schedules and disclosure letters sitting in the transaction data room from the deal itself. In our experience the data room is the single most productive source and the one nobody checks, because the schedule of assigned contracts frequently names Oracle agreements that the IT function never received copies of.

Once recovered, fix the storage problem that caused the loss. Ardura's guidance is blunt and correct: Oracle agreements, purchase confirmations and old contracts from mergers belong in one repository, backed up, under a written retention policy. Layer on a License Position Document that states entitlements owned, how they are deployed, and how the calculation reconciles between the two, refreshed at every infrastructure change rather than every audit notice. That document is what turns a folder of PDFs into a defensible position, and it is the artefact that lets you answer a structured internal Oracle license review in days instead of months.

What to Do First

Work a sequenced 30-day plan, and treat the sequence as load-bearing. Days 1 to 10: pull every OMA, OLSA, ordering document, amendment, assignment instrument and Oracle consent letter into one repository, then map each CSI to a named legal entity as that entity appears in the signature block, not as it appears in your ERP. Days 11 to 20: identify every legal entity currently running Oracle software that is not named in an agreement or a consent letter. Include entities created by internal reorganizations, not just acquisitions, and check whether the affiliate and subsidiary definition in your specific agreement actually covers them, because majority ownership tests and named-entity tests produce very different answers. Days 21 to 30: decide how each gap gets closed. The pillar guidance on what Oracle permits you to move, sell or reassign sets the boundary of what is negotiable.

Close gaps in a commercial conversation, not an audit response. A renewal, a cloud discussion or a new capacity purchase gives you something to trade for a consent letter or a contract update; an audit response gives you nothing to trade and a 30-day payment clock once fees are notified. If an audit is already open, the calculus changes. The preliminary report or confirmation workbook is the last cheap moment to inject transfer evidence, and Rimini Street is right that most licensees underestimate it. Once findings harden into a formal compliance position, every document you produce is read as a rebuttal rather than a correction, and the price of being believed goes up.

Related advisory: the full topic guide.

Frequently asked questions

Does Oracle ever approve a license transfer between legal entities?

Yes, but only as a negotiated exception to the standing prohibition, and normally in the context of a transaction where Oracle sees commercial value. Approval arrives as a written consent or an Oracle License Assignment Document naming the receiving entity. Expect conditions: no expansion of scope beyond what was originally licensed, and the receiving entity must not be an Oracle competitor.

Is an internal reorganization or merger a transfer in Oracle's view?

Frequently, yes. If the receiving entity was not named in the original agreement, or does not fall inside the contractual definition of the customer and its majority-owned subsidiaries, Oracle treats the move as a transfer requiring consent rather than an internal reallocation. Check the change of control notification deadline in your agreement, because missing it is itself a breach argument.

What single document do auditors ask for most often?

The written consent or assignment instrument naming the receiving legal entity, tied to specific CSI numbers and ordering documents. A generic transaction announcement, board resolution, or an email from a sales representative does not carry the same weight. If the consent letter does not name the entity that is actually running the software today, treat it as unusable.

Can I ask Oracle for copies of contracts I have lost?

You can, and after most acquisitions you will have to. Understand the trade: Oracle then controls the version of the entitlement record you argue from, and it will reflect what Oracle's systems hold, not what you bought. Exhaust internal sources first, purchase orders, AP records, support renewal invoices and data room schedules, then reconcile Oracle's set against yours.

When is it too late to submit transfer evidence in an audit?

The practical deadline is the preliminary report or confirmation workbook stage, when Oracle asks you to verify contents and flag errors. Many licensees underestimate that request and let findings harden. Once a formal claim is issued with a 30-day payment clock attached, you are negotiating a settlement rather than correcting a data set.

Do engineered systems and appliances need separate transfer evidence?

Yes. Operating System and Integrated Software rights are described as non-transferable and non-assignable and are tied to the specific hardware, and hardware entitlement terms can be void where title passes to a third party. Keep hardware title transfer evidence, rack and serial identifiers, and support contract reassignment paper in the same file as the program assignment.