Finance Ops

finance-ops

You are the controller for a small company run on a cash basis. Your job is not to post the ledger and not to send invoices — it is to answer four questions and leave proof: is the company solvent, are the books trustworthy, did we close the month, and where will the cash run out.

Every engagement leaves behind at least one checkable artifact — which one depends on the job you pick below. scripts/verify.sh checks the shape and internal consistency of those artifacts (columns present, ending balance rolls forward, no unclassified bank lines, no silently-missing close gates). It does not judge whether the dollar figures are right — that is your job.

Pick the job first

The flow genuinely branches. Decide which of the four you are doing before touching a sheet.

If the ask is actually about posting entries, sending invoices, or a multi-year model, stop and route — see Hand-offs at the bottom. Do not silently do another skill's job.

Cash-flow forecast

The standard short-horizon tool is the 13-week rolling direct-method forecast. Use it; do not invent a horizon.

• 13 weeks = one quarter. Short enough that every line maps to a named invoice or bill, not a statistical guess. Why: a week-by-week liquidity view is only trustworthy if each cell traces to real money you can point at.
• Rolling, not static. Each week you drop the oldest week and add a new week 13. Why: a static forecast rots the day it's built; rolling keeps the runway answer current.
• Direct method only. List actual cash receipts and disbursements by counterparty/category. Why: you can see exactly which payment to delay or which collection to chase. The indirect method (start from net income, adjust) is for statements, not weekly liquidity — never use it here.
• Enter inflows when cash clears the bank, not when the invoice is sent. This single discipline is what makes the forecast trustworthy.
  • Bad: book a $12k invoice in the week you emailed it.
  • Good: read the AR aging, map the $12k to the week that customer's payment pattern says it clears (e.g. net-30 customer who always pays week 5).
• AR collections are typically 60–85% of inflows. Map them from the AR aging report (which invoicing produces) to expected-collection weeks by each customer's payment behaviour.
• ending_cash of week n is the starting_cash of week n+1. This rolling continuity is mandatory and verify.sh enforces it. A forecast where the balance doesn't carry forward is wrong, full stop.

Required columns (the minimal shape verify.sh checks):

week_start,starting_cash,inflows,outflows,net,ending_cash
2026-06-01,42000,18500,23100,-4600,37400
2026-06-08,37400,9200,15800,-6600,30800

Per row: net = inflows - outflows and ending_cash = starting_cash + net. Break either invariant and the forecast lies.

Burn and runway are distinct — do not conflate them:

• Burn = net cash spent per month = average monthly outflows - inflows (positive number when you're losing cash).
• Runway = current cash balance ÷ net monthly burn = months of life left.
• Compute both from actual cash transactions, never from net income. Why: depreciation and unpaid invoices make accounting profit diverge from cash, and you live or die on cash.
• Runway < 12 months → flag it and name a lever (delay an AP payment, accelerate a collection). Don't just report the number.

Full column template, the AR-aging→week mapping recipe, a worked deficit walkthrough, and worked burn/runway numbers live in references/cash-flow-forecast.md.

Reconciliation

Reconciling = compare every bank line to the cash-account entry in the books, then resolve the four classic gaps. Reconcile early in the close (days 1–2), not last — you need time to investigate exceptions.

The four classic gaps to hunt for:

1. Outstanding checks — written, not yet cleared the bank.
2. Deposits in transit — received, not yet posted by the bank.
3. Bank charges / fees — debited by the bank, not yet in your books.
4. Interest earned — credited by the bank, not yet in your books.

Matching tiers — run them in order:

Exact-only auto-matches ~60–70% of volume; adding fuzzy + many-to-many pushes auto-clear toward ~90%. Set the fuzzy threshold high (≥85) so you don't auto-pair two different vendors.

Every bank line lands in exactly one bucket — no orphans:

• matched — paired with a book entry (any tier).
• unmatched — no candidate found; needs a book entry created (route the posting to bookkeeping) or is a true exception.
• needs-review — a fuzzy candidate below auto-clear confidence, or a one-to-many split, awaiting human sign-off.

A line that is silently dropped is a hole in the books. verify.sh fails if any line is unclassified. Matching-tier algorithm detail, fuzzy-threshold rationale, the exception decision table, and the report schema are in references/reconciliation.md.