Budget vs. Actual Variance Analysis

The control flow a finance team actually needs.

The ERP surface involved.

Variance calculations must use the formula (Actual − Budget) with sign convention matching income-statement presentation (favorable revenue variance is positive; favorable expense variance is positive); drill-down from variance line to individual GL journal entries must be available in three clicks; commentary must be required on any variance exceeding configurable absolute or percentage thresholds; report must be filterable by entity, department, cost center, account, and period; export to Excel must preserve formulas; system must clearly label the budget version used for comparison.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

negative) when report is generated before period close is confirmed then 409 with error_code: period_not_closed.

Audit evidence is a chain, not a folder.

Given a closed GL period with imported actuals and an approved budget version;
when FP&A Analyst opens the variance report;
then system displays (Actual − Budget) with correct income-statement sign convention, drill-down to individual GL journal entries is available in three clicks, and commentary is required on variances exceeding configurable absolute or percentage thresholds;
(negative) when report is generated before period close is confirmed then 409 with error_code: period_not_closed.

variance_report { id: vr_*, period: date, budget_version_id: string, entity_id: string, generated_at: timestamp };
variance_line { id: vl_*, report_id: string, account_code: string, cost_center_code: string, actual_minor: int64, budget_minor: int64, variance_minor: int64, variance_pct: numeric, currency_code: char(3), commentary: string };
(reference, product may differ).

GET /v1/variance-reports?period={date}&budget_version_id={id}&entity_id={id} -> 200 { lines: [] };
GET /v1/variance-reports/{id}/lines/{line_id}/journal-entries;
PUT /v1/variance-reports/{id}/lines/{line_id}/commentary { text, category };
emits variance.report_approved event.

DRAFT -> COMMENTARY_PENDING -> APPROVED;
guard: APPROVED requires commentary on all lines exceeding threshold;
variance_minor formula: actual_minor − budget_minor with income-statement sign convention enforced.

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

`variance_report` { id: vr_*, period: date, budget_version_id: string, entity_id: string, generated_at: timestamp }; `variance_line` { id: vl_*, report_id: string, account_code: string, cost_center_code: string, actual_minor: int64, budget_minor: int64, variance_minor: int64, variance_pct: numeric, currency_code: char(3), commentary: string }; (reference, product may differ).

`GET /v1/variance-reports?period={date}&budget_version_id={id}&entity_id={id}` -> 200 { lines: [] }; `GET /v1/variance-reports/{id}/lines/{line_id}/journal-entries`; `PUT /v1/variance-reports/{id}/lines/{line_id}/commentary` { text, category }; emits `variance.report_approved` event.

`DRAFT -> COMMENTARY_PENDING -> APPROVED`; guard: APPROVED requires commentary on all lines exceeding threshold; variance_minor formula: actual_minor − budget_minor with income-statement sign convention enforced.