Record three dates, not one

A property file can hold three plausible versions of the same scope: an estimate received last week, a revised attachment sent yesterday and an approved version forwarded again this morning. Sorting by download date will not explain which document the team should use. A version-and-conflict register creates a small, explicit record of that decision while preserving the originals.

Give each document an internal identifier and record its source, filename, stated issue date, revision label and receipt date separately. If the sender did not supply a revision number, write not supplied. Do not invent one that looks like the sender's own designation. An internal sequence such as DOC-014 is useful precisely because it is clearly your filing reference rather than a claim about the document's authority.

Define what the document is approved for

Record purpose and status as separate fields. A document may be useful for pricing but not approved for work. Another may be approved for one building but not the entire property. Preserve that boundary in plain language. Received, under review, approved for a stated purpose, superseded and withdrawn describe different conditions; do not collapse them into a single current checkbox.

When two documents disagree, identify the exact location of the difference: page, section, line item, quantity, location or drawing note. Quote only the short passage needed in the internal register and link to the originals. Ask the responsible reviewer a specific question, such as whether the second-floor corridor was removed from the scope or merely omitted from the later attachment. Do not resolve a material omission by guessing what the sender intended.

Work through a version mismatch

Consider a hypothetical file with estimate A dated October 2, revision B dated October 5 and an approval email dated October 6 that explicitly refers to A. Receiving B after that email does not establish that B was approved. The register should retain all three records, flag the mismatch and identify who must clarify the approved scope before the affected work proceeds under the property's authorization process. This is an illustration, not a description of an RLF transaction.

Separate an administrative replacement from a substantive change. A corrected contact number may not change the work, while a different quantity, exclusion, material or completion condition may do so. The person authorized to approve the relevant change should decide its treatment. The register records that decision; it does not grant approval authority or substitute for contractual review.

Close the conflict with an explicit decision

Close a conflict with evidence. Save the response identifying the controlling document, the specific purpose and any exceptions. Record the decision date and reviewer, then tell the people using the file which version to use. Mark the older copy superseded for that purpose without deleting it. A later question should still be traceable to what was available when the earlier decision was made.

Keep one access-controlled location for working documents and a concise index pointing to it. Avoid circulating resident information, access codes or unrelated financial details merely to explain a revision. When exporting a package for a vendor or adviser, record which versions were sent and when, rather than assuming everyone has the same attachments.

Preserve the decision trail

At closeout, retain the register alongside the approved scope, documented changes and completion evidence. Leave unresolved differences open with an owner and review date. The practical test is simple: could someone new to the property explain which document supported the decision, what changed and where the confirmation can be found?

A compact document-conflict register
FieldUseful entry
IdentityInternal ID, original filename, issuer and source link
DatesDocument issue date, received date and decision date, each separately labeled
ScopeProperty, building, location and purpose covered
ConflictExact section and difference; avoid a vague versions differ note
DecisionResponsible reviewer, controlling version, limits and supporting response
DistributionWho received the resolved package and when
HistoryPrior copies retained with their superseded or withdrawn status

Connect the approved documents to the vendor closeout record →

Practical takeaway

The latest received file is not automatically the approved file. Keep version identity, authorization and the resolution of discrepancies explicit.

Return to RLF Companies Insights →