Most technology contracts do not get renegotiated. They renew. The notice date passes on an ordinary Tuesday while everyone is closing the month, and the first person to notice is whoever approves the invoice for the next term.
I have run technology reporting to the CFO, and the gap was the same every time. Finance could tell me what the company spent on technology last year. Nobody could tell me what it was committed to next year, or when each of those commitments could still be changed.
The second question is the one that matters, and one spreadsheet answers it. I call it the renewal calendar. I think the CFO should own it.
The notice date sets the timetable, not the business case
The clearest example I have is a payments decision. In one operating role the company ran two card processors, and neither was connected to the ERP. A new mobile point of sale needed integrated payments, so the processors had to change. The business case was sound. It did not set the timetable.
The contracts did. One processor needed notice before the end of the calendar year. The other had a 180-day notice clause. Working back from those two dates, the decision had to reach the executive team in December, with the comparison built, the price negotiated and the integration work already booked with the ERP vendor, whose development capacity was the real constraint. I gave notice in December so the old contract would end in June. The first store went live on the new processor at the end of May.
None of that was clever. It was arithmetic on two dates I happened to know. Most of the time nobody knows them. They sit in a PDF in someone's inbox, and the vendor's renewal team knows them better than the customer does.
How contracts renew before anyone looks
The failure is rarely negligence. It is structure. Technology agreements are signed by whoever needed the system: IT, operations, marketing, a store team. They are paid through accounts payable, which sees an invoice, not a term. They are filed wherever the person who signed them files things. No one person holds the whole list, so no one person sees a date coming.
Then the business adds things one at a time. In one role, store tablet replacements were being requested one device at a time. Each request was small and reasonable. Nobody had added them up, and nobody had asked whether the whole fleet should be replaced on a plan instead. Software works the same way. A subscription for one team becomes five. A support contract renews at last year's scope after the system it supported is gone.
Acquisitions make it worse. After a deal closes you inherit a second set of agreements, often for the same things, with notice dates nobody on your side has seen.
What goes in it
The calendar is not complicated. One row per agreement, and eight columns.
- Vendor. The legal entity you pay, not the brand on the login screen.
- Scope. What the agreement covers, in one sentence: licences, modules, sites, support tier.
- Term. Start date, end date, and whether it renews automatically.
- Notice period. How many days before the end date you must give notice to change or exit. This is the number in the contract that nobody reads.
- Notice date. The end date minus the notice period. This is the date that matters. Sort the calendar by it.
- Annual value. What you pay in a year, taken from the invoices, not from the quote.
- Owner. One named person accountable for the decision. Not a department.
- Action. What happens at the next notice date: renew, renegotiate, consolidate or exit. Blank is not an answer.
Two of those columns do most of the work. The notice date tells you when your bargaining power ends. The action column forces a decision before it does.
Start from accounts payable, not the contract drawer
The hard part is not the spreadsheet. It is finding every agreement. Ask department heads for their contracts and you get the ones they remember. Start from twelve months of accounts payable instead, because every agreement you pay for shows up there, including the ones nobody can find the paperwork for. Match each technology vendor to a contract, and chase the ones that do not match.
When I pushed for budgets and ledger codes per application and subscription in one role, the reason was the same. If technology spend is coded to one general line, you cannot see which contract a payment belongs to, and you cannot see what each agreement costs.
Expect to find agreements nobody can explain. Expect at least one where the notice date for this term has already passed. That one is not lost. It is the first item for next year.
Who should own it
The CFO, or someone who reports to the CFO. Not because IT cannot keep a spreadsheet. Because the calendar is a financial control, not a technical one. It decides when the company commits money, for how long and on what terms. The person who owns the ledger should own the list of commitments that feed it.
IT still matters. The technology lead knows which systems are on their way out, which vendors are slipping and which contracts are worth a fight. In the version that works, finance owns the dates and IT owns the action column. They meet once a month and look at the next six months of notice dates together.
Timing pays for that meeting. In one role, a contract approval stalled in finance at the end of a month. Each month of delay would have cost several times what signing on schedule cost. I chased it until it was signed. The calendar is what tells you which approvals are worth chasing.
What to do this month
Pull twelve months of accounts payable. List every vendor that looks like technology. Find the contract for each one and write down five things: the end date, whether it renews automatically, the notice period, the annual value and one owner. Sort by notice date. Anything inside the next 120 days gets a decision this month.
I have published the renewal calendar template I use. It calculates the notice date for you. If you would rather have someone build the calendar from your contracts and ledger, reconcile the spend and size what each renewal is worth, that is the first deliverable of the Technology Spend and Contract Diagnostic.