What Is a Software Licence Position Document?
A Software Licence Position (SLP) — also called an Effective Licence Position (ELP) — is a structured document that reconciles what your organisation has purchased against what it has deployed. Its output is simple: for each software product, it tells you whether you are over-licensed (more licences than deployments), compliant (deployments match licences), or under-licensed (deployments exceed licences). The consequence of each state is financial: over-licensing is wasted spend; under-licensing is audit exposure.
Despite its importance, most organisations either do not maintain an SLP or maintain one that is too inaccurate or too stale to rely on. Annual "point in time" SLPs, assembled hastily in anticipation of an audit or renewal, are the norm rather than the exception. They consistently produce unreliable results because software environments change continuously — deployments are added, removed, and moved; purchases are made outside central procurement channels; vendor agreements are renegotiated mid-year. A position document that was accurate in January may be misleading by March.
Organisations that maintain current SLPs consistently achieve better outcomes in both audit scenarios and renewal negotiations. The reason is straightforward: the vendor knows precisely what it claims you owe; you, without an accurate SLP, do not know what you actually owe. The asymmetry of information is the primary mechanism by which vendors extract over-payments in audits and renewals. An accurate SLP eliminates that asymmetry.
The Six Core Components of an SLP
A complete and defensible SLP contains six categories of information. Together, they tell the full story of an organisation's licence position for a given vendor or product set.
1. Entitlement Register
The entitlement register is the complete record of what the organisation has the right to use. It includes every licence agreement, volume purchase, OEM licence, and subscription in scope, documented with purchase date, licence type (perpetual, subscription, perpetual with maintenance, SaaS), quantity purchased, applicable licensing metric (per user, per device, per processor, per virtual machine), and any material contract terms that affect licence usage rights — such as geographical restrictions, use-type limitations, or virtualisation rules.
Entitlement data must be sourced from procurement systems, vendor portals, and contract databases — not from memory or informal records. For long-tenured organisations, entitlement reconstruction is often the most time-consuming phase of initial SLP creation, particularly for vendors like Oracle, IBM, and SAP where licensing terms have changed multiple times over the years and historical purchases have complex stacking implications. Every entitlement claim must be supported by documentary evidence: purchase orders, invoice records, and licence agreements. Without evidence, entitlements cannot be defended in an audit.
2. Deployment Inventory
The deployment inventory is the complete record of what is actually installed and running. It must be generated through automated discovery tools — manual inventory is insufficiently accurate for any software estate above a few hundred devices. Discovery must cover on-premises servers and workstations, virtual machines across all hypervisors (VMware, Hyper-V, Nutanix), cloud instances (AWS EC2, Azure VMs, Google Cloud instances), container orchestration environments (Kubernetes), and SaaS application usage.
Each discovery method has specific limitations that affect SLP accuracy. Agent-based discovery is highly accurate for managed devices but misses unmanaged assets and devices that are offline during the scan window. Agentless discovery avoids the agent deployment overhead but may have more limited software recognition accuracy. Cloud-native discovery tools provide good coverage of IaaS and PaaS but may not capture all containerised workloads. A robust SLP uses multiple discovery sources and reconciles their outputs rather than relying on any single method.
3. Licence Metric Mapping
Different vendors use different licence metrics, and applying the wrong metric to a deployment produces an inaccurate position. This is one of the most technically complex aspects of SLP creation and one of the most consequential for audit outcomes. Oracle database licences may be measured per processor (full capacity), per processor (capped by virtualisation if specific conditions are met), or per named user plus. IBM software uses Processor Value Units (PVUs) or Virtual Processor Cores (VPCs) depending on the product and edition. Microsoft SQL Server uses per core or per user/device. SAP has indirect access and digital access metrics that apply in complex integration scenarios.
The metric mapping layer of the SLP applies the correct licensing rule to each deployment, accounting for the vendor's virtualisation policies, partitioning rules, and any contractual modifications that affect measurement. This requires deep licensing knowledge — the technical capability to read and interpret complex product use rights documentation — that is genuinely specialised. Organisations without in-house expertise in the relevant vendor's licensing model should engage external advisory support for this component, particularly for Oracle, IBM, and SAP positions.
4. Variance Analysis
The variance analysis is the reconciliation output: for each product and metric combination, it shows entitlements purchased, deployments identified, and the resulting surplus or deficit. Surpluses represent over-licensing — typically an opportunity to reduce future spend by reducing the contract quantity at renewal. Deficits represent under-licensing — compliance exposure that requires remediation before an audit or disclosure to the vendor.
The financial quantification of each variance is essential for prioritising remediation. A deficit of 10 IBM PVU licences may represent $50,000 of exposure or $5 million depending on the product and edition. Understanding the financial magnitude of each variance drives the right remediation priority — either purchasing additional licences, uninstalling or reconfiguring deployments to reduce the licence requirement, or negotiating a resolution with the vendor.
5. Evidence Documentation
An SLP without evidence is an assertion, not a position. Every entitlement claimed must be supported by contemporaneous documentary evidence that can be produced in an audit. This means purchase orders, invoices, executed licence agreements, order confirmations from vendor portals, and any contract amendments that affect licence rights or quantities. Evidence should be stored centrally, associated with the specific entitlement record in the SLP, and version-controlled so that historical positions can be reconstructed if needed.
The quality of evidence matters as much as its existence. Purchase orders without associated licence agreements, or agreements without clear metric definitions, are weaker evidence than a complete package of purchase order, invoice, signed agreement, and licence certificate. For complex vendor relationships with multi-year agreement histories, evidence quality audits are worth conducting before any anticipated vendor audit activity.
6. Usage and Activity Data
The final component moves the SLP beyond pure compliance analysis into optimisation intelligence. Usage and activity data — how frequently is each licenced application actually used, by which users, and at what usage intensity — enables the right-sizing decisions that drive licence cost reduction. An application with 500 licences and 180 active monthly users is an optimisation opportunity, not just a compliance data point. Usage data also informs the reclamation workflow: licence reclamation is most credible and least operationally disruptive when it is based on zero or near-zero usage evidence rather than arbitrary thresholds.
The Six-Phase Process for Creating an SLP
Building an SLP from scratch for a large enterprise is a significant project. The following phases provide the structure for doing it methodically rather than reactively.
Phase 1 — Scope and Prioritise: Define which vendors, product families, and geographies are in scope for the initial SLP. For a large enterprise, attempting to build a complete SLP across every vendor simultaneously is counterproductive. Prioritise by financial value, audit risk, and strategic importance. Start with your top three to five vendors by spend or exposure — typically Oracle, Microsoft, IBM, SAP, or Salesforce — and extend scope once the initial positions are established and maintained.
Phase 2 — Entitlement Reconstruction: Pull all purchase records, contracts, and licence documentation for in-scope vendors from procurement systems, vendor portals, and contract databases. Reconstruct the full entitlement history, including purchases that predate current procurement systems. Validate completeness by cross-referencing against vendor account records — most major vendors will share your purchase history on request and any discrepancies between your records and theirs are worth resolving before an audit arrives.
Phase 3 — Discovery Execution: Deploy discovery across all in-scope environments and collect software installation data. For on-premises environments, this means deploying SAM tool agents or running agentless scans. For cloud environments, it means using cloud-native inventory APIs. For SaaS environments, it means connecting to identity providers and SaaS management platforms to pull usage data. Validate discovery completeness by comparing asset counts against your CMDB and network infrastructure records.
Phase 4 — Normalisation and Metric Application: Map discovered software installations to the licence metric definitions in your entitlement register. Apply vendor-specific licensing rules — virtualisation policies, partitioning eligibility, per-processor versus per-user metrics — to each deployment. This phase requires the most technical licensing expertise and is where errors most commonly occur in self-built SLPs.
Phase 5 — Reconciliation and Variance Identification: Compare entitlements against metricated deployments to produce the variance analysis. Quantify the financial exposure for each deficit and the cost reduction opportunity for each surplus. Prioritise remediation actions based on financial magnitude and audit risk timeline.
Phase 6 — Governance and Continuous Maintenance: Establish the cadence and process for maintaining the SLP going forward. For on-premises environments, quarterly refresh is the minimum. For cloud and SaaS environments, monthly or continuous refresh is preferable. Define who owns SLP maintenance, how new purchases are reflected in the entitlement register, and how changes to the deployment environment trigger SLP updates.
How Vendors Use the SLP in an Audit
Understanding how vendors approach audits — and what role they expect the SLP to play — is essential for using the SLP effectively in a compliance context. The major vendors differ in their audit approach and expectations.
Oracle is the most aggressive auditor in the enterprise software market. Oracle's audit process typically begins with a letter requesting that you provide your software licence position within 30–60 days. Oracle's audit team will compare your submitted SLP against their own entitlement records and against an Oracle-generated discovery of your environment if they conduct on-site verification. Oracle scrutinises virtualisation configurations particularly closely — the rules governing when Oracle database licences can be applied to a subset of a physical server's processors are complex and frequently misapplied, creating significant exposure for organisations that believe they are compliant. An accurate SLP that applies Oracle's virtualisation rules correctly is the primary defence against inflated audit findings.
IBM focuses its audits on ILMT (IBM Licence Metric Tool) configuration compliance. Sub-capacity licensing — where IBM software is licensed only for the virtual processor cores it can access, rather than all physical cores on the host — is only valid when ILMT is correctly installed, configured, and generating compliant reports. Organisations claiming sub-capacity pricing without a properly maintained ILMT deployment are vulnerable to IBM requiring full-capacity licensing retroactively. The SLP for IBM products must document not only deployments and entitlements but also the ILMT configuration status for every host running IBM software under sub-capacity licences.
SAP conducts both Basic and Enhanced audits. Enhanced audits include indirection access analysis — examining whether third-party systems call SAP functions in ways that trigger licensing requirements for indirect users. The SLP for SAP must account for both direct user licences and indirect access scenarios, which requires careful analysis of integration architectures and API call patterns.
Microsoft audits are typically less confrontational than Oracle or IBM audits, but the scale of most enterprise Microsoft deployments means that even a small per-unit error rate can produce significant aggregate exposure. Microsoft expects an SLP that accurately reflects all Office, Windows Server, SQL Server, and Azure entitlements and deployments, including Software Assurance status and any applicable Azure Hybrid Benefit activations.
Vendor-Specific SLP Requirements
- Oracle: Virtualisation configuration is the primary risk — document hypervisor settings and partitioning rules for every database host
- IBM: ILMT configuration must be verified and documented for all sub-capacity licence claims; incorrect ILMT = full-capacity exposure
- SAP: Include indirect access analysis alongside direct user licence positions; document integration points with third-party systems
- Microsoft: Document SA status, Azure Hybrid Benefit activations, and SPLA/hosting licence structures separately from standard volume licences
Using the SLP in Vendor Negotiations
The SLP is not only a compliance tool — it is a commercial one. An accurate position document transforms renewal negotiations from a vendor-led exercise into a buyer-led one. When you know precisely how many licences you are using, which you are over-licensed on, and which you may need to add, you negotiate from a position of data rather than assumption.
The three ways an accurate SLP improves renewal outcomes are: it identifies over-licensing that justifies a request to reduce contract quantities at renewal rather than accepting the vendor's proposed uplift; it provides the usage data that supports right-sizing from higher to lower licence tiers where your usage profile does not justify the premium; and it enables you to challenge the vendor's entitlement position if their records differ from yours, preventing you from being pressured into accepting inflated claims.
Organisations that systematically connect their SLP to their renewal preparation process consistently achieve 10–20% better renewal outcomes than those that negotiate without accurate position data. The investment in maintaining the SLP pays back not just in audit risk avoidance but in every renewal cycle where the SLP provides the evidentiary foundation for a more aggressive negotiating stance. For more on connecting your licence position to your broader SAM programme, see our SAM Tools Guide 2026 and our guide to building a Software Licence Management CoE.
Need help building or validating your Software Licence Position?
Redress Compliance provides independent ELP construction and validation for complex vendor environments. Buyer-side only.Eight Common SLP Mistakes
The failure modes of SLP management are consistent across organisations. Understanding them is the fastest way to avoid them.
Annual-only updates make the SLP useless for audit defence or negotiation most of the time. Software environments change continuously; a position document that is refreshed only once per year is stale within weeks of completion. At minimum, quarterly refreshes are needed; for cloud and SaaS environments, continuous or monthly refresh is the professional standard.
No centralised inventory means there is no single source of truth. SLP data scattered across spreadsheets, SAM tools, and procurement systems produces contradictory positions and cannot be efficiently updated or defended.
Entitlement data without evidence produces an SLP that looks complete but cannot be defended. Every entitlement must be supported by purchase documentation that can be produced on demand.
Tracking installations without usage produces a position but not an optimisation opportunity. Usage data is what enables right-sizing, reclamation, and the renewal arguments that reduce software spend.
Excluding cloud and SaaS creates a systematic blind spot that vendors know about. Oracle audit teams routinely examine cloud deployments as part of their standard process; excluding them from your SLP creates an asymmetric information disadvantage that is entirely avoidable.
No clear ownership means the SLP is maintained by whoever happens to have time, which in practice means it is maintained inadequately. Every licensable software title needs a named owner accountable for keeping its position current.
Wrong metric application produces an SLP that is inaccurate even when the discovery data is correct. Oracle's virtualisation rules, IBM's PVU and VPC calculations, and SAP's indirect access analysis all require specialist knowledge to apply correctly.
Disconnection from procurement means new purchases are not reflected in the entitlement register and the SLP becomes stale immediately after any software purchase. The entitlement register must be updated as a standard step in every software procurement workflow.
The SLP Governance Framework
Sustaining SLP accuracy over time requires governance, not just process. Governance means clearly defined ownership, documented responsibilities, and accountability mechanisms that ensure the SLP remains current even as priorities change and staff turnover occurs.
The governance framework should specify: who owns the SLP for each vendor, what the refresh cadence is, what events trigger an out-of-cycle update (a new significant purchase, a major deployment change, a vendor audit notification), how conflicts between SLP data and vendor records are escalated and resolved, and how SLP data is made available to the procurement and renewal teams who need it. For organisations that have established an SLM CoE, the CoE provides the governance home for these decisions. For organisations without a CoE, the governance owner is typically the IT director or CTO, with day-to-day operation owned by the SAM team or a designated licence manager.
The SLP is a living document, not a project deliverable. Treating it as a project — building it once, presenting the results, and moving on — is one of the primary reasons so many organisations find themselves unable to use their licence position data when they need it most. The organisations that derive sustained value from their SLPs treat them as operational infrastructure, maintained with the same rigour as financial accounts, because that is effectively what they are: the organisation's financial exposure and opportunity in the software domain, quantified and updated continuously.