The sequence most teams get backwards
Cash-flow forecasting for SMBs has become a standard feature expectation in modern neobank and challenger bank products. Every banking product roadmap in the space includes some version of "show the customer their projected balance" or "predict when they'll run out of cash." The ambition is right. The implementation sequence is almost always wrong.
The dominant failure mode: teams build the forecasting model first and treat transaction categorization as a data problem they'll clean up later. The result is a forecasting feature that launches with impressive-looking projections, gets adopted by a cohort of early users, and then quietly loses trust as users notice that the projections don't match their experience. By the time the team investigates, they've shipped a feature that an accountant would call "garbage in, garbage out" — the forecast algorithm is fine, the input data it was built on wasn't.
This article is about the correct sequence: categories first, forecasting second. Not because forecasting is unimportant — it's the feature users actually value — but because a forecast is only as trustworthy as the historical data it's trained on.
Why miscategorized inputs corrupt forecasting models
A cash-flow forecast for an SMB works by extending historical patterns into the future. The core inputs are: recurring income (customer payments, subscription revenue), recurring fixed expenses (rent, insurance, payroll, SaaS subscriptions), variable expenses (materials, contractor payments, usage-based costs), and one-time cash movements (equipment purchases, tax payments, loan draws). A good model identifies these categories from historical transaction data and projects their continuation forward, adjusted for trend and seasonality.
When transaction categories are miscategorized, the model's input buckets are contaminated. Consider a landscape services business with a reliable commercial maintenance contract that pays monthly via ACH. If those ACH credits are labeled TRANSFER instead of Revenue, the forecasting model excludes them from the recurring income stack. The model then sees an SMB with little predictable income and high predictable expenses — which looks like a cash-flow emergency. The forecast shows a projected negative balance in 45 days when the business is actually stable. That's not a forecasting model failure. That's an input classification failure masquerading as a forecasting failure.
The inverse problem is equally common: owner capital injections or business loan disbursements labeled as Revenue inflate the income forecast. The business looks like it's generating more operating cash than it is. A forecast built on that input suggests more runway than exists.
The practical category requirements for forecasting accuracy
Not all categorization accuracy matters equally for forecasting. The errors that break forecasting models are a specific subset:
- Revenue vs. Transfer misclassification — ACH credits that are customer payments must be distinguished from capital injections and intercompany transfers. This requires counterparty history and amount pattern analysis; raw MCC codes don't help on ACH transactions.
- Recurring vs. one-time expense identification — A recurring expense that appears in the history as one-time (due to classification inconsistency across months) does not get projected forward. The model underestimates fixed costs.
- Payroll identification — Payroll runs are typically the largest recurring expense for service businesses. Payroll ACH debits must be correctly identified and projected forward on their cadence (weekly, bi-weekly, semi-monthly). Misclassification as generic debits destroys the most important recurring expense signal.
- Tax and debt service — Quarterly estimated tax payments and monthly loan payments need their own categories. Mixing them with operating expenses distorts average monthly expense trends.
Getting these four categories right is more important than getting 100% of categories right for forecasting purposes. The Pareto principle applies: 20% of category types drive 80% of forecast accuracy impact.
Building the forecasting layer on corrected history
Once you have a corrected transaction history — where the categories listed above are reliably accurate — the forecasting layer becomes tractable. The model can identify recurring income streams with known counterparties and cadences, project them forward with appropriate confidence intervals. It can stack recurring fixed expenses against projected income to produce a cash-flow waterfall: income minus fixed costs gives operating margin, variable costs are projected as a percentage of revenue where there's a historical relationship, one-time items are flagged as non-recurring and excluded from the baseline projection.
A 90-day horizon is the practical limit for SMB cash-flow forecasting with meaningful accuracy. Beyond 90 days, the confidence interval on any individual projection becomes wide enough to be unhelpful for business decisions. Within 90 days — especially the first 30 — a well-constructed forecast on clean data gives useful signal: will the business have enough operating cash to cover the next payroll cycle? Is a large receivable overdue enough to create a near-term liquidity problem? Should the owner defer a capital expenditure by two weeks?
We're not saying cash-flow forecasting is easy or that clean categories magically solve it — the model design, confidence scoring, seasonality adjustment, and edge case handling are genuinely complex engineering problems. We're saying you cannot solve those problems well on top of corrupted input data. The forecasting layer presupposes an accuracy layer beneath it.
A scenario: what happens when you fix the sequence
Imagine a small consulting firm that processes about 150 transactions per month through their business checking account. They have four major revenue clients, paying via ACH on 30-45 day net terms. They pay rent, payroll (two employees plus themselves), business insurance, and a collection of SaaS tools. Occasional equipment and travel expenses round out the picture.
Before categorization correction: the four ACH client payments are variably labeled — sometimes TRANSFER, sometimes ELECTRONIC_PAYMENT. The payroll runs are labeled ACH_DEBIT_MISC. The rent ACH is labeled correctly. A forecasting model built on this data sees inconsistent income and underestimates payroll as a recurring cost. The 30-day projection shows a cash surplus that is actually smaller than projected, because projected income is overestimated (two of the ACH credits happened to be labeled as income, two as transfers, so only half the revenue is in the income stack). The owner sees a forecast that says they're comfortable; they defer invoicing follow-up on a slow-paying client. Two weeks later, a cash-flow crunch they didn't see coming.
After categorization correction: all four client payment ACH credits are correctly identified as Revenue based on counterparty history and amount pattern. Payroll is correctly identified as a bi-weekly recurring cost. The 30-day forecast correctly shows a moderate cash position with a flagged risk: one receivable is 12 days past due and if it doesn't clear in the next 10 days, the payroll cycle in week 3 will need coverage. The owner follows up on the overdue invoice. That's the feature earning its place in the product.
Measuring forecast quality independently of categorization quality
One underappreciated practice is tracking forecast accuracy and categorization accuracy as separate metrics. A team that conflates them will attribute forecast errors to model problems when they're actually categorization problems, and vice versa. Build two measurement loops: one that compares categorized transactions against a human-reviewed sample monthly, and one that compares 30-day forecast projections against actual outcomes for the same accounts monthly. If forecast error is high and categorization accuracy is also high, you have a model problem. If forecast error is high and categorization accuracy is low, the sequence is the issue — fix categories first.
The metrics that matter for each: categorization accuracy should be measured on the transaction types that most impact forecasting (ACH transfers, payroll, recurring vendors) rather than overall accuracy across all transactions. Forecast accuracy should be measured as mean absolute percentage error on the 30-day projected balance compared to actual ending balance, segmented by business type — service businesses with regular ACH revenue will forecast differently than retail businesses with card-based revenue and higher variability.
Building this measurement infrastructure before shipping the forecast feature is the single most valuable investment a banking product team can make. It gives you the data to distinguish model errors from data quality errors — and to fix the right thing when something goes wrong.