/cash-flow-snapshot

name: cash-flow-snapshot
description: >
  Reads AR/AP, historical cash timing, and known fixed costs from the ledger
  (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books) or from PayPal, Square, or Stripe — or
  a CSV upload — and produces a 30/60/90-day cash flow forecast with
  percentage-variance confidence bands and named risk flags. Delivers a chat
  summary and a downloadable XLSX. Use when the user asks "forecast my cash
  flow," "will I make payroll," mentions "runway," or says "cash crunch."
  Falls back to CSV upload when no connector is live.
compatibility: "Requires one or more of: a ledger MCP (MYOB, NetSuite, QuickBooks, Xero, Zoho Books), PayPal MCP, Shopify MCP, Square MCP, Stripe MCP, file upload (CSV fallback). Output uses xlsx skill."
allowed-tools: Read, WebFetch

Cash Flow Snapshot

Produces a 30/60/90-day cash flow forecast with percentage-variance confidence bands and named risk flags. Delivers a two-part output: a concise chat summary and a downloadable XLSX workbook.

**Quick start**

> "Will I make payroll next month?"

Claude pulls the current bank balance, AR/AP, and fixed costs from connected sources, calculates expected inflows and outflows across 30, 60, and 90-day windows, applies confidence bands from each customer's payment variance, and flags specific risks by name.

---

Workflow

Step 1 — Identify available data sources

Check which connectors are live. Pull from every one that is, in one batch:

1. The ledger — MYOB, NetSuite, QuickBooks, Xero, or Zoho Books, whichever is connected — for AR aging, AP, fixed costs, and the cash balance. Ledgers are peers (`../../shared/connector-neutrality.md`); if two are connected, ask which is the source of record and take totals from that one only 2. PayPal — transaction history and settlement timing 3. Square — sales and payout history 4. Stripe — charge and payout history 5. Shopify — orders (`list-orders`) as the inflow, plus payout timing. Shopify on its own is enough to run: for a commerce business it is often the largest inflow. The payout read may fail because the connector's scopes exclude Shopify Payments — then ask the owner for their payout schedule and model from that; never infer a lag (`reference/v2_sources.md`) 6. CSV upload — when no connector is connected

If no connector is live and no file is attached, ask the user to either connect a source or upload a CSV (income/expense tabular data, any reasonable format). Note which sources were used in the output — this affects confidence band width.

**Always establish the starting cash balance** — "will I make payroll" is a question about the balance, not the net. Pull it in Step 2, or ask: "What's in the business account right now, and as of what date?" **Never assume one.** If nobody knows, head the output "no opening balance — net change only" and drop cash-on-hand from the risk flags.

Step 2 — Pull the data

**From the ledger:**

• Balance sheet: bank and cash balances with the as-of date — the opening balance

(MYOB holds none; see `reference/v2_sources.md`)

• AR aging report: customer name, invoice amount, invoice date, due date, days outstanding
• AP: vendor name, amount due, due date
• Recurring fixed costs: rent, payroll, subscriptions (look for recurring transactions)

**From Gusto, when connected:**

• The next payroll run's date and expected amount, and the regular pay-schedule

cadence — the real numbers for the biggest fixed cost, instead of inferring payroll from recurring transactions. When Gusto and the ledger disagree on payroll, trust Gusto for timing and amount and say so in the output

**From PayPal / Stripe / Square:**

• Settlement history: transaction date, amount, settlement date
• Use settlement lag (transaction date → payout date) to compute each source's

average and variance payment delay

**From CSV upload:**

• Parse as income/expense tabular data
• Required columns (flexible naming): date, amount, type (income or expense), description
• If columns are ambiguous, show the header row and ask the user to confirm mapping

Step 3 — Compute historical payment timing

For each AR customer (or income source from CSV), calculate:

• **Mean payment lag** — average days from invoice/transaction date to receipt
• **Payment variance** — standard deviation of payment lag across last 6–12 payments
• Use variance to set confidence band width (see Step 4)

If fewer than 3 payments exist for a customer, use the population mean as the point estimate and apply a ±30% variance band as the default. When running on CSV data with sufficient history (≥3 payments per source), compute the band from the actual payment variance — do not assume ±30%.

Step 4 — Build the 30/60/90-day forecast

Produce three time windows: 0–30 days, 31–60 days, 61–90 days.

For each window, compute:

| Line | Method | |---|---| | Expected inflows | AR due in window, adjusted for mean payment lag | | Expected outflows | AP due in window + fixed costs falling in window | | Net cash position | Inflows − Outflows | | Confidence band | ± weighted average payment variance as a % of expected inflows |

Confidence band formula:

band_pct = weighted_avg_stddev_days / avg_payment_lag_days
low  = net_cash × (1 − band_pct)
high = net_cash × (1 + band_pct)

Round band_pct to one decimal place. Cap at ±50% — higher variance means the data is too thin to model; flag it instead (see Step 5).

Step 5 — Flag named risks

Scan for conditions that push the low-band estimate negative or create a liquidity crunch. For each risk found, produce a one-line flag:

• **Late-payer risk:** "Customer X historically pays 18 days late; that shifts

their USD 8,400 invoice out of the 30-day window into day 48."

• **Payroll crunch:** "Payroll (USD 22,000) hits April 15. Opening balance USD 31,000

on April 1, plus inflows, minus outflows, puts low-band cash on hand April 14 at USD 19,200. Shortfall risk: USD 2,800." Needs a sourced balance.

• **Thin data warni