ReflectHub forecasts the final cost of every task from data — logged hours, expense allocations, labor cost and open commitments — instead of trusting a typed-in number. The engine's forecast sits next to the PM's own forecast in the Cost control grid on the Finance Overview tab, and the gap between the two is treated as a signal in its own right. The point is early warning: a job rarely announces an overrun; it drifts into one, and the drift shows up in the data before it shows up in a meeting.
How percent complete is derived
Earned value — the value of work done so far, priced at budget — needs a percent complete per task. ReflectHub resolves it in a fixed order:
- PM override — if you have set one, it wins.
- Logged hours vs estimate — when the task has estimated hours, progress is logged hours divided by the estimate, capped at 100%.
- Task status — a finished task counts as 100%, an unstarted one as 0%.
If none of these apply, the task has no signal. It is excluded from the earned-value calculation rather than guessed at — the engine never invents 50%. Every value carries a source badge — Override, Hours or Status on the task's % Complete field, abbreviated to OVR/HRS/STS in the grid's % complete column (hover for the full name); rows without a signal read No signal. Either way, you always know where a number came from.
The override is deliberate, not casual. It is set per task and written to the finance event log with who set it and when. When your value deviates from the derived value by more than 20 points, a note is required. The note travels with the number.
The earned-value figures, in plain terms
For a task with a budget baseline (the current baseline, after approved change orders):
- EV (earned value) — percent complete × baseline. The value of work done, priced at budget.
- Actual (AC) — what the work has actually cost so far: expense allocations plus labor cost from worklogs and cost rates.
- CPI — EV ÷ AC. Below 1 means you are spending faster than you are earning; the grid marks it explicitly.
- EAC (system) — the forecast final cost: baseline ÷ CPI. If the first half of the job ran 25% over, the engine assumes the second half will too, until the data says otherwise.
- VAC — baseline minus EAC. Negative means a forecast overrun.
- TCPI — the efficiency you would need on the remaining work to still land on budget. A TCPI of 1.33 means every remaining euro must buy €1.33 of progress.
A worked example. A groundworks task has a baseline of €40 000 and is 50% complete, so EV is €20 000. Actual cost to date is €25 000. CPI is 0.80. EAC is €40 000 ÷ 0.80 = €50 000. VAC is −€10 000. TCPI is (40 000 − 20 000) ÷ (40 000 − 25 000) = 1.33 — a recovery the engine flags as unrealistic.
The commitment floor
The forecast never dips below what is already contractually committed. If a task carries €30 000 in open commitments — RFQ awards and manual subcontract entries — the forecast cannot be less than the greater of actual cost and the total open commitment amount, no matter how good the CPI looks. When this floor lifts the forecast, the EAC (system) cell shows a Floor badge instead of EVM (earned value management — the CPI-based forecast described above).
When there is no progress signal
Tasks with no percent complete fall back to a rules-based forecast: the estimate if there is one, otherwise the baseline, each lifted to the commitment floor; failing both, the floor itself. These rows carry a Rules badge — or Floor, when the commitment floor is what set the number. The fallback keeps project totals honest without pretending to know progress it cannot see.
The system's forecast next to yours
The grid shows EAC (system) and EAC (PM) side by side, with the difference under the PM column. Your forecast is never merged into the system's — it stays a second opinion. When the two diverge, one of you knows something the other does not: either the data is missing context, or the plan is. Either way, the disagreement is the earliest warning an owner gets, well before an invoice makes it official.
The forecast bridge
The Forecast bridge on the Overview tab decomposes the drift from the original baseline to the system forecast as a waterfall: Baseline → Change orders → Spend efficiency → Manual overrides → Committed growth → Forecast (EAC). Approved change orders moved the baseline itself; spend efficiency is the CPI effect; manual overrides show what your percent-complete corrections did to the forecast; committed growth is the commitment floor at work. Every bar is labeled with a signed amount, a View data toggle gives the same figures as a table, and clicking a step opens the finance events behind it.
Alert thresholds
| Condition | Chip |
|---|---|
| Actual cost ≥ 80% of baseline | ≥80% budget |
| Actual cost ≥ 100% of baseline | Over budget |
| Forecast overrun > 10% of baseline | At risk |
| TCPI ≥ 1.10 | TCPI 1.3 (shows the task's own value) |
Alerts appear as text chips on grid rows and roll up into the project's alert digest. The TCPI chip fires when on-budget recovery has become unrealistic. Color reinforces state but never carries it alone.
Every number has a trail
Each figure traces to finance events: expense and allocation saves, invoice ingestion, change-order approvals, commitment changes, cost-rate changes, percent-complete overrides. Events record who, when, what changed and the before/after values, and override notes ride along. The bridge's click-through and the task and project event feeds read from the same trail, and the grid exports via Export XLSX with the same columns you see on screen.