Committed cost, change orders and earned value that has to foot

Where each column of the cost report came from

A construction budget report has five or six money columns — original, changes, committed, actual, projected — and each of them is fed by a different mechanism. The number that gets argued about in a monthly review is almost never wrong arithmetic. It is a column whose feed nobody at the table could name.

So every money column carries a provenance strip naming the feed it came from. Not a tooltip and not a help page: a line under the column, on the report, saying where that money arrived from.

Committed cost, cost to date, and the third no commitment covers

Committed cost is subcontracts and purchase orders. Labour comes through the timesheet pipeline. The remainder — direct purchases, equipment, small tools, the invoices that arrive with no commitment behind them — is the third that most systems leak. Four rules govern it here:

• A line with a quantity and no rate is incomplete, never zero. A missing rate that renders as $0 is a cost that has silently left the report.
• Only approved money is cost to date, and counted + every exclusion === gross. Nothing can quietly fall out, because the exclusions have to add back up.
• Double counting is excluded by name. A posting invoiced through a commitment, one arriving from the timesheet pipeline, and an approved change order bound to a commitment are each already counted somewhere else — so each is excluded explicitly, with its name on the exclusion, rather than by a rule somebody has to remember.
• A change event's pending exposure is netted against every change order raised from it, so the same dollars are never carried in both the exposure and the order.

Every money column is computed twice — by cost-code row and as a project total. A column that does not foot is printed instead of the over-under verdict.

That last rule is the one worth dwelling on. A cost report that does not foot is a cost report whose verdict is meaningless, and the normal failure mode is that it still shows the verdict. Here the failing column is what you get, in place of the answer.

Earned value management, and the three things that are load-bearing

1. The earned value technique is a choice, and every result names which one

Duration percentage, physical percentage, units installed, 0/100, 50/50, a custom split, or level of effort. The technique is resolved per activity, then per work-breakdown branch with the deepest rule winning, then per project — and every result and every row says which was applied, because "planned value $200,000" means materially different things under different techniques.

2. The technique phases the planned value as well as the earning

A 0/100 activity is worth nothing until the day it was planned to finish. If you earn by a step but phase the plan as a ramp, you invent a schedule variance out of the mismatch alone — a variance that is an artefact of the measurement and not of the job. So the same record drives both the planned fraction and the earned fraction, and changing one without the other is not possible.

3. With no baseline there is no planned value

Planned value, schedule variance, the schedule performance index and earned schedule come back null beside a named refusal. Never 1.00, and — the important half — never phased on the current start and finish dates, which have already been re-forecast to match what actually happened. Phasing a plan on dates that were updated to match reality produces a schedule performance index of almost exactly 1.00 on a project that is months late.

Percent complete is not redefined for earned value either. Duration percent complete and physical percent complete are different claims and are kept apart; the duration technique reads the same clamped field the schedule weights, and the test suite asserts the two agree exactly.

Change orders, commitments and the contract chain

Everything exports, and every export carries provenance

Every register in Slipcurve has the same export mechanism — one shared implementation, mounted on all of them, reading the rendered table at the moment you click. That uniformity is deliberate: a tool where some registers export and some do not is worse than one where none does, because a user cannot tell which is which.

Four things in that export are arithmetic with a plausible wrong answer, and each is pinned by a known-answer test: column typing ($1,234 leaves as the number 1234, while 12d stays text and 007 stays an identifier); the filtered-subset statement, where the hidden count is null rather than zero when the population was not stated; a formula-injection guard on untrusted imported text; and a placeholder em dash becoming an empty cell rather than a zero.

Beyond the registers, a report builder lets you define your own — choose registers, columns, filters, grouping and sort, save the definition, and regenerate it next month against live data. Its register list is read from the platform's own registry at run time and its columns from the records themselves, so a renamed field shows up as a column that stopped being offered rather than as a table quietly going stale.

A filter naming a field that nothing carries evaluates false on every row. The section is produced, holds nothing, and reads as there are none.

That is a broken question, not an empty answer, so it comes back marked unavailable and naming the field. There is no code path in the report runner that drops a section.

Related

• Estimating and quantity takeoff — where the budget comes from, and the trade-class classification that lets it be joined to actuals.
• Scheduling and schedule risk — cost distributions and recommended contingency at a chosen confidence.