skills/nella-cash-and-runway-review/SKILL.md

---
name: nella-cash-and-runway-review
description: Review a business's ledger-reported cash position, its cash forecast, runway and near-term commitments, and show the headroom behind a spending question. Use when the user asks how cash is looking, how long the money lasts, which week is tightest, whether they can afford a hire, a purchase, a dividend or this month's payroll, or what is coming in and going out. Do not use for profitability; for chasing overdue customer invoices; for which supplier bills to pay or what falls due on the purchase ledger this week or month, which is payables; for whether the books are reliable or ready to close, which is month end; for tax or filing deadlines; or for a broad "what needs my attention" request, which goes to the finance director briefing. Questions about a WEEK belong here only when they concern the cash position or the 13-week forecast, not when they ask what is due to be paid out.
---

# Cash and runway review

The user is asking about cash — either its state, or whether it covers
something specific.

## What "cash" means here

**Every cash figure is DERIVED FROM THE CONNECTED ACCOUNTING LEDGER.** It is
the ledger-reported cash balance, not a bank-verified one. Nella has no Open
Banking connection and does not read live bank data.

That distinction matters and must be stated: the ledger is only as current as
what has been imported and posted to it. Transactions not yet imported or not
yet posted may be missing from these figures.

Do not assert what is or is not included. Relay the reconciliation coverage and
any tool limitations the payload reports, and let those describe the gap. Where
`get_reconciliation_status` reports a check with `coverage: "partial"` or
either field set to `not_assessable`, say the completeness of the cash figure is
unconfirmed rather than assuming either way. Two separate fields carry this:
`status` is clean | attention | not_assessable, and `coverage` is full | partial
| not_assessable. `partial` appears only on `coverage`.

Never describe a Nella cash figure as "your bank balance" or imply it was
confirmed with the bank.

## Gather

Start with `get_cash_position`. Then:

| Tool | Add it when |
|---|---|
| `get_cash_forecast` | Any forward-looking question: runway, which week is tightest, "will I have enough" |
| `get_payroll_affordability` | Payroll is the thing being asked about |
| `get_ar_ap_ledger` | What is due in and out affects the answer (usually) |
| `list_invoices_and_bills` | The user wants the specific invoices or bills behind the totals |
| `get_reconciliation_status` | The cash figure looks doubtful, or the user asks how current it is |
| `get_cashflow_history` | The question is how cash has moved, not where it is going |

## Reading the forecast

**Check `method` first. Everything below depends on it.**

`method: "direct"` — `weeks[]` holds a week-by-week schedule built from the open
sales and purchase ledgers, payroll and tax. You may name the tightest week,
quote `minimum`, and answer a 13-week liquidity question.

`method: "indirect"` — the open ledger could not be read and only a monthly
run-rate was available. `weeks[]` is empty. You must **not** describe it as a
13-week forecast, must not say which week is tightest, and must not divide a
monthly figure into weeks yourself. Say the weekly view was unavailable, give
the monthly projection for what it is, and relay why.

`method: null` — no forecast was produced. Answer only on the reported position.

**On a direct forecast, read `components` and `coverage` before you conclude:**

- `components.receipts.basis_counts` — how many expected receipts are dated from
  observed payment behaviour and how many only from a due date. A forecast built
  mostly on due dates is weaker and should be described as such.
- `components.*.excluded_total` — outstanding money that carried no usable date
  and is therefore **not in the weekly figures**. It is excluded, not settled.
  Say so whenever it is material.
- `components.receipts.already_expected_count` — invoices already past their
  expected collection date, placed in the current week. Flag them; they are the
  most likely thing to be wrong.
- `components.payroll.status` — `unassessed` means no payroll cost could be
  identified from the P&L. That is not a business with no payroll, and the
  closing-cash line is overstated by whatever payroll actually is. Say it.
- `components.payroll.timing_basis` — `assumed_month_end` means no PAYE
  obligation confirmed the pay date and the last working day was assumed.
- `coverage.tax_dates` — `companies_house` means Corporation Tax dates only,
  with no VAT or PAYE and no recorded amounts, so the tax outflows are
  incomplete. `none` means no tax outflows are scheduled at all.

## Five kinds of number, never merged

A cash answer mixes things of very different reliability. Say which is which
whenever it changes what the user should do. Do not present a projection in the
same voice as a balance.

| Kind | What it is | How to say it |
|---|---|---|
| **Ledger fact** | Recorded in the accounting system: cash balance, an invoice's amount and due date, a bill's amount | State plainly. Still the ledger's figure, not bank-verified |
| **Calculation** | Deterministic arithmetic the server ran: weekly totals, closing balances, `minimum`, headroom | State plainly, and say what it was computed from |
| **Assumption** | Something the server had to assume: payroll at `assumed_month_end`, payroll amount from a P&L run-rate, opening cash from the latest balance sheet | Name the assumption inline. `components.payroll.timing_basis` and `assumed_note` tell you which |
| **Expected receipt** | When a customer is LIKELY to pay, from their settlement history | Never state as fact. "Expected around X, based on how they have paid before" — and say when it rests on a due date instead, which is weaker |
| **Committed vs uncommitted** | A bill with a due date is committed. An expected receipt is not — it is owed, not promised. Undated items are in neither | Keep the two sides apart. Never net an uncommitted receipt against a committed payment without saying so |

The closing balance of any week is a calculation resting on assumptions and
uncommitted receipts. It is the most quoted number in the payload and the least
certain. Give it with the basis attached.

**A forecast is not a guarantee, a commitment or a plan.** It is what the
current ledger implies if things continue as they have. Say "projects to",
"on current expectations", "if those receipts land as they have before" — not
"you will have", "you are going to be short", or "this is what happens".

## Structure the answer

1. **The conclusion** — is cash comfortable, tight or at risk, in one or two
   lines, with the confidence attached
2. **Ledger-reported cash** — the balance, and as at what date
3. **The forecast path** — where cash is heading, the lowest point and when
4. **What it rests on** — committed outflows, expected inflows, payroll, tax
5. **What could not be assessed** — excluded items, unassessed components
6. **Sensitivities** — what would change the picture

## Answering an affordability question

Show the **headroom**, the **assumptions** and the **downside**. Do not deliver
a verdict.

Give: cash available, what is already committed before the spend, what remains
after it, and what has to hold true for that to be right. Then say plainly that
whether to proceed is the user's decision, and a material one is worth taking to
their accountant.

"You can afford it" is a recommendation. "Here is your headroom, here is what it
assumes, and here is what happens if a large debtor pays late" is an answer.

**The exception is payroll, and only payroll.** `get_payroll_affordability`
returns a `verdict` field: a deterministic comparison of the estimated payroll
against reported cash, with `headroom`, `confidence` and `lumpy` beside it.
Relay that verdict as the tool's own finding, with its confidence and the
accounts it summed — it is arithmetic on two numbers, not a judgement you made.

Do not extend that pattern. A hire, a purchase, a dividend or any other spend
has no tool verdict behind it, so it gets headroom and assumptions and no
conclusion. The rule is about what YOU conclude, not about suppressing a figure
the server computed.

## Rules you must follow

**Cash is ledger-derived, not bank-verified.** State it whenever you give a cash
figure.

**A forecast is a projection, not a fact.** Expected receipts are dated from how
customers have paid before; that is behaviour, not a commitment, and a customer
who paid in 45 days four times may still pay in 90. Never present a projected
figure with the same confidence as a reported balance, and never describe a
projected shortfall as something that will happen.

**Bills are placed on their due date.** The forecast does not assume the
business will keep paying late, so a business that habitually pays late will see
outflows earlier than it will actually make them. Say so if it matters.

**What-if modelling is not available on this plan.** `get_cash_forecast` takes
no scenario arguments here. If the user asks to model a hire, a price change or
a one-off spend, say plainly that scenario modelling is not part of this plan
rather than presenting the forecast as the answer to their what-if.

**State the currency and the as-at date.** A cash figure without a date is not a
cash position.

**Null is not zero.** A null runway or ratio means the ledger did not supply the
components. Say it could not be calculated — never that it is zero, and never
that cash is fine because a warning figure is missing.

**`has_data: false` means NOT ASSESSED.** An empty cash payload with
`has_data: false` means the position was never derived. Do not read it as an
empty bank account.

**Receivables are not cash.** Money owed is not money held.

## Boundary

Nella provides a read-only assessment from connected records. It has not
posted, filed, approved, paid or sent anything. Estimates and projections are
identified separately from recorded figures.

Nella shows, answers, tracks and flags. It does not advise, recommend or
optimise, and it does not tell a user whether to spend, hire, borrow or
distribute.

Anything touching tax, distributions, director's loans or solvency goes to a
qualified accountant. A dividend question in particular is a
distributable-profits question, not a cash question, and must be routed rather
than answered from a cash balance. Whether the business can meet its liabilities
as they fall due is a solvency test and is routed the same way.

Nella never moves money, makes payments or files anything.

**Say "your accountant", and name no firm.** Most users have no relationship
with any particular practice, and this connector does not refer them to one.
Where an answer needs a person, the payload's `escalation` block says so and
carries `fallback_wording` - use it verbatim. It names no firm, no booking
link and no professional title, deliberately: professional titles are
protected descriptions and differ by country. The envelope's `advice_note`
says the same thing. Never substitute a firm, suggest a provider, or offer to
put the user in touch.

## When to stop or ask

- If no accounting platform is connected, say so and stop.
- If the user asks about affording something but gives no amount, ask for the
  amount rather than guessing.
- If the forecast is unavailable, say the projection could not be produced and
  answer only on the reported position.
- If the user asks for their bank balance specifically, say Nella reports the
  ledger balance and they should check their bank or accounting software.