Every technology business case I have written or reviewed had a savings number in it. Very few of those numbers were ever checked against an invoice. That includes some of mine.
This is not a confession about bad math. The numbers were usually reasonable when they were built. The problem is what happens after approval. The project goes live, the team moves on, and the savings figure becomes a fact by repetition. Two years later it is in a board deck, and nobody can say whether it ever showed up.
Two decisions from my operating roles show the difference between a saving you can prove and one you cannot.
The saving you can see on a purchase order
In one role, the store tablet fleet was failing. An audit found devices that had dropped off the network domain and could not be used, and replacements were being bought one at a time. I wrote a stabilize, refresh and replace plan, piloted two device platforms in real stores, and took one fleet decision to the executive team instead of a stream of small ones.
The result: device hardware cost cut by more than 50%, while equipping about 1,500 front-line staff.
That saving is real in the plainest sense. It is a price on a purchase order compared with a price on an earlier purchase order. Finance can check it without a model. Nobody has to take my word for it.
The same business case also claimed lower support cost, cheaper repairs and faster onboarding for new staff. I believe those were true. I never measured them. If you asked me to prove them on an invoice today I could not, so I do not count them. And the first rollout wave was rough, with remote desktop drops, printing failures and thin training. I wrote that up for leadership as it happened. A saving that ignores the cost of a bad rollout is not a saving either.
The saving that lives in a forecast
The payments decision is the other kind. The company ran two card processors, neither integrated with the ERP, and I replaced them with one integrated platform. I built the comparison, pushed the competing processors to the same rate, and took a decision request to the executive team with the net implementation cost and a saving of about $480K a year, projected. It was approved the next day. The rollout finished on schedule.
That $480K a year is projected, and I want to be precise about why. A processing saving depends on volume, card mix, rates, fees and terms that move every month. The only way to prove it is to compare monthly processing statements after the change against a baseline from before it, adjusted for volume. I do not recall anyone building that tracking, and I did not build it myself. The number I presented became the number people repeated.
The case was honest in one way I am still glad about. For the Canadian stores, the numbers favoured staying with the incumbent processor for another year, and I recommended exactly that. The recommendation followed the numbers, not the preferred outcome. But an honest forecast is still a forecast.
Why a signed baseline matters
The difference between those two decisions is a baseline. The device saving had one by accident: two purchase orders. The payments saving needed one on purpose, and did not get it.
A baseline is the annualized committed spend before any change, agreed in writing by the person who owns the ledger. It has to be built from invoices and accounts payable, not from quotes or memory, and it has to be signed before the negotiation starts. Once a vendor has agreed a new price, everyone has a reason to remember the old one generously.
I have seen what happens without one. On a supplier-integration contract, a cost figure was circulating that rested on an assumption about what the company paid. I corrected it from what the company actually paid, and it fell sharply. The saving was the cost you stop paying, so the saving fell with it. Over the following months the same saving was still quoted three different ways in three different documents. The figure in the final approval, about $300K a year, is projected. A signed baseline would have ended that argument before it started.
The same discipline applies to your own numbers. In one budget I found that a currency mix-up had overstated a hosting line, and I corrected it before it went further. Small errors in a baseline become large errors in a savings claim, because every saving is measured against it.
How to tell projected from realized
Four tests. If a savings claim fails any of them, call it projected and say so out loud.
Is there a signed baseline? Built from invoices, agreed in writing by finance, before the change.
Does it show on an invoice? Realized savings are a lower number on an actual invoice or statement, measured against that baseline. A rate card is not an invoice. A signed contract is not an invoice.
Is it net of what it cost? Implementation, parallel running, the exit terms on the old contract, and the internal time it took.
Has it survived a full cycle? Twelve months of statements, or one full renewal. Processing, usage and support savings drift. One good month is not a result.
The language matters as much as the tests. Projected is not a weaker word for saved. It is a different fact. Keep the two in separate columns, and never add them together.
The practical takeaway
Before your next renegotiation or consolidation, sign the baseline first. Pull twelve months of invoices for the vendors in scope, annualize them, and have finance sign the number. Then track every saving against it, on invoices, for at least twelve months, and report projected and realized separately.
That is how the Contract Renegotiation and Systems Consolidation Program is run. Savings are tracked against a signed baseline using your own invoices, and nothing is reported as realized until it shows up there.