A monthly savings register for audit findings

A cost audit that ends as a slide deck has not finished its job. It has produced leads. The business only gets the money when someone owns each change, the baseline is defensible, and finance can see the result in a bill, payroll report, or contract.

That is why I turn audit findings into a monthly savings register before I discuss the total opportunity. The register is deliberately less exciting than an audit presentation. It forces the questions people prefer to postpone: Who will do this? What precisely falls off the monthly run rate? What could break? When will we know whether the number was real?

Most teams lose savings in the handoff between discovery and execution. The auditor reports that duplicate tools cost money, idle infrastructure costs money, and a bloated delivery team costs money. Everyone nods. Three months later, the tools still renew, the instances still run, and the headcount plan has changed twice. A register turns those observations into a managed operating commitment.

A finding is not yet a financial result

A finding says that money may be recoverable. A savings item says what will change, who will make it change, and how the company will prove the outcome. Treating those as the same thing is how a credible audit becomes a wish list.

The FinOps Foundation makes a similar distinction in its unit economics guidance. It asks teams to document metrics, data sources, calculations, and a review cadence, rather than celebrate the existence of a dashboard. It also separates resource-efficiency measures, such as cost per workload, from business measures, such as cost per transaction. That separation matters because a lower infrastructure bill can still accompany a worse customer outcome.

A register works across payroll, vendors, cloud, AI spend, and process waste, but each row needs the same minimum structure:

• a specific intervention rather than a diagnosis
• one accountable owner rather than a committee
• a baseline drawn from actual cost data
• a stated proof date and evidence source
• an actual result that stays visible when it disappoints

For example, "Engineering uses too many project-management tools" is an audit finding. "Cancel 42 unused seats at the next renewal and migrate the remaining users to the standard workspace" is a savings item. The first invites debate. The second can be accepted, rejected, or assigned.

Do not allow rows such as "use AI to increase productivity" or "optimize cloud spend." Those are themes, not implementable changes. A real row names the spend, the intervention, the affected scope, and the person who can make a decision stick.

There is one other rule I enforce early: every item has a status, but status does not determine whether it counts in the savings total. Only verified actual saving counts as realized. Everything else is forecast.

The register needs one row per economic change

Split findings into separate rows whenever they require different owners, different proof, or different dates. A single row called "reduce engineering cost by $40,000 per month" hides too much to manage. It may contain contractor exits, unused SaaS cancellations, a hosting redesign, and an automation project. Those changes have different risk profiles and will not land at the same time.

Use this template in a spreadsheet, database, or project tracker. The tool is unimportant. The definitions are not.

id,initiative,owner,baseline_cost_monthly,expected_saving_monthly,implementation_effort,risk,decision_date,implementation_date,proof_date,evidence_source,actual_saving_monthly,status,notes
SR-001,Cancel unused design-tool seats,Head of Design,4200,1800,Low,Low,2026-08-03,2026-08-10,2026-09-01,Vendor invoice and seat export,,Proposed,Keep 48 active seats
SR-002,Move nightly jobs to scheduled workers,Platform Lead,9600,3100,Medium,Medium,2026-08-05,2026-08-22,2026-09-15,Cloud billing export and job logs,,Approved,Verify no missed jobs
SR-003,Do not backfill departing QA contractor,VP Engineering,14500,14500,High,Medium,2026-08-01,2026-08-31,2026-09-30,Payroll report and release metrics,,In progress,Requires test automation coverage
SR-004,Retire duplicate customer-support platform,COO,6800,6800,High,High,2026-08-12,2026-09-20,2026-10-01,Final invoice and migration sign-off,,Proposed,Contract notice period applies

The template includes more than the requested columns because a monthly register fails without dates, evidence, and status. Keep the visible view simple if your leadership team needs it, but preserve the full record underneath. A number without a source turns into an argument at the worst possible moment.

The U.S. Government Accountability Office Cost Estimating and Assessment Guide requires a technical baseline, documented assumptions, risk analysis, and updates with actual costs. The guide was written for public programs, not a 40-person startup, but its discipline transfers cleanly: an estimate that never meets actuals is not a management instrument.

Use a unique ID even if the register has only ten rows. Initiative names change as people rewrite them for meetings. IDs let finance, engineering, and the founder discuss the same item without losing its history.

Baseline cost must describe the world before the change

The baseline is the recurring monthly cost that would continue if nobody implemented the item. It is not the budget, the contract ceiling, a hoped-for hiring plan, or the most expensive invoice you can find. It is the starting point against which actual results will be measured.

For stable SaaS subscriptions, the last complete invoice is usually enough. Record the invoice month, currency, number of paid seats, and any annual commitment. If the invoice includes several products, isolate the product or seats the initiative will change. A total vendor bill is a poor baseline for a narrow seat-reclamation task.

For variable infrastructure, take a trailing three-month average unless a material product event makes those months unrepresentative. Write down the exception. If a customer launch doubled compute use last month, a three-month average might be misleading. In that case, calculate baseline cost per transaction, per active customer, per build minute, or per supported environment, then state the expected usage for the proof month.

Use these formulas:

baseline monthly cost = relevant recurring spend before implementation
expected monthly saving = baseline monthly cost - expected monthly cost after implementation
actual monthly saving = adjusted baseline monthly cost - actual monthly cost after implementation
annualized actual saving = actual monthly saving x 12

The phrase "adjusted baseline" matters. If traffic rose 40 percent after the change, comparing raw cloud dollars alone gives you a false result. Adjust the baseline for the driver that caused the spend to move. A practical calculation might look like this:

May compute cost:             $9,000
May completed jobs:           3,000,000
Baseline cost per job:        $0.0030
August completed jobs:        4,000,000
Adjusted August baseline:     $12,000
Actual August compute cost:   $8,400
Actual monthly saving:        $3,600

Do not turn every cost line into unit economics. For a fixed contract, that adds pointless complexity. Do it when usage can move enough to make an absolute-dollar comparison dishonest. The FinOps Foundation specifically recommends documenting the cost and business data behind a unit metric, because a metric without its data lineage creates recurring debates over definitions.

For payroll, use the fully loaded monthly cost only when the company will actually remove, avoid, or replace that cost. Salary, employer taxes, benefits, contractor fees, management overhead where material, and committed agency fees may all belong in the baseline. Do not claim the whole salary of an employee who remains employed and simply has more capacity. That is a capacity gain, which deserves tracking, but it is not a cash saving.

Expected savings need a calculation, not optimism

Expected saving is a forecast. Write it with enough arithmetic that another person can reproduce it in two minutes. If you cannot explain the number without opening a ten-tab spreadsheet, the register is too opaque.

A strong expected-saving note looks like this:

Baseline: 140 paid seats at $30 per seat per month = $4,200
Expected active seats after cleanup: 80
Expected monthly cost: 80 x $30 = $2,400
Expected saving: $1,800 per month
Assumption: vendor allows seat reduction at the next monthly true-up

A weak note looks like this:

Expected saving: $2,000
Reason: remove unused licenses

The difference is not paperwork for its own sake. The first note tells you what can go wrong. Perhaps the vendor has an annual minimum. Perhaps the 60 dormant accounts belong to contractors who return quarterly. Perhaps the seat report counts service accounts. You can investigate those facts before someone reports a saving that contract terms block.

Keep expected savings conservative. I would rather show a lower number that finance validates than publish a large opportunity figure that collapses under inspection. This is especially true for labor. Teams often calculate an automation initiative as "two engineers saved." Unless headcount, contractor spend, or planned hiring actually changes, report it as capacity released and describe what the company will do with that capacity.

Separate three categories in the register or in the reporting view:

Cost avoidance is popular because it makes the total look larger. It also creates the most disputes. If a startup planned to hire four developers and later hires two because its engineers can ship more with AI assistance, that may be a sound business result. But it is only avoidance if the hiring plan was funded, approved, and genuinely would have happened. A rough hiring idea in a founder's head does not qualify.

An owner must control the change, not merely attend the meeting

The owner is accountable for moving an item from approved to proven. That person does not need to perform every task, but they must have authority to make the decision, obtain support, and explain slippage.

Do not assign savings work to finance by default. Finance can validate the baseline and actual outcome, but finance cannot remove an unused development environment, decide whether a support tool is redundant, or redesign a deployment workflow. Assign the owner where the operational control lives.

Use a simple responsibility model:

One name in the owner column. If two executives jointly own an item, nobody owns the next action. You can list collaborators in the notes, but the register needs one person who feels the deadline.

Implementation effort should measure the work needed to reach proof, not the amount of thought behind the finding. Use Low, Medium, or High if you want the register readable. Define them in operational terms. Low means a reversible administrative action that one person can complete quickly. Medium needs coordinated work, testing, or a vendor conversation. High changes production architecture, customer workflows, security boundaries, contracts, or staffing.

Risk is different from effort. Cancelling ten unused seats is low effort and low risk. Ending a customer-support platform can be straightforward from a technical standpoint but high risk because a poor migration affects customers. Reducing an autoscaling floor may take minutes to configure and still be high risk if it can cause an outage during a traffic spike.

This distinction catches a frequent management error: treating a low-effort change as an automatic change. Some of the most damaging production incidents begin with a small setting adjustment that nobody bothered to test because it looked easy.

Risk belongs beside the saving, not in a separate review

A saving that damages revenue, security, compliance, or delivery speed can cost more than it returns. The register should make that trade explicit before the owner ships the change.

Use the risk field with a short failure statement. Do not write "medium risk" and leave it there. Write what fails, who notices, and what limits the blast radius.

Atlassian's change-management guidance frames change control around context, transparency, and risk mitigation rather than a ritual approval board. That is the useful part. A two-person company does not need a ceremonial committee, but it does need a record of what can fail and who can reverse the change.

For each medium- or high-risk row, add four sentences in the notes:

1. The failure mode: "Reducing worker capacity may delay customer exports."
2. The guardrail: "Keep queue depth below the existing alert threshold for seven days."
3. The rollback condition: "Restore prior capacity if queue age exceeds the agreed limit."
4. The decision owner: "Platform Lead can restore capacity without waiting for a meeting."

That is enough for most startups. A long risk register that nobody reads does not protect production. A short operational plan that an engineer can execute at 2 a.m. does.

Avoid the opposite mistake too. Some leaders reject every item that has any risk and keep paying for inactive infrastructure, redundant products, and manual work. The register lets you compare the saving with a stated risk and mitigation plan. It does not pretend the risk is absent.

Proof dates stop forecasts from lingering forever

A proof date is the first date on which reliable evidence should show whether the expected saving happened. It is not the day someone clicks "cancel," and it is not a vague target such as "Q4."

Set proof dates from the billing and payroll cycle backward. If a SaaS vendor invoices on the first day of the month, a seat reduction submitted on August 18 may not show until the September invoice. If a contractor ends on August 31, finance may not see the final payroll effect until the September close. Record that timing rather than pretending the saving appeared the day the decision was made.

The proof source must be named before implementation. Good sources include:

• a vendor invoice and seat export
• a cloud billing export matched with the usage driver
• payroll reports or contractor invoices
• a signed contract amendment
• an accounts-payable report showing the recurring charge ended

Do not accept a screenshot from an admin console as final proof of financial savings. It can prove that someone changed a setting or removed a user. It does not prove the company paid less. Pair operational evidence with financial evidence when the change affects a bill later.

A row should move through a small set of statuses: Proposed, Approved, In progress, Implemented awaiting proof, Verified, Rejected, or Closed with no saving. The last status is important. It tells the truth about an initiative that ran into a contract restriction, technical constraint, or bad assumption.

Do not delete failed rows. Deletion converts a useful learning record into a clean-looking fiction. Keep the original expected saving, add actual saving of zero where appropriate, explain why it failed, and close it. Over time, these rows reveal whether the company overestimates vendor flexibility, underestimates migration work, or repeatedly mistakes capacity for cash.

Actual saving must survive a hostile review

When the proof date arrives, the owner updates actual saving, evidence source, and notes. A finance reviewer should be able to challenge the row without reconstructing the entire audit.

Use this review sequence:

1. Confirm that the baseline refers to the same scope as the current cost. A lower bill does not count if the workload simply moved into another account or vendor.
2. Confirm that the change caused the reduction. If spend fell because a customer churned or a project paused, do not credit the initiative.
3. Adjust for the usage driver where necessary. Compare cost per job, transaction, active user, or environment when raw spend is distorted by volume.
4. Confirm that the reduction is recurring. A one-time credit, refund, or delayed invoice is not monthly saving.
5. Set the actual saving and lock the calculation. If the benefit later reverses, open a new row or mark the saving as reversed rather than quietly editing history.

Consider a familiar failure. An audit finds a $12,000 monthly cloud bill and recommends turning off idle environments. The owner shuts down three environments, and the next bill falls to $8,000. The register records $4,000 in savings. Then someone discovers that a major test workload finished during the same period, cutting normal usage by $2,500. The real result may be closer to $1,500, and only if the environments remain off when the workload returns.

That does not mean the initiative failed. It means the team needs better proof. Compare tagged environment spend, hours running, and workload volume. If the cloud account lacks tags, record that limitation and make cost allocation its own item. Never use missing data as permission to report the most flattering number.

This is where an audit often earns back its cost. A Team & AI Audit should leave the company with a register that separates verified run-rate reductions from plausible estimates, instead of a single headline total nobody can defend six months later.

The monthly meeting should decide, unblock, and verify

Run the register review monthly with the owner, finance reviewer, and whoever can remove cross-team blockers. Thirty minutes is enough for a small company if the owners update their rows beforehand. If the meeting takes two hours, the register has become a reporting exercise rather than a decision tool.

Review items in this order: those awaiting a decision, items past their implementation date, items past their proof date, then verified results. Do not start with the grand total. Start with the rows that need a person to make a call.

Ask the same questions every month:

• What action must happen before the next review?
• Is the owner still the person with control over that action?
• Did an assumption change the expected saving, effort, or risk?
• What evidence will prove the outcome, and who will retrieve it?
• Should the item be closed because the saving is unavailable or not worth the risk?

Publish three totals, never one blended number: expected monthly saving from approved items, verified monthly saving, and cost avoidance or capacity released. Founders need the full picture, but mixing those numbers creates false confidence and makes finance distrust the entire program.

The register should also expose the cost of waiting. An approved $3,000 monthly cancellation that slips for two months has a visible $6,000 delay cost. Do not call that a penalty or invent a complicated interest calculation. Just show the missed run-rate reduction. It makes stalled decisions concrete.

There is no prize for having the longest register. Close low-value rows that require too much political or technical effort. Keep the focus on changes that can reduce recurring spend, protect delivery capacity, or prevent an expensive hire or contract from becoming unavoidable. The monthly discipline is what turns a good audit into lower payroll and lower operating cost, one verified row at a time.