Who changed the cause, and when: the audit table behind every change

Apr 16, 20264 minute readBy Reltic VDC

A spreadsheet cell holds one value. Type a new one and the old one is gone. That is fine for a grocery list and a problem for a change order register, where the value in the cause column decides who pays and can be edited by anyone with the file open.

An audit table sits behind the register and records every change to the fields that matter: what the value was, what it became, who changed it, and when. It is not an accusation. It is the difference between a register that reports the project and one that can be trusted to.

What the audit table records

Not every field needs history. The description can be tidied without a trace. The fields that need it are the ones that move money or responsibility: cause, fund, amount at each stage, state, and the dates that feed notice compliance. For each of those, the table stores one row per edit with the entry reference, the field, the old value, the new value, the user, the timestamp, and an optional reason.

The reason field is the one people skip. It should be required for a cause change. A cause that moved from design gap to owner scope with the reason owner letter dated March 3 is a normal correction. The same move with no reason is a question waiting to be asked.

Three things the table makes visible

An audit table is rarely read day to day. It earns its place in the moments when the register is challenged.

Reclassification patterns

One cause change is a correction. Twenty in a week, all in the same direction, is a decision someone made about the project's story. The table shows it. It might have been a careful review that found the original causes were wrong. It might have been a cleanup before a board meeting. Either way the owner can see it happened and ask.

Amount drift

A PCO that started at $60,000, was negotiated to $41,000, and was executed at $58,000 has a story. Perhaps scope was added. Perhaps the negotiation did not hold. The register with only the executed amount shows $58,000 and nothing else. The table shows all three numbers with dates.

Who was holding the pen

Owners change staff. Owner's representatives change firms. A register that has been through three hands in two years can still be read if the table shows whose hands. When an entry looks wrong, the owner knows who to ask, or knows that the person is gone and the entry should be treated with care.

A fictional closeout

Take a fictional $39 million county courthouse on CM at risk, with a shared savings clause. At closeout the contractor's final accounting shows contractor contingency fully spent and a small savings pool. The owner's register agrees on the totals but the county's finance director asks how contingency was spent.

The owner's audit table shows that eleven entries worth about $460,000 were recorded as coordination for most of the project and then changed to owner scope in the final two months, each with the reason per contractor reconciliation. The change moved $460,000 from contractor contingency to owner funded change orders, raised the GMP, and increased the savings pool the contractor shares in. The county may agree with the reclassification after review. The point is that the county can review it, because the table exists. Without it, the final register would simply show owner scope and the question would never arise.

Building it without building software

A spreadsheet can approximate an audit table with a second sheet where every change is logged by hand. It works until someone is in a hurry. A shared file with version history is better, but reconstructing a cause change from version history is slow and rarely done.

An owner's ledger that writes the audit row automatically on every edit removes the discipline problem. Costwitness keeps that table behind the change order register and the contingency ledger, with a required reason on cause and fund changes, and reports the count and value of reclassifications each month. The owner reads the summary and decides whether any of it needs a closer look.

What to do this month

  1. Decide which fields in your register require history and list them on the first sheet of the file so everyone knows.
  2. Start a change log sheet today, even by hand, with entry, field, old value, new value, name, date and reason.
  3. Add a line to the monthly owner report showing how many cause or fund values were changed that month and their total value.

Questions on this

Is the audit table something the contractor should see?

Not necessarily. It is the owner's record of the owner's own decisions. Sharing the current register with the contractor is normal and useful. Sharing the history of how the owner's causes evolved is a choice, and it may be more useful in a reconciliation meeting than in routine reporting.

Should old values ever be deleted from the table?

No. The table is only useful if it is complete. If an entry was created in error, mark it void with a reason and leave the history. A table with gaps is not much better than no table.

What if a change was made by someone who no longer has access?

The row stays. The name and the date are facts about the past. If the entry needs review, the current owner's representative reviews it and records the review as a new row with their own name.

In the product

Change order register, Contingency ledger, Monthly owner report. Free tool: Change Order Exposure, Pre-GMP Readiness Score.

Keep reading

Earlier: Disputed change orders: keeping a record that holds up later. Later: Time and material change orders: the controls an owner should insist on. All articles on change orders.

One next step

See the cause register on a project like yours.

Thirty minutes on a call. The change order register with causes, the audit trail, and the notice clock, on a fictional project.

Create a free account