Chapter 05 — Budgeting, Estimates & Variance Analysis

·article·2026-06-12

Chapter 05 — Budgeting, Estimates & Variance Analysis

"A budget is a theory. Actuals are the experiment. Variance is what you learn."

This chapter covers the planning side of cost accounting: how to estimate the cost of work before it happens, how to capture what it actually cost, how to analyze the gap (variance), and how to roll task-level costs up into goal-level budgets using weighted allocation.

5.1 Estimates vs. Actuals — Two Records, Never One

A disciplined cost system keeps the estimate and the actual as separate, immutable records:

Estimate: made before (or early in) the work — e.g., an engineering estimate of effort × rate.
Actual: captured from real sources as the work happens — payroll allocations, cloud bills, vendor invoices.

Never overwrite an estimate with the actual. The gap between them is the most valuable management signal you have.

Worked Example — Estimating a Task

Task: "Build payment-reconciliation service."

Estimate:
   Backend engineer    80 h × $60/h  = $4,800
   QA engineer         20 h × $45/h  =   $900
   Cloud (test env)    1 month        =   $300
                                       -------
   Total estimate                      $6,000

Capturing Actuals

Three weeks later, from timesheets and the cloud bill:

Actuals:
   Backend engineer   102 h × $60/h  = $6,120
   QA engineer         18 h × $45/h  =   $810
   Cloud (test env)                   =   $470
                                       -------
   Total actual                        $7,400

5.2 Variance Analysis

Variance ($) = Actual − Estimate
Variance (%) = (Actual − Estimate) ÷ Estimate

Sign convention: with Actual − Estimate, positive = over budget for costs. (Some teams flip the sign; pick one convention and document it.)

Worked Example (continuing)

Variance ($) = $7,400 − $6,000 = +$1,400
Variance (%) = $1,400 ÷ $6,000 = +23.3%   → over budget

Decomposing the Variance

A good analysis splits variance into price and quantity components:

Backend line:
   Quantity variance = (102 − 80) h × $60 = +$1,320   ← took longer
   Price variance    = (60 − 60) × 102 h  =     $0    ← rate as planned

Cloud line:
   +$170 — usage higher than the flat estimate

Conclusion: the overrun is almost entirely effort under-estimation (22 extra engineering hours), not rate or vendor pricing. That tells you to fix the estimation process, not to renegotiate salaries.

Variance Thresholds

A common operating rule:

Variance	Action
within ±10%	normal noise — no action
±10–25%	flag; review at sprint/month close
> ±25%	requires written explanation and re-baselining

5.3 From Tasks to Goals — Weighted Allocation

Strategic goals are delivered through many tasks, and a single task may serve several goals at once. To build a goal's budget honestly, each task's cost is split across its goals with allocation weights that sum to 100% per task.

Worked Example

Two goals:

G1 — "Launch in EU market"
G2 — "Achieve SOC 2 compliance"

Three tasks with costs and weights:

Task                          Cost      → G1      → G2
─────────────────────────────────────────────────────────
T1  Data-residency storage   $9,000     60%       40%
T2  Audit-logging service    $5,000     20%       80%
T3  EU payment integration   $6,500    100%        0%

Goal budgets (from estimates):

G1 = 0.60×$9,000 + 0.20×$5,000 + 1.00×$6,500
   = $5,400 + $1,000 + $6,500 = $12,900

G2 = 0.40×$9,000 + 0.80×$5,000 + 0.00×$6,500
   = $3,600 + $4,000 + $0     =  $7,600

Check: $12,900 + $7,600 = $20,500 = total task cost ✅

The check matters: weighted allocation must conserve money — no double counting, nothing lost.

Goal-Level Variance

When actuals arrive (say T1 actually cost $11,000):

G1 actual = 0.60×$11,000 + …  → G1 over budget by 0.60×$2,000 = $1,200
G2 actual = 0.40×$11,000 + …  → G2 over budget by 0.40×$2,000 =   $800

A task overrun automatically propagates to every goal it serves, in proportion to its weight — giving leadership a live, honest picture of what each strategic objective truly costs.

5.4 The Five-Layer Pattern for Task Costing

Mature implementations separate the concerns into layers:

Layer 1  Estimates        — engineering estimates per task (immutable record)
Layer 2  Actuals          — real costs flowing in from payroll, cloud, vendors
Layer 3  Variance views   — computed comparisons of L1 vs L2
Layer 4  Goal–task links  — many-to-many links with allocation weights
Layer 5  Goal budgets     — weighted roll-ups of L1/L2 to the goal level

Each layer has one job; the upper layers are derived, the lower layers are facts. This separation is what makes the numbers trustworthy and the analysis reproducible.

5.5 Common Pitfalls

Editing estimates after the fact — destroys the learning signal. Re-baseline with a new estimate record instead.
Weights that don't sum to 100% — silently leaks or duplicates cost. Enforce the constraint in software.
Mixing planning logs with financial audit trails — planning churn (re-estimates, re-weighting) is operational history; financial transactions are compliance history. Keep the logs separate (see Chapter 06).
Single-number estimates for risky work — for high-uncertainty tasks, record a range (best/likely/worst) and budget at likely, reserve at worst.

5.6 In Practice — TupicFinance

The five-layer pattern in §5.4 is implemented one-for-one in TupicFinance: task cost estimates and actuals live in separate tables, database views compute variance on the fly, goal–task links carry explicit allocation weights, and goal budgets roll up automatically from the weighted task costs. Goals, Outcomes, and Task Costs each have dedicated workspaces with per-project filtering, and — following pitfall #3 above — planning activity is logged in its own activity stream, completely separate from the financial audit trail. The platform thus turns this chapter's discipline into default behavior: estimates are preserved, weights are enforced, and every variance is explainable.