The Savings Tracker: Running IT on a Cost-Out Ledger Before FinOps Had a Name

Turn a few pages into the 2020 year-in-review deck for the UC team I led and you hit a page that isn’t a vision statement. It’s headed “Cost savings in a 3 Year Period.” Three columns — 2018, 2019, 2020 — and at the bottom, in small type, a single line of provenance: all data based on savings recorded in the 2018, 2019 & 2020 savings tracker Excel. With a hyperlink. To the file.

That footnote is the whole article. Long before FinOps was a phrase a board would recognize, the org kept a living ledger of what it had taken out of the cost base — each circuit retired, each contract renegotiated, the platform consolidations, logged in a running spreadsheet that carried forward year over year. The annual deck didn’t assert savings. It cited a source. Anyone in Finance could open the file and check the math against the contracts.

Let me be precise about what this is and isn’t. There’s a separate argument — that IT is a capability center, not a cost center, and the fix is to report outcomes instead of inputs. That’s the thesis. This is the mechanism: the instrument that let a technology team walk into a budget conversation holding receipts instead of adjectives.

Two columns, and why the second one mattered more

The part most people miss is the column structure. The page didn’t report one number per year. It reported two, side by side.

The first was realized savings — net-new cost taken out in that specific year. In 2018, ~$71K. In 2019, ~$144K. In 2020, ~$20K. Money that left the run rate this year because of something the team did this year. Sum the realized column across all three years and you get ~$235K — and 2020 was deliberately thin, the COVID year where the easy wins were already booked and the team was holding the line, not harvesting.

The second column was year-over-year savings — the run-rate effect of everything still in force. ~$371K in 2018. ~$215K in 2019. The footnote that year named the driver in plain terms: 40% telecom circuit run-rate reduction in 2019, compared to the beginning of 2019.

The second column was run-rate reduction — the recurring spend a change takes off the books and keeps off, year over year. The same decks log it separately: ~$371K in 2018, ~$215K in 2019. That separation is the discipline. Realized savings and run-rate reduction are different numbers measuring different things — cash out this year versus recurring burn permanently removed — and a ledger that keeps them in their own columns is one a CFO can reconcile rather than discount. The deck’s headline three-year banner reads ~$464K; the figures that taught me more were the two honest columns underneath it, because a pair of columns survives scrutiny that one rounded total never does.

Conflating the two is how most IT savings claims quietly fall apart. A contract you renegotiate once is realized the year you sign it. It keeps paying every year it stays signed — that’s run-rate. Book the same renegotiation as fresh savings in year two and Finance catches it the first time they reconcile, then stops trusting every number you bring after. Drop it in year two and you’ve understated the durable value of the work. Hold the two apart, label both, and the ledger reconciles against the general ledger instead of fighting it.

The ledger predates the deck

This wasn’t a one-year exercise dressed up for a review. The continuity is in the documents.

The 2019 deck carries the same page, headed “Cost savings in a 2 Year Period,” sourced to the 2018 and 2019 savings tracker Excel. A year later the page reappears, extended to three years and the same file, grown a column. Same structure, same provenance line, one more year of entries. The spreadsheet wasn’t a slide rebuilt each cycle to make a point. It was a register the team appended to — a standing instrument the deck merely pointed at.

That distinction matters because of what it signals about how the work was run day to day. You don’t reconstruct three years of circuit retirements and contract terms from memory at review time. Either the team logged it as it went — contract reference, dollar figure — or it didn’t have it. The deck was downstream of the discipline. The OKRs underneath were blunt about the mandate — reduce operations costs by 10%, negotiate existing telecom circuit contracts for lower rates and terminate legacy circuits — and the tracker was where the team proved, line by line, whether it had hit them.

How it scaled when the org did

By 2021 the same reporting habit had moved from one telecom-and-UC team to the whole Corporate IT organization I directed — network, infrastructure, service desk, cloud, endpoint, vendor management, program management. The 2021 year-end statistics lead with the same kind of number at org scale: >$994K realized in 2021, ~$1.46M year-over-year. The org’s stated mission named it directly — introduce new business functionality while reducing overall operating costs — and the cost OKR was specific: drive 10% cost savings by consolidating processes, applications and services.

The number got an order of magnitude bigger. The discipline didn’t change. Realized held apart from run-rate. The same instinct that a savings claim is only as good as the ledger behind it. That’s the tell of a mechanism rather than a slogan — the realized-apart-from-run-rate split survived being handed to seven other functions and kept its shape at the org rollup.

I’ll be careful here, because this is exactly where these stories get oversold: the >$994K is the org-wide figure for the whole Corporate IT organization, not a personal slice. The work was the team’s — including the line-by-line logging and the call to report cost-out as two columns rather than one. What I’m claiming is the operating model: the decision that we would report cost-out as an auditable ledger, not as a number that asks to be believed.

The origin: instrument first, then spend

The habit didn’t start with a savings spreadsheet. It started with a different question, six years before that 2021 deck.

In May 2015, deep in a weekly status report, there’s a one-line entry under the SIP trunk project: worked with an engineer from the data-innovation group to get CUCM CDR records into Splunk and started working on the data to provide a dashboard which shows necessary bandwidth going forward. Unglamorous sentence. It’s the seed of everything above.

We were about to make a sizeable bet — moving voice off legacy circuits onto SIP across a global estate, with a multi-carrier RFP behind it. The temptation in that moment is to size the buy off the vendor’s capacity model, or a rule of thumb, and sign. Instead the first move was to instrument what we actually had: pipe the call-detail records — the real, per-call usage the phone system was already generating — into Splunk, and build a dashboard showing genuine demand and the bandwidth the new design would truly need. We sized the spend off measured consumption, not off a quote.

That’s a feedback loop most people now call FinOps: meter real usage, model the unit economics off that data, then commit. We were doing it for telecom years before the cloud world gave the practice a name and a conference. The savings tracker is the same instinct pointed at the outcome instead of the input — measure what’s real, write it down, let the data carry the argument.

The AI-spend version is the same instrument

This is the part every board is reaching for right now, as they ask what the return on AI spend actually is.

The cloud-era version of the ledger is a FinOps practice with showback, unit economics, and a shared dashboard between engineering and Finance. The AI-era version is the same instrument again. Meter the one number that matters — token, inference, and seat consumption of the new capability — and hold it against realized savings, the actual tool decommissions and headcount-hours the AI took out. Put both in a ledger Finance can open, not a number they have to take on faith. The technology under the spreadsheet keeps changing. The discipline is the one that hyperlinked an Excel file at the bottom of a 2019 slide.

The one position I’ll defend

Here’s the lesson worth more than the dollar figures.

Most IT cost narratives fail not because the savings aren’t real but because they’re unauditable. The leader walks into the budget meeting with a round number and a story. The CFO has no way to check it, so they apply a discount — sometimes openly, usually silently. Over a few cycles the discount becomes the relationship. IT’s numbers get treated as aspirational, the function gets treated as a spend problem, and the budget conversation turns adversarial because the trust to make it collaborative was never built.

The savings tracker inverts that. By logging cost-out as a running, two-column ledger — realized apart from run-rate, every line traceable to a contract — you change the kind of conversation you’re having. You’re not asking to be believed. You’re handing over an audit trail and inviting them to check it. The design goal is specific: claim slightly less than the file supports, every figure carrying a “~” or a “>”, so that when Finance reconciles, the number holds and then some. Build it to be rounded up, not discounted. That’s not a reporting trick. It’s the difference between IT as a cost center to be managed and IT as a function whose word on money is good.

Want the Monday version? Open one sheet today. One row per cost-out action. Columns for the contract reference, the realized-this-year dollars, and the run-rate-still-in-force dollars. Carry it forward — never rebuild it. Hyperlink it in the next review and let the source file do the talking. Build the instrument before you spend the money. Write down what’s real. Let the file argue for you.

— Read next: IT Is Not a Cost Center — It’s a Capability Center for the thesis the ledger makes defensible, and The M&A Playbook Was Decided Before the Deal for the same instrument-first instinct applied to integration.

Common questions

How do you measure ROI on AI spend with a FinOps-style ledger?
Use the same two-column instrument that predates FinOps: meter the real consumption of the AI capability — token, inference, and seat usage — and hold it against realized savings, the actual tool decommissions and headcount-hours the AI took out of the cost base. Report both in a ledger Finance can open and reconcile, with each line traceable to a contract or invoice, rather than a single round ’AI ROI’ number taken on faith. The origin of this discipline in Christian Merkel’s organization was a 2015 telecom decision: before a large SIP migration, the team piped CUCM call-detail records into Splunk to size the bet on measured usage instead of a vendor’s capacity model — meter first, then commit. That meter-then-report loop is exactly what FinOps later formalized for the cloud and what boards now need for AI spend.

What is the difference between realized savings and run-rate (year-over-year) savings?
Realized savings is net-new cost taken out in a specific year because of something done that year. Run-rate, or year-over-year, savings is the ongoing annual effect of everything still in force. A contract renegotiated once is realized the year it’s signed but keeps reducing the run rate every year it stays signed. Holding the two columns apart is the whole instrument: booking the same renegotiation as fresh savings twice gets caught on reconciliation and destroys Finance’s trust, while dropping it understates the durable value of the work. In Christian Merkel’s 2018–2020 savings tracker the realized column summed to roughly $235K over three years, while the deck’s cumulative banner — realized plus carried run-rate — read about $464K. Different numbers measuring different things, kept in separate columns so a CFO can reconcile them.

What is a two-column savings ledger and why does it make IT cost claims auditable?
A two-column savings ledger is a running, multi-year register of IT cost reductions in which realized savings (net-new cost removed in a given year) are logged in one column and run-rate / year-over-year savings (the ongoing annual effect of measures still in force) in a second, with every line traceable to the underlying contract. In Christian Merkel’s organization each annual review deck opened with a ’Cost savings in a 2/3 Year Period’ page sourced by name and hyperlink to a savings-tracker Excel, so Finance could open the file and reconcile against the actual contracts instead of taking a round number on faith. The point is auditability: the ledger reconciles against the general ledger rather than fighting it, which is what lets a CFO put the figure on a board slide instead of discounting it.

How do you report IT cost savings to the CFO so they’re trusted?
Report cost-out as a running, two-column ledger — realized apart from run-rate, every line traceable to a contract — rather than a round number with a story attached. Claim slightly less than the file supports, marking figures with ’~’ and ’>’, so that when Finance reconciles, the number holds and then some; the design goal is to be rounded up, not discounted. In Christian Merkel’s organization the savings page was sourced by name and hyperlink to the tracker Excel, and the discipline scaled from one telecom-and-UC team to the whole Corporate IT organization, reporting over $994K realized and about $1.46M year-over-year in 2021. The Monday version: one sheet, one row per cost-out action, columns for contract reference, realized-this-year, and run-rate-still-in-force; carry it forward and hyperlink it in the next review.