A mid-month spend forecast projects a large overrun from two weeks of actuals — what makes that projection wrong?

## What a forecast actually computes A month-end spend projection is rarely sophisticated. In its usual form it is: ```pseudocode forecast = spendSoFar / daysElapsed * daysInPeriod ``` Some implementations add a trend term, or fit the last few days more heavily than the first few. The assumption underneath all of them is the same: **the days that remain will resemble the days that have passed.** Everything that goes wrong with a forecast is a way that assumption is false. ## Five inputs that break it | Input | Direction of the error | Why | |---|---|---| | A one-off charge early in the period | Over-predicts | Divided by days elapsed and multiplied by days in the period, a single charge is counted many times over | | A charge on a monthly cadence | Over-predicts | A fee that lands once is treated as if it lands every day | | Weekday and weekend shape | Either way | A window that is mostly weekdays projects a weekday level across weekend days, and the reverse | | Monotonically growing stored volume | Under-predicts | Per-unit-time storage charges rise with the volume held, so the early days were genuinely cheaper than the late ones | | A deliberate change mid-period | Under-predicts a scale-up, over-predicts a scale-down | The elapsed window describes a system that no longer exists | The first two are the ones that produce the alarming projection on day two and the sheepish retraction on day four. A single large charge — a bulk data movement, a one-time retrieval, a migration — dominates a short elapsed window completely. The fourth is the one people get backwards. Storage charged per unit of volume per unit of time costs *more* per day as the stored volume grows, so a naive run rate built on the first fortnight of a growing dataset systematically **under**-predicts the period's total. It is the one direction in which a forecast is quietly reassuring while being wrong. ## Making the projection useful The repair is not a better curve fit; it is decomposition. 1. **Split the charges by recurrence** before extrapolating: one-off, monthly-cadence, and genuinely variable. Add the first two back once, and extrapolate only the third. 2. **Forecast per charge dimension and sum the parts.** A dimension that grows with stored volume and a dimension that tracks request count have different shapes, and a forecast on the total averages them into something that describes neither. 3. **Re-anchor after a deliberate change.** If capacity tripled on the 9th, the window that matters starts on the 9th, not on the 1st — and the forecast will be noisier for a few days because it has less data, which is honest rather than a defect. 4. **State the assumption next to the number.** "On the last six days' run rate, excluding the one-off on the 3rd" is a sentence someone can argue with. A bare projected figure is not. ## What the forecast is genuinely good for It is worth being clear about why teams keep a forecast in spite of all of the above: **a projection can cross a budget while there is still period left to act, and an actual cannot.** An actual figure crosses the line near the end, by construction. That is the whole value, and it is real — a threshold evaluated against a projected figure is the earliest signal in the entire billing system. Platforms differ on whether they let you set one; where yours does, it is the threshold worth having. It is also compounded by the reporting lag underneath it: the actuals feeding the projection are themselves hours old and provisional until the period closes, so an early-period projection is an extrapolation of an estimate. That is not an argument against forecasting. It is an argument against reporting the projected figure to anyone as though it were a commitment. ## How to read one in practice When a projection shows a large overrun, the useful sequence is short: - **Look at the daily series, not the projection.** A step tells you something changed on a date; a ramp tells you something is growing; a single tall bar tells you the projection is an artefact of one charge. - **Check for a one-off.** If removing one day's charge collapses the overrun, you have your answer and there is nothing to investigate. - **Check what changed on the day the curve bent.** Deployments, capacity changes, a new data feed, a retention setting. - **Only then ask what dimension it landed in**, which is where this stops being a forecasting question and becomes a question about what generates the charge — a different subject, owned elsewhere in this category.