Banking, Payments & Credit
Cash Flow Forecasting API
Your customers already know what they have in the bank. What they want to know is whether it is enough, and for how long.
- Accounting software
- SME neobanks
- Spend management platforms
- Lenders
- ERP vendors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Small businesses do not fail because they are unprofitable. They fail because a large receivable lands three weeks after payroll. The information needed to see that coming is almost always sitting in the software they already use — the ledger, the bank feed, the open invoice list, the recurring supplier payments — and almost no product assembles it into a forward view.
The forecasts that do exist tend to be straight-line extrapolations of last quarter, which is the one method guaranteed to miss the thing that matters. Business cash flow is lumpy, seasonal and dominated by a handful of large irregular events: a VAT payment, an annual insurance renewal, a single customer who pays on day sixty-eight. An average monthly outflow smooths away exactly the detail that determines whether the account goes negative.
Doing it properly means forecasting at the level of individual cash events rather than aggregate totals. Recurring commitments are near-deterministic and should be treated as such. Open receivables need a per-invoice expected payment date. Tax obligations follow a published calendar. The genuinely uncertain part — new sales — is a smaller share of the forecast than most teams assume, which is why the whole thing is more tractable than it looks.
Who buys this
Accounting software, SME neobanks, Spend management platforms, Lenders, ERP vendors
What the API returns
What comes back
- Daily cash balance projection with confidence bands over a configurable horizon
- Runway in days and months, with the date the balance is first projected to go negative
- Forecast decomposed into recurring commitments, expected receivables, tax events and new revenue
- Per-invoice expected payment dates feeding the receivables component
- Scenario forecasts: lost customer, delayed payment, hiring plan, price change
- Liquidity stress testing against defined shocks, with the shortfall amount and date
- Anomaly detection on cash events that break an established pattern
- Explanation of what changed since the previous forecast, and which component drove it
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/forecast | Daily cash projection with confidence bands for one entity |
| GET | /v1/entities/{id}/runway | Runway summary and first projected shortfall date |
| POST | /v1/scenarios/run | Forecast under one or more user-defined scenarios |
| GET | /v1/entities/{id}/commitments | Detected recurring inflows and outflows |
| GET | /v1/entities/{id}/forecast/explain | What changed since the last forecast and why |
| POST | /v1/entities/{id}/sync | Push updated ledger, bank and invoice data |
Request and response
illustrativeRequest
{
"entity_id": "biz_55120",
"horizon_days": 180,
"base_currency": "GBP",
"include": ["commitments", "receivables", "tax_events", "confidence_bands"],
"scenarios": [
{ "name": "lose_largest_customer", "type": "revenue_loss", "share": 0.22 },
{ "name": "hire_two_engineers", "type": "cost_increase", "monthly": 12000 }
]
}Response
{
"entity_id": "biz_55120",
"as_of": "2026-10-21",
"opening_balance": 184210.55,
"runway": {
"days": 212,
"first_negative_date": "2027-05-21",
"confidence": "medium",
"p10_first_negative_date": "2027-02-14"
},
"components_next_90d": {
"recurring_outflows": -241800.00,
"expected_receivables": 318400.00,
"tax_events": -48200.00,
"new_revenue_estimate": 96500.00
},
"pressure_points": [
{ "date": "2026-12-31", "projected_balance": 21400.00,
"cause": "VAT payment coincides with December payroll" },
{ "date": "2027-02-28", "projected_balance": 8900.00,
"cause": "Annual insurance renewal, two invoices overdue" }
],
"scenarios": [
{ "name": "lose_largest_customer", "runway_days": 118,
"first_negative_date": "2027-02-16" },
{ "name": "hire_two_engineers", "runway_days": 149 }
],
"forecast_accuracy_30d_mape": 0.061
}Where the data comes from
| Bank transaction feeds | Open banking or direct feeds providing the actual cash events, which anchor the whole forecast to reality rather than to accruals |
| Accounting ledger data | Chart of accounts, open invoices, bills and payment terms from the accounting platform the customer already uses |
| Open receivables and payables | Per-invoice amounts, due dates and payment history, which drive the largest and most forecastable component |
| Payroll and recurring commitment records | Salaries, rent, subscriptions and loan repayments — near-deterministic and the easiest major component to get right |
| Tax calendars and rates | Published filing and payment deadlines by jurisdiction, so the obligations appear on the correct dates rather than as a monthly average |
| Industry seasonality references | Where available and licensable, used only as a weak prior for entities with short history |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Event-level forecasting rather than aggregate extrapolation: each recurring commitment, invoice and tax obligation is projected as a dated cash event
- Recurring transaction detection from bank and ledger history, with amount drift and schedule drift tracked separately
- Per-invoice payment date prediction feeding the receivables component, which is where most of the forecastable variance lives
- Probabilistic output throughout — the forecast is a distribution, and the p10 shortfall date is usually more decision-relevant than the median
- Hierarchical modelling so an entity with four months of history borrows structure from comparable entities, with the borrowing declared in the response
- Backtesting on rolling origins with MAPE reported per horizon, because thirty-day accuracy and one-hundred-eighty-day accuracy are entirely different claims
- Scenario engine built on the same event model, so a scenario changes specific cash events rather than scaling a curve
- Forecast change attribution between successive runs, which is what turns a number into something a user trusts
What it changes for the business
A reason to connect the bank feed
Forward visibility is the most compelling justification a product has for asking a customer to link their bank account.
Earlier intervention
A shortfall visible in December is a financing conversation; the same shortfall in February is an emergency.
Lending qualification
Forecast-based affordability is a materially better signal than trailing revenue for short-tenure businesses.
Advisory positioning
Accountants using your software get a forward conversation with clients instead of a retrospective one.
How it fits into your product
How it embeds
- Nightly batch forecasting across your whole customer base, with on-demand recomputation when a user changes an assumption
- Chart-ready output for balance projections, confidence bands and pressure-point markers
- Scenario endpoints wired to interactive controls, so a user drags a hiring slider and sees runway move
- Webhooks when a customer’s projected shortfall date moves materially, which is the useful trigger for in-product messaging
- Multi-entity aggregation for accountants and groups managing several companies
- Deployment inside your infrastructure where bank and ledger data must not leave your environment
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How accurate is a six-month forecast?
Much less accurate than a thirty-day one, and the API reports both separately rather than quoting a single figure. Recurring commitments and tax events project well over long horizons. New sales do not. For a business where new revenue dominates, the honest output is a wide band at six months and a usable number at thirty days, and we would present it that way rather than flattering the model.
What if a business has only a few months of history?
Then recurring detection is weak and seasonality is unknowable. The forecast falls back on ledger commitments and open invoices, borrows structure from comparable entities, and returns low confidence with that borrowing stated explicitly. It is still more useful than a straight line, but we would not dress it up as a well-fitted forecast.
Does this need bank data, or is the ledger enough?
The ledger alone gives you an accrual view, which is not the same thing as cash and can be badly misleading for a business with long payment terms. You can build a forecast from ledger data only, and we have scoped it that way, but the accuracy difference is large enough that we would always recommend the bank feed.
Can lenders use this for credit decisions?
As one input, with care. If the forecast informs lending decisions it becomes subject to your credit governance — documentation, validation, fair-lending review and the explainability your regulator expects. That changes the build, so it needs to be stated as a requirement at the start rather than added once it is live.
Will it predict a specific customer paying late?
It predicts an expected payment date with uncertainty, built on that customer’s own payment history where you have it. It does not know that their finance director is on leave. Per-invoice prediction is reliable in aggregate and noisy case by case, which is the right way to read it.
Related blueprints
Invoice Payment Prediction API
Expected payment date and late-payment risk per invoice, for the B2B platforms whose customers are waiting to be paid.
Credit Risk Scoring API
Probability-of-default modelling on permitted data, built to be explained, documented and defended to a regulator.
Transaction Fraud Scoring API
Real-time risk scores for payments and account events, with explanations your analysts and your customers can both understand.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.