Software License Agreements
A Software License Agreement is a parent record that groups together licenses purchased under a single contract — a Microsoft Enterprise Agreement, an Adobe ETLA, an Oracle ULA, an Open Value, a VPP. Modeling agreements in xAssets gives you per-contract roll-ups for renewal planning, audit defense, and cost allocation.
When to Use Agreements
Use an agreement when you have:
- Multiple licenses purchased on a single contract
- A renewal date or term you need to track at the contract level
- Vendor-side rules (downgrade rights, cross-product transferability, true-up cycles) that apply to the whole contract
- Cost allocation that should roll up at the contract level
Skip agreements for one-off retail purchases or perpetual single-license buys — the overhead is not worth it for two licenses.
Viewing Agreements
Navigate to Licensing → Software License Agreements to see the list of agreement records.
Each agreement shows:
- The agreement name and supplier
- The total license seats rolled up across all child licenses
- The renewal date (if set)
- The expenditure across the agreement
Click an agreement to see its child licenses and details.
Creating an Agreement
- From the Software License Agreements list, choose Create New Agreement.
- Fill in:
- Description — the contract name (e.g., "Microsoft EA 2024-2027")
- Supplier — the vendor or reseller
- Start Date — contract effective date
- End Date — contract end date or renewal point
- Cost — total contract value
- Save.
Once the agreement exists, license records can be attached to it.
Linking Licenses to an Agreement
Two ways:
Method 1: Set Software Agreement on the license record.
- Open the license from Licensing → Licenses.
- Set the Software Agreement field to the parent agreement.
- Save.
The license now appears as a child of the agreement.
Method 2: At import time.
The Standard License Import has an Agreement column. If a row's Agreement value matches an existing agreement's name, the license is linked at import. Note: agreements are not auto-created — the agreement must exist before the import.
The MLS import creates the agreement automatically as part of the pipeline. See Microsoft License Statement Import.
Why It Matters for the Engine
Agreements do not change how allocation works — the engine allocates per license. But agreements drive:
- Reporting — per-agreement seat counts and expenditure
- Renewals — querying "what is up for renewal in the next 6 months?"
- Audit lineage — every license points back to its source contract
For a vendor audit, being able to say "this license came from contract X, signed Y, here is the agreement record with expiry and signatory" is significantly faster than producing it from scratch each time.
Renewal Workflow
When an agreement renews:
| Pattern | What to Do |
|---|---|
| Same contract continues | Update the End Date on the agreement; leave child licenses unchanged |
| New contract supersedes the old | Mark the old agreement Out of Service; create a new agreement; either move children to the new or create new child licenses for the new term |
| Partial renewal (some seats not renewed) | Mark non-renewed child licenses as Expired; keep renewed ones In Service; update the agreement End Date |
The choice depends on whether your audit posture treats it as one continuous license or distinct annual purchases.
Agreements and Compliance
The licensing position is computed per product. An agreement is a financial / contractual grouping rather than a compliance unit.
That said, the per-agreement view is essential for:
- Spotting agreements where allocated seats exceed purchased seats (over-deployment within a contract)
- Identifying agreements with surplus seats that can be trimmed at renewal
- Cross-checking vendor invoices against your records
Common Agreement Types
There is no fixed list of agreement types in xAssets — the agreement record is a generic parent. The taxonomy below covers the common Microsoft and Adobe programs and the modelling pattern for each.
| Agreement | Vendor | Typical Modelling |
|---|---|---|
| Enterprise Agreement (EA) | Microsoft | One agreement record per EA term (typically 3 years). Use the MLS import to populate child licenses from the Microsoft License Statement. |
| Enterprise Subscription Agreement (EAS) | Microsoft | Same as EA but with subscription licenses; child license records use a per-user License Type (USER / NAMEDUSER) and end on the agreement End Date. |
| Microsoft Products and Services Agreement (MPSA) | Microsoft | One agreement per contract; child licenses imported via MLS. Per-component subscription terms may have different end dates than the parent. |
| Open Value / Open License | Microsoft | Smaller-scale Microsoft programs. One agreement per contract; child licenses entered via Standard Import or manually. |
| Enterprise License Agreement (ELA) | Oracle, IBM, others | One agreement record. Children typically entered manually since vendors do not export to a standard format. Annual true-up may add new children mid-term. |
| Adobe ETLA / VIP | Adobe | One agreement per contract. Use the Adobe import for the child licenses. |
| Volume Purchase Programme (VPP) | Apple, others | One agreement per programme; child licenses entered via Standard Import. |
The pattern is the same for all: parent agreement with Software License Agreements record, child licenses with the agreement field set to the parent. The differences are in how the child licenses arrive (MLS / Adobe pipeline / manual / Standard Import) and what License Types they use.
Software Assurance and Maintenance
Microsoft Software Assurance (SA) is recorded as an attribute on the license record rather than as a separate agreement. The SA-relevant fields:
| Field | Use |
|---|---|
| Software Assurance | Set when the license includes SA. Drives certain renewal and downgrade-rights behaviours. |
| Maintenance Type | Records the maintenance program for vendors that have one (Adobe Maintenance, Oracle Premier Support, etc.). |
| End Date | The expiry of the SA / Maintenance term. |
For Microsoft per-core licenses with SA, the typical practice is to set the Downgrade Rule on the license to Any — SA implies downgrade rights to any earlier version. Without SA, choose None or One depending on the product's specific terms.
When an SA term expires:
- If you renew, update the End Date and SA-related fields.
- If you do not renew, the underlying license remains valid (you still own the rights at the SA expiry version) but downgrade rights and version-upgrade rights end. Consider changing the Downgrade Rule to None at expiry.
When End Date Has Passed
A license with an End Date in the past is treated by the engine as having no capacity for periods after that date. The license record itself stays In Service unless you change its status manually — the engine does not auto-flip status, only stops counting capacity.
This means:
- The license is still visible in queries and reports (useful for renewal planning)
- It still has its purchase data (cost, supplier, etc.)
- It contributes zero seats to the licensing position from the End Date onward
For a clean register, periodically review expired licenses and set Status to Out of Service. See License Status Codes.
Related Reading
- Importing Licenses: Microsoft License Statement Import — auto-creates agreements
- License Status Codes
- Daily Tasks: Audit Preparation — using agreements during an audit