The Filename Is Evidence: A Scan-Naming Rule for UK Firms That Expect to Be Asked
A scan is only as good as its index
When a UK practice converts a paper file into a set of PDFs, the scanner rarely causes the problem. The weak point is usually the name attached to each file. A scan without a disciplined name becomes an orphan: it exists, but it cannot be reliably found, linked or explained. In an audit, a subject-access request or an internal review, the filename is often the first evidence a reviewer sees. It should answer basic questions without forcing anyone to open the document, and it should not answer questions that were never asked.
Why the filename is a control, not a label
Firms often treat filenames as a convenience. Someone types what they see, adds a date if they remember, and moves on. That works until the file set has to be defended. A defensible naming rule does three things. It makes the set searchable by people who did not create it. It preserves a link between the digital file and the paper original. And it avoids putting sensitive details into a place where they can be seen in a folder listing, an email attachment or a shared drive preview.
That last point matters. A filename such as Smith_employment_dispute_dismissal_letter.pdf tells anyone with folder access more than they need to know. A coded name can be just as findable, provided the code is mapped in a controlled index.
The five-field convention
A workable convention for small UK practices uses five fields in a fixed order. The aim is consistency, not cleverness.
- Entity code: a short, stable code for the client, matter or department. It is assigned in an index and never contains a person's name.
- Record class: a controlled label such as CORR for correspondence, LEG for legal, FIN for finance, HR for personnel, CON for contracts. Keep the list short.
- Event date: the date on the document or the date of the event it records, in YYYY-MM-DD format. This is not the scan date.
- Version or sequence: v01, v02 and so on for successive versions; seq-001 for multiple scans of the same item.
- Status: DRAFT, FINAL, APPROVED or SUPERSEDED, using a fixed vocabulary.
Separate the fields with underscores. Avoid spaces, brackets and special characters. Use lower-case file extensions. The index — a simple spreadsheet or a field in the practice management system — holds the mapping between the code and the real name, together with access controls and retention information.
Before and after
A common before state looks like this: a folder called New folder (2) containing scan_0043.pdf. The file may be a signed agreement, but nothing in the name says so. A reviewer has to open it, read it and guess.
An after state might be HV-0142_LEG_2026-03-14_v02_APPROVED.pdf. The code HV-0142 maps in the index to the client and matter. LEG identifies the record class. The date is the date of the agreement, not the day it was scanned. v02 shows it replaced an earlier version, and APPROVED shows its status. The filename does not reveal the client's name or the subject of the matter, but a colleague who knows the convention can locate it quickly.
A finance example follows the same pattern: AB-0007_FIN_2026-01-31_v01_FINAL.pdf rather than statement.pdf.
Metadata needs a decision, not a default
Scanners and PDF software often carry metadata from the device or the operator: author, creator, last modified by, sometimes an internal file path. In a subject-access request, that metadata is part of the record. It can disclose a username, a former folder name or a device label that has no place in a released set.
Set a documented metadata profile for scanned files. Where searchability matters, use OCR and a suitable archival PDF format. Set the author field to the firm name or another neutral value rather than an individual's login. Keep the scan operator in a separate log if the firm needs that trail. Do not rely on the scanner's defaults.
A one-page template for small practices
The rule does not need to be long. It needs to be written down and followed.
| Field | Rule | Example |
|---|---|---|
| Entity code | 2-8 characters, assigned in the index, never a person's name | HV-0142 |
| Record class | One code from a list of no more than twelve | LEG |
| Event date | YYYY-MM-DD; use UNDATED only with an index note | 2026-03-14 |
| Version | v01 upward; seq-001 for repeat scans | v02 |
| Status | DRAFT, FINAL, APPROVED or SUPERSEDED | APPROVED |
| Separator | Underscore; no spaces; lower-case extension | _ |
Add three short sections: who assigns codes, where the index lives, and what to do with an undated or handwritten item. Review the rule once a year, or after any audit finding. In 2026, a printed one-page rule taped near the scanner is still more effective than a long policy nobody reads.
A short test before the next batch
Before a scanned set is closed, ask five questions.
- Can a colleague find the document from the filename and index alone, without opening it?
- Does the filename reveal a client name, a health detail or a matter description that should have been coded?
- Can you show the chain from paper receipt to scan to filing, including who scanned it and when?
- Does the embedded metadata agree with the filename, or does it contradict it?
- If a subject-access request arrived tomorrow, would the set be coherent, complete and explainable?
A set that passes all five is not guaranteed to satisfy every auditor, but it is far easier to defend than a folder of scan_0043.pdf files.
Where conventions fail
Most failures are mundane. One department uses hyphens, another uses spaces. A new starter copies an old naming pattern that was never documented. Someone renames a file to send it by email and forgets to restore the original. The fix is ownership: one person or team maintains the index, samples a batch each quarter, and corrects drift at induction rather than at audit.
The filename is not the whole record. It is the handle. A good handle survives being picked up by someone who was not there when the paper was scanned.
