ERP, operations base, debt and fundraising schedules, assumptions
Actual, contracted and forecast apart; weighted pipeline; assumptions with validity
Projected balance by week, minimum cash and forecast snapshot
Cash meeting, committee, budget and AI agent
What it solves
- A weekly forecast that starts from the real balance and separates what already came in, what is contracted and what is still pipeline.
- The pipeline enters weighted by its chance of closing, and contracted deals at full value.
- Every management assumption has a value, validity period and author, and last week's forecast can be rebuilt.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- ERP with receivables, payables and account balances, and the operations base, connected to Nekt
- The debt, fundraising and investor distribution schedules
- Management's assumptions in writing: probability scale, overdue rule, renegotiations and manual expectations
What you get
- A week x flow type x view table, with cumulative balance and minimum cash
- An assumptions table with validity dates, separate from the raw data
- Weekly forecast snapshots to compare with actuals and with the budget
- An AI agent that answers about cash stating which view it is using
Where to activate
Forecast with and without the manual expectation, minimum cash and the week it occurs, read from the week's snapshot.
Answers about cash, disbursements and debt stating the view, the snapshot date and the assumptions in force.
A notice when the projected balance for any week in the horizon falls below the minimum set by management.
It combines several sources and depends on assumptions only management defines. Start with the raw ERP base and add pipeline, debt and assumptions in layers. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
Cash in a financial operation comes from sources that do not talk to each other: the ERP has receivables due up to ten years out, the operations base has disbursements that are still negotiations, the debt has interest that depends on the Selic rate and investors have their own distribution dates. Adding it all into one number mixes certain money with bets. When management adjusts the spreadsheet by hand, last week's forecast can no longer be rebuilt and nobody knows how far off it was.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
Actual is what already moved, by the date it happened (posting or realized date). Contracted is what has a contract, by the contract date and amount or the current best estimate. Forecast is pipeline without a contract yet. Each row carries its view, and actual, contracted and forecast are distinct products, not a cascade where one fills the other's gaps.
Disbursements and contributions under negotiation enter multiplied by the commercial probability scale (for example: approved by committee 100%, hot 80%, warm 45%, cold 15%). A deal without a linked probability takes the lowest band, never 100%. From contracted onward, the amount enters in full. When the scale changes, comparisons crossing that date mix method with pipeline: record the date.
Portfolio bases often use the exposure sign: a disbursement or contribution adds to capital deployed, buybacks and amortization subtract. In cash it is the opposite: a disbursement is an outflow, a buyback or an installment received is an inflow. Convert once, in the cash layer, and state the convention: inflows positive, outflows negative.
Upcoming installments enter by expected date and, without one, by due date, within an explicit window: long contracts generate receivables for years. Upcoming installments from borrowers who are already delinquent stay out of inflows, except for an approved exceptions list. Overdue amounts go to their own recovery line. Renegotiated debt enters by the agreement's schedule, never by the old receivables.
Interest and dividends receivable, debt amortization and interest, and investor distributions enter by each contract's schedule (Price, SAC (constant amortization), scheduled amortization or cash sweep). A floating rate uses the projected index for the agreed period (for example, the previous month's Selic), with the contract's cap. Forecast uses the contracted view; actuals use what was actually paid.
The starting point is the closing balance of every bank account of every company or vehicle, on the last available day, converted to America/Sao_Paulo. Past months use the last day of the month. When management provides a statement balance different from the ERP, it enters as a one-day assumption, with the ERP amount kept alongside for audit.
Overdue rule, approved exceptions, renegotiations, new contracts, the week's manual expectation and the provided balance live in a table with value, validity (from and to) and a note, published from a versioned file. The adjusted forecast is the raw base plus the assumptions valid on the reference date. Meeting decisions go in another table, with no numbers. Nobody edits the query by hand.
The weekly manual expectation is an amount management expects to receive from new work or collections in progress. It is not a historical collection average. It appears on its own line and the forecast is also shown without it. An expected receipt only improves the forecast if it is additional (outside what the ERP already projects); if it is already in the ERP, it is already provisioned.
Save each week's forecast with the date it was made, in append mode, and keep the last version of each day of the pipeline. An approved budget is a frozen snapshot per cycle, compared with the target and with actuals. A cycle that was not run is absent on purpose and is not a load failure.
Where each cash line comes from
View, date and amount used for each flow type.
Definitions
Pitfalls that already happened
Deals with no linked probability entered at 100% and inflated the contribution forecast. The default moved to the lowest band, and the forecast dropped at once.
Lowest band as default and the date of the change recorded.
Upcoming receivables from recurring contracts ran up to ten years out, and the sum described the long-term portfolio, not the quarter's cash.
An explicit forecast window.
ERP dates stored as dd/mm/yyyy text sorted alphabetically, and the daily balance stamped at midnight UTC only landed on the right day by coincidence.
Convert text to date and the timestamp to America/Sao_Paulo explicitly.
One company's financial summary showed receivables and payables at zero while its receivables table showed significant overdue amounts.
From the summary, use only the balance; inflows and outflows come from the receivables and payables.
A payment read as a current monthly fee was an agreement installment used to settle old receivables, and the customer looked current.
Classify the receipt by the agreement category before projecting recurrence.
Changing the probability scale moved the forecast on a day when no deal changed stage.
Store the scale with validity dates and compare forecasts using the same scale.
Acceptance test
The case is done when every item passes.
- For each week, opening balance + inflows - outflows = closing balance, and the closing balance is the next week's opening balance.
- The opening balance matches the ERP or statement balance for the day (zero difference), or the provided-balance assumption appears with the ERP amount alongside.
- No contracted or actual deal appears with a weighted amount, and no pipeline deal appears at full value.
- No upcoming installment from a delinquent borrower outside the exceptions list enters projected inflows.
- Running the forecast again does not change any earlier week's snapshot.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Cash flow forecast - Horizon: <13> weeks, starting on Monday of the current week (America/Sao_Paulo). - Views: actual (effective date), contracted (best date and amount, full value), forecast (pipeline x probability). Every answer states which view it uses. Never fill one view with another. - Probability: <approved 100%, hot 80%, warm 45%, cold 15%>. No probability = lowest band. - Sign: inflows positive, outflows negative. Disbursements and contributions are outflows; buybacks, installments and interest received are inflows. - Portfolio receivables: by expected date, otherwise due date. Installments from delinquent borrowers stay out, except <exceptions list>. Overdue on its own line. Renegotiated by the agreement schedule. - Debt, interest and investors: by each contract's schedule, with the projected index for the period and the cap. - Opening balance: closing balance of every account included, across all vehicles. A balance provided by management applies only within its validity and keeps the ERP amount alongside. - Assumptions in <assumptions table>, filtered by validity on the reference date. The manual expectation is not a collection average; show the forecast with and without it. - Minimum cash = lowest projected balance in the horizon and the week it occurs. - Past forecasts and budgets come from the snapshots. Do not recalculate a week's number that was already presented. Client exceptions: - <client>: vehicles <list> enter the consolidated view; <vehicle> stays out. - <client>: the probability scale changed on <date>; before that, <old scale> applied.
Build the "Cash flow forecast" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/financeiros/projecao-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
Budget frozen per cycle, forecast at the last version of the day and actuals, side by side by month and by deal type.
The same model at day x account grain, to decide investments, redemptions and transfers between vehicles.
One forecast per client of the firm, each with its own assumptions table and its own ERP connection.