Software license register: every key, seat, and renewal on one page

The licenses are the part of the estate nobody inventories until one fails. A seat count drifts quietly until payroll audit; a renewal fires silently until the card declines on the one tool the whole company runs on; a serial number lives in one ex-employee's email until the machine is rebuilt. This page is the register that makes all three boring — one spreadsheet, one owner column, one calendar feed, and a decision made sixty days before every invoice.

1. The register: one row per thing you pay for

The register is a spreadsheet, not software. One row per paid product. Eight columns, all of them fillable in one sitting: product and vendor, what breaks without it (one sentence — this is also the delete-me test), plan and seat count, annual cost, renewal date with an auto-renew yes/no flag, one owner's name, where the license key or credential lives, and the support tier you actually bought. The asset inventory counts machines; this counts the money and the keys behind them.
Every blank is a future incident. The row with no owner is the tool nobody renews deliberately and nobody cancels either. The row with no key location is the outage that waits on a mailbox archaeology dig. The row with no renewal date is the surprise invoice — and surprise invoices are what the cloud cost spike runbook exists for. Filling the register once is an afternoon; leaving it blank is a subscription to surprises.
Start from the card statements, not from memory. The fastest first pass: walk the last twelve months of card and bank statements, list every recurring charge, and make a row for each. Memory-based registers are missing exactly the tools bought in a hurry during an incident — which are the ones with the worst terms. Anything you cannot map to a row gets a row that says unknown: investigate.
One line per row in the log, same as changes. When a row changes — new tier, new seat count, new owner — that is a change like any other, and it gets the same one-line treatment the window log uses: date, row, what changed, who decided. Eleven months of those lines is an answer, not a shrug, when the customer security questionnaire asks how you manage third-party software.

2. Renewals: the sixty-day decision

Calendar every renewal 60 days out. The renewal date column feeds a recurring calendar reminder two months before each date. Sixty days is enough time to actually decide — renew, downgrade, or cancel — before the auto-renew makes the decision for you. The reminder is five minutes of setup that converts every renewal from a surprise into a decision.
The three-word decision gets written down. Sixty days out, the owner writes one line: "renew at current tier," "downgrade to X seats," or "cancel, alternative is Y." The written line is what stops the quiet default where everything renews forever because nobody was willing to spend an hour thinking about it. When the answer is negotiate, that is when you climb the escalation ladder — not the week after you already paid the full invoice.
Trials are rows too, on a leash. A trial started on a company card is a row in the register with the trial-end date in the renewal column and auto-renew flagged in red. Trials that lapse into paid subscriptions are the classic zombie spend; the register is where you catch them, and the cancellation happens on trial-end day, not when the first real invoice arrives.
Report the year's renewals in one line per quarter. The weekly status report carries the quarter's tally: "Q4 renewals: 7 due, 5 renewed, 1 downgraded (CRM, −$960/yr), 1 cancelled (replaced by the OSS option)." That line is the whole business case for the register — visible savings, zero drama.

3. Seats: the count nobody reconciles

Quarterly seat true-up, tied to the access review. Once a quarter, compare each register row's seat count against reality: headcount, active contractors, and the actual last-login list where the product shows one. The user access review and this true-up are the same meeting; the register rows are just the licensed slice of it. Every seat you remove is budget you keep.
Offboarding removes the seat the same day it removes the account. The offboarding checklist should already deprovision accounts; add one line: revoke or reassign the licenses on the register rows too. A departed employee's seat that keeps renewing for six months is not a security hole — but it is money leaking, and sometimes it is still a login.
Contractors get named seats with expiry dates. The contractor onboarding checklist names the tools and the end date; the register row carries the same expiry. A contractor seat without an expiry is a permanent line item for a temporary person — the most common single line of recoverable spend in a small team's stack.
SSO converts seat hygiene from memory into mechanics. Where a product supports SAML or SSO through your identity provider, connect it. Deprovisioning the identity account then revokes the seat automatically, and the quarterly true-up becomes a five-minute confirmation instead of a forensic audit. Products you cannot connect are exactly the rows to watch at renewal time.

4. Keys: where the licenses and serials actually live

The key column points to a place, not a person. "In Dana's head" or "in Dana's email" is a bus-factor incident waiting for its day. License keys, serial numbers, and account credentials live in the same vault pattern as the backup key escrow card — one shared, access-controlled location; the register row holds the pointer. The test: can a new admin, on day one, find every key without asking a human? The first-week runbook makes that test explicit.
API keys are register rows with a rotation habit. Any product row that involves an API credential gets its key location noted and its last rotation date; the key rotation checklist owns the schedule. The register is where the two disciplines meet: if the rotation date column is blank, the credential is being treated as permanent, and permanent credentials are how leaks become breaches.
The license file rides the backup like everything else. Export the register and the key vault on the same schedule as the rest of the estate, encrypted before upload per the backup encryption rules. A register that survives a laptop loss but not a ransomware rebuild was never really a register — it was a note.
Break-glass access is a row with a red flag. The vendor support portal login that saves you during an outage belongs in the register with its own row and its own owner, next to the break-glass accounts it parallels. When the vendor's dashboard is the only way to check status during an incident, the person holding the phone needs the login in one hop, not one hunt.

5. The annual prune and the evidence it produces

One annual review, every row gets a verdict. Once a year, alongside the annual security review, walk all rows and write one of three verdicts on each: keep, watch (renew once more, revisit next year), or kill (cancel and name the replacement). The delete-me test from column two does the work: if you cannot finish the sentence "without it, … breaks," the row is a candidate for kill.
Zombie rows are the prize. Every annual pass reliably finds one or two: the paid plan the free tier replaced, the seat block sized for a team that shrank, the backup tool duplicated by a feature the main vendor added. Kill them at renewal time and the register pays for its own upkeep many times over.
The register is insurance evidence. Cyber insurance applications and renewals ask what software you run and how you manage access; the register answers in one attachment. The cyber insurance checklist lists the questions — the register is most of the answers, already written.
The verdict log is the year's one-line story. "2026 license review: 23 rows, 18 keep, 3 watch, 2 killed, −$2,140/yr recurring." That sentence, in the annual report next to the security review, is what "we run a tight operation" looks like as evidence instead of adjectives.

Small-team honesty note: a five-person company does not need license-management software; it needs one spreadsheet, one owner column, one calendar feed, and the habit of updating the row in the same five minutes as the renewal email. The trap this page exists to prevent is register drift — a beautiful register nobody updated since the quarter it was born, now an inventory of comfortable lies. A stale register is worse than none: none makes you look; stale makes you sure. Update the row when the email arrives, and the register stays an asset instead of becoming one more thing to distrust.