Feature catalogue

Forecasting an account

The Forecast panel runs an account forward and shows you what it will do. It is a projection, not a posting. Nothing is written, nothing reaches the ledger, and running it changes no balance.

What makes the answer trustworthy is that it is not a separate calculator. The forecast runs the account through the same end-of-day processing the account goes through every night — the same schedules, the same day count, the same business day rules. It just runs it over days that have not happened yet.

What you see

The panel opens already run to the account’s maturity date, because the question it exists to answer is “what does this account do over its life”. You can change Target Date to any date. If the account has no maturity date — a call deposit, say — the field starts empty and nothing runs until you pick one.

The table shows one projected transaction per row, latest first:

Column What it holds
Type The transaction type, as the customer would see it
Trading Date The date the projected transaction is raised
Value Date The date it counts from — see value dating
Amount The projected amount, signed against the account
Net / Tax / Gross Shown instead of Amount when withholding tax applies
A balance column per position The running balance after that row
System Marks a row the engine raises rather than a person

The bottom row is the Starting balance — the account’s real balance today. Every balance above it is a continuation of that one, so you can read a column downward and see where the account ends up. Use Balance View to choose which position columns appear; the views on offer belong to the account type. See position types.

You can export the projection from the panel as a spreadsheet, CSV or JSON.

Where the forecast starts

The forecast starts from the day after the account’s last processed day, and from today’s real balances. It never replays history.

That distinction matters when you read the table. An account that has already received 1,000 shows the interest that 1,000 will earn, but not the 1,000 again — the deposit is already in the starting balance, and repeating it would double-count the running column.

A payment you have booked with a future value date is not history yet. It settles inside the window and appears as a row. A deposit of 100 value-dated 10 June shows up in a forecast run to 15 June.

An account still being captured forecasts too. Before it is activated there is no history at all, so the forecast opens the account in memory and projects from what it would open with — the answer to “what happens if I activate this?”. A closed, closing or suspended account cannot be forecast, and the panel says so.

There is no limit on how far ahead you can go. A long horizon costs time, because every day between here and the target date is processed one at a time.

What one projected day does

Each day in the window runs in the order money actually moves.

flowchart LR
  A["Start of day: instalments and other dated postings fall due"]
  B["Collections raised for what is due"]
  C["Payments already in flight settle on their value date"]
  D["End of day: interest, fees, capitalisation"]
  E["Notices reaching expiry pay out"]
  A --> B --> C --> D --> E

The order is the reason a day’s rows read sensibly. An instalment falls due before the payment that clears it, and interest for the day accrues on the balance those movements leave behind.

Assuming the repayments

Expected Payments tells the forecast what to assume about money coming in. It changes the answer, so choose it deliberately.

Setting What it assumes Use it for
None Nothing extra. Collections the account already arranges are still projected The worst case
Match instalment Every instalment is paid in full on its due date The contractual case
From debit / standing order Every debit order or standing order occurrence in the window is collected What is actually arranged

A loan of 100,000 with an instalment of 1,500 collected by direct debit shows two rows on the due date: the instalment falling due, and the 1,500 received. That collection is projected whatever this setting says, because the account arranges it and the nightly run raises it.

An occurrence that has already been raised is counted once, not twice. A 200 debit order collection that is already in flight settles once in the forecast, and the next occurrence is projected once.

See the repayment schedule for how instalments are set, and how a repayment is recorded for what happens when one actually arrives.

Trying a what-if

Select Add Simulated Entry to put a transaction into the projection that has not happened. Give it a type, an amount and a value date. It appears as a chip above the table, and the forecast re-runs on its own.

A call deposit with nothing in it forecasts nothing. Add a simulated deposit of 100,000 dated on the account’s start date, and the projection fills with the daily interest that balance earns on the account’s own day count convention.

You can date a simulated entry in the past. That answers “what if I had booked this at trade date?” on a deal that has not started yet. The entry lands on the date you gave it, and scheduled work still waits for the account’s start date: a deal starting 1 June with a simulated deposit dated 4 May accrues nothing until 1 June.

A simulated entry is never saved. Remove it with the x on its chip, or leave the panel — either way nothing was recorded.

Forecasting a change before you commit it

Changes staged in the studio are included. Stage a deposit, a rate change or a revised instalment plan, and the forecast projects from the account as it would be once those changes apply — not as it is now.

Stage a deposit of 100,000 on an account holding nothing, and the forecast’s starting balance reads 100,000. Run the plain forecast alongside it and the starting balance reads zero, because nothing is committed.

That is what lets you shape a change and see its effect before anyone signs it off. Where a change needs a second pair of eyes, the approver sees the same projected effect — see countersign.

Why the forecast matches what the account goes on to do

Because it is the same run. A worked case: 100,000 at 10%, accruing on ActualActual for the first two days and on Actual360 from the third, after a convention change dated mid-window. Forecast five days, then let five nights process. The five projected accruals equal the five booked accruals, to the cent — including the two either side of the switch. The per-day amounts for those conventions are in day count conventions.

The same holds for money leaving. An account holding 1,000 with notice given on 400 over 32 days shows the 400 paying out three days after expiry — the settlement lead time on the rail, not the expiry date itself. Nothing special was done to make the notice appear: the forecast runs the expiry step the nightly run runs. See notice periods and business day conventions.

Capability switches move both sides together. Switch notice periods off and the forecast projects no payout, because the nightly run would instruct none. A forecast can never show you work the engine will not do.

What would make the forecast and reality differ

The engine is the same. The inputs are what can drift.

Cause What to do about it
Activity nobody told it about — a deposit, a withdrawal, an early settlement The forecast assumes the account is left alone. Re-run it after anything moves
Rates that move Each projected day is priced at the rate in force as of that day, from today’s rate card. A rate agreed tomorrow was not knowable today — see changing a rate
The Expected Payments setting “Match instalment” is an assumption, not a fact. An account in arrears will not match it
Simulated entries They answer a what-if. A forecast carrying them is not a prediction
A capability switched on or off between now and then Both sides move together, but they move on the day of the switch, not retrospectively

There is also work the nightly run does that the forecast does not project. The forecast covers the account’s own dated timetable — scheduled postings, interest, instalments and their collections, payments settling, notices expiring, and withholding tax. It does not project arrears classification and default, provisioning, write-off of small residues, prescription, expiry of a settlement quote, or repricing driven by a card tier. Those still run at night. If one of them is material to your answer, read the forecast as the account’s timetable rather than as the whole night.

What your organisation configures