Cash flow forecast

Source

Balances, receivable and payable bills, card schedule and recurring revenue

Rule

Each amount on the date money moves, plus versioned assumptions

Outcome

Projected balance by week and minimum cash

Activation

Weekly cash meeting, alerts and AI agent

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.

Business questions it answers

Ask your agent these questions once the case is live.

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

Where to activate

Weekly cash meeting

13-week forecast with minimum cash, current assumptions and the previous week's projected vs actual.

AI agent via MCP

Answers about balance and forecast, citing the assumption applied and the snapshot date.

Alerts

Notice when any week's projected balance falls below the defined minimum.

Ready to build?

The raw base comes out of the ERP quickly. The work is writing the assumptions with leadership and connecting the real bank balance. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.

See detailed view

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.

How it is usually done, and the rule

Each row is a mistake that already happened in practice.

The common wayThe rule

Starting from a balance typed into the spreadsheet or summing every registered account.

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.

Adding settlements and open bills for the same month.

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.

Summing every bill still due in the base.

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.

Pulling all overdue amounts into the current week as if they were certain.

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.

Booking the card sale on the sale date and at gross value.

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.

Ignoring recurring revenue that has no bill yet, or counting it twice once the bill is created.

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.

Adding the outflow from one account and the inflow to the other as cash movement.

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.

Adjusting the week's number directly in the spreadsheet or the query.

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.

Recomputing the forecast over the previous one on every run.

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.

Which date each amount uses

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

Closing balance per account on the last available dayOpening balancestatement or ERP balance

Open receivable billsInflowexpected date, else due date

Card sales, installment by installmentInflowacquirer release date

Subscriptions and contracts with no bill yetExpected inflownext billing cycle

Open payable billsOutflowexpected date, else due date

Corporate card purchasesOutflowcard bill payment date

Receivables already overdueOverdue to recoveroutside the balance unless an assumption applies

Transfers, investments and redemptions between own accountsOutside the cash flow

Definitions

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 that already happened

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.

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.

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.

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.

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.

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.

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 case is done when every item passes.

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.

Agent package

Paste into Claude, ChatGPT or any client with the Nekt MCP connected.

Full Markdown

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.

Build the "Cash flow forecast" case in my Nekt workspace following the rules at https://academy.nekt.com/en/casos/fluxo-de-caixa.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.

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.