License reconciliation — entitlement vs. deployment, done right.

Reconciliation is not inventory.

Most teams use the words "inventory" and "reconciliation" interchangeably. They are different work. Inventory tells you what is installed and where. Reconciliation tells you whether what is installed is licensed under the entitlement you actually purchased. The difference matters because vendors are not auditing your inventory — they are auditing the gap between entitlement and deployment, and a tidy inventory can mask a six-figure shortfall.

In our experience across 340+ engagements, the customers who survive audits well share one habit: they reconcile against the Ordering Document, not against the marketing description of the product. An Adobe ETLA is not licensed by what the renewal quote says — it is licensed by the Schedule. A Microsoft EA does not entitle you to whatever your tenant is consuming — it entitles you to the SKUs on your true-up roster, with the qualifying-user and qualifying-device definitions exactly as drafted. Reconciliation reads those Schedules first.

Three views, one truth

A defensible reconciliation produces three reconciled views simultaneously: an entitlement view (what the contracts grant), a deployment view (what is installed or assigned), and a usage view (what is actively consumed). The reason all three matter is that some vendors license deployment (Microsoft, Adobe), some license assignment (Salesforce, ServiceNow), and some license usage or consumption (Oracle Diagnostic Pack, SAP indirect access). A single deployment number cannot serve all three vendor models.

The 80% rule

Across the engagements we run, 80% of audit exposure typically sits inside 20% of the estate — specifically, the workloads that crossed an entitlement boundary that the operations team did not know existed. Common examples: a database upgraded from Standard Edition 2 to Enterprise Edition without a licence change, a SQL Server cluster that started using AlwaysOn Availability Groups, an Oracle instance that started writing AWR snapshots after a DBA enabled Diagnostic Pack at the database parameter level. Reconciliation surfaces these crossings; inventory does not.

How to run a reconciliation that actually holds up.

Reconciliation work that survives vendor pushback follows the same sequence regardless of vendor. We have refined this method across hundreds of engagements; the order matters and the shortcuts that look attractive (skipping the entitlement extract, working from the partner portal rather than the Schedule) consistently cost customers money downstream. Where an internal team lacks the bandwidth to run the full sequence, a scoped software license compliance assessment applies the same method across the estate before a renewal window closes.

1. Build the entitlement register from the Schedules. Not from the renewal proposal, not from the vendor portal, not from the partner deck. The Schedule and the Ordering Document are the only documents that bind. Build a row per SKU with the exact metric, the volume entitled, the use rights, and the geographic or affiliate scope.
2. Generate the deployment extract. Use the vendor's own measurement tool where it exists (Oracle LMS scripts, Microsoft MAP/Configuration Manager, Adobe Admin Console) but run it internally first and review every line before sharing externally. Capture the raw output and the date.
3. Normalise both sides to the same metric. An entitlement granted in "Named User Plus" cannot be reconciled against a deployment count expressed in "unique authenticated identities." The translation rules — multiplexing, batch users, monitoring accounts — are vendor-specific and have to be applied before comparison.
4. Compute the gap. For each SKU, surface the over-deployment, under-deployment, and unused-but-entitled positions. Unused entitlement is leverage at renewal; over-deployment is exposure to be remediated before any vendor conversation begins.
5. Document the basis. Every gap row should carry the evidence trail — which extract, which Schedule, which translation rule applied, and which configuration assumption is being made. This is the document that wins disputes; it is not optional.

Where reconciliation looks different by vendor.

Vendor models diverge enough that a single reconciliation methodology cannot apply uniformly. The high-stakes vendors — Oracle, Microsoft, SAP, IBM, Adobe — each require their own reconciliation rules. Below are the patterns we apply most often.

Oracle

Oracle reconciliation hinges on options and packs. The deployment is rarely the issue — the database is licensed at scale — but Diagnostic Pack, Tuning Pack, Partitioning, Advanced Security, and Active Data Guard generate disproportionate exposure because they are enabled without explicit purchase. Run the LMS Options Usage script against every production database; reconcile each option to a Schedule line; document any disabled-then-re-enabled history. This work alone has reduced Oracle audit claims by an average of 68% in our practice.

Microsoft

Microsoft reconciliation in an EA world has three moving parts: qualifying user/device count for Enterprise Products, true-up calculation for additive SKUs, and tenant-level consumption for Azure. The qualifying-user definition is the trap — contractors, third-party staff, M&A acquired users and dormant identities all count under most EA definitions, and the partner-portal report rarely reflects this faithfully. Reconcile against Azure Active Directory plus your HR system, not against the licence-assignment report alone.

SAP

SAP reconciliation must capture both named-user counts (Professional, Limited Professional, Employee, Developer) and engine measurements (Payroll Accounting, FI, Logistics) plus — critically — indirect/digital access. The Digital Access Adoption Programme reframed indirect use as document-based, but most customers have never reconciled their document volume against the entitled tier. The reconciliation here is finance-led, not IT-led.

Adobe and Salesforce

Adobe ETLA reconciliation is straightforward in structure but tactical in execution: assigned-named-user counts in the Admin Console reconciled against ETLA entitlement, with deployment of point-products (Acrobat Pro, Photoshop) versus all-apps suites tracked separately. Salesforce reconciliation is similar in shape — active user assignments against entitlement — but layered with the question of feature licences (CPQ, Service Cloud Voice, Sales Cloud Einstein) which carry independent counts.

From one-off project to running discipline.

A reconciliation done once, before an audit or a renewal, captures value once. A reconciliation done continuously — quarterly, against a defined run-book — captures value at every contract event and drives optimisation between events. The discipline that distinguishes mature SAM programmes is not the tool, it is the cadence.

• Quarterly reconciliation cadence for the top 10 vendors by spend; annual for everything below the threshold.
• Pre-renewal reconciliation initiated 180 days before any contract anniversary, regardless of vendor health.
• Event-triggered reconciliation on M&A, divestiture, cloud migration or significant deployment change.
• Continuous control over high-risk configurations: Oracle option flags, SQL Server edition upgrades, Adobe deployment package selection.
• Vendor-specific run-books codified and version-controlled — the run-book is the institutional memory, not the analyst.