Ugo ChukwuAI & Financial Systems
← Work

Financial Intelligence

90-Day Cash Flow Engine

Operational financial data turned into a forward view: a modelled cash position, a 90-day forecast, named scenarios, runway monitoring and alerts that fire on thresholds a CFO actually set.

StatusValidated prototype
DomainFinance & treasury
RoleModelling & build
Core stackPython · Postgres · SQL

01 — The problem

Finance can tell you about last month. Nobody can tell you about the next quarter.

The cash position lives in a spreadsheet assembled by hand from bank exports, the billing system, an AP inbox and someone's memory of what payroll looks like next month. It is accurate on the day it is built and decaying by the afternoon.

So decisions that depend on cash — hiring, inventory, a raise, a large payment — get made on a stale number, or get delayed until someone rebuilds the sheet.

Cost of the gap

Days of senior finance time rebuilding the same model every month.

Risk

Runway surprises discovered weeks after they became true.

Blocker

No way to test a decision against the forecast before making it.

02 — The system

A forecast that rebuilds itself, and shows its work.

Financial data is ingested on a schedule, normalised into one model of inflows and outflows, and projected forward 90 days under explicit, stated assumptions. Scenarios are saved parameter sets — "hire two engineers in March", "the enterprise renewal slips a quarter" — that can be compared side by side.

Financial data ingestion

Bank, billing, receivables, payables and payroll pulled into one normalised timeline.

Cash-position model

Today's position, reconciled and traceable back to the rows that produced it.

90-day forecast

Committed items, recurring patterns and stated assumptions — each labelled as such.

Scenario simulation

Named, stored, comparable. Not a copy of the spreadsheet with one cell changed.

Runway monitoring

Months of runway under each scenario, recomputed on every ingest.

Threshold alerts

Fire when a projected balance or runway crosses a line finance defined in advance.

03 — Architecture

How the forecast is built

Bank feedsBilling / ARAP & payrollAccounting
Ingestion & normalisationdedupe · currency · categorisation
Cash modelcommitted · recurring · assumed
Forecast engine90-day horizon · daily granularity
Scenario layernamed parameter sets · side-by-side
Decision dashboardRunway alertsBoard reporting
Projected position · 90 daysactualforecast
todayminimum-balance threshold+90d

04 — Engineering decisions

A forecast is only useful if you can argue with it.

Deterministic before probabilistic

Explicit rules and stated assumptions, not a black-box model. A CFO has to defend this number to a board; "the model said so" is not a defence.

Three classes of money

Committed, recurring and assumed are modelled and displayed separately. Confidence in the forecast is a function of how much of it is assumed.

Every figure traces to source

Any number on the dashboard drills back to the transactions and assumptions behind it. Untraceable numbers do not get trusted, and untrusted numbers do not get used.

Scenarios are objects, not copies

Stored parameter sets with an owner and a date, so a decision can be revisited against the scenario that justified it.

Recompute on ingest

The forecast is a derived artefact, rebuilt whenever inputs change, with a visible timestamp and a stale-data state when a feed is late.

Forecast accuracy is tracked

Past forecasts are compared against what actually happened. Without that loop, a forecasting system is just a confident opinion.

05 — Reliability & controls

What the system does when things go wrong.

Failure modeBehaviour
Late or missing bank feedForecast is served with an explicit stale-as-of banner rather than silently using old data.
Partial period dataIncomplete periods are flagged and excluded from pattern derivation.
Duplicate invoices or transfersDeduplicated on source identity; internal transfers netted so cash isn't double-counted.
Multi-currency driftRates stored with the transaction; revaluation is a visible line rather than a silent adjustment.
Assumption goes staleAssumptions carry a review date and surface for confirmation before they quietly distort the forecast.

06 — Evidence

Project statusValidated prototype

Verified results

None published. No client cash figures or accuracy claims appear on this page.

Benchmarked results

  • Forecast error at 30 / 60 / 90 days on held-back historymeasurement pending
  • Model rebuild time per ingestmeasurement pending

These metrics have not been measured yet. Nothing is claimed for them until a reproducible run exists.

Simulated results

Synthetic company histories with seasonality, late receivables and lumpy payables, used to exercise the forecast and alerting paths.

Projected business value

Modelled from finance hours spent rebuilding the model, plus the cost of decisions currently delayed for want of a current number.

Verified, benchmarked, simulated and projected figures are kept separate on purpose. A benchmarked number is never presented as a verified client result.

07 — Technology

PythonPostgreSQLSQL modellingSupabaseBanking & accounting APIsScheduled jobs

Technology supports the story. The architecture and the controls are the story.

Still rebuilding the cash model by hand?

We can look at where your financial data actually lives and what a current, defensible forward view would take.

Book a Discovery Call