Correct a project date without losing the calculation history
Keep a user-maintained correction ledger with before-and-after facts, evidence, reviewer decisions, fresh calculations and downstream reminder reconciliation.
When a supplier corrects a delivery date, the team needs to know more than the new number. Record what changed, why it changed, who checked the evidence, and what happened to the calculation and follow-up tasks. Otherwise, the next person can see a current deadline without understanding why an earlier reminder said something different.
Use a correction ledger that your team maintains alongside the project file. The workflow below is a recordkeeping practice, not a promise that the application automatically stores an accessible version history or cancels every old reminder. Preserve the prior facts and result before replacing them.
Separate a correction from a new event
A correction fixes an inaccurate record of something that already happened. A new event documents additional furnishing, a termination, or another relevant project occurrence. They may both require a fresh review, but they are not interchangeable.
Suppose an invoice date was entered as the delivery date. Replacing it with the supported delivery date corrects the record; it does not create new furnishing on the day of the edit. Similarly, a later replacement ticket does not by itself establish a later legal trigger. Florida's §713.01(12) excludes correction of prior deficiencies from final furnishing. Apply that labeled Florida example only after the event's purpose has been established.
Keep a before-and-after ledger
One row per correction is usually enough:
| Field | What to preserve |
|---|---|
| Project and field | Job identity and the exact fact being changed |
| Before | Previous date or answer, with its earlier source or uncertainty |
| After | Proposed corrected fact, or “unknown” if the evidence does not establish it |
| Evidence | Source record, event date and where the original is retained |
| Reason | Entry error, newly located document or resolved factual conflict |
| Reviewer | Person who confirmed the correction and any legal classification |
| Recheck | Fresh result, as-of date, sources and any unresolved outcome |
| Handoff | Tasks, recipients and reminders requiring reconciliation |
Do not overwrite a source ticket to make it match the new value. Preserve the original and add the explanatory note separately. Keep the ledger in your controlled project records rather than in public content or an unprotected shared link.
Worked example: invoice date replaced by delivery evidence
This fictional project used October 7 as its final-furnishing date because that was the invoice issue date. Dispatch later locates the corresponding delivery record dated October 3. The credit manager checks that the ticket belongs to this job and asks whether any genuine outstanding furnishing followed it.
The ledger records “October 7 → October 3,” the invoice and ticket references, the entry-error explanation, the reviewer's name and the verification date. If a later shipment remains unresolved, the completion answer stays under review; finding one ticket does not settle every question.
The team then makes a fresh calculation using the corrected facts and all relevant event answers. The ledger stores the earlier and fresh results with their labels. If the new result is review-required, the handoff says that clearly rather than substituting the old date. No deadline is inferred from the fictional dates in this example.
Recheck explicitly after changing facts
In the supplier calculator, confirm the state, project type, hiring relationship, furnishing facts and relevant project events. Read preliminary notice and lien filing separately, along with sources and warnings. A calculated outcome, an unresolved outcome and a conservative planning target are different kinds of information.
For saved supplier projects, the current save flow uses a revision check to detect a changed saved record and stores the current reviewed facts and result. That concurrency protection is useful, but it is not an automatic visible archive of every prior version. Keep your own ledger and copies of the results you need. A “saved” message confirms a save, not that all legal questions are resolved.
If a save reports a conflict, reload the current project, compare it with your proposed correction, and reconcile the difference before saving again. Do not repeatedly submit an old revision or assume another person's change was wrong because it differs from your worksheet.
Reconcile every downstream use
After a fresh result, check the places that consumed the old one:
- Collection and notice preparation tasks.
- Internal calendar entries and assigned follow-up dates.
- Exported reports, spreadsheets and queue rows.
- Handoffs to counsel or a notice provider.
- Reminders or messages already scheduled or sent.
For each, record whether it was updated, cancelled, retained for a stated reason, or still needs action. Verify changes in the system that owns the task; do not assume editing a saved project retracts an earlier email or updates an external spreadsheet.
Keep statutory deadlines separate from internal planning targets. An earlier fresh deadline needs prompt attention, and a later fresh date needs a supported explanation before the team relaxes an existing action plan. If legal time may already have passed, seek review immediately; storing a correction does not extend it.
Should I delete the old calculation?
Preserve it as a clearly labeled prior result in the project file, with the superseding correction and fresh result linked. Retention and access should follow your organization's records policy.
What if the evidence proves the original date was uncertain?
Record the uncertainty instead of selecting a convenient date. Assign the missing-fact request and use the qualified-review handoff while it is resolved.
This is operational guidance, not legal advice. Use counsel-approved policies for final notice and lien decisions.