Sales forecasting is a statistics problem wearing an AI Agent costume in most vendor pitches, and it's worth separating the two before designing anything. The actual number-crunching — projecting future revenue from historical order patterns — belongs to time-series methods that have existed for decades. What an agent legitimately adds is context an equation can't reach: qualitative signals from open opportunities, deal-specific risk factors, and a natural-language explanation of why the number moved.
The forecast itself should be statistical
Pull historical sales order and invoice data from Acumatica's SOOrder and ARInvoice tables (or the equivalent GI), aggregate by period, and run it through a standard forecasting method — exponential smoothing, or a seasonal ARIMA if the business has clear seasonality. These methods are well-understood, produce confidence intervals, and don't hallucinate a number that looks plausible but has no basis in the data. An LLM asked to directly project "next quarter's revenue" from a table of historical numbers will sometimes get close and sometimes be confidently, quietly wrong — and a wrong revenue forecast used for staffing or inventory decisions is expensive in a way that's hard to catch after the fact.
Compute the forecast with a statistical model. Only afterward, hand the computed forecast plus supporting context to an LLM to narrate. Never let the LLM compute the forecast number itself — that's the one place a wrong answer directly costs money.
Where the agent adds real value: blending pipeline signal
Pure time-series forecasting misses information sitting in open CRM opportunities — deal stage, probability, expected close date — that a salesperson already knows but that historical order data doesn't capture yet. An agent's useful job is pulling open opportunity data alongside the statistical baseline and adjusting the narrative (not necessarily the number) to flag when the pipeline looks thinner or richer than the historical trend alone would suggest. This is synthesis across two data sources, which is squarely in an LLM's strength zone, done well.
Explaining variance, not just reporting it
The recurring ask from sales leadership isn't "what's the number" — it's "why did the number move since last week." That requires diffing the current forecast inputs against the prior period's: which opportunities moved stage, which deals slipped their close date, which large orders posted since the last forecast run. Compute that diff in code, then ask the LLM to turn a list of deltas into two or three sentences a VP will read in a Monday pipeline review instead of a wall of numbers.
def build_forecast_narrative(current, previous, llm):
delta = {
"forecast_change_pct": round((current.total - previous.total) / previous.total * 100, 1),
"opportunities_advanced": diff_stage_changes(current.pipeline, previous.pipeline),
"large_orders_posted": [o for o in current.new_orders if o.amount > 50_000],
"slipped_close_dates": diff_slipped_deals(current.pipeline, previous.pipeline),
}
# LLM only narrates the pre-computed delta, never recomputes the forecast
return llm.complete(system=NARRATION_SYSTEM_PROMPT, user=json.dumps(delta), max_tokens=150)Accuracy tracking is not optional
Every forecast should be logged with a timestamp and compared against actuals once the period closes. Without this, "the forecast is helpful" is an opinion; with it, you can report forecast accuracy as a real metric (mean absolute percentage error, typically) and catch model drift — a statistical model trained on pre-disruption data quietly getting worse as market conditions shift is invisible unless someone is measuring it against what actually happened.
Be honest about forecast horizon
Statistical forecasts get less reliable the further out they project, and that uncertainty should be visible, not smoothed over into false confidence. Present a confidence band, not a single number, and widen it appropriately for longer horizons. A forecast presented as a bare point estimate trains its consumers to over-trust a number that was never that precise to begin with.
| Component | Method |
|---|---|
| Baseline revenue projection | Statistical time-series model (exponential smoothing, ARIMA) |
| Pipeline signal blending | Agent synthesizing CRM opportunity data alongside baseline |
| Variance explanation | Computed diff, narrated by LLM |
| Accuracy tracking | Logged forecast vs. actual, MAPE over time |
Wrapping up
Sales forecasting works best as a statistical model doing the actual projection, with an agent layered on top to blend in pipeline signal and narrate what changed and why. Keep the LLM out of the arithmetic entirely, track accuracy against real outcomes, and show a confidence band instead of a single deceptively precise number.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.