codexkit-budget-variance-explainer

# 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