Update the 13-week cash forecast

When to use

Every Monday, or any time the owner asks "can we afford X next month?". Not for the monthly accounts — use money.month-close. Not for collecting a specific overdue invoice — use money.chase-overdue-invoice (but this forecast names which invoices to chase first). Not for recurring card or subscription spend review — that lives in ops.supplier-review-yearly.

Before you start

• Last week's forecast and its variance note are at hand (or this is the first run — say so).
• The owner's spending decisions from last week are known (done, postponed, cancelled).
• Bank read access is in place for all company accounts.

What a run requires1

The trail8 steps

1. S1

   Pull actualsagent

   Read today's balances from every bank account and reconcile against last week's forecast closing balance.

   Done when each account's actual balance is written next to the forecast figure, and any difference over a small tolerance (agree one, e.g. €50) has a one-line cause.

2. S2

   Record the varianceagent

   Compare last week's forecast for this week against reality: which receipts came late or short, which payments were bigger than planned.

   Done when the variance note names each miss over the tolerance and its cause — not "timing", but whose invoice, which fee, which tax.

   ⛔ A variance note that explains nothing ("small differences") trains the forecast to stay wrong.

3. S3

   Update receipts, weeks 1–13agent

   List every expected receipt by due date and realistic pay date: open invoices from the money module, recurring revenue, grants or loans already agreed. Mark anything already overdue separately.

   Done when every open invoice appears in some week, and nothing uncertain is counted as certain.

4. S4

   Update payments, weeks 1–13agent

   List payroll and salary taxes by their actual dates (⚠ verify current-month deadlines, vid.gov.lv), VAT by the LV declaration and payment date (⚠ verify vid.gov.lv), rent, loan instalments, supplier invoices due, and known one-offs.

   Done when every known obligation sits in a week with a date.

5. S5

   Compute the weekly closing balance and the gapagent

   Running balance across 13 weeks; mark the lowest point and compare against the company's safety line (agreed minimum balance).

   Done when the table shows a closing balance per week and the gap or surplus against the safety line is stated in one sentence.

6. S6

   Review and decide actionsownerneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   Present the table, the lowest point, the variance note and 2–4 proposed actions: which invoices to chase first, which payments to schedule or delay (within agreed terms — never late tax), which spending to hold.

   Done when the owner has accepted, changed or rejected each proposed action.

   ⛔ The agent never postpones a payment to a supplier or a tax authority on its own — that is an owner decision with contract and penalty consequences.

7. S7

   Record the actionsagent

   Create a task per accepted action (bc tasks add), each with a due date inside the next two weeks and a named owner.

   Done when every accepted action is a task, and rejected ones are noted with why.

8. S8

   File and hand backagent

   Save the updated table and variance note in the money module; send the owner a three-line summary: lowest point, week, the actions agreed.

   Done when next Monday's run can start from this file.

Checks — how we know it worked

• Sum of week-1 receipts and payments matches the bank's own scheduled list for the week.
• Every open invoice appears exactly once across the 13 weeks.
• Tax and payroll dates in weeks 1–4 match the official calendar, not memory (⚠ verify vid.gov.lv).
• Last week's variance note exists and names causes, not just numbers.
• Every accepted action from S6 is an open task with a due date.

If it goes wrong

What each step leaves behind

1. S1each account's actual balance is written next to the forecast figure, and any difference over a small tolerance (agree one, e.g. €50) has a one-line cause.
2. S2the variance note names each miss over the tolerance and its cause — not "timing", but whose invoice, which fee, which tax.
3. S3every open invoice appears in some week, and nothing uncertain is counted as certain.
4. S4every known obligation sits in a week with a date.
5. S5the table shows a closing balance per week and the gap or surplus against the safety line is stated in one sentence.
6. S6the owner has accepted, changed or rejected each proposed action.
7. S7every accepted action is a task, and rejected ones are noted with why.
8. S8next Monday's run can start from this file.

Evidence to keep

Each weekly run stores: the forecast table version, the variance note with causes, the owner's decisions in S6 (who, when, what changed), and the task ids created in S7. These let a later run — or money.loan-application or growth.valuation-xray — trust the history instead of rebuilding it.

How this playbook improves

After every 8 runs ask: what was the forecast error at 4 weeks out, and did it shrink? Which variance cause appeared more than once? Did any action from S6 stay undone past its due date, and was the cause the action or the owner? A new version changes the step that produced the repeat error, and says so in its change note.