Atjaunot 13 nedēļu naudas plūsmas prognozi

Kad izmantot

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.

Pirms sāc

• 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.

Ko izpilde pieprasa1

Ceļš8 soļi

1. S1

   Pull actualsaģents

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

   Izdarīts, kad 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 varianceaģents

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

   Izdarīts, kad 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–13aģents

   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.

   Izdarīts, kad every open invoice appears in some week, and nothing uncertain is counted as certain.

4. S4

   Update payments, weeks 1–13aģents

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

   Izdarīts, kad every known obligation sits in a week with a date.

5. S5

   Compute the weekly closing balance and the gapaģents

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

   Izdarīts, kad 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 actionsīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   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.

   Izdarīts, kad 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 actionsaģents

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

   Izdarīts, kad every accepted action is a task, and rejected ones are noted with why.

8. S8

   File and hand backaģents

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

   Izdarīts, kad next Monday's run can start from this file.

Pārbaudes — kā zinām, ka izdevās

• 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 (⚠ jāpārbauda 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.

Ja noiet greizi

Ko atstāj katrs solis

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.

Ko saglabāt

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.

Kā šī procedūra uzlabojas

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.