MANAGEMENT AND FINANCE
Reviewing budget variances with operational context
Illustrative project
Illustrative scenario. The data and calculations are assumptions used to explain the application.
Application: Management and finance
Business type: Maintenance services provider with contracts across several regions
Key decision: Which variances need an explanation, a revised forecast, or a spending decision from leadership.
The context and the question
The maintenance provider manages maintenance contracts across several regions. Each manager prepares a budget, and Finance consolidates the results. Monthly reviews reveal spending above plan in some units and below it in others. Comparisons are difficult: a purchase may have been recorded late, a service may still be awaiting invoicing, or a unit may be handling a different volume than expected.
Leadership needs to distinguish a variance that calls for intervention from a timing difference. It also needs to know which spending is already covered by an authorized commitment. Comparing the budget only with payments could conceal obligations or give a misleading view of performance.
Sources and shared definitions
The project would start with the approved budget and its versions, accounting records, cost centers, authorized orders, and relevant operational data, such as completed services. The availability and quality of accrual data would be reviewed. Paid, accrued, and committed amounts would be shown separately, with rules to prevent double counting.
Finance would define the mapping between accounts and budget categories. Regional managers would have access to their own area; Leadership and Finance would have the consolidated views they are authorized to use. The first phase could work with controlled files, without assuming direct integration with every system. An item without an agreed classification would be sent for review, rather than automatically allocated to make the totals match.
What could be built
STRTGY could develop a budget control view that links each variance to its account, unit, period, and supporting evidence. The team would set review thresholds that combine absolute amounts and percentage variances, avoiding disproportionate alerts when a budget is small or zero.
The solution would allow users to record explanations and compare period-end scenarios built on explicit assumptions. Each forecast would have a version, author, and approval status. It would not replace the accounting system or decide spending cuts, hiring, or payments. AI, if included in the scope, would help prepare summaries of the available context. Figures and scenarios would rely on verifiable calculations and financial review.
A review cycle with clear responsibilities
Finance selects the version. It fixes the budget, cutoff period, and comparison rules so that different plans are not mixed together.
The workflow organizes the information. It links transactions, units, and commitments, and identifies records that need clarification.
Accounting validates the totals. It confirms the cutoff and the treatment of accruals. Discrepancies remain visible and prevent the information from being labeled as validated.
The solution prepares the review. It ranks variances using agreed criteria and shows operational volumes where they are available and comparable.
Each manager provides an explanation. They attach evidence and distinguish timing, volume, price, and execution factors. An unsupported explanation remains pending.
Finance builds scenarios. It adjusts authorized assumptions and compares their effects. Earlier versions remain identifiable.
Leadership decides. It approves a forecast or requests more information. Financial commitments continue to follow their usual authorization processes outside this analysis.
The team reviews what was agreed. It checks actions and assumptions against the next cutoff, without overwriting the history.
The user experience
Leadership would see a comparison by unit showing the budget, recorded expenditure, commitments, and approved forecast. Opening a variance would reveal the calculation, related transactions, the manager's explanation, and what still needs validation. A scenario would clearly show its assumptions so it could not be mistaken for an observed result. Missing information would be distinguished from a value of zero.
Photographic illustration of reviewing work orders and operational evidence to explain variances before a financial decision.
Deliverables and phases
Deliverables could include an account and cost center mapping, comparison rules, review views, an explanation log, and an update procedure. The work would move from source assessment to a pilot in representative units. Testing would then cover incomplete closes, reclassifications, and budget changes. Rollout would depend on Finance's acceptance and the permissions and integrations available. The schedule would be agreed after the initial assessment.
Metrics and baseline
Complete cycles would be observed before the pilot, using identical closing criteria.
Consolidation time: hours from source availability to a review-ready package, separating waiting time from active work.
Traceability: reviewed items with source evidence / reviewed items × 100.
Variance explanation: priority variances with a validated explanation / priority variances × 100.
Corrections: items corrected after release / items released × 100.
Hypothetical economic example
With six units, two monthly reviews per unit, and five hours of preparation per review, the work would total 60 hours. If a pilot validated three-hour preparation, the difference would be 6 × 2 × (5 − 3) = 24 hours. At an assumed internal cost of MXN 500 per hour, that would represent MXN 12,000 per month in available work capacity. This excludes the costs of the solution and does not demonstrate a reduction in budgeted spending. Each economic effect would need to be evaluated with evidence and without double counting benefits.
How much of a variance can you explain before asking for another file? Let's review your budget cycle.