How we count a saving
Every savings number leancosts shows — a console counter, a digest ROI line, a total in a sales conversation — comes from the Realized Savings Ledger and nothing else. Before an amount enters that ledger it has to clear four filters. Without all four, we do not count it as recovered. The criteria are the same for audit, for sales, and for you, and they do not change.
The four filters
Section titled “The four filters”I. There is an approved change request
Section titled “I. There is an approved change request”Without dual-control recorded in the audit log, nothing counts. A suggestion is not a saving. An insight is not a saving. A recommendation in the inbox is not a saving. It only becomes a saving when someone from your organization other than the author has signed the change request and it has been executed — two people, never one.
II. There is a pre and post measurement
Section titled “II. There is a pre and post measurement”Resource cost is captured for four weeks before and four weeks after execution, in contract currency. If the pre/post window does not cover four stable weeks on both sides, the row sits in pending verification and does not enter the ledger until it does.
III. The delta is positive and materially attributable
Section titled “III. The delta is positive and materially attributable”Price/volume/mix variance isolates the change-request effect from other movements (a price change, a usage shift, a new workload) that ran in parallel. If it cannot isolate the effect — because a price hike or a new workload contaminated the post window — the row goes in as inconclusive and does not add up. Materially attributable means the change request is the dominant explanation for the difference.
IV. It is in the Realized Savings Ledger
Section titled “IV. It is in the Realized Savings Ledger”An immutable row, linked to the change request, the pre evidence, and the post evidence — auditable end to end. The ledger is the single source behind every number that leaves leancosts, including console counters and sales-material totals.
Why this rigor
Section titled “Why this rigor”Unproven savings are vendor fiction. The usual FinOps tool reports “$X saved” because someone recommended turning off a VM — and the VM was never turned off, or was turned off for another reason, or had its workload migrated elsewhere with the cost coming back through the side door. The ledger exists so that does not happen to your numbers.
To turn a finding into a ledgered saving, follow Act on a cost finding.
The strongest version of this page is a real, anonymized, customer-consented before/after pulled straight from the ledger — a defended amount, the before and after cost, and the executed change request behind it.
We have not published one yet. When a customer agrees in writing to a published, anonymized case, it will appear here — and not before. An empty slot is more honest than a number we cannot fully stand behind.