Reporting looks back; planning looks forward. FP&A — budgets, rolling forecasts, scenario models — runs on the same ERP-fed warehouse, just pointed at the future. This leaf stays ERP-agnostic, leans on driver-based models instead of a thousand-tab spreadsheet, and keeps the human owning the assumptions.
Financial planning and analysis is the forward half of finance: the annual budget, the rolling forecast that updates it, and the scenario models that ask "what if input costs rise 8%?". Where reporting tells you what happened, FP&A tells you what's likely to — and what to do about it.
The crucial idea: planning isn't a separate dataset. A good forecast is built on actuals, and the actuals already live in the ERP and the warehouse the reporting leaf feeds. FP&A reuses that foundation and layers drivers on top — volume, price, headcount, capacity — rather than re-keying history into a spreadsheet that drifts from the books within a month.
A forecast is an opinion about the future, owned by finance. The agent and the tooling assemble it from history and assumptions; they never post it to the ledger. When a plan becomes a commitment (a budget the business is held to), it's a human decision, versioned alongside the reports.
Every forecast is history extended by assumptions. The history comes from the ERP; the assumptions are the drivers a finance team actually argues about.
| Ingredient | Source | Example |
|---|---|---|
| Actuals | ERP / warehouse marts | Last 24 months of revenue, COGS, opex by cost centre |
| Volume drivers | Sales pipeline, ops capacity | Units sold, machine hours, billable headcount |
| Price drivers | Assumption | Selling-price increases, input-cost inflation |
| Cost drivers | HR + ERP | Headcount plan, salary review %, supplier terms |
| Cash drivers | AR/AP ageing | Collection days, payment terms, capex timing |
Driver-based planning is the difference between a forecast you can defend and a number you typed. Change one assumption — "we win the big contract, volume +20%" — and the model recomputes margin and cash without anyone editing 40 cells. The drivers are the conversation; the maths is the tooling's job.
FP&A produces three related things that teams often blur together. Keeping them distinct is half the discipline.
| Artefact | Question it answers | Cadence |
|---|---|---|
| Budget | What did we commit to this year? | Annual, then fixed |
| Forecast | What do we now expect, given actuals? | Rolling — monthly or quarterly |
| Scenario | What if a key assumption changes? | Ad-hoc, on demand |
The plan-vs-actual view is where this connects back to reporting: every month, the management pack shows the forecast next to what really happened, the variance, and the narrative. That loop — forecast, measure, re-forecast — is the entire point of FP&A, and it only works when the actuals and the plan sit in the same warehouse.
If you've stood up the warehouse + Evidence stack for reporting (see the reporting leaf), FP&A is mostly an extension of it — not a new tool to buy. ERPNext's open data makes the actuals free to pull; the planning logic lives as version-controlled SQL alongside the reports.
Driver tables in Git mean a forecast is auditable: you can see exactly which assumption changed between the March and April forecasts, and who changed it. That's something a sprawling spreadsheet can never give you. Heavier dedicated FP&A platforms (Pigment, Anaplan, Planful) exist for large, complex planning estates — but for a mid-sized business already on an open ERP, the warehouse-plus-code approach is far cheaper and reproducible.
Forecasting is judgement plus arithmetic. The agent is excellent at the arithmetic and the first-draft narrative, and must stay out of the judgement.
Extend the trend from actuals, seasonalise it, and present a baseline the team can argue with. A starting point beats a blank sheet.
"Show me downside, base and upside on input-cost inflation." The agent spins the driver dials and renders the three P&Ls; finance picks which to plan against.
Draft the plan-vs-actual narrative each month from the numbers. Finance edits the story; the figures come from SQL.
The agent never decides that volume will grow 20% or that the contract lands. It models the consequence of an assumption a person owns and can defend to a board.
| Build it on the warehouse when | A spreadsheet is fine when |
|---|---|
| You re-forecast monthly and want plan-vs-actual automatically | You budget once a year and rarely revisit it |
| Multiple cost centres / entities to roll up | One simple P&L, a few lines |
| You need to defend which assumption changed when | The plan is directional and low-stakes |
| You already run the reporting warehouse | There's no warehouse and the ROI isn't there yet |
The honest line: a spreadsheet is a perfectly good FP&A tool for a small, stable business. The warehouse approach earns its keep when the forecast is frequent, multi-dimensional, and has to reconcile to the actuals — which is exactly when spreadsheets quietly start lying.
Two local realities belong in the drivers, not the footnotes. Forex: if you import inputs or export goods, the ZAR/USD rate is a planning assumption with real margin consequences — model a range, not a point. Interest rates: SARB's repo rate feeds finance costs and the cost of working capital, so a rate-sensitivity scenario is worth keeping warm.
B-BBEE spend targets are themselves a plan — procurement and skills-development budgets that the same model can track against actuals. And the discipline holds: an agent can model the rand at R19 or R21, but the assumption it plans on is a human's call.
FP&A and reporting are two views on one warehouse — backward and forward.
The open tooling the warehouse-backed planning approach is built on.