---
id: casos/fluxo-de-caixa
area: Finance
usage: common
effort: medium
grain: Bill x expected date; aggregated to week x account x type (inflow or outflow)
---

# Cash flow forecast

The balance for the next 13 weeks from the real bank balance, receivable and payable bills and the card schedule, with leadership's assumptions kept apart from the raw data.

## Executive summary

**For:** Finance and leadership who need to know weeks in advance when cash gets tight.

**What it solves**

- The projected balance starts from the real bank balance, not a copied spreadsheet.
- Every inflow and outflow lands on the date money actually moves.
- Leadership's assumptions are recorded and kept apart from what the ERP says.

**Why it matters:** Receivables, payables, the card schedule and recurring revenue live in different systems, and adding them without rules produces cash that does not exist: ten-year bills, overdue amounts treated as certain, transfers counted as inflows. A forecast with fixed rules shows the gap in time to prepay a receivable, delay a payment or raise capital, and the weekly comparison with actuals shows how much to trust it.

**Business questions it answers**

- What is our cash balance today across all accounts?
- What is the projected balance for each of the next 13 weeks?
- In which week does cash fall below the minimum, and by how much?
- How much card money will be released over the next few weeks?
- How much of what we projected last week actually came in?
- Which large payments are due before the revenue arrives?

**What you need**

- Finance ERP connected to Nekt, with receivables, payables and balances by account
- The acquirer or billing schedule, if there are card sales or subscriptions
- Leadership's assumptions in writing: what to do with overdue amounts, renegotiations and new contracts

**What you get**

- A table per week with opening balance, inflows, outflows and projected balance
- Minimum cash over the horizon and the week it happens
- Projected vs actual by week, with a snapshot of each forecast stored
- An AI agent that answers about cash with the current assumptions

## Detailed

### The problem

The ERP shows the bills, but not when money will actually move. Whoever sums everything still due includes recurring contracts that fall due ten years from now; whoever treats overdue bills as this week's inflow counts on money that is not coming; whoever books card sales on the sale date pulls forward by 30 days cash that does not exist yet. Leadership's adjustments go in by editing the spreadsheet, and nobody can rebuild last week's number.

### Business rules

1. **The opening balance comes from the bank.** The starting point is the closing balance of each bank account on the last available day, summed across the accounts that belong in the cash flow. Accounts of another company, supplier credit accounts and pass-through accounts (a card terminal that forwards to the bank) are left out or handled separately. The ERP's financial summary may show receivables and payables as zero: use only its balance. (Avoid: Starting from a balance typed into the spreadsheet or summing every registered account.)
2. **Actual and projected are not added together.** Actual is the real settlements, by payment date. Projected is the open bills, by expected date (or, without it, by due date). The two views sit on flagged rows and meet only at the cutoff date: before it, actual; from it on, projected. Inflows positive, outflows negative. (Avoid: Adding settlements and open bills for the same month.)
3. **Limited horizon, cancelled out.** Project a fixed window, for example 13 weeks. Recurring contracts create bills due for years; summing everything describes a long-term portfolio, not the quarter's cash. Cancelled bills always leave, and bills with clearly invalid dates (such as undated provisions set in the year 2000) are excluded. (Avoid: Summing every bill still due in the base.)
4. **Overdue is not this week's inflow.** An overdue receivable does not automatically enter the current week. The rule belongs to leadership and is written down: for example, short delays from recurring customers enter a defined week, and the rest becomes an overdue-to-recover line outside the projected balance. An active renegotiation uses the new schedule, never the old bill. (Avoid: Pulling all overdue amounts into the current week as if they were certain.)
5. **Cards enter on the release date.** Card sales enter cash on the date the acquirer releases each installment, read from the receivables schedule, and at their net-of-fees value. Pix and boleto enter within a few days. Contracted prepayment changes the date and reduces the amount. A refunded sale leaves the schedule. (Avoid: Booking the card sale on the sale date and at gross value.)
6. **Recurring revenue that is not a bill yet.** Active subscriptions and contracts whose installments the ERP has not generated yet enter as projected inflows on the next billing cycle date, net of fees and flagged as expected recurring revenue. Cancelled contracts stop generating inflows from the cancellation date. (Avoid: Ignoring recurring revenue that has no bill yet, or counting it twice once the bill is created.)
7. **Moves between own accounts are neither inflow nor outflow.** Transfers between company accounts, investments and redemptions cancel out in the consolidated view. Compute them per entry so both sides cancel, including withheld IOF and income tax. The corporate card enters on the bill payment date, not on each purchase date. (Avoid: Adding the outflow from one account and the inflow to the other as cash movement.)
8. **Versioned assumptions, separate from data.** The raw ERP base is one table. Leadership's assumptions (overdue rule, renegotiations, new contracts, a manually expected inflow) live in another, with amount, validity and who decided. The adjusted forecast is the base plus the assumptions valid on that date. Nobody edits the query by hand to change a number. (Avoid: Adjusting the week's number directly in the spreadsheet or the query.)
9. **Every forecast is snapshotted.** Store each week's forecast with the date it was made, without overwriting. That makes it possible to compare what was projected with what came in and to measure accuracy by inflow and outflow type. A transformation that rebuilds the whole table on every run erases that history: use append mode. (Avoid: Recomputing the forecast over the previous one on every run.)

### Which date each amount uses

The forecast puts each amount on the date money actually moves.

- **Closing balance per account on the last available day** → Opening balance (`statement or ERP balance`)
- **Open receivable bills** → Inflow (`expected date, else due date`)
- **Card sales, installment by installment** → Inflow (`acquirer release date`)
- **Subscriptions and contracts with no bill yet** → Expected inflow (`next billing cycle`)
- **Open payable bills** → Outflow (`expected date, else due date`)
- **Corporate card purchases** → Outflow (`card bill payment date`)
- **Receivables already overdue** → Overdue to recover (`outside the balance unless an assumption applies`)
- **Transfers, investments and redemptions between own accounts** → Outside the cash flow

### Definitions

| Metric | Definition |
|---|---|
| Opening balance | sum of the closing balance of the accounts in the cash flow, on the last available day before the cutoff date |
| Projected inflows | sum of open receivable bills, the net card schedule and expected recurring revenue dated in the week, excluding cancelled and overdue |
| Projected outflows | sum of open payable bills and corporate card bills dated in the week, excluding cancelled |
| Projected weekly balance | previous week's projected balance + projected inflows - projected outflows, starting from the opening balance |
| Minimum cash | lowest projected balance within the horizon and the week in which it occurs |
| Overdue to recover | balance of receivable bills overdue on the cutoff date, outside the projected balance unless a declared assumption applies |
| Forecast accuracy | 1 - |projected - actual| / actual, per week, comparing the snapshot made before the week with the actual settlements |

### Pitfalls

- **Bills into the next decade.** Long-term recurring contracts created bills due more than ten years ahead. The sum of everything still due had nothing to do with the quarter's cash. How to avoid: Limit the forecast window before summing.
- **A fake opening balance.** With no statement connected, the forecast started from a fixed demo balance per account, and the number came to be read as real. How to avoid: Flag the opening balance source and switch to the real bank balance as soon as it is connected.
- **ERP summary at zero.** One company's financial summary showed receivables and payables at zero, while the bills showed significant open amounts. How to avoid: Take only account balances from the summary; inflows and outflows come from the bills.
- **A transfer that inflated both sides.** Investments and redemptions between bank and investment accounts, with IOF and income tax withheld, appeared as an outflow in one account and an inflow in the other and inflated the month's movement. How to avoid: Compute per entry so transfers cancel out.
- **An overrun that was early payment.** Bills due early in the following month were paid in advance, and the current month seemed to have blown its outflow budget. How to avoid: Compare expected date and payment date before calling it an overrun.
- **A join that duplicated payments.** Payables (one row per installment) were joined with paid bills (one row per settlement) without aggregating, and installments with several settlements were repeated. How to avoid: Aggregate settlements per installment before joining.

Validated on real data: In Nekt's own Stripe account, most card charges only became available for payout 29 days after the sale, while boleto released in 1 to 4 days. Projecting the card inflow on the sale date would pull forward by a month the cash from most of the revenue.

### Acceptance test

- [ ] The opening balance equals the sum of bank balances of the cash flow accounts on the cutoff date (zero difference).
- [ ] For a past week, actual inflows and outflows match the ERP settlements and the statement (difference below 0.5%).
- [ ] No cancelled bill, no transfer between own accounts and no bill outside the window appears in the forecast.
- [ ] The snapshot of a past week's forecast stays the same after new runs.
- [ ] Every applied assumption appears in an assumptions table with amount, validity and owner.

### Context document

```text
Cash flow forecast
- Opening balance = sum of the closing balance of the accounts in the cash flow, on the last available day. Accounts outside the cash flow: <accounts>.
- Actual = settlements by payment date. Projected = open bills by expected date, else due date. Never add the two.
- Horizon: <13 weeks>. Cancelled always out.
- Overdue bills do not enter as the week's inflow. They stay in overdue to recover, unless the current assumption says otherwise.
- Cards: release date from the acquirer schedule, net value. Pix and boleto: <lag>.
- Recurring revenue without a bill: expected inflow on the next billing cycle, replaced by the bill once it exists.
- Transfers, investments and redemptions between own accounts cancel out. Corporate card by bill payment date.
- Leadership's assumptions come from the assumptions table, with validity. Cite the assumption whenever it changes the number.
- For projected vs actual, use the snapshot made before the week, not the current forecast.
- Inflows positive, outflows negative.
Client exceptions:
- <client>: delays of up to <n> days from recurring customers enter the week after the due date.
- <client>: account <account> is a card terminal pass-through and does not count in the balance.
```

### Variations

- **Several companies:** One forecast per company and a group consolidation, with transfers between companies eliminated.
- **By project or site:** The same rule per cost center, with each project's minimum cash and the funding it needs.
- **Scenarios:** Base, optimistic and pessimistic from the same assumptions table, with one validity per scenario.