codexkit-finance-variance-story

Analyze budget-versus-actual or forecast-versus-actual performance and turn finance data into a management-ready narrative using variance logic, drivers, cash impact, and forward actions. Use when fin

SKILL.md

GitHub

Finance Variance Story

Purpose

Convert raw financial movements into an explanation that managers can act on.

When to use

  • Actual results differ materially from budget or forecast.
  • A monthly business review needs finance commentary.
  • Leadership wants the story behind revenue, margin, cash, or cost movement.

When not to use

  • The request is for journal entries or bookkeeping.
  • Formal statutory accounting treatment is the main question.

Inputs

  • actuals, budget, forecast, or prior-period data
  • key business drivers and assumptions
  • notable one-offs, mix effects, or timing issues
  • audience: board, exec, functional leader, or finance team

Procedure

  1. Separate size, timing, volume, price, mix, and controllability effects where possible.
  2. Identify the 3-5 drivers that actually explain most of the movement.
  3. Connect the variance to cash, margin, runway, or operational implications.
  4. Distinguish structural change from one-off noise.
  5. Recommend actions, owners, and forecast implications.
  6. Flag missing data and confidence limits.

Output

  • executive summary of the variance story
  • driver table with impact and explanation
  • cash and margin implications
  • forward-looking actions and watchpoints
  • short management commentary in plain language

Definition of done

  • A non-finance leader can understand the business story.
  • The explanation distinguishes causes from symptoms.
  • Recommended actions follow from the analysis.

Examples

  • "Explain why gross margin missed plan this quarter and what actions we should take."
  • "Turn these budget versus actual numbers into management commentary for the board pack."

Quality Criteria

  • All claims reference specific frameworks, standards, or quantifiable data
  • Content matches the stated audience's expertise level
  • Recommendations are actionable — each includes a concrete next step
  • No unsupported assertions or generic filler language

Verification (4C)

Check Question
Correctness Do referenced frameworks and standards match their official definitions?
Completeness Are all key concepts covered without significant gaps for the stated audience?
Context-fit Would this be useful for someone new to this domain, or is it too advanced/too basic?
Consequence If a stakeholder acted on this immediately, what could they misinterpret?

Edge Cases

  • Conflicting frameworks — State which framework takes precedence and why. Document the trade-off explicitly.
  • Rapidly changing domain — Note information currency date. Flag sections likely to need updates.
  • Audience has mixed expertise levels — Provide a glossary and mark advanced sections as optional.

Changelog

  • v1.0.0 — Initial release