Hard Savings vs Soft Savings: Getting Finance to Sign Off

A Black Belt closes an inventory project and reports $400,000 in annual savings. The controller reads the claim, strikes the capacity line, strikes the avoided hiring, strikes the annualized projection built on six weeks of data, and signs off on $61,000. The project was real. The improvement was real. But the number that survives is the one finance can trace to a ledger, and now every future claim from the CI program gets read with the same red pen.

That review meeting is where continuous improvement programs earn or lose their credibility. The distinction between hard savings and soft savings exists to prevent it from going badly. Classify benefits correctly from the start, agree on the rules with finance before the project ends, and the controller becomes a validator instead of an adversary.

What makes a saving hard

A hard saving is a benefit that shows up in the financial statements. Spending that stopped. Revenue that appeared. Money that finance can find by comparing this period's actuals to a documented baseline. iSixSigma's treatment of the subject compresses the definition into one sentence: we're no longer spending the money on X; we were, but now we're not.

Common hard savings from CI projects include:

• Reduced unit cost of production or operation, such as scrap, rework, and material waste eliminated
• Reduced transaction or overhead cost, including overtime that is no longer worked
• Reduced headcount, where a position is actually removed or redeployed against budget
• Increased throughput that converts to recognized revenue

The test is auditability. A hard saving survives the question "show me where this appears in the P&L" without a story attached. Six Sigma Material's overview of project financials makes the same point: hard dollars justify projects because they are verifiable, and verifiable numbers are what leadership uses to fund the next wave of work.

What makes a saving soft

A soft saving is a real benefit that does not land directly on the bottom line, or lands there in a way nobody can isolate. iSixSigma defines soft savings as project outcomes that benefit the organization without a direct, measurable impact on the financial statements.

Typical soft savings include:

• Improved employee morale, engagement, and retention
• Improved customer satisfaction and reputation
• Reduced working capital needs before the cash effect is measured
• Compliance and safety improvements with no incident baseline to compare against
• Capacity freed up that has not yet been loaded with new work

None of these are fake. A project that halves onboarding time or removes a safety hazard created value. The mistake is not claiming soft benefits. The mistake is summing them with hard savings into one headline number, because the moment a controller finds one soft dollar inside a "total savings" figure, every dollar in the figure becomes suspect.

The spectrum from hard to soft

Classification is easier with a gradient than with a binary. The iSixSigma framework referenced above sorts benefits into four bands, from hardest to softest:

1. Savings with current-period P&L impact. Spending reduced against baseline, revenue recognized. This is the band finance signs without argument.
2. Balance sheet and working capital effects, such as inventory reduction that frees cash. Real and measurable, but the benefit is cash flow and carrying cost, not the full inventory value.
3. Cost avoidance and capacity enhancement. A future cost prevented or capacity created, with no current-period ledger entry to point at.
4. Benefits with no credible quantifier at all: safety, legal exposure, morale. Worth doing, worth recording, not worth a dollar claim.

Time can move a benefit up the spectrum. Avoided hiring becomes hard when the hiring plan existed in the budget and the requisition is cancelled. Freed capacity becomes hard when it absorbs demand that would otherwise have required overtime or capital. Until that happens, the benefit stays in the band where it currently lives, and the report should say so.

Cost avoidance is its own category

Cost avoidance causes more classification arguments than any other benefit type, because practitioners feel it as savings and controllers cannot find it in the books. The distinction is settled in corporate finance: cost savings reduce spending that exists today, while cost avoidance prevents spending that has not happened yet. A negotiated-away price increase, a maintenance program that prevents a failure, a redesign that avoids a planned capacity expansion: all avoidance.

The controller's position is not hostility. Avoided costs never appear in a financial statement, so they can never be audited against one. Procurement teams run into the identical wall, and the discipline that works there works for CI: report avoidance separately, against a documented would-have-been baseline, and never blend it into the savings total.

So track cost avoidance as a first-class benefit type, distinct from the hard and soft classification. A benefit can be a well-documented, finance-acknowledged cost avoidance and still be excluded from net savings. Both facts belong in the record.

The discipline that gets claims approved

The pattern across finance-facing guidance is consistent: credibility comes from rules agreed in advance, not from persuasion at review. Air Academy Associates' treatment of CI program ROI recommends finance validation for every hard savings claim and conservative, standardized assumptions for everything softer. In practice the discipline has five parts.

1. Fix the baseline before the improvement. Document the measurement, the period, and the data source in the charter. Get finance's agreement on it while the number is still uncomfortable rather than convenient.
2. Agree the recognition rules once, at program level. What counts as hard, how many months of post-improvement actuals a claim needs, how annualization works, and when a claim expires. Twelve months of credit for a recurring saving is a common convention; whatever the rule, it must be written down before anyone needs it.
3. Classify at entry, not at review. Every benefit gets its hard or soft classification and its benefit type the day it is recorded. Sorting a pile of unclassified benefits at close-out invites exactly the reconstruction finance distrusts.
4. Keep hard and soft arithmetic separate. Net savings math runs on hard savings minus implementation costs. Soft savings and avoidance are reported alongside, itemized, never summed into the headline.
5. Deduct the costs. A savings claim that omits the project's own implementation and capital costs is not conservative, and controllers notice. Net is the only number worth defending.

None of this requires finance to run the CI program. It requires one agreement, made early, about what the numbers mean.

Give the controller a seat on the project

The cheapest validation is the kind that happens continuously. A project that involves a finance representative from the charter onward never faces a surprise review, because the person who would reject the claim helped record it.

This is the reason SixGrid's project model includes a Financial Rep as a named project role. The Financial Rep sees the project's financials as they accumulate and validates classifications while the context is fresh, without holding edit rights over the work itself. Every benefit in SixGrid carries the two fields this post has argued for: a hard or soft classification, and a separate benefit type that includes cost avoidance alongside cost savings, revenue increase, and safety, compliance, and environmental impact. The classification then does the reporting automatically. The Net Hard Savings card computes hard savings minus total costs, and soft savings stay visible in their own column instead of inflating the headline.

The opportunity a project is chasing is kept separate too. SixGrid records the cost of poor quality as its own annualized figure with a documented basis, and it never counts toward benefit totals, because an opportunity estimate and a validated saving are different numbers with different owners. For a walkthrough of how the full project structure fits together, from charter to financials to final report, see What Is SixGrid? in the Continuous Improvement hub.

What leadership should see

Report one headline number: net hard savings, validated by finance, costs deducted. Then itemize everything else. Soft savings listed with their evidence. Cost avoidance listed against its documented would-have-been baseline. Band 4 benefits described in words, not dollars.

A program that reports this way gives up the biggest possible number and gets something better in return. Its claims stop being negotiations. When leadership compares projects, funds the next wave, or defends the program's budget, the numbers have already survived the only review that matters. That is the actual deliverable of classification discipline: not tidier bookkeeping, but a CI program whose word is good.