Custom financial predictive analytics
Appfront builds predictive models on financial data: liquidity, revenue, margin and debtor risk. Fed from your accounting system and bank transactions, and set up so the outcome can be defended to management and your auditor. A model nobody can explain does not get used, however well it scores on paper.
Forecasting on figures that must be accounted for
Financial predictive analytics applies statistics and machine learning to the figures already in your ledger: how much cash will be in the account in eight weeks, which invoices will arrive late, how revenue is tracking against budget. If you are looking for predictive analysis in a broader sense, such as attrition or customer churn, see our page on the predictive analytics dashboard. This is the financial vertical.
A machine maintenance forecast does not need to be defended to an auditor. A cash flow forecast on which management postpones an investment, or on which the going concern assumption in the annual accounts rests, does. That brings requirements found nowhere else: reconciliation to the general ledger, every variance traceable to an assumption, and the previous version reproducible. And the controller should be able to say in one sentence why the line falls in October.
Liquidity based on payment behaviour
Works from what each debtor actually does, not from the due date on the invoice.
Forecast alongside the budget
The budget remains the agreement, the rolling forecast the expectation. Two objects, the difference visible at a glance.
Debtor risk with an action attached
Per invoice, an expected payment date and a reason: call, request the order number, or discuss the credit limit.
Where financial forecasts fall apart in practice
The open items list is not a forecast
Forecasting cash flow by placing open items on their due dates merely repeats what is printed on the invoices. The predictive value lies in payment behaviour per debtor. Customer A consistently pays eleven days late. Customer B only pays after the first reminder. Customer C runs payment batches on the fifteenth and the last working day, so an invoice arriving on the sixteenth sits untouched for two weeks. An aggregated DSO hides all of that. You need the matched payments per debtor; customers with too few invoices belong in a segment.
More important is the distinction between two kinds of lateness. Someone who cannot pay is a credit risk. An invoice that stays put because the purchase order number is missing, and therefore never enters the approval flow, is a process failure on your side. Statistically they look alike; the required action is entirely different.
A single one-off order makes the model structurally too optimistic
Almost every history contains an unusually large order, an insurance payout or a sold asset. If you leave it in the training data as ordinary revenue, it lifts the baseline and the model forecasts too high for years. If you remove it, the series no longer ties to the annual accounts. The practical route is to leave the entry in place but flag it as one-off, by the controller who knows it.
Nobody needs to teach a model calendar effects: varying working days per month, holiday pay in May, VAT payments per quarter. These belong in as a deterministic component, which makes the learning part smaller and easier to explain. Also watch for breaks: an acquisition, a new pricing model or a migration to a different accounting package makes the period before it partly unusable.
Forecast and budget do not belong in the same field
The budget is an agreement: set, frozen, and the basis on which people are held to account. The rolling forecast is an expectation that changes by definition. As soon as a forecast is read as a revised budget, people start managing it rather than reporting on it.
We keep three layers separate, each with its own owner: a budget that is fixed for the financial year, a monthly rolling forecast where every version is retained, and beneath those a thirteen-week cash flow forecast using the direct method, built from actual bank movements, debtors and creditors.
Explainability outweighs accuracy in finance
This is the design choice we make explicit: for financial models we choose the most explainable variant, even if a more opaque model predicts marginally better. A gradient boosting model that sharpens the cash flow forecast by a fraction but cannot be justified to the board, the accountant or the bank is not used. A model that is actually used delivers more than a better model that sits on the shelf.
In practice that means an additive structure: baseline level, seasonality, known items, deterministic calendar items and expected payment behaviour per debtor. If the line falls in October, you can point to which component is falling and by how many euros. Where a learning model earns its place, for example in the probability that an invoice arrives late, we show the most heavily weighted factors using SHAP values, with the caveat that this explains the model, not reality.
We also deliver a range with scenarios rather than a single number, and record every forecast version in a frozen state. Without those versions you never measure whether the model is getting better.
A prediction is only worth something if an action hangs on it
The first design question is not what is technically feasible, but which decision would turn out differently if the prediction were correct. Whoever flags everything flags nothing: every signal needs a threshold and an owner.
Targeted chasing
The worklist is sorted by expected loss times amount, not by age, with the reason included. Six customers get a phone call instead of thirty standard emails.
Adjusting credit limits
Internal payment behaviour often signals something earlier than an external score. A credit insurer lowering its limit on a customer is itself a signal.
Postponing or proceeding with an expense
We test an investment against the cautious scenario: not whether it fits on average, but whether the tightest week survives.
Headroom under bank covenants
If ratios are tested quarterly, the model takes them into account, so you can see when the headroom is becoming tight.
Sources, integrations and one legal pitfall
For bookkeeping we work with the APIs of Exact Online, AFAS, Twinfield and Visma: the general ledger, open items and especially the reconciliations, where payment behaviour is recorded. We read in bank movements via CAMT.053, the ISO 20022 format that replaces MT940 and carries structured payment references. Do not build new processing on MT940: Rabobank is discontinuing the MT formats as of 15 November 2026.
One thing up front, because it often goes wrong: retrieving account information live via PSD2 is a licensed service supervised by De Nederlandsche Bank. We do not build our own integration for this, but work through a licensed provider. If the forecast ends up in an application your customers use, this touches on our fintech app development.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →GDPR, the AI Act and the accountant
If you only assess legal entities, the landscape is fairly clear. If your debtor file includes sole traders, freelancers or private individuals, things change: a natural person's payment behaviour is personal data, and under the GDPR a automated decision with legal effect requires human intervention. For that same group, Annex III of the AI Act classifies creditworthiness assessment as high risk, with fraud detection as an exception.
A third framework is often overlooked. If the model estimates a default probability for each debtor, that outcome affects the provision for doubtful debts. The expected credit loss approach under IFRS 9 looks at the entire debtor portfolio, not only at what is already overdue; the Dutch Accounting Standards Board has also permitted this under the Guidelines. The accountant will then want to know whether that outcome is reproducible.
- Distinguish legal entities and natural persons in the design
- Human intervention for decisions with legal effect
- Reproducible forecast versions for the audit
When custom development is not the answer
A mature market of packaged products exists for financial forecasting, and for many readers a package is the better choice. Visionplanner is widely used by Dutch accountancy firms, integrates with Exact Online and AFAS, and produces a forecast your accountant will immediately recognise. Agicap focuses on cash flow, and for more demanding planning there are Jedox, Pigment, Anaplan and Prophix. Such a package does not leave you with model maintenance.
Sometimes we give an even more honest answer: don't start with a model. If invoices are booked late or reconciliation is falling behind, no algorithm will help. Get your bookkeeping in order first.
Custom development makes sense for a revenue model that doesn't fit the standard mould: subscriptions with variable usage, instalment billing on long-running projects, consignment, or a platform model where receipts and payouts are separate. Also for sources no package supports, such as claims flows in healthcare and education, or when the forecast must land inside your own product.
That brings the burden that custom work carries. You become the owner of a model that ages: the customer base shifts, payment terms change, a major client leaves. Someone has to measure the drift and retrain. With a package, the vendor does that.
- Choose a package if your bookkeeping is standard and your revenue model is conventional
- Choose a package if you have no in-house capacity to maintain models
- Fix your administration first if bookings and reconciliation are falling behind
- Custom development for subscription, instalment, consignment or platform models
- Arrange ongoing model maintenance before you start, not after
Frequently Asked Questions
Technically the difference is small; in accountability it is large. A general dashboard predicts churn, demand or customer attrition, and nobody has to defend that to an accountant. A financial forecast does: once the board postpones an investment based on it, every euro must be traceable to an assumption.
For many organisations that is the right choice, and we say so. Visionplanner integrates with Exact Online and AFAS, Agicap focuses on cash flow, and Jedox, Pigment, Anaplan and Prophix on more demanding planning. Custom software only makes sense for an unusual revenue model, for data sources with no existing integration, or when the forecast needs to land in your own product.
By building the model so that the question can be answered. The forecast is the sum of recognisable components: base level, seasonality, known items, calendar events and expected payment behaviour per debtor. If the forecast drops in October, you can point to which component is falling. For a learning model, we show the most influential factors using SHAP values, as an explanation of the model rather than of reality.
That depends on who your debtors are. Annex III of the AI Act classifies the creditworthiness assessment of natural persons as high risk, with fraud detection as an exception. If you assess only legal entities, your model does not fall under this. For sole traders or private individuals it does, with requirements for logging, transparency and human oversight; the application date has, at the time of writing, been postponed to 2 December 2027.
You become the owner of the source code and the model specification, with documentation stating, for each component, which assumption it contains. The honest caveat is that owning the code is not the same as being able to maintain it; a model built in-house needs someone who understands the assumptions and checks them periodically. Assign that role before you start.
It will happen, and it is better to measure it than to wait and see. We record each forecast version as it stood at the time and later compare it against actual outcomes. We report the average error and the systematic bias. For cash flow series with weeks of no receipts, we use WAPE or MASE, because MAPE breaks down with low or zero values.
Related services
Predictive analytics dashboard
Predictive analysis outside the financial domain: failures, demand, customer churn and capacity. See predictive analytics dashboard.
Fintech app development
If the forecast lands in an application that customers use, additional requirements apply. See fintech app development.
Discuss your forecasting challenge
Tell us which decision you would like to make better and which systems your figures come from. We will assess whether your data can support the forecast and whether a packaged product would get you there faster. If it does, we will tell you so.