Team journey

It is the standard treasury horizon: short enough to be reliable, long enough to give time to react. Beyond it the projection becomes fiction; short of it, you discover the problem too late.

It opens the calculation record: which entries made up that number. It is the proof of the value — no number on this screen needs to be accepted on trust.

The panel shows the calculated balance of each active bank account: the opening balance entered in the record plus the settlements linked to that account since then. INVESTMENT and SAVINGS accounts appear marked because their money doesn't rescue the day — it goes into the "Invested / locked" card, not into the available balance. An account that came from the ERP through the connector appears identified as mirrored.

The screen says how many inflows were shifted, and the calculation record of each day/week shows the original due date next to the probable date (e.g. "due 10/09, +12d by behavior"). Whoever pays early shifts BACKWARD. The profile is recalculated at each projection, so a customer who improved their behavior improves the projection on their own.

When there are enough outcomes (5 or more in 4 weeks), the screen shows the forecast's average error (WAPE: sum of deviations divided by the sum of forecasts). It is the projection's public scoreboard: if the average error is at 6%, the number you see deserves trust; if it's at 40%, the projection is telling you a story — and there are probably realistic due dates missing or the probable date needs turning on. Without a sufficient sample the card doesn't appear, because accuracy calculated over 2 days is a gauge that lies.

Cash is the payment date. A September bill that falls due in November enters in November. What has already fallen due and is still open enters in the first week — a delay doesn't disappear from cash just because the date has passed.

An investment with a future redemption doesn't rescue next week. Adding everything into a single balance is declaring solvency with money that can't be withdrawn — that is why the two lines appear separately.

When the accumulated balance turns negative, the screen shows the week, the size of the hole and how much it would cost to cover it. The estimated cost uses the advance rate; it serves to compare with the cost of acting now — negotiating a deadline, bringing a collection forward, postponing a purchase.

This screen is 100% financial — balances, bills, cash holes — so it is blocked entirely by the "View Values" governance: without the permission on the profile, the access notice appears instead of the panel. There's no partial version without numbers, because a projected cash flow without values tells nothing. If someone on the team needs to follow cash, the way is for the administrator to grant "View Values" to that person's profile.

A few times a day the system reprojects cash and, if a week has started crossing zero when it didn't before, you receive the notice right away — with the date and the size of the hole. An alert that only arrives at closing warns of a problem that has already happened. The same notice isn't repeated while the situation doesn't change.

The Week/Day button changes the granularity of the SAME horizon: both modes read the same bills, the same recurrence and the same balance. Adding the days of a week gives exactly that week's total — there is an automated test that fails the build if the two calculations diverge, precisely because two screens answering "how much do I have" with different numbers is the kind of defect nobody notices. Use DAY to decide this week (which day money runs short, how much is missing) and WEEK to see the trend.

If the account has no opening balance in the record, the number shown is only the sum of what was entered here — it looks like a balance and isn't. The screen warns how many accounts are in this situation; enter the opening balance (and its date) in the account record so the position matches the bank statement.

Set TESOURARIA.SALDO_MINIMO in the company parameters to receive the yellow alert on the first day the projection breaks through your cash floor. It is deliberately different from the red alert: the red one says the money has run out and how much the rescue costs; the yellow one says it is going to run out and you still have a cheap choice. Without the parameter, the screen reports that the notice is off.

The same ending balance can mean very different futures. If cash grows because OPERATIONS generate it, the company sustains itself; if it grows because a LOAN came in, the same number hides a debt that will come back in installments. The three cards separate this over the whole horizon, with the same classification the actual cash flow statement uses — the nature that is financing there is financing here, always. Buying a machine falls into investing; taxes stay in operating (in cash terms, tax is operations).

The "Ask the cash flow" panel answers questions like "on what day does cash get tight first?" or "what are the biggest outflows on the horizon?". Every number in the answer comes from the panel itself — the artificial intelligence is forbidden from doing calculations on its own, precisely so it never invents a plausible and wrong value. If the question asks for data the panel doesn't have, the answer says so instead of estimating. And if the AI is unavailable, nothing is lost: the screen's numbers remain valid without it.

A hypothetical question ("what if I invest 200 thousand for 90 days?") doesn't get a guess: the copilot guides you to create the corresponding lever on the Scenarios screen (investment, exchange, credit, price adjustment or movement), where the engine calculates the real effect, month by month. It is the same rule as in all of Simulation: the machine types and calculates, the decision is yours.

The Due date/Probable date button changes the date of the INFLOWS: in probable mode, each receivable is shifted by that customer's typical delay — the MEDIAN of the delays of their settlements over the last 12 months. A customer who pays the 10th every 22nd appears on the 22nd, which is where the money really arrives. A customer with fewer than 3 settlements has no profile and stays on the due date — the platform prefers the plain due date to inventing behavior from a sample that proves nothing. Outflows never shift: paying on time (or not) is your decision, not a forecast.

Every day the platform freezes the day's forecast inflows and outflows and, the next day, compares them with what was actually settled. When the deviation exceeds BOTH thresholds (TESOURARIA.VARIANCIA_PCT and TESOURARIA.VARIANCIA_VALOR), the owner receives the notification with the explanation — including who was due that day and didn't pay, by name and amount. A quiet day (nothing forecast, nothing realized) is neither a hit nor a deviation: it's a quiet day, and it doesn't raise an alarm.

The projection rewrites itself every time someone opens the screen — that is why the question "what were we projecting in July?" had no answer. Once per period the platform keeps a SNAPSHOT of the forecast (on its own, in the daily cycle), and the panel shows each snapshot next to what actually happened in the month. The "Close the period and roll the horizon" button does this right away, and it is idempotent: clicking twice neither duplicates the snapshot nor rewrites the outcome.

The snapshot keeps the balance projected at the end of the 13-week horizon at that moment; "what happened" is the net amount the month actually produced (settled inflows minus outflows). They are close readings but not identical by construction — the comparison serves to see the TREND of your error, not to match cent by cent.

Due date shows the contract; Likely date moves each inflow to when the customer usually pays; Likely × chance does that and also multiplies the amount by the chance of the customer paying within 60 days of the due date. Customers with fewer than 3 invoices overdue for more than 60 days keep the full amount. A payment promise is never weighted.

This happens when the bills haven't been generated yet. The projection fills in with the recurrence of the active contracts, but only where there is no bill — so as not to count twice. If the horizon looks too empty, there are probably contracts with no monthly value registered.

The classification comes from the accounting group of the bill's financial nature. A bill whose group wasn't filled in counts as operating — which is the cash flow statement's default — instead of being left out of the calculation. If your financing flow appears smaller than it should, check the accounting group of the loan natures in Records › Financial Natures.