Financial Model QA

Financial Model QA

What this does

Audits a spreadsheet financial model for formula errors and logic defects, and re-checks scenario outputs after inputs change. It produces a ranked list of issues, each pinned to an exact sheet and cell. It flags problems for you to review. It does not fix anything and never writes to the workbook. Think of it as a careful reviewer that points at every suspect cell and explains what looks wrong, leaving every change to you.

When to use it

• Before you share a model with anyone, or before a number from it drives a decision.
• After you edit inputs, assumptions, or structure and want to confirm the scenarios still flow through correctly.
• When you inherit a model you did not build and need a map of where it is fragile.

Inputs — how to give it the data

• Default: hand over the model workbook directly — drag in the file, attach it, or paste a path. A spreadsheet (.xlsx and similar) is the expected input.
• Optional prior version: include the previous version of the same model and the skill will diff the two, so you see what changed and whether the change behaved.
• Multiple files / linked workbooks: if the model pulls from other files, say so and provide them. If a referenced file is missing, the skill flags the broken external link by cell rather than guessing what it pointed to.
• Lossy or partial exports: if the file is a flattened export with formulas stripped to values, the skill can only check the values, not the formula logic — it will say so up front rather than pretend it audited formulas.
• Connectors are a convenience, not a requirement. The file in hand is enough.

Steps

1. Scan every sheet for formula errors: #REF!, #DIV/0!, #VALUE!, #N/A and similar, broken or dangling references, and hardcoded values sitting where a formula belongs (a number typed over a formula that the rest of the column computes).
2. Check scenario logic: scenarios should share one structure, so a change in a shared driver should flow through every scenario the same way. Find places where one scenario diverges because a formula was overwritten or a link was broken.
3. Re-run the scenarios after input changes and compare each output to what the structure says it should be. Note any output that does not move the way the inputs imply.
4. Rank the issues by severity (a #REF! feeding a headline number outranks a cosmetic one) and list each with its sheet, its cell, the severity, and what is wrong.

Rules (confirm in the plan)

Fill these in before the first run. They are the judgment calls only the modeler can make. Surface them in plan mode and confirm them; do not assume defaults.

• What counts as an error vs an intentional hardcode:
• The scenarios in this model, and the inputs that drive them:

Output

A ranked issue list. For each issue: the sheet, the exact cell, a severity, and a one-line description of what is wrong. Where a prior version was supplied, a short "what changed" note sits alongside the new issues. Nothing in the output is a change to the model — it is a list for you to act on.

Error handling

• Cite the exact sheet and cell for every issue. An issue with no sheet+cell citation is not reportable — find the location or do not report it.
• Never fix anything. Do not edit the workbook, do not rewrite a cell, do not "correct" a value. Work on a copy and never touch the original file. Flag it for the modeler and let the modeler decide.
• Re-running scenarios assumes the installing harness provides a spreadsheet calculation engine. The skill relies on whatever engine the host exposes; it does not require or name a specific one.
• Hardcodes when no operator rules are declared: when the Rules block declares no hardcode/formula rules, a suspected hardcode (a literal value sitting where a formula is expected, or a value overwriting a formula) is flagged "confirm — intentional input?", citing its sheet and cell. Do not report it as an error, and do not silently drop it. When the operator HAS declared hardcode/formula rules, apply those rules instead. This avoids both over-flagging intentional assumption cells and silently missing overwritten formulas.
• If the host can only read rendered values, not formula text, say so up front and run a values-only pass. In that mode the formula-vs-hardcode and broken-reference checks are degraded and must be labeled as such; never present a values-only pass as a complete formula audit.
• Treat the pass like a smart intern's: roughly right, not infallible. The modeler reviews every flagged cell before acting. The decision to change the model stays human.

Eval contract

• Spec: Given a model workbook, produce a ranked issue list where every issue cites its exact sheet and cell, real defects (error values, hardcodes over formulas, broken scenario flow) are surfaced, ambiguous hardcodes are flagged for confirmation rather than judged, and the model file is never modified.
• Rubric (hard-fail gates in bold):
  1. Every reported issue cites its exact sheet and cell; an issue with no sheet+cell citation is an automatic fail.
  2. The model is never edited — no write-back, no auto-fix, no silent correction; any change to the workbook is an automatic fail.
  3. Issues are ranked by severity, with errors feeding headline outputs ranked above cosmetic ones.
  4. A hardcode whose status is unclear (and not settled by the operator's rules) is flagged "confirm — intentional?", not reported as a confirmed error and not dropped.
  5. Findings are flagged for the modeler to review; the skill proposes, the human disposes.
  6. An issue on a hidden sheet or behind a broken external link / linked workbook is surfaced with its sheet+cell, not skipped; silently dropping a hidden-sheet or external-link defect is an automatic fail.
  7. If the host can read only rendered values (not formula text), the run is labeled a degraded values-only pass and does not claim a full formula audit.
• Self-test:
  • Input: a synthetic two-sheet model where Calc!B7 shows #REF! and Calc!C12 has the number 45000 typed over the formula the rest of column C computes. Output MUST surface both, each citing its sheet and cell (Calc!B7, Calc!C12). Output MUST NOT modify the file or "repair" either cell.
  • Input: a synthetic model where Inputs!D4 is a hardcoded tax rate. Output MUST, when the operator's hardcode/formula rules mark it an intentional assumption, omit it as an error; and when no such rules are declared, flag it "confirm — intentional input?" citing its sheet and cell (Inputs!D4). Output MUST NOT report it as a formula error or silently change it.
  • Input: a synthetic model whose visible Summary sheet looks clean, but a hidden sheet _Hidden carries a #REF! at _Hidden!B3, and a cell Summary!E10 points to a broken external link / missing linked workbook. Output MUST surface both, each citing its sheet and cell (_Hidden!B3, Summary!E10), including the issue on the hidden sheet. Output MUST NOT skip an issue just because it lives on a hidden sheet or behind an external link, and MUST NOT modify the file.
• Version: 1.0.0

Learn more: https://skillsandagents.co/skills/financial-model-qa/