A software audit letter is designed to make you move fast. It arrives with an official tone, a short timeline, and often a number attached, and the instinct is to reply quickly, agree to the process, and start pulling the data the vendor asked for. That instinct is where most of the money is lost.
The number in the first letter is almost never the number you end up paying. Understanding how a software audit actually works, what set it off, and what happens at each stage is what turns a frightening letter into a manageable process. This guide walks through all of it.
What is a software audit?
A software audit is a vendor’s contractual way of checking that your real-world use of its software does not exceed what you bought. Publishers such as Microsoft, Oracle, IBM, SAP, and Adobe build audit rights into their agreements to protect themselves against software being used beyond what was paid for, whether deliberately or, far more often, by accident.
Not every letter that feels like an audit is a formal one, and the difference matters.
A formal audit is contractually binding and mandatory. It usually arrives as an official letter and invokes the audit clause in your agreement.
A soft audit, also called a license review, self-audit, or SAM engagement, usually comes by email or phone and is technically voluntary. It can feel friendlier, but declining one can prompt the vendor to escalate to a formal audit. One licensing firm that reviews these letters for a living reports that roughly one in three are not formal audits at all, but sales-led reviews wearing audit language.
The practical difference is in how findings get resolved. Under a soft review, a shortfall can often be settled at your normal, discounted license prices. Under a formal audit, the vendor can require you to buy licenses at a markup and can recover the cost of running the audit. Knowing which one you are actually facing changes how you should respond, and it is not always obvious from the letter.
Why did we get audited?
Audits are rarely random. The most common triggers are well understood.
A renewal or the end of a contract term is the classic one, because it is the moment you have to disclose data anyway. A merger, acquisition, or divestiture is another, since ownership changes and inherited estates create exactly the kind of unreconciled sprawl auditors look for. Many organizations see a review roughly every three years. Vendor sales pressure near the fiscal year end drives letters that are really about closing a deal. A sudden drop in your spend with a publisher can prompt one, as can a casual disclosure in a support ticket or a vendor questionnaire.
Reports from former employees are a real trigger too. The Business Software Alliance, for example, offers rewards for information that leads to a settlement, which gives disgruntled ex-staff a direct incentive to report.
Finally, a change in a vendor’s licensing metric can change the economics of future purchases or renewals. Oracle introduced employee-based Java SE Universal Subscription pricing in 2023, which can tie a new commercial subscription to a much larger population than the installations using Java. That change does not by itself invalidate existing license rights: qualifying legacy subscriptions, perpetual licenses, and permitted free use have their own terms. Check the rights covering your deployments before assuming the new metric applies.
What actually happens during an audit?
The sequence is remarkably consistent across vendors, even if the terminology varies. There are seven stages worth knowing.
First, the notification letter. This invokes the audit clause and sets the process in motion. Most agreements require the vendor to give written notice, commonly 30 to 60 days. Microsoft’s standard agreement, for instance, gives it the right to verify compliance on 30 days’ notice.
Second, the kickoff and scoping. The vendor proposes which products, which entities, and which environments are in scope. This is the stage most organizations rush through, and it is the one that matters most. Scope is negotiable, and getting it agreed in writing is what stops an audit of one product from turning into an audit of everything.
Third, data collection. You are asked to run measurement scripts, export deployment data, and often self-declare usage. This is usually the most labor-intensive phase for your team, and the most sensitive, because everything you submit becomes evidence.
Fourth, the analysis, where the auditor builds your Effective License Position.
Fifth, preliminary findings. You typically get a short window, often a week or two, to review and rebut the draft numbers before they are finalized. This rebuttal window is a right, not a formality, and it is where errors in the vendor’s math get corrected.
Sixth, the final report.
Seventh, negotiation and settlement. The vendor’s opening proposal is typically at list price. It is an opening position, not a verdict, and it is routinely negotiated down.
What is an Effective License Position?
Everything in an audit comes down to one calculation, the Effective License Position, or ELP. It is the reconciliation of your entitlements, what you actually bought, against your consumption, what you have actually deployed.
If your consumption exceeds your entitlements, you have a negative ELP, which is the compliance gap the vendor will bill you for. If your entitlements meet or exceed consumption, you are compliant, or even over-licensed and paying for shelf-ware you could cut.
The reason to build your own ELP before you hand over a single data point is simple. The vendor is going to build one either way. If theirs is the only version in the room, their assumptions become the settlement. If you have done your own first, you can see where their numbers are inflated, and you almost always find that they are.
Where do companies actually lose money in an audit?
Most large audit claims are not built on obvious over-deployment. They are built on contested interpretations of complex licensing rules, and this is where expertise pays for itself.
Oracle running on VMware is the most expensive example. Oracle’s position is that its software could theoretically run anywhere in a VMware environment, so every host in the cluster must be licensed, not just the ones actually running Oracle. Initial claims have been known to count many times the cores actually in use. What is critical to understand is that this position lives in Oracle’s partitioning policy, not in your contract. Oracle itself labels that policy as educational and states it may not be incorporated into any agreement. That is a claim to be challenged, not a bill to be paid.
IBM sub-capacity licensing is another. For products licensed by Processor Value Units, sub-capacity licensing can let you license eligible virtualized capacity rather than the whole server. It generally requires the IBM License Metric Tool or another IBM-approved tool, along with the applicable metering and reporting requirements. Failing to meet those requirements can make full-capacity licensing necessary, which can multiply a claim.
SAP indirect access catches organizations whose other systems connect to SAP. In a well-known UK court case, a company’s customer-facing ordering platform that fed into SAP was ruled to be licensable indirect use, with the vendor initially seeking tens of millions in fees. If third-party or homegrown systems touch your ERP, that connection can carry a license cost you never budgeted for.
And for deployments requiring a new Oracle Java SE Universal Subscription, employee-based pricing can make a handful of installations costly. Establish which existing license or free-use rights apply before accepting that subscription as the required remedy.
What should you do in the first days after a letter arrives?
The first response sets the tone for the entire audit. A few principles hold across every vendor.
Acknowledge the letter promptly and professionally, but concede nothing and accept no findings in writing. A prompt, businesslike reply buys goodwill without giving anything away.
Control the flow of information. Route everything through a single coordinator, avoid over-sharing, and wherever possible have your own team run the measurement scripts rather than handing auditors direct access to your systems.
Run your own internal license position before you submit anything. This is the ELP point again, and it is the one that saves the most money.
Treat the kickoff as a scoping negotiation and get the agreed scope in writing, so the audit stays inside the boundaries you agreed rather than expanding as it goes.
Review the audit clause in your actual contract, including notice periods and how findings are meant to be resolved, and bring in independent licensing expertise before you accept any number. The vendor’s auditors know these rules cold. You need someone in your corner who knows them just as well.
For vendor-specific first steps, we have written detailed guides on the first 48 hours after a Microsoft audit letter, the first 48 hours after an IBM audit letter, and how the Oracle license audit process works.
The people who used to run these audits
Here is the part most companies do not know until it is too late. The knowledge that builds an audit claim and the knowledge that defends against one are the same knowledge, and it usually sits on the vendor’s side of the table.
We spent years on that side, running the audits that landed on enterprises just like yours. We know how an Effective License Position is assembled, where the assumptions are aggressive, and which parts of a claim rest on policy rather than contract. That is why we defend rather than audit now, and why we are paid only from what we save you, not from the size of the claim.
If a letter has arrived, or you think one is coming, start with our software license audit defense guide or reach out about audit defense. The best time to understand your position is before the vendor tells you what it thinks that position is.