How planning, budgeting and forecasting is set up in finance and ERP systems

In most organisations the general ledger holds actuals, while budgets and forecasts are built in a separate planning tool or spreadsheet model. Approved figures are then loaded into the ERP as a budget version. That version drives spending controls and is compared with actuals once each period closes.

Where the planning work happens

Most ERP systems carry a budget ledger or a version table that accepts figures by account, cost centre and period. The actual building of a budget rarely happens there. Finance teams draft in spreadsheets or a dedicated planning application and collect input from department heads. They then push an approved set of figures into the ERP through an import file or an integration job.

That split matters more than it looks. The planning model holds the drivers: headcount, pay rates, volumes, project phasing. The ERP only sees the result. When someone asks why a cost centre was given a particular budget, the answer usually lives outside the system of record.

Versions, structures and the chart of accounts

Budgets are stored as named versions. A typical setup keeps an original approved budget alongside a revised budget that reflects in-year changes, plus one or more forecast versions. Each is a snapshot, and good practice locks a version once it is approved so that later edits create a new one.

Planning is often done at a coarser grain than the ledger records actuals. A department might budget one figure for travel while the ledger splits it across several accounts. A mapping table bridges the gap. When the chart of accounts or the cost centre hierarchy changes, that mapping is the first thing to break, and variance reports quietly start showing nonsense.

Turning the approved budget into controls

Loading the numbers is only part of implementation. Many setups switch on commitment control or funds checking. A requisition or purchase order is tested against remaining budget before it can be approved. Depending on configuration, an overrun produces a warning or a hard stop.

In the public sector this control carries legal weight. Spending beyond an appropriation is a reportable breach, so funds checking tends to be strict and closely monitored. Commercial firms usually apply hard stops only to capital spend or to discretionary lines, and set tolerances elsewhere. Some organisations release budget in tranches through the year so that managers cannot commit the whole amount early.

Forecasts and the cash view

Forecasts normally start from closed actuals to date, with the remaining periods re-estimated. Rolling forecasts extend the horizon each time one is produced. On the revenue side, a sound forecast includes accruals for income that has been earned but not yet billed. Without them, the outlook looks weaker than reality just after a busy period.

Cash forecasting is frequently a separate exercise owned by treasury. It draws on payables schedules, expected customer receipts, payroll and debt payments, and it flags unusually large deposits or disbursements so funding can be arranged. The profit forecast and the cash projection often disagree. Someone should own explaining the difference, and in many places nobody does.

Variance reporting and the ledger

Variance reports compare a budget or forecast version with actuals across the same dimensions. They are usually built in a reporting or analytics layer that reads both the planning data and the ledger. The control that matters most is traceability. Report totals should tie to general ledger balances, and that tie should be checked before anything is circulated.

Policy normally sets the thresholds above which a manager must explain a variance. The explanations themselves often travel by email and end up scattered, which makes the next planning round harder than it needs to be.

Policies, workflow and access

Budget policy defines who approves the plan and when money may move between lines. It also covers how reallocations are recorded. In the system, this shows up as workflow for budget transfers and as security over who can post to each version. Weak setups let planners overwrite approved figures directly, so the audit trail disappears.

Questions to ask the people who run it

• Where is the budget really built, and which file or model is treated as the master?
• When an approved figure changes, who loads the revision, and does the original version survive untouched?
• Which accounts or cost centres trigger a hard stop, and what do people do when they hit one?
• Who can move budget between lines without anyone signing off?
• Does the forecast start from closed actuals, or from an estimate made before close?
• How does the treasury cash projection relate to the finance forecast, and who reconciles the two?
• Do variance reports tie to the trial balance, and who checks that before they go out?
• Where do variance explanations end up once they are written?

Where changes tend to break things

Most trouble comes from touching structure. A new cost centre hierarchy, a revised chart of accounts or a replacement planning tool will disturb the mappings and the integration jobs. Comparisons with prior versions are affected too. Test a full cycle of load, funds check, forecast and variance report against known figures before switching over. Keep the old mappings available until the first variance reports under the new structure have been reconciled to the ledger.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.