Cost Avoidance vs Cost Savings in Six Sigma Projects
Why cost avoidance feels like savings to the practitioner and vanishes at the controller's desk, the three-condition test that makes it hard, how to document the would-have-been baseline, and why it needs its own benefit type.
A Green Belt finishes a preventive maintenance project and reports $210,000 in savings: the compressor that failed twice last year did not fail this year, and each failure cost $105,000 in emergency repair and lost production. The controller opens the maintenance cost center and finds spend down by $8,000. The other $202,000 does not exist anywhere in the ledger, because the failures it refers to never happened.
Both people are right. The practitioner prevented a real cost. The controller cannot book a cost that was never incurred. The disagreement is not about the improvement, it is about which accounting system each of them is using, and a CI program that does not settle the question in advance re-argues it at every close-out.
This post covers cost avoidance specifically. Hard Savings vs Soft Savings: Getting Finance to Sign Off covers the wider hard and soft spectrum and where avoidance sits on it; read that first if the spectrum is new to you.
Two accounting systems in the same meeting
The practitioner is doing counterfactual accounting. The benefit is the difference between the world where the project ran and the world where it did not, and in that comparison a prevented failure is worth exactly as much as an eliminated one. Procurement teams reason the same way: an avoided cost is the gap between what was prevented and the baseline projection, and it is hard to audit for the same reason it is easy to feel, because it is measured against something that did not happen (Ramp).
The controller is doing ledger accounting. A cost center has a budget and an actual, and the variance report compares the two. If the $210,000 of failures was never in the budget, then avoiding it produces a variance of zero. Nothing moved. The controller is not being obstinate; the instrument they are required to use cannot detect the event.
That is the whole mechanism. Avoidance feels like savings because the counterfactual is vivid to the person who ran the project. It vanishes at review because the ledger only records transactions, and a prevented transaction is not one.
When avoidance hardens
Avoidance becomes hard the moment it produces a ledger movement of its own. The guidance published by Sudeshna Banerjee sets the test in one sentence: avoided costs qualify as hard financial benefits only when they have been previously incurred or their future incidence is certain, meaning they were budgeted for in the annual operating plan (Process Excellence Network). iSixSigma's treatment is blunter still: if a process owner is willing to book something into his or her budget, then that is hard savings (iSixSigma).
Apply that as three conditions, all of which must hold.
- The spend existed as a line. A requisition number, a capital appropriation request, an approved purchase order, or an AOP line with a cost center and an amount. Not a forecast in a slide.
- The spend was committed, not contingent. A budgeted hire the department was actively recruiting for. A capital purchase with an approved appropriation. A renewal the contract obliged the company to pay.
- The line was removed and the removal is documented. The requisition was cancelled, the appropriation withdrawn, the budget reforecast, and there is a dated record signed by the budget owner.
Two examples that pass. A department had a budgeted second-shift supervisor, requisition open, start date set, and the project's cycle-time reduction made the shift unnecessary; the requisition is cancelled and the AOP is reforecast down by the loaded salary. A plant had an approved $340,000 appropriation for a third packaging line, and a changeover project freed enough capacity that the appropriation is withdrawn. In both cases the controller can point at a line that used to exist and now does not. That is a ledger movement, and it can be classified Hard.
Note what hardened them. Not the size of the number, and not the quality of the engineering. A cancelled document.
When avoidance stays soft
Everything that fails one of the three conditions stays soft, and most avoidance does.
- A supplier proposed a 6 percent increase and the team negotiated it to 2 percent. The 4 percent was never budgeted, never committed, and never paid. It is avoidance, and it is soft.
- A maintenance project prevents a failure that happened twice last year. Last year's failures were incurred, so the guidance above allows a case for hardness, but only for the portion finance agrees was expected to recur. A failure that might have happened is a probability, not a line.
- A redesign removes the need for a capacity expansion that was discussed but never appropriated. No line existed, so nothing was removed.
Soft does not mean unreported. It means the benefit is recorded, valued, attributed, and kept out of the headline. iSixSigma puts cost avoidance and capacity enhancement in its Category C, real with reasonable confidence, and Banerjee's rule for the whole soft class is that it should be reflected separately and never added to the hard financial benefits.
Documenting the would-have-been baseline
A cost saving has a baseline in the past: actual spend before the change. An avoided cost has a baseline in a future that will not occur, so the baseline has to be constructed, and the construction is what finance audits. Build it before the improvement, not at close-out, and attach the evidence.
- Identify the source document. The quote, the requisition, the appropriation request, the contract renewal notice, the failure history. This is the thing that proves the cost was coming.
- Record its date and its approver. A baseline that was written after the improvement is a rationalization, and reviewers know it.
- State the period. What window the avoided spend would have fallen in, and how many recurrences you are claiming inside it.
- State the probability if it is not 100 percent. Two failures in each of the last three years supports a claim of two. One failure in five years does not support a claim of one per year.
- Write the formula on one line. Loaded salary times months, or unit price delta times committed volume, or repair cost times supported recurrence. If it takes a paragraph, the number is soft regardless of what the source document says.
- Get the Financial Rep to initial it. Before the Improve phase, while the baseline is uncomfortable rather than convenient.
The same discipline applies to the charter's Primary Metric, as described in Six Sigma Financial Tracking That Finance Will Sign Off On: fix the measurement and the data source before the number has a stake in the outcome.
Record it as its own benefit type
The reporting failure that damages programs is not claiming avoidance. It is summing avoidance into "total savings" so that the headline contains a number finance cannot find. Once a controller finds one avoided dollar inside a savings figure, every dollar in the figure is reopened.
The fix is structural. Give avoidance its own benefit type, distinct from cost savings, so that a benefit can be tagged Cost Avoidance regardless of whether it is Hard or Soft. The two questions are independent. A cancelled budgeted requisition is Cost Avoidance and Hard. A negotiated-away price increase is Cost Avoidance and Soft. A reduction in scrap is Cost Savings and Hard. Collapsing the two fields into one forces a choice between an honest type and an honest classification.
In SixGrid's full accounting model, each benefit carries both fields. The Hard or Soft classification drives the Hard Savings, Soft Savings, and Net Hard Savings summary cards. The Benefit Type field (Cost Savings, Cost Avoidance, Revenue Increase, Safety Impact, Compliance Impact, Environmental Impact, or Other) is separate and does not change the arithmetic. A soft cost avoidance sits in the Soft Savings card and never touches Net Hard Savings, which is Hard Savings minus Total Costs. A hard cost avoidance, one that passed the three-condition test, counts in Net Hard Savings, and the type field still says what kind of money it is so the controller can go find the cancelled line. The Financial Rep project role sees every entry, with its classification and type, read-only, and validates it while the context is fresh.
What the report should say
Lead with Net Hard Savings, costs deducted, validated by the Financial Rep. If a cost avoidance passed the test and is included, name it and cite the cancelled document in the same line. Then, under a separate heading, list every soft cost avoidance with its would-have-been baseline, its source document, its recognition period, and its formula. Leadership sees the full value. Finance sees a headline it can sign.
The compressor project from the opening reports $8,000 in Net Hard Savings, plus $210,000 in soft cost avoidance against a documented two-failure baseline with the repair invoices attached. That is a smaller headline than $210,000. It is also the only version of the claim that survives a second reading, and the only one that leaves the program's next claim intact.
Frequently asked questions
Is cost avoidance a hard or soft saving in Six Sigma?
Soft by default. It becomes hard only when the avoided spend was already budgeted or committed, the line was removed, and the removal is documented and confirmed by finance. A cancelled budgeted requisition or a withdrawn capital appropriation can qualify; a negotiated-away price increase cannot.
Should cost avoidance be included in net savings?
Only the portion that meets the hard test. Report all other avoidance separately, itemized against its would-have-been baseline, and never add it into the net hard savings headline.
How do you calculate cost avoidance for a Six Sigma project?
Start from a dated source document that proves the cost was coming (a quote, a requisition, an appropriation, a failure history), state the period and the recurrence rate the data supports, and write the formula on one line. Have the Financial Rep agree the baseline before the improvement is made.