Capture the correction
Write the note while the correction is still fresh, before the next package distracts the reviewer. Record the drawing or schedule reference, the original quantity, the corrected quantity, and the rule that decided the change. Add the reviewer initials and the date.
A note without the source reference cannot be audited later. Keep the note in the same folder as the takeoff and link it from the review log. The takeoff service page shows where this note fits in the handoff, and the takeoff review guide explains the sampling step that usually finds the error.
Record the link date as well, because a note that points to a moved file is almost as weak as no note at all. The reviewer should be able to open the source from the note in one click. Use the same note template for every correction so the fields are predictable.
A template with source, change, cause, and verification takes less time than a free-form email. Attach the marked drawing or the workbook row when the correction depends on a visual detail. The attachment should be a copy, not a replacement for the original source.
Name the root cause
Choose one root cause from a short list: unclear brief, wrong revision, formula error, scope duplication, or missing source. The cause should point to a change someone can make. If the note says human error, it stops the investigation before it starts.
A cause that cannot be acted on is not a useful cause. Compare the correction to earlier notes from the same project. Two corrections with the same cause are a pattern, while one is an event.
The pattern is what justifies a brief change or a new check. Record the comparison in the note so the pattern is visible without a separate report. Write the cause in plain language so the next reviewer can search for it later.
A note that says the schedule column was read as a count is more useful than a note that says measurement error. Use the same vocabulary across projects, and add a new cause only when the old list cannot describe the failure. The list should stay short enough to scan.
Update the rule
If the correction changes how a scope item is measured, update the task brief before the next batch. Give the brief a new version number and list the changed rule in its change log. Tell the team which rows were affected by the old rule.
An updated brief without a note leaves the team unsure which instruction is current. For a formula or workbook error, fix the template rather than the single row. Lock the corrected cell and add a check that would have caught the error.
The AACE recommended practices support a documented estimating process, and the documentation is only credible when the template actually changes. Record the template version in the next review note so the change is visible to anyone comparing batches. A rule change should name the old rule, the new rule, and the first package that used it.
Without that history, a later reviewer may revert to the old practice because it looks familiar. Keep the rule text in the brief rather than in a separate memo that can be lost. The brief is the document the team reads before every batch.
Verify the fix
After the rule or template changes, run a small test on the next batch. Check the row that failed before and one similar row that did not fail. Confirm the new rule produces the expected quantity in both cases.
Record the test result in the correction note. Do not close the note just because the template was updated. Close it when the next batch passes the check.
If the same error returns, reopen the note and look for a second cause. A fix that was not verified is only a hope. Pick the verification row before the next batch arrives so the test is not chosen after the result is known.
Check the corrected row and a nearby row that used the same rule. If the nearby row still fails, the rule was applied too narrowly. Record both results, including the failure, because a partial fix is still useful evidence.
Build a learning library
Group correction notes by scope category so the next assistant can find the relevant lessons. A short index by trade is more useful than a chronological pile. Include the rule, the source, and the check, and remove notes that no longer apply.
The library should grow slowly and stay usable. Review the library during onboarding and again before a complex bid. The review does not need to be long; fifteen minutes on the most common corrections is enough.
Over time the library becomes the team memory that survives staff changes and busy seasons. Assign a review date to the library so old notes do not become silent rules. Give each note a short title that names the scope item and the failure, not the project name.
That makes the library searchable by trade and avoids exposing commercial details in the index. Review the index quarterly and merge notes that describe the same rule. A library that is easy to search gets used, while a perfect archive that no one opens does not.
| Field | What to record | Why |
|---|---|---|
| Source | Drawing or schedule reference | Makes the note auditable |
| Change | Original and corrected quantity | Shows the size of the error |
| Cause | One actionable root cause | Points to a fix |
| Verification | Next-batch test result | Proves the fix held |
