Mortgage document version control: keep the current pack identifiable

Control mortgage document versions by identifying each received file, recording which version is current for the task and preserving the pack snapshot that was reviewed or sent. Keep superseded material distinguishable from current material. A filename ending in “final” does not establish which document the broker accepted.

This guide proposes an internal operating method for Australian mortgage teams. It does not set document-retention periods or decide whether evidence is acceptable to a lender. Use your organisation's approved storage and records policy alongside the method.

Separate document identity from task suitability

Record what the document is, who or what it relates to, its relevant period and when it arrived. Then record its state for the specific task. A newly received statement may be newer but still incomplete; the arrival time alone should not decide which evidence is suitable.

Use the document request tracker for the collection action. Version control adds the relationship between received files: which one replaced another, who made that decision and which pack used it. Keep these records linked rather than building a second document-request queue.

Use neutral internal file references where possible. Avoid putting unnecessary sensitive information into a filename simply to make it unique. The authorised record should provide the context needed to identify the file without exposing a full customer story in a broadly visible list.

Choose a naming convention people can apply consistently

A proposed pattern is “[internal applicant label] – [document type] – [document period] – received [date] – [version identifier]”. Adapt it to your existing approved system. The exact separators matter less than the team's ability to distinguish two files without opening the wrong one.

Preserve the original received file in the approved location under your records process. If an authorised copy is renamed for organisation, keep its relationship to the original clear. Do not treat renaming as verification of the contents or source.

Write down how the team handles missing dates, duplicate names and multipart documents. A worker should have an exception route rather than invent a different convention for each unusual file. Test the naming pattern with fictional examples before applying it to a large queue.

Use a small version register

Document version register

Field	Purpose
Document reference	Identify the exact stored item
Type and relevant period	Distinguish files serving different requests
Received time and source	Explain arrival without assuming acceptance
Current task state	Awaiting review, current, superseded or questioned
Replacement relationship	Link the newer and earlier items
Reviewer and decision time	Record who confirmed the task state
Pack reference	Identify reviewed or submitted use

These are proposed internal states, not lender classifications. A document can be current for one reviewed task and historical evidence for another. Keep the task or pack reference explicit so “superseded” does not become an instruction to erase the record.

Where the existing tool already records version history, use that capability and a concise task-state record. Avoid downloading copies into personal folders merely to maintain a separate register. The method should reduce uncertainty within the approved system.

Freeze the pack that the reviewer actually checked

Give the prepared pack a reference and checked time. List the document identifiers included, the broker instruction used and any open questions. If the storage tool permits links to exact versions, use the approved version reference rather than a link that always points to the newest file.

When a document changes during review, identify the affected portion and ask the reviewer what needs checking again. Do not silently swap the attachment while keeping the earlier approval label. The review record should identify the actual pack accepted.

After the authorised submission, record the submitted pack and available receipt evidence. Keep prepared, reviewed and submitted states distinct. This makes it possible to explain a later question about which version was sent without guessing from the current folder contents.

Practise with two similar fictional documents

Illustrative exercise: a mock customer sends two statements for the same period. The first file lacks its final page. The second contains the full fictional page set. The support worker records both arrivals and asks the reviewer to confirm the current item for the request.

After that confirmation, the first item is marked superseded for the task and linked to the second. It remains handled under the organisation's records policy. The current review pack points to the accepted item. The example is constructed; it does not claim that a complete page set proves authenticity or lender acceptability.

Now add a third file covering a different period. Ask the trainee whether it replaces the second item or answers a separate request. This reveals whether they understand document identity instead of automatically treating the latest arrival as the only current evidence.

Sample selection mistakes and fix their cause

• Could the preparer identify the current item without guessing?
• Did a changed document trigger the appropriate review?
• Does the pack record identify exact document versions?
• Are superseded items clearly distinguishable?
• Can the reviewer explain what was actually submitted?

Use the file quality sampling checklist to examine a small authorised sample. If errors come from similar filenames, improve naming; if they come from changing links, improve pack references. Do not respond to every version problem by adding more generic checklist items.

A clear version method also makes a support role easier to train. If document organisation and pack preparation need dedicated ownership, explore the processor role and share the work your team needs covered. Include the approved storage tool, review process and version problems you want resolved.