What to record for every subscription: the 12 fields a software register actually needs

Search for a software register template and you will be handed thirty columns. Asset tag, serial number, physical location, depreciation schedule, per-user assignment, last audit date. Fill all thirty in for forty tools and you have built something nobody will ever update. Six months later the file is wrong in ways you cannot see, which is worse than not having it.

A register earns its keep by being current, not by being comprehensive. So the question is not what you could record about a subscription. It is which fields will change a decision you actually make - and every other field is a maintenance tax you pay forever.

Start from the decisions, not the field list

There are only four questions a software register needs to answer, and they are the questions you get asked:

1. 1What are we paying for, and how much does it come to in a year?
2. 2What is coming up for renewal, and by when must we act to stop it?
3. 3Who do I talk to about this tool before it renews?
4. 4If this went away tomorrow, how much would it hurt?

Every field below exists to answer one of those. If a column you are about to add does not, leave it out. You can always add it later for the handful of tools that genuinely need it.

The twelve fields that earn their place

Identity (3 fields)

• Name. The name people actually say out loud, not the legal product name on the invoice. If the invoice says something different, that belongs in notes.
• Vendor domain. One bare host, like slack.com. This is the field that stops duplicates: two people will spell a product name three ways between them, but the domain is unambiguous, and it is what you match invoices and card statements against.
• Category. Keep the list short and boring - around eight to twelve buckets. Categories exist so you can spot that you are paying for four things that do the same job, and a long tail of one-off categories destroys exactly that.

Ownership (2 fields)

• Owner. A named person, never a team or a mailbox. "Marketing" does not answer an email about a renewal; a person does. This is the single field most registers skip and most regret skipping.
• Business unit. Which part of the company the cost belongs to. One field, and suddenly you can hand each department its own spend without re-reading the whole list.

Commercials (4 fields)

• Cost and currency. Record what you pay per billing cycle, in the currency you are billed in. Do not silently convert to your reporting currency as you type - you will lose the original figure and never reconcile it against the invoice again.
• Billing cycle. Monthly, quarterly, annual, or one-off. Without it, the cost field is meaningless: 400 a month and 400 a year look identical in a spreadsheet column.
• Seats. The number you are contracted and billed for, not the number of people currently using it. The gap between those two numbers is where most renegotiation leverage lives, and you can only see the gap if the register holds the contracted figure.
• Licence type. Subscription, perpetual, usage-based, or open-source. It decides whether a renewal date even applies, and usage-based tools need watching on consumption rather than on a date.

Dates and terms (3 fields)

• Renewal date. When the current term ends and the next one begins.
• Notice period, in days. How much warning the contract demands before you can walk away. Read it off the termination clause and record the number, not a description of it.
• Auto-renew, yes or no. Whether silence means it rolls over. On most business software it does, and that flag is what separates a tool you can leave alone from one that will renew itself unless someone intervenes.

That is eleven. The twelfth is the one nobody thinks to add:

• Criticality. Low, medium, high, or critical - how much it would hurt to lose the tool. It is a judgement, recorded once, and it is what turns a flat list into a triage order when eight things renew in the same month. It also stops the reflex of cancelling the cheapest tool rather than the least useful one.

The fields that quietly rot

These all look reasonable on a template. Each one is a promise to keep something up to date that changes faster than you will ever revisit the register.

• Per-user assignment lists. Who holds a seat changes with every joiner and leaver. The vendor's own admin console already knows, and it is never out of date. Record the seat count; look up the names when you need them.
• Invoice-by-invoice payment history. That is your accounting system's job, and it does it properly. A register that tries to mirror it becomes a second set of books that disagrees with the first.
• Usage or adoption percentages copied in by hand. Genuinely useful numbers, and stale within weeks. Pull them at review time from the tool itself rather than freezing a snapshot into a cell.
• The contract pasted into a cell. Store the document and link to it. A truncated clause in a spreadsheet cell is how notice periods get misread.
• A manual "last reviewed" column. It only ever tells you the truth if everyone remembers to update it, which is the same as saying it does not.
• Free-text status. "Chasing Dave", "maybe cancelling?", "see email". Status needs to be a short fixed list you can filter and count - active, in trial, notice given, cancelled - with the rest in notes.

The rule that keeps a register alive

A register decays for one reason: it is updated in a separate exercise from the work that changes it. Someone buys a tool in March and the register is next opened in October.

So make the record part of the purchase rather than an afterthought. A tool is not bought until it has a row, and the row needs a name, a domain, an owner, a cost, a renewal date and a notice period before anyone approves the spend. Those six are all you should insist on at the point of entry; the rest can be filled in at the first review. Insisting on all twelve up front is how the process gets routed around, and a partly filled row that exists beats a perfect one that does not.

The other half of the rule is that the register must be the thing that speaks first. If it sits there silently and waits to be consulted, it will not be. If it emails the owner before their notice window closes, it gets read - and corrected, which is how it stays true.

When a spreadsheet stops being enough

A spreadsheet holds these twelve fields perfectly well, and for a dozen tools it is the right answer. Start there. It stops being the right answer at three specific points, and they are worth naming so you can recognise them:

• When the derived dates have to be right. Deadline formulas survive until someone sorts the sheet, pastes over a column, or moves a row, and a broken formula looks exactly like a working one.
• When it has to reach people. A file cannot email an owner sixty days before their notice window closes. Somebody has to remember to look, which is the failure you were trying to fix.
• When more than one person edits it. Two versions in two inboxes, and neither is authoritative.

StackTrackr is that register with the derived parts done for you: one record per tool with these fields, the cancellation deadline computed from the renewal date and notice period, and reminders that reach the named owner before the window shuts. See the features overview, read how to track software renewals for the process around it, or start free and get your first ten tools recorded properly.