Budget Variance Explainer

Purpose

Make budget data understandable for non-finance managers so they can act on it.

When to use

• a team lead receives budget vs actual numbers and needs to understand them
• a department manager needs to explain their cost center to leadership
• monthly or quarterly financial reviews for non-finance stakeholders
• translating finance team output into operational language

When not to use

• technical accounting analysis or journal entries
• external audit preparation or regulatory reporting
• when the variance requires forensic investigation

Inputs

• budget vs actual data (table, spreadsheet extract, or raw numbers)
• time period (month, quarter, YTD)
• any known context (e.g. "we hired 2 extra people" or "project X was delayed")
• audience (team lead, VP, non-finance manager)

Procedure

1. Identify the top 3–5 variances by absolute dollar impact.
2. Classify each: favorable or unfavorable.
3. Explain WHY each variance happened in one sentence (driver).
4. Determine if the variance is one-time or recurring.
5. Suggest what action to take for each significant variance.
6. Write a 2-sentence headline summary suitable for an exec email.
7. Produce an action table: driver → impact → owner → action.

Output

• headline summary (2 sentences)
• variance explanation table (line item, variance, driver, one-time/recurring, action)
• recommended talking points for presenting to leadership

Definition of done

• every variance > 5% is explained
• explanations use business language, not accounting jargon
• each significant variance has an owner and recommended action
• a non-finance person can understand the summary without follow-up questions

Examples

• "Explain why our department is $30K over budget this month in plain English."
• "Turn this spreadsheet into talking points for the VP meeting."
• "Our travel spend is 40% over plan — write an explanation and recommended action."

Quality Criteria

• Data sources and assumptions are explicitly stated
• Calculations are reproducible from provided inputs
• Visualizations or tables have clear labels, units, and time ranges
• Caveats and confidence levels are documented for estimates

Verification (4C)

Check	Question
Correctness	Are formulas, aggregations, and statistical methods applied correctly?
Completeness	Does the analysis cover all requested metrics and time ranges?
Context-fit	Are the chosen metrics relevant to the business question being answered?
Consequence	If this data were used for a decision today, what blind spots remain?

Edge Cases

• Missing or incomplete data — Document gaps and their potential impact on conclusions. Provide ranges instead of point estimates.
• Outliers skewing results — Report with and without outliers. Document the decision to include or exclude.
• Changing data definitions mid-period — Split analysis at the change boundary and note the schema difference.

Changelog

• v1.0.0 — Initial release