Forecasting and Anomaly Detection
The data that produces your monthly pack can also tell you what is coming and what looks wrong in it. Forecasting turns history into a defensible projection. Anomaly detection surfaces the transactions that do not fit the pattern, which is a fraud control and a data quality control at the same time. Both work on data you already have.
1
Baseline
Understand the history
2
Model
Fit and validate
3
Backtest
Prove it on the past
4
Deploy
Into the reporting cycle
5
Monitor
Watch for drift
How We Build It
01
Historical Baseline
We start by understanding the history properly, including the events that distort it. A model trained across a period containing a strike, a system migration or a pandemic will learn from noise unless those periods are identified.
- Historical depth and completeness assessed
- Seasonality and cyclical patterns identified
- One off events flagged and treated
- Data quality issues corrected before modelling
02
Model Development
We use the simplest approach that performs. A well specified statistical model is frequently more accurate and far more explainable than a complex one, and explainability matters when the output goes into a budget meeting.
- Simplest adequate method selected and justified
- Drivers and assumptions made explicit
- Confidence intervals rather than single point estimates
- Model documented so finance can interrogate it
03
Backtesting and Validation
A forecast is only credible if it can be shown to have worked. We backtest against held out history and report accuracy honestly, including the periods where the model performs poorly.
- Backtesting against held out historical periods
- Accuracy reported by horizon, near and far
- Comparison against your current forecasting method
- Conditions under which the model performs badly
04
Anomaly Detection
For detection we establish what normal looks like per category, supplier and user, then surface departures from it. Thresholds are tuned deliberately, because alerts that fire constantly get ignored within a fortnight.
- Normal behaviour established per dimension
- Threshold tuning to control false positive volume
- Duplicate, round sum and out of hours indicators
- Alerts routed to a named reviewer with context
05
Deployment and Monitoring
Output lands in the reporting cycle rather than in a separate tool nobody opens. Accuracy is monitored, because models drift as the business changes and a stale model is worse than none.
- Integration into the existing reporting pack
- Scheduled refresh aligned to the reporting calendar
- Ongoing accuracy monitoring against actuals
- Retraining triggers defined and automated
What You Receive
- Forecasting model with documented drivers and assumptions
- Backtesting results including where the model performs poorly
- Confidence intervals rather than single point estimates
- Anomaly detection with tuned thresholds and routing
- Integration into your existing reporting cycle
- Accuracy monitoring with defined retraining triggers
Indicative Timeline
A first forecasting model normally takes four to eight weeks. Historical data quality drives the timeline; where history is short or inconsistent, more effort goes into preparation than into modelling.
- Historical assessment and preparation: one to two weeks
- Model development and fitting: two weeks
- Backtesting and validation: one week
- Deployment, integration and handover: one to two weeks
What We Model
Applications where the data already exists and the pattern is stable enough to learn from.
Cash Flow
Short and medium term cash position based on receipts, payment behaviour and known commitments.
Revenue
Revenue and collection forecasting incorporating seasonality and customer payment patterns.
Debtor Behaviour
Which accounts are likely to pay late, ranked so collections effort goes where it recovers most.
Expenditure
Spend forecasting against budget, with variance predicted before it materialises.
Transaction Anomalies
Duplicates, round sums, out of hours activity and departures from supplier norms.
Budget Variance
Early warning where a line is trending toward overspend with time still to intervene.
Frequently Asked Questions
How accurate will the forecast be?
It depends on the stability of the underlying business, and we report accuracy from backtesting rather than claiming a figure up front. A useful forecast is one where the error is known and stated, not one that appears precise.
How much history do we need?
For seasonal patterns, ideally three years or more. Two is workable. Less than that and the model cannot distinguish seasonality from trend, and we would say so rather than build something unreliable.
Is this better than our spreadsheet forecast?
Sometimes not, and we backtest against your current method to find out. Where an experienced finance manager forecasts well, the value is in speed and consistency rather than accuracy. We report the comparison honestly.
Will anomaly detection find fraud?
It surfaces transactions that do not fit the pattern, which includes fraud and also includes legitimate exceptions and data errors. It is a detective control that directs attention, not a determination of wrongdoing.
How do you avoid alert fatigue?
By tuning thresholds deliberately and reviewing them after deployment. A detection system generating fifty alerts a day gets ignored inside a fortnight, so we tune for a volume a reviewer can genuinely work through.
What happens when the business changes?
Accuracy degrades, which is why monitoring against actuals is built in. Retraining triggers are defined so the model is refreshed on evidence of drift rather than on a calendar reminder nobody actions.
Related Services
This sits inside our AI Services practice. Related work: Automated Reporting and Analytics, which usually supplies the data these models run on, and Audit of AI and Automated Decisions where model output influences material decisions.
