A Register of Unknowns Beats a Falsely Complete Inventory
Ask most ITAM teams whether the software inventory is complete and you will get a careful answer: mostly, for the main estate, with some exceptions. Ask leadership and the answer is shorter: yes. The gap between those two answers is where licensing decisions go wrong. A dashboard with no blanks is read as a statement that nothing is missing, and the people who know better rarely have a place to say otherwise.
This post argues for a different artifact: a register of unknowns, published alongside the inventory, that says which conclusions the organization can rely on and which it cannot yet. It is less comfortable than a clean total. It is also far more useful to anyone who has to decide something.
Mismatches are signals, not clean-up tasks
Every estate has mismatches between what was bought, what is installed, what is used and what is paid for. The usual response is to treat them as data quality chores: dedupe the names, fix the versions, close the tickets. Some of that is right. But a persistent mismatch is usually telling you something about how the organization works.
- Entitlement without deployment. Nobody owns the purchase after the project ended, or the software was replaced and nobody told procurement.
- Deployment without entitlement. Installation is not gated by anyone who sees contracts, or an acquired business brought its own estate.
- Usage that does not match either. A team is using a product through a channel that inventory cannot see, or a license metric does not map to the thing the tool counts.
- Cost that does not match entitlement. Invoices include products no contract record mentions, or the contract record is out of date.
Each of these is a question about ownership: who is responsible for this record, who decides when it changes, who is told. Cleaning the record without answering that means the same mismatch reappears next quarter. That is why the same problems turn up again after every reconciliation project, and why the pattern in the infrastructure data problem behind every licensing risk is an ownership problem as much as a data one.
How a falsely complete inventory misleads
A total with no caveats invites three mistakes.
First, leaders take the number as settled and plan against it. A renewal is sized on a count that nobody has tested. Second, the team hides its own doubt: the person who knows the virtualization data is a quarter out of date has nowhere to put that, so it stays in their head. Third, when the count is wrong, credibility is lost all at once. One surprise in an audit and every earlier figure is questioned, including the ones that were sound.
A team renewing Oracle, Microsoft and Salesforce in the same quarter might present one consolidated list of installs and seats, complete to the last row. If the Oracle host data is six months old, the Microsoft true-up is based on a manual export, and the Salesforce seats were never matched to active users, those are three different levels of confidence on one page with one level of presentation. The reader cannot tell which line to trust. The register of unknowns separates them.
What the register contains
A register of unknowns is a short, maintained list. Each row is one thing the organization does not know well enough to rely on, written so that someone outside the team can understand it. Six columns are enough.
| Field | What it says | Example |
|---|---|---|
| Item | The specific gap, in plain words | Cluster membership for the finance database hosts |
| Why unknown | What prevents a confident answer | Last discovery scan predates two host moves |
| Owner | One named person responsible for closing it | Infrastructure lead |
| Impact | What decision or position it affects | Oracle processor count and renewal quantity |
| How to resolve | The concrete next step and a date | Rescan the clusters and confirm with the virtualization admin by the 15th |
| Confidence | High, medium or low for the related conclusion, today | Low |
Keep it short. Ten well-written rows that are read are worth more than two hundred that are not. Sort it by impact and confidence, so the top of the list is the gaps that matter most and that are least understood.
Publishing conclusions with a confidence level
The register has a partner: a statement, for each main conclusion, of how reliable it is. This turns the inventory from a single total into something leaders can use.
- Reliable: reconciled against source records in the last quarter; the owner would defend it in an audit.
- Usable with care: mostly reconciled; known gaps are in the register and their direction is understood.
- Not yet reliable: built on estimates or stale data; do not size a commitment on it without resolving the listed gaps.
This is what leadership actually needs when a decision is close. The argument is developed in what executives actually need from SAM during renewal negotiations: a position they can act on, with its limits stated, not a larger report. A leader who is told the Microsoft position is reliable and the Oracle position is not yet, with two named gaps and a date, can decide whether to negotiate now or wait a fortnight. A leader handed a clean total cannot.
Two habits keep the register honest. Write every row so that it can be closed: a gap that says data quality is poor cannot be resolved, while one that says the contract record for the EMEA subsidiary was never loaded can. And never delete a row without a reason. A gap that disappears because someone stopped looking is worse than one that stays open, so each closure should say how it was confirmed.
Where software license visibility comes from
Software license visibility is not the absence of blanks. It is knowing which parts of the picture are solid, which are not, and what it would take to fix each. A register makes that explicit, and it works best when the underlying data sits in one place. Software inventory accuracy improves when the inventory is fed from discovery sources and compared routinely, which is the job of the Software Inventory Manager. Entitlement reconciliation, matching what was bought against what is deployed and used, then becomes a repeatable check rather than a project, and the mismatches it finds go straight into the register with an owner. That is the same shift described in why your software intelligence is just another reporting layer: the value is in what the organization can decide, not in how much was reported.
Starting your register this week
- Pick one vendor with a renewal or audit risk in the next six months. Do not try to cover the whole estate.
- List every number in the current position for that vendor: installs, hosts, seats, entitlements, costs.
- For each, ask: when was this last checked against a source, and by whom? If the answer is unclear, it goes in the register.
- Fill the six fields for each row. Be specific about the owner and the date. A row with no owner is not finished.
- Mark each main conclusion reliable, usable with care or not yet reliable.
- Share it with whoever uses the numbers, finance and procurement included, and ask them to challenge the confidence ratings.
- Review the register every two weeks. Close rows, add rows, and keep the closed ones as history.
The first version will feel exposing. That is normal, and it passes quickly once leaders see that it makes the team easier to trust. A team that says what it does not know is believed when it says it does.
