A software license register is one list with one row for every piece of software and every subscription the organization pays for. Each row records what the thing is, who inside the organization owns it, how many seats are assigned and to whom, when it renews, and where the signed agreement is filed. Build it once, keep it current, and you stop finding out about subscriptions by accident.
This article is general information about records and administration. It is not technical, security, contract or legal advice, and it contains no configuration guidance. License and agreement terms differ from one agreement to the next, and what any particular agreement permits or requires is a question for the supplier and for your organization’s own advisors.
What a software license register actually is
Most organizations already have fragments of one. There is a card statement somebody reconciles, a shared folder with some agreements in it, and a handful of people who each know what they personally signed up for. None of those is a register, because none of them answers the questions you ask under pressure.
A register is a single table. One row per piece of software or subscription, one set of columns, held in one place that more than one person can open. That is the whole idea. It does not need to be clever, and it should not be interesting to look at.
The value is not the list itself. It is that the register makes four questions answerable on the spot: what are we paying for, who inside the building is responsible for it, when does the next commitment date arrive, and where is the paperwork. When those four are unanswerable, every conversation about software turns into an investigation.
What belongs in each row of the software license register
Keep the columns few enough that people actually fill them in. These are the ones that earn their place.
| Column | What it records | Common failure |
|---|---|---|
| Name | The product or service as it appears on the invoice | Recording the internal nickname, so nobody can match it to a charge |
| Internal owner | A named person, not a department | “IT” or “Finance”, which means nobody |
| Seats assigned | How many are paid for and how many are in use | Counting what was bought and never checking what is used |
| Assigned to | The people the seats are allocated to | A total with no names behind it |
| Renewal date | The next date a commitment falls due | A month with no day, which defeats any look-ahead |
| Billing cadence | Monthly, annual, or per-term | Left blank, so forecasting is guesswork |
| Where the agreement is filed | A specific location, named | “In email somewhere” |
| Status | Current, under review, or ending | Rows that quietly stay forever |
Two of these deserve a note.
Internal owner must be a person. The owner is whoever answers the question “do we still need this, and is it the right size?” when the renewal comes round. A team name cannot answer that. A person can.
Where the agreement is filed must be specific. Not “the shared drive”. The folder, the file name, or the reference number. If the register tells you the paperwork exists but not where, you have moved the search rather than ended it.
You may want a notes column as well. Keep it for context a successor would need: why the thing was bought, what it replaced, which internal process depends on it. Resist the urge to turn notes into a journal.
How to find what you are already paying for
Almost nobody can list their software from memory, and the gap is usually larger than expected. Work through these sources in order, and add a row for each item the moment you find it.
- The card and bank statements. Go back far enough to catch annual charges, not just monthly ones. Annual subscriptions are the ones people forget, because they bill once and then go quiet for a long stretch.
- The accounts payable records. Invoices paid by transfer never touch a card statement, and this is where larger agreements usually sit.
- Expense claims. Individual staff subscriptions get reimbursed rather than invoiced. These are the rows that surprise people most.
- The email archive of whoever handles billing. Receipts, renewal notices, and confirmations all arrive by email, and searching for terms like “renewal”, “receipt” and “your subscription” will surface items that never made a statement line you recognized.
- Ask each team what they use. Not what they pay for, what they use. People forget they are paying; they rarely forget what they open every day.
- Ask the suppliers you already know about. An organization often holds more than one agreement with the same supplier under different internal owners.
Expect to find three categories of row: things you knew about, things you forgot you were paying for, and things nobody uses any more. Record all three. The third category is the reason the exercise is worth doing, but it is not the only reason.
Building the software license register for the first time
The first pass is a data-gathering job, not a decision-making job. Keep those separate or the exercise stalls.
- Decide the columns before you gather anything. Changing the shape of the table halfway through means revisiting every row.
- Fill in what you can prove. Invoice, agreement, or receipt. If a value is a guess, mark it as a guess rather than leaving it blank, so a successor knows the difference.
- Leave the decisions until the list is complete. Do not cancel, resize, or renegotiate anything while gathering. A half-finished register is a poor basis for a decision.
- Assign an owner to every row, including the awkward ones. Rows with no obvious owner are exactly the rows that cause trouble later. Give them to someone, even provisionally.
- Date the register. A record with no date on it loses credibility the first time someone questions a number.
- Then, and only then, review it with the owners. Each owner reads their own rows and confirms or corrects them.
A first pass built this way is usually imperfect and still immediately useful. Completeness matters more than polish.
Keeping the register current
A register decays fast, because the things it describes change constantly. Three habits keep it alive.
One route in. New software gets a row at the moment it is bought, by whoever buys it. If anyone can commit the organization to a subscription without a row appearing, the register will always be behind.
One review rhythm. Someone opens the register on a fixed cadence, reads the rows whose renewal dates are approaching, and checks each with its owner. This is where the register stops being a list and starts being useful. The renewals calendar does the heavy lifting here, and it works best when it reads from this register rather than duplicating it.
One closing line per row that ends. When something stops, the row does not get deleted. It gets a status change and a dated line saying what happened and who decided. Deleted rows throw away the history that makes the register trustworthy, and the question “did we ever have that?” comes up more often than people expect.
What the register is not
It is not a decision about whether any given agreement is appropriate, correctly sized, or being used within its terms. Those are judgments, and they belong with the owner, the supplier, and your organization’s own advisors. The register’s job is to put the facts in one place so those conversations start from something real.
It is also not a technical record. It does not describe how anything is set up or connected. Keep it administrative and it stays readable by the people who need it most, who are usually not the most technical people in the building.
Build the register, name the owners, date it, and put the renewal dates somewhere they will be read. Everything else in software administration gets easier once the list exists, and nothing else gets easier until it does. If you want a starting structure rather than a blank table, the column layout above is also available as a worksheet on the Free Resources page.