Cash Flow
You can read every row of the grid and know which question each one answers, and that the period columns are a view rather than stored data.
Columns are periods. Rows are what happened in them, in a fixed order that reads top to bottom as a story.
| Row | What it is | | ----------------------- | ---------------------------------------------------- | | **Income** | money in, from the financing plan | | **Total Income** | the sum of it for the period | | **Expenses** | money out, from the budget or cost control set | | **Total Expenses** | the sum of it for the period | | **Cash Flow** | total income minus total expenses — the period alone | | **Cumulated cash flow** | every period's Cash Flow added up to here | | **Start/End Balance** | the bank position opening and closing the period |
Tax rows sit alongside — see [read the VAT rows](/kb/article/read-the-vat-rows).
**Cash Flow** is the period on its own. Negative periods are normal — a production spends long before it is paid — so a row of them is not a problem in itself.
**Cumulated cash flow** is the running position, and it is the row financing decisions are made on. Its **deepest negative point** is how much bridging money the production needs, and **when** it needs it. That single figure is why this module exists.
A typical production makes the same shape: a shallow dip in prep, a steep fall through the shoot, a recovery as financing instalments land, and a long tail waiting on final payments.
What you are looking for is where the curve bottoms out and how long it stays there. A short deep trough and a long shallow one need very different arrangements with a bank.
The two are groups, not single lines. Income breaks down by financing source; expenses by budget category or group, depending on the detail level you have chosen. Collapse them to read the shape, expand them to find out what caused it — see [choose the budget detail level](/kb/article/choose-the-budget-detail-level).
The toolbar offers **Weekly**, **Bi-Weekly** and **Monthly**. The choice applies to the whole grid, and column headers follow it — W1, W2… BW1, BW2… M1, M2…
**No per-period amount is stored anywhere.** The plan holds placements — this money, on this date, by this rule — and the columns bucket them on the fly.
So switching from monthly to weekly re-buckets the same placements into narrower columns. No figure is recalculated, nothing is redistributed, and the totals are identical. Switch as often as you like.
| Period | Good for | | ------------- | ------------------------------------------------------------- | | **Weekly** | the shoot, where a fortnight's difference matters to the bank | | **Bi-Weekly** | a compromise across a long production | | **Monthly** | anything you are showing a financier |
Monthly is the one to present. Weekly is the one to plan a shoot on — and the granularity at which a plan that looks comfortable monthly can turn out to have a two-week hole in it.
The window decides how many columns there are: start and end dates bound the grid, and a plan with no window still shows placements but cannot show balances — see [set the plan window](/kb/article/set-the-plan-window).
Every figure is placed by a rule authored somewhere else, so there is no cell in this grid to correct — neither an amount nor a period. A reader who expects to type a number into a period column will hunt for the editable cell and conclude the grid is broken; it is not. If a number is wrong, the fix is in the budget, the financing plan, or the rule that placed it — see [how an amount becomes a period](/kb/article/how-an-amount-becomes-a-period).
Markdown