Corporate software licensing: inventory and audit preparation

Why license tracking breaks and what it leads to

Buying software is not the same as having unrestricted right to use it. A license is a set of conditions: who may use the product, on which devices, in what scope and with what limitations. When there is no tracking, a company often pays twice: first for the purchase, then for fixes after an audit.

An audit usually checks one simple thing: whether actual usage matches what the contract permits. Auditors look at installations and active users, license type (per device, per user, subscription), virtualization and remote access rights, and proof of purchase or legitimate acquisition. Additional charges appear when there are more installations than purchased entitlements, or when the wrong metric was chosen (for example, device licenses while tens of remote users access the software).

Most problems start not from bad intent but from lost traces. Documents and usage rights go missing when licenses were bought via different suppliers and invoices are stored in different places, keys and access remain with a departed employee, hardware is retired but the license isn't returned to the pool. Two other common scenarios are auto-renewing subscriptions without checking real need and "temporary" installs that quietly become permanent.

Tracking usually fails where roles are not separated. For proper corporate software licensing it's important that IT is responsible for actual installations and changes, procurement for contracts and closing documents, legal for interpreting terms, and system owners for who needs access and why. When these people don't synchronize, shadow installs, unnecessary purchases and a perpetual fear of an audit letter appear.

Basic concepts to speak the auditor's language

Terms often confused

In an audit it's important to separate three things: installation, usage and right to use. Software may be installed on 200 PCs, but actually used by 120. The right to use may cover only 100. For the auditor, the right matters, not how many shortcuts are on desktops.

The right to use is defined by the license type. Most common are:

• Per user: the license is tied to a person who signs in to the system.
• Per device: the license is tied to a specific PC, terminal or server.
• By cores (or processors): computing power is counted, typically on servers.
• Subscription: the right is valid while you pay and requires tracking of dates.

These distinctions are critical in corporate software licensing. The same product can be cost-effective "per user" for office roles but become expensive on a server if cores are miscounted.

A separate risk area is additional rights that many assume but cannot prove. For example, downgrade rights (using an older version), license transfer to another device, temporary secondary use (e.g. on a spare PC) or operation in a virtual environment. All of this is possible only if written in the contract, vendor terms or subscription conditions.

What counts as proof of entitlement

An auditor usually asks for documents, not explanations. You need a linkage: what was bought, who it was registered to, the scope and the conditions.

Good proof typically includes the contract and specification, invoice and payment, delivery act or packing list, license certificate or a letter from the vendor. Sometimes correspondence confirming disputed points (for example, transfer rights) is important.

Simple example: procurement bought 50 subscriptions, while IT deployed 60 installations expecting to close the gap later. In an audit that looks like 10 violations even if users rarely logged into the product. It's better to agree on terms and documents in advance rather than on the day of the request.

What to include in inventory and where to get data

Inventory for license tracking starts not with a spreadsheet, but with a clear answer: what exactly you are counting and under which rules. This matters especially in corporate licensing where the same purchase can be counted by device, user or server cores.

Count more than just "office and Windows"

To avoid missing costly items and "gray" installs, record the full set of software actually used in the company: client and server OS, office suites and collaboration tools, server products (databases, terminal services, virtualization, backup), department-specific specialized software, as well as plugins and small utilities that may have separate licenses.

Don't try to perfect the list right away. It's more practical to gather a complete draft and refine it, rather than initially miss positions that often cause overspend.

Where to get data: build a picture from multiple systems

One system almost never gives the full picture. You'll usually need to reconcile multiple sources: an account directory (for example, Active Directory), MDM/EMM for mobile devices, the virtualization platform (hosts, VMs, test clones), device inventory and CMDB (serial numbers, owners, location), service desk and tickets (who requested an install and why, what approvals existed).

Then choose a single identifier around which to build tracking: device, user, physical server or VM. The key is not to mix different "axes" in one register without marking them, otherwise later it's hard to explain your calculation logic to an auditor.

Set boundaries immediately: which branches and subsidiaries are included, what to do with contractors, whether to include test environments. A typical case is trial software in a training lab that is later rolled out to 30 PCs. If boundaries are defined in advance, such stories are caught faster.

Inventory process step by step

Inventory is not for the spreadsheet itself. Its goal is to always be able to answer two questions: where the software is installed and on what basis it is used. This is the foundation for proper corporate software licensing and calm audit preparation.

A repeatable workflow, run quarterly or before a major purchase:

1. Compile a complete asset list: desktops and laptops, servers, virtual machines, terminal farms, test benches. Include branches and remote devices, otherwise figures will look neat but be wrong.

2. Collect actual installations: product names, editions, versions and where exactly installed. For some software it's critical to understand not just the installation but the mode of use (for example, via a terminal server or on an application server).

3. Gather entitlement documents: invoices, contracts, certificates, keys, renewal confirmations. Link each license to a product and a metric (per device, per user, by cores, subscription). If the metric is unclear, mark it as a disputed case.

4. Reconcile: match installations with entitlements. The result usually falls into three zones: shortfall (risk), surplus (idle money), and unclear situations (different versions, different upgrade rights, mixed environments).

5. Record the outcome and an action plan: what to remove, what to buy, what to reassign, what to clarify with the vendor or supplier. Assign owners and deadlines, otherwise the inventory quickly becomes outdated.

Simple illustration: some employees use new PCs while others connect by RDP to shared servers. If you count only installations on PCs, it's easy to buy too many licenses. If you count only the server, you might miss user-based requirements. So record not only "where installed" but also "how it is used."

How to build a license and evidence registry

A license registry is a set of facts you can quickly show an auditor: what was bought, under which conditions, where it is used and why it is legal. The closer the registry is to actual installations and purchases, the lower the risk of overpayments and claims.

It's convenient to keep the registry in one place (CMDB, ITSM or a corporate spreadsheet) with unified filling rules. A practical rule is one license (or one understandable package of rights) per card, with all supporting evidence attached.

Minimum fields for a card:

• Product and edition (exact name from the contract or invoice).
• Metric (per device, per user, by cores, etc.) and transfer rules.
• Term (perpetual or subscription, start and end dates).
• Quantity and limitations (branch, usage type, virtualization).
• Procurement data: contract/order number, date, supplier, invoice/delivery act number.

Store evidence centrally rather than in mailboxes or personal folders. Agree on one naming format so a document can be found in 30 seconds. For example: "Vendor_Product_DocType_Date_Number_Quantity". Inside the card, note where the folder with files is and what each document proves.

Don't forget change history. Audits almost always ask not only about purchase but about movements.

It's useful to log events: purchase, installation/assignment, transfer, decommission (freed, retired, removed).

Example: a government organization bought licenses for a project, then some workstations were replaced with new PCs. If the card contains transfer rights and a log "old PC -> new PC" with date and request, the tracking looks transparent and raises no extra questions.

Procurement and redistribution rules to avoid overpaying

Purchasing licenses often breaks down not because of price but because of chaos in requests: "urgent needed", "just in case", "same as last time". To prevent licensing from becoming perpetual top-ups, enforce a simple rule: demand must be confirmed by numbers and a process owner.

Demand is easiest to measure by a clear metric: people (FTE), devices, servers, cores or active users over a period. Assign who confirms the numbers: unit manager, application owner, InfoSec or IT operations. Without confirmation the request does not go to procurement.

Rule before buying: redistribute first, then purchase. If an employee left, a project closed or a server decommissioned, the license should return to the pool. The registry should support a "available for issue" status and a clear reclaim period during which a license can be reassigned without extra approvals.

Before payment check conditions that often lead to overspend: licensing metric, territory and branch usage rights, renewal terms, reassignment rights and minimum reassignment interval, downgrade, virtualization and test environment rules.

Also agree standard workstation and server configurations: baseline software set and variants like "office", "engineering", "contact center". If some staff only need web access, they don't need expensive "thick" licenses. It's easier to codify this in a standard than decide each request ad hoc.

In practice it looks like this: a department requests 30 licenses but 90-day active user data shows 22. First reassign 6 free licenses, then buy 16, keeping the budget under control.

Common mistakes that cause overspend

The most costly mistakes come from mismatches between what was bought, how the software is used, and what can be proven with documents. This usually leads to double purchases, lost update rights and stressful audit prep.

Mistake 1: wrong licensing metric

A common story: the product is licensed per device but purchased per user (or vice versa). In the registry everything looks "logical", but on inspection it turns out that 200 thin clients were covered by 200 user licenses, while device licenses were needed. Or vice versa: devices were licensed but access is given to shift workers and contractors.

Mistake 2: mixed editions and versions

When a department uses different editions (e.g., Standard and Enterprise) and product generations, it's easy to lose support or upgrade rights. Worse is when some installations were upgraded but documents still reflect old purchases. Then you overpay twice: for new licenses and for support that could have been covered by existing rights.

Mistake 3: not accounting for virtualization, test and standby

VMs, clusters, DR sites, standby nodes and test benches often live "off the record" while auditors count them as full usage. Typical example: a standby server used once a month may still require a license by the rules.

Mistake 4: hardware retired but licenses not returned

A PC was decommissioned, a user account closed, but activation remained. The license is formally occupied and procurement buys a new one while an existing entitlement could have been returned to the pool.

Mistake 5: evidence not tied to actual use

Invoices, delivery acts and keys may sit in a folder but it's unclear which purchase relates to which installation and who was granted access. A simple control helps: each installation has an owner (user or device), each license has a metric and limits, each record has a supporting document, virtual environments show hosts and spares, and there is a deactivation rule on retirement.

How to prepare for an audit without panic

Panic starts when the audit is on the doorstep and evidence is missing: who bought what, where it's installed, who uses it and under which conditions. It's calmer when a package of facts is already collected and there's a clear communication scenario.

Gather the evidence package in one folder

Auditors almost always want proof. Prepare it in advance and store it together so you don't have to collect items from people and mailboxes at the last minute:

• Contracts and amendments, including terms of use.
• Invoices, delivery acts, packing lists, letters from vendor or partner.
• Licenses, keys, certificates, exports from vendor portals.
• Inventory reports and snapshots of installations/usage.
• Internal orders and procedures (who is responsible, how rights are issued).

Appoint a small responsible group (usually IT + procurement + legal) and one communication channel with the auditor. This reduces contradictory answers from different people and the risk of accidentally disclosing unnecessary data.

Take a "snapshot" and run a mini-check

Agree on a snapshot date for data: device list, users, installations and licenses. During the check period introduce a simple rule: any change (new install, transfer, termination) goes through the responsible group and is marked separately. Then the report won't drift day by day.

Pick 1–2 highest-risk products: usually those licensed per user or per cores, or those heavily installed on request. Do an internal reconciliation: purchases versus actual usage. This quickly exposes gaps before an auditor does.

Prepare explanations for disputed cases in advance: test benches, temporary accounts, standby servers, bundled licenses. Simple example: finance has 30 active users but only 25 purchased. Better to show a plan to top up or reassign and attach documents than argue emotionally.

If you build licensing as a process, an audit becomes a check of order, not a crisis.

Short checklist: is your tracking ready?

If tracking lives in emails and spreadsheets across drives, the unpleasant truth usually emerges during an audit: you cannot quickly prove entitlement. This checklist helps identify which holes to fix first.

Check these five points. If you answer "no" to at least two, tidy up before new purchases.

• There is a complete list of hardware where software may be installed: desktops, laptops, servers, VMs, test benches and remote desktops.
• For key products you can reconcile "installed" vs "permitted" and know the sources of both figures.
• Purchase proofs and entitlement documents are stored centrally and can be accessed within minutes: contract, invoice, delivery act, certificates, vendor letters, subscription terms.
• There are rules for what to do with software on termination, transfer, PC replacement and equipment write-off, including return or reassignment of rights.
• New installs and access issuance go through approvals: who initiates, who checks available entitlements, who records the installation.

Quick test: can an employee answer within 30 minutes "how many rights do we have for the office suite and on which devices it is installed" and show the documents? If not, tracking is vulnerable not only to audits but to overspend.

In practice it's common to buy "just in case" and later discover some installs were on old VMs not used for a long time. A simple rule to remove and return rights typically saves more than a one-off "optimization" at year-end.

Practical example: getting ready before an audit

A 500-person company prepared for a license audit. HQ in one city, several branches and remote workers. Software had been bought over years: some purchases through IT, some via procurement, subscriptions often arranged by team managers on a corporate card.

The reconciliation quickly revealed three typical problems. First, excess subscriptions: licenses for employees who had left or changed roles. Second, duplicate user entries: the same person appeared in two domains or had two accounts (corporate and a temporary contractor account). Third, forgotten servers in branches running old software not reflected in the asset registry.

They cleaned up in four weeks without heroics or emergency purchases. First they cleaned: exported users from HR, matched them to directory accounts and subscription lists, and disabled extras. Then they reallocated licenses: some subscriptions were reassigned to those who needed them, and infrequently used tools were pooled for project teams. They only purchased what was truly missing after final reconciliation.

To answer the auditor calmly they prepared an evidence package: contracts and invoices (including license types and dates), rules for assignment and removal, exports from account and subscription systems, inventory results for devices and servers (including branches), and a change log for the month before the audit.

They answered typical questions with numbers: how many installations, how many active users, where purchase proof is stored, and why exceptions exist (e.g., test benches). To prevent recurrence they defined metrics and rules: monthly HR vs account reconciliation, limits on ad hoc purchases, lifetime for temporary accounts, quarterly branch server checks. As a result license spending dropped and audit risk became manageable.

Next steps: make the process stick and avoid chaos

After inventory it's important to turn a one-off cleanup into habit. Then corporate software licensing stops being a source of surprises and urgent top-ups.

Start small this week. Pick the 10 most expensive or most audited products (typically office suites, OS, server licenses, databases, remote access tools) and reconcile data from at least two sources: procurement (invoices, contracts, keys) and actual installs (inventory on PCs and servers). Appoint one process owner responsible for the master registry and evidence.

Minimum to keep order:

• Roles: registry owner, procurement lead, administrator who verifies installs.
• Frequency: a short check every month and a full review quarterly.
• Change rule: new install or license transfer only by request and recorded in the registry.
• Central evidence storage: invoices, specifications, vendor letters, portal exports.
• Short report to management: what changed, where risks are, how much can be avoided.

If you have many sites, complex virtualization or start tracking from scratch, it's often easier to engage a system integrator to collect data, verify metrics and formalize procedures.

For such tasks GSE.kz (gse.kz) may be a suitable system integrator: they can help with inventory, basic registry structure and organizing change support so the registry updates as work proceeds rather than being filled retroactively.