Submission Reviewer

---
name: submission-reviewer
description: >-
  Reviews one department's budget submission the moment it comes back —
  against their own trailing actuals, their guardrail, and their peer
  departments. Flags padding and gaps, tells you which lines to push back
  on and why, and drafts the reply to the owner. Use whenever a budget
  owner has sent their numbers in and finance needs to decide whether to
  accept, question, or send it back. Triggers include "review this
  submission", "did marketing pad this", "check this budget request
  against last year", "what should I push back on", "is this submission
  reasonable", "review the numbers engineering sent", or uploading a
  department's budget submission mid-collection.
metadata:
  author: "Aleph - getaleph.com"
  version: "1.0.0"
---

# Submission Reviewer

## What this skill does

Budget submissions come back over three weeks, in different shapes, and the
padded ones look exactly like the honest ones until somebody compares them to
history. Most teams don't catch a padded line until consolidation — at which
point questioning it is a renegotiation rather than a two-minute question.

This skill reviews **one submission at a time, on arrival**. It compares what
the owner sent to what they actually spent, checks it against their guardrail
and their peers, and returns a verdict plus the specific lines worth
challenging — with the reason attached to each one.

The discipline that makes it work: **a line is only questionable if you can
say why.** "This feels high" is not a finding. "This grew 58% against trailing
actuals with no assumption attached, and the guardrail is $45K" is.

## When to use it

- A department has submitted and you want to review it before consolidating
- You suspect padding but need something defensible to point at
- You want a consistent standard applied across every department, not just
  the ones you have time to scrutinise
- A resubmission comes back and you need to check what actually changed

## Inputs

**Required**
- **The submission** — one department's requested FY budget by line item
  (`.xlsx`, `.csv`, or pasted).

**Strongly recommended**
- **That department's trailing actuals**, ideally twelve months by line. Without
  history the rubric can only test two of its four parts — say so explicitly
  rather than implying a full review.
- **The department's guardrail**, and any line-level caps.

**Optional, improves output**
- Peer departments' submissions, for the consistency test
- The owner's stated assumptions, if they came separately
- Last cycle's submission from the same owner, to see whether they habitually pad

## Workflow

0. **Validate the input.** Confirm this is a *submission* — a forward-looking
   request from one department. If you've been handed a finished company budget
   for board review, stop: that's `/budget-pressure-tester`. If you've been
   handed actuals and asked to create a request, that's `/owner-packet-builder`.

1. **Align to history.** Match every submitted line to its equivalent in
   trailing actuals. Handle renames. List anything you could not match rather
   than silently dropping it.

2. **Apply the four-part rubric** in `references/review-rubric.md` to every
   line: grounded in history / supported by a stated assumption / within
   guardrail / consistent with peers. Record which tests each line passed and
   failed.

3. **Flag padding.** Lines that grew materially against trailing actuals with
   no assumption attached. Materiality thresholds are in the rubric.

4. **Flag gaps.** Costs that exist in the trailing actuals and have vanished
   from the submission with no note. These are as expensive as padding and
   almost nobody looks for them.

5. **Reach a verdict** — accept, accept with questions, or send back. The
   thresholds are defined in the rubric; apply them rather than improvising.

6. **Write the output** in exactly the format in
   `references/output-template.md`, then draft the reply using
   `references/reply-templates.md`.

## Hard rules

- **Every challenge carries a reason and a number.** If you cannot state what
  the line was, what it is now, and which test it failed, it does not go on the
  list.
- **Never infer an assumption the owner did not state.** A plausible reason you
  invented is worse than a flagged gap, because it closes an open question that
  should stay open.
- **Growth is not padding.** A line that grew with a stated, checkable
  assumption passes. The flag is for growth *without* explanation.
- **Look for what is missing, not just what is inflated.** Under-requesting is
  a real failure mode — it surfaces as an emergency in Q2.
- **One submission at a time.** Do not consolidate, roll up, or compare totals
  across departments beyond the peer-consistency test.
- **Write the reply for a non-finance reader.** The recipient runs marketing or
  engineering, not FP&A.
- **Stay inside the data.** If the trailing actuals were not provided, say which
  parts of the rubric you could not run.

## Output format

Every run produces four things, in this order:

1. **The verdict** — accept / accept with questions / send back, with the
   one-line reason
2. **The challenge list** — every line worth questioning, with prior, requested,
   delta, the test it failed, and the question to ask
3. **The full line-by-line table**, every line tagged with its rubric result
4. **The draft reply** to the owner

## A note on scope

This skill reviews one submission and stops. It does not consolidate, does not
track versions across rounds, and does not maintain the plan of record — the
moment you are comparing many versions over time rather than judging one
arrival, you want `/budget-change-digest`, and the ongoing orchestration
belongs in a connected FP&A platform like Aleph.

Keep this skill focused on the judgement call at the moment a submission lands.

# The Four-Part Rubric

Every submitted line is tested against four questions. Record a pass, a fail,
or `n/a` (with the reason) for each. A line only appears on the challenge list
if it fails at least one test **and** you can state which.

| Test | Question | Fails when |
|---|---|---|
| **1. Grounded in history** | Does this line track what they actually spent? | Grew or shrank materially against trailing actuals |
| **2. Supported by an assumption** | Did the owner say *why*? | The change has no stated driver |
| **3. Within guardrail** | Does it fit the number they were given? | Department total or a capped line is over |
| **4. Consistent with peers** | Does it behave like the same line elsewhere? | An outlier against comparable departments |

Tests 1 and 2 are the workhorses. A line that fails **both** is the definition
of padding: it moved, and nobody said why.

---

## Materiality

Do not flag noise. A line is material if it clears **either** bar:

- **Relative:** moved more than **15%** against trailing actuals
- **Absolute:** moved more than **2%** of the department's total request

Below both, carry it forward without comment unless it fails test 3 (a
guardrail breach is material at any size, because it is a breach of an
agreement rather than a variance).

Cap the challenge list at **eight lines**. If more than eight qualify, the
submission is a send-back and the list becomes the reason. State the cap
whenever you apply it.

---

## Padding — grew with no explanation

The signature: **test 1 fail + test 2 fail**, in the upward direction.

Detection:
- Line grew past the materiality bar against trailing actuals
- No assumption, driver, or note attached
- Especially where the same owner's other lines *do* carry assumptions — the
  selective absence of a reason is itself a signal

Treat these as questions, not accusations. The owner may have a perfectly good
reason they simply did not write down; the ask is for the reason, not a cut.

> Events & sponsorships — $38K last year, $60K requested, +58%, no assumption
> attached, and $15K above the $45K cap. What does the extra buy?

## Gaps — costs that quietly vanished

The mirror image, and the one most reviews miss.

Detection:
- A line present in trailing actuals with **no** corresponding submitted line
- No note explaining the removal
- **Exclude genuine one-time costs** — a migration or severance line that
  correctly does not repeat is the process working. Check the one-time
  vocabulary before flagging: implementation, migration, severance,
  settlement, rebrand, rollout, transition.

An unexplained gap is a cost that will reappear in Q2 as an emergency.

> Content & production — $96K last year, absent from the submission, with no
> note. Was this cut deliberately, or has it moved somewhere else?

## Peer inconsistency

Only run this test when you have comparable submissions. Compare the same line
across departments as a **percentage of departmental total**, never in absolute
dollars — a $340K tools line is normal for a 28-person sales team and absurd
for a 5-person one.

Flag when a line sits more than **2×** the peer median share. Say which
departments you compared against; an unstated comparison set is not a finding.

---

## Verdicts

Apply these thresholds. Do not improvise a fourth category.

**Accept** — nothing material fails, or the only failures are gaps the owner
already explained. The submission goes into consolidation as-is.

**Accept with questions** — the total is within guardrail and the failures are
individually answerable. You consolidate now and resolve the questions in
parallel. This is the most common verdict and should be.

**Send back** — any of:
- Department total is over guardrail by **more than 5%** with no stated plan to
  close it
- More than eight material lines fail
- A single unexplained line exceeds 10% of the department's total request
- The submission has no assumptions attached anywhere

The 5% qualifier matters. A submission landing 1–2% over guardrail is a
conversation, not a rejection — and it is frequently closed by the answer to a
single question on the challenge list. Sending it back costs the owner a cycle
and costs you the goodwill you will need in November. Over guardrail is only
structural when the number is too far out for questions to close it.

Send-back is expensive — it costs the owner a cycle and costs you goodwill.
Use it when the submission genuinely cannot be consolidated, not when it is
merely annoying.

---

## What this rubric will not tell you

It tests whether a number is **explained**, not whether it is **right**.
A well-documented assumption can still be optimistic — sales forecasting 40%
pipeline growth on flat headcount will pass every test here, because it is
grounded, stated, within guardrail and consistent with peers.

Catching that takes someone who remembers what they forecast last year. Say so
in the output rather than implying the rubric caught everything.

# Output Format

Produce these four blocks, in this order, every run.

---

## 1. The verdict

```
{Department} · FY{YY} submission · reviewed {date}

VERDICT: {ACCEPT / ACCEPT WITH QUESTIONS / SEND BACK}

Requested        ${total}
Guardrail        ${guardrail}        {over/under} by ${gap}
Trailing actual  ${prior}            {+/-}{pct}% year over year

{One sentence: the single reason for the verdict.}
```

If the trailing actuals were not supplied, add immediately beneath:

```
⚠ Reviewed without trailing actuals — tests 1 and 4 could not be run.
```

If no guardrail was supplied, write `not provided` on the guardrail line — test 3
then covers only the line-level caps you were given, and the verdict's
over-guardrail trigger cannot fire.

---

## 2. The challenge list

The heart of the output. Ordered by dollar impact, capped at eight.

| # | Line | Last year | Requested | Δ | Failed | The question to ask |
|---|---|---|---|---|---|---|
| 1 | {line} | ${x} | ${y} | {+n%} | {tests} | {one sentence, in the owner's language} |

Rules:
- Every row names the failed test(s) explicitly
- The question is written to be forwarded verbatim, not paraphrased
- Padding and gaps are interleaved by materiality, not grouped — the biggest
  number matters more than its category

If the list is empty, say so plainly: *"Nothing material failed. Consolidate
as submitted."*

---

## 3. The full line table

Every submitted line, so the owner can see the review was even-handed rather
than a hunt.

| Line | Last year | Requested | Δ | History | Assumption | Guardrail | Peers | Result |
|---|---|---|---|---|---|---|---|---|
| {line} | ${x} | ${y} | {+n%} | ✓/✗ | ✓/✗ | ✓/✗ | ✓/–  | PASS / QUESTION / GAP |

Use `–` for tests not run, never a blank cell, and never a ✓ you did not earn.

Below the table:
- **Materiality thresholds used**, so the run is reproducible
- **Unmatched lines** — anything in the submission with no history equivalent,
  or vice versa
- **One-time costs correctly excluded** — list them, so their absence reads as
  deliberate rather than missed

---

## 4. The draft reply

Per `references/reply-templates.md`. Always produced, even on an accept — the
owner should hear that it landed cleanly.

# Replies to the Owner

The review is for finance. This is what the owner actually reads, so it decides
whether the next submission comes back better or later.

Two rules that outrank the templates:

1. **Lead with what you accepted.** An owner who opens with a list of
   challenges reads the whole message defensively.
2. **Ask, never assert.** "What does the extra buy?" gets an answer. "This looks
   padded" gets an argument.

---

## Accept

```
{First name} — {department}'s numbers are in and they look good. Everything
lines up against last year, and you're ${gap} {under/at} guardrail.

Nothing needed from you. I'll fold this into the consolidated plan this week.
```

## Accept with questions

The default, and the one to get right.

```
{First name} — thanks, {department} is in. Most of it I can consolidate as-is:
{one clause naming the biggest lines that passed}.

{N} things I want to understand before this goes into the roll-up:

1. {Line} — ${prior} last year, ${requested} this year. {The question.}
2. {Line} — {the question.}

{If there's a gap:} Also, {line} was ${amount} last year and isn't in here at
all — deliberate, or has it moved?

No need to resubmit. Reply here and I'll adjust on my side. I'm consolidating
{date}.
```

The closing line matters: **"no need to resubmit"** is what keeps this a
two-minute exchange rather than a fortnight.

## Send back

```
{First name} — I can't consolidate {department} as it stands, and I'd rather
tell you now than in November.

{The single structural reason — over guardrail, or no assumptions anywhere.}

What I need:
- {Specific, ordered, no more than three}

Happy to walk through it live if that's faster — {offer}. Deadline is {date}.
```

Never send a send-back without offering a conversation. A written rejection
with no human attached is how a budget cycle turns adversarial.

---

## Tone rules

- **First name, second person, contractions.** These are colleagues.
- **No finance vocabulary** — not "variance to guardrail," not "unsupported
  delta," not "materiality." Say "more than last year" and "you didn't say why."
- **Never imply bad faith.** The most common cause of an unexplained line is
  that nobody asked for the explanation.
- **Name the deadline and what happens at it.** "I'm consolidating Friday" is a
  reason to reply. "Soon" is not.
- **Keep it under 150 words** unless it's a send-back.

WHAT THIS FILE IS
=================
submission-reviewer.skill — Reviews one department's budget submission the
moment it lands, against their own history, their guardrail, and their peers.

A .skill file is Anthropic's packaging format for Claude Skills. It is a
standard ZIP archive, nothing more. This build is intentionally uncompressed
so the contents stay human-readable in a text editor.

LOOK INSIDE YOURSELF
====================
Rename the file from .skill to .zip and extract it, or run:  unzip submission-reviewer.skill
Every file inside is plain-text markdown. There is no executable code.

WHAT'S INSIDE
=============
  SKILL.md
  references/review-rubric.md
  references/output-template.md
  references/reply-templates.md
  README.txt (this file)

WHAT IT DOES
============
Submissions come back over three weeks in different shapes, and a padded line
looks exactly like an honest one until somebody compares it to history. Most
teams don't catch it until consolidation, when questioning it is a
renegotiation instead of a two-minute question.

This skill reviews one submission on arrival: what they sent against what they
actually spent, checked against their guardrail and their peers. It returns a
verdict, the specific lines worth challenging with the reason attached, and a
ready-to-send reply.

WHAT YOU GIVE IT
================
  Required:     one department's budget submission (.xlsx, .csv, or pasted)
  Recommended:  that department's trailing twelve months of actuals
                their guardrail, and any line-level caps
  Optional:     peer submissions, the owner's stated assumptions

WHAT YOU GET BACK
=================
  A verdict: accept, accept with questions, or send back
  The lines to challenge, each with prior, requested, delta and failed test
  The full line table, every line tagged
  A ready-to-send reply written for a non-finance reader

HOW TO USE IT
=============
Upload this file as-is to Claude: Settings -> Skills -> Add.
Or add it in Claude Cowork or Claude Code.

Sits between /owner-packet-builder (which creates the ask) and
/budget-change-digest (which tracks versions over time). Distinct from
/budget-pressure-tester, which reviews a finished budget for board-readiness.

From Aleph (getaleph.com), the FP&A platform.
The full guide: https://www.getaleph.com/claude-skills-library
Questions: marketing@getaleph.com