Budget Consolidation / Reconciliation is where ERP discipline either begins or breaks.
Top-Down and Bottom-Up Budget Reconciliation looks operational from far away. In a real finance team, it is a chain of assertions: the right actor started the work, the required records existed, the control policy was applied, the state change was preserved, and the outcome can be explained later without rebuilding the transaction from emails and spreadsheets.
The expected business outcome is specific: Annual budget where the sum of departmental plans reconciles to CFO-approved company targets, eliminating the manual spreadsheet reconciliation that previously consumed 2 - 3 weeks of FP&A time.
The control flow a finance team actually needs.
Step 1
Reconciliation Report Display Top-Down...
Step 2
Drill-Down From A Gap Line To...
Step 3
Configurable Reconciliation Tolerance
Step 4
Adjustments Made During Reconciliation...
Step 5
Reconciliation Be Recalculated In Real...
The ERP surface involved.
Module
Budget Consolidation / Reconciliation
Actors
FP&A Manager, CFO, Department Managers
Tier
Tier 2
Finance area
Budgeting, Planning & FP&A
Region lens
US and UK finance teams
Publication date
April 12, 2026
Reconciliation report must display top-down targets, bottom-up totals, and variance in both absolute and percentage terms for every P&L account group; drill-down from a gap line to individual departmental submissions must be available; system must support configurable reconciliation tolerance (e.g., ±1% of target); adjustments made during reconciliation must be versioned and attributed to the user who made them; reconciliation must be recalculated in real time as adjustments are entered; final reconciled budget must be exportable as a structured Excel file with separate sheets per department.
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.
| Control area | Requirement | Acceptance proof |
|---|---|---|
| Control 1 | Reconciliation report must display top-down targets, bottom-up totals, and variance in both absolute and percentage terms for every P&L account group | Given top-down budget targets set by CFO and bottom-up departmental submissions |
| Control 2 | drill-down from a gap line to individual departmental submissions must be available | when FP&A Manager runs the reconciliation report |
| Control 3 | | then system displays top-down targets, bottom-up totals, and variance in absolute and percentage terms for every P&L account group, recalculates in real time as adjustments are entered, and all adjustments are versioned with user attribution |
| Control 4 | adjustments made during reconciliation must be versioned and attributed to the user who made them | negative) when reconciliation gap exceeds configurable tolerance and no adjustment is recorded then consolidation cannot be marked RECONCILED. |
| Control 5 | reconciliation must be recalculated in real time as adjustments are entered | Annual budget where the sum of departmental plans reconciles to CFO-approved company targets, eliminating the manual spreadsheet reconciliation that previously consumed 2 - 3 weeks of FP&A time. |
| Control 6 | final reconciled budget must be exportable as a structured Excel file with separate sheets per department. | Annual budget where the sum of departmental plans reconciles to CFO-approved company targets, eliminating the manual spreadsheet reconciliation that previously consumed 2 - 3 weeks of FP&A time. |
Audit evidence is a chain, not a folder.
| Evidence layer | What should be preserved |
|---|---|
| Business event | CFO establishes top-down budget targets for revenue, gross margin, and OPEX as a percentage of revenue. Department Managers independently build their budgets from the bottom up, based on their operational plans. FP&A Manager runs the reconciliation report, which compares the sum of bottom-up departmental submissions against the top-down targets for each P&L line. The report highlights gaps - where the bottom-up total exceeds the top-down target - with drill-down to the contributing departments. FP&A Manager facilitates a negotiation session with Department Managers and CFO to close the gap, adjusting specific departmental lines until the bottom-up sum reconciles to the top-down target within the approved tolerance. |
| Control rules | |
| Acceptance proof | Given top-down budget targets set by CFO and bottom-up departmental submissions; when FP&A Manager runs the reconciliation report; then system displays top-down targets, bottom-up totals, and variance in absolute and percentage terms for every P&L account group, recalculates in real time as adjustments are entered, and all adjustments are versioned with user attribution; (negative) when reconciliation gap exceeds configurable tolerance and no adjustment is recorded then consolidation cannot be marked RECONCILED. |
| Data record | |
| System event | |
| Lifecycle state | |
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.
Reference data model
`reconciliation_run` { id: rr_*, budget_version_id: string, tolerance_pct: numeric, status: enum(IN_PROGRESS/RECONCILED/FAILED), run_at: timestamp }; `reconciliation_line` { id: rl_*, run_id: string, account_group: string, topdown_target_minor: int64, bottomup_total_minor: int64, variance_minor: int64, variance_pct: numeric, currency_code: char(3) }; `reconciliation_adjustment` { id: ra_*, run_id: string, department: string, account_code: string, adjustment_minor: int64, currency_code: char(3), adjusted_by: string, adjusted_at: timestamp }; (reference, product may differ).API and events
`POST /v1/reconciliation-runs` { budget_version_id, tolerance_pct } -> 201 { id, status: IN_PROGRESS }; `GET /v1/reconciliation-runs/{id}/lines`; `POST /v1/reconciliation-runs/{id}/adjustments` { department, account_code, adjustment_minor, currency_code }; emits `budget.reconciliation_completed` event; idempotent via `external_id`.State transitions
`IN_PROGRESS -> RECONCILED`; terminal `FAILED`; guard: RECONCILED requires gap within tolerance_pct on all P&L account groups; adjustments versioned and attributed.Common implementation traps.
Treating the workflow as data entry
If the ERP only stores the final record, the team loses the decision trail that explains how the record became valid.
Hiding exception logic
Exceptions need owners, reason codes, and time stamps. A vague pending state is not a control.
Posting without recovery design
Retries, duplicate submissions, and partial failures must be explicit so the system does not create inconsistent records.
Skipping evidence design
A workflow that cannot produce evidence on demand will eventually push finance teams back into manual screenshots and spreadsheets.
Where Rivane fits.
Rivane is built for finance workflows where automation must stay tied to source documents, approvals, state transitions, ledger impact, reporting, and audit evidence. Use this guide as a checklist for evaluating whether an ERP workflow is merely digitized or actually controlled.
References and source basis.
These sources provide the standards, regulatory, or government context around the flow. They are included so the guide is useful to finance operators, auditors, and implementation teams, not only buyers reading software copy.