How to Name and Index Scanned Documents

Give each scanned record a stable identifier, use a short, consistent filename and keep richer lookup details in an index. Agree how those parts connect before requesting a quote, including who maintains the connection when a filename, project description or storage location changes.

Start with questions staff actually ask: “Where are the minutes for project PRJ-042?” “Which file contains the east-wing inspection report?” “Can I find everything under the old project reference?” These questions reveal what the archive needs to remember. A folder full of readable PDFs does not, by itself, answer them.

This guide offers a practical specification for Australian organisations planning a scanned project archive. The examples are fictional buyer instructions, not Pexatech customer records or promised delivery formats.

Keep identity, name, description and location separate

Four parts serve different purposes:

• Record ID: a stable reference for one record, used to connect its file, index entry and later corrections.
• Filename: a compact label staff can recognise when browsing or downloading the file.
• Index fields: descriptions and references used to find one record or filter a group of records.
• Folder location: where the file currently sits, which can change without changing the record's identity.

A project code identifies a project, not necessarily an individual document. Several meeting records can belong to the same project. Giving each its own record ID lets staff discuss a particular item without relying on a description such as “the other minutes”.

State Records NSW's guidance for NSW public offices recommends planning metadata early and documenting consistent, unique file titles; existing numbering systems may be suitable. Its metadata section also discusses reusing existing systems and registers. This is useful context, not a mandatory naming standard for every business. State Records NSW digitisation specifications.

Decide what one record means

For the fictional archive below, one record is one meeting's minutes with its attachments, or one inspection report with its supporting pages. Each becomes one PDF and one index entry. An entire project can contain many such records.

Your boundary may instead follow existing folders. State it explicitly and agree how the provider will recognise it. If a record needs several digital files, specify how those parts share a parent reference and how the index identifies each part; do not silently apply a one-row-per-file assumption.

The document preparation guide covers physical order and separation. The decision here is which unit receives an identity that staff can continue using after scanning.

Choose a short naming convention that avoids collisions

A proposed convention for this fictional archive is:

[record-id]_[project-code]_[record-type].pdf

For example: ARC-0101_PRJ-042_MINUTES.pdf.

Here, ARC-0101 is a unique record ID within the archive, PRJ-042 is the customer's project code, and MINUTES is an agreed category. The ID remains fixed if someone later corrects the project code or category. Those corrections may change the filename, with the change recorded in the index.

Document the allowed categories and who allocates IDs. A single allocation register, or another agreed mechanism, should prevent separate scanning batches from reusing an ID. Avoid using the scanning date or box position as the only identity: another batch can share that date, and a box can contain multiple records.

Consider two separate meeting records for PRJ-042. Naming both PRJ-042_MINUTES.pdf creates a collision. The proposed names instead begin ARC-0101 and ARC-0102, so neither must overwrite the other. Do not resolve the collision by assuming the records are duplicates or letting a computer-generated “copy” suffix become the archive rule.

If reliable identifiers already exist, assess reusing them before allocating a new series. Check uniqueness across the whole scope, including departments that may have used the same numbering scheme. Where a separate archive ID is necessary, retain the existing reference as a lookup field.

Build an index around retrieval questions

The following four rows form a fictional project archive example. All references and titles are invented. The record ID appears in its own column so it can remain the link between descriptions and files even after a rename.

On a small screen, scroll the table sideways if needed.

To retrieve one known item, look up ARC-0103, or filter project PRJ-042 and source reference INS-07. To list the project's records, filter the project-code column: the result includes both minutes and the report. Searching only for “inspection report” returns two projects, which is why the project context matters.

This compact table illustrates the relationship, rather than a complete import template. A working index may also need a separate record-type column, source box/folder reference, current relative path and any agreed date used for retrieval. Make each additional field earn its place through a real staff task.

Keep long titles, former project names and explanatory notes in the index. Putting every detail in a filename makes it harder to maintain and can force a rename whenever a description improves. Choose whether personal or confidential names are needed for retrieval; avoid exposing them in filenames merely because they appear on the source. Naming is not access control, and the index needs appropriate access arrangements too.

Establish where descriptions come from

Start with the customer's project register, folder list or existing records system where available. Record which register and version supplied the values, and retain the source references needed to investigate a mismatch. An inherited description is useful evidence, but it is not automatically correct for every enclosed document.

For example, a folder labelled with an old project code may contain a report showing a different code. Flag that conflict for the customer's decision instead of silently choosing one or rewriting the source reference. Keep the observed reference distinguishable from the approved lookup value.

Agree a small, controlled list of record types so “minutes”, “meeting notes” and “meeting record” do not become accidental categories for equivalent items. The customer should approve any equivalence; some organisations deliberately distinguish those records. Capture uncertainty without guessing, and name the person who can resolve it.

The searchable PDF and data-extraction guide explains output formats and field definitions. For this naming brief, the essential question is which trusted source supplies each lookup value and who can authorise a change.

Agree the destination mapping separately

Specify the relationship that travels with the delivery: record ID, exact filename and, where subfolders are used, a path relative to the agreed package root. For example, PRJ-042/ARC-0103_PRJ-042_REPORT.pdf identifies a location inside the package without depending on a particular employee's desktop folder.

That relationship still needs maintenance after a move or import. A CSV supplied beside PDFs does not automatically embed its fields in those PDFs or populate a document-management system. Agree the intended index format and destination mapping before treating either as included work.

SharePoint provides a concrete example: its managed metadata columns can use agreed term sets, helping users apply consistent labels and find or filter information. A destination using those columns needs its own mapping decisions. Microsoft's introduction to managed metadata.

Also ask the destination owner to check proposed filenames within the actual full path, including parent folders and any relevant sync location. Microsoft documents naming restrictions and explains that path limits vary between applications, Office versions and setups; a filename working on one desktop is insufficient evidence for another destination. Microsoft's OneDrive and SharePoint restrictions.

Use the fictional pattern in a small destination check: can a staff member find a known record, list its project's records and open the associated file? This tests the proposed retrieval design. The wider scanning quality checklist covers delivery acceptance.

Assign ownership of changes before the quote

The customer's records owner confirms project codes, categories, existing references and disputed descriptions. The scanning provider confirms which values it will capture or carry forward, how record boundaries will be identified and which exceptions it will report. The destination owner confirms the receiving fields, mapping and import responsibilities.

These roles may overlap, but someone must own each decision. Ask the quote to distinguish supplied-register reuse, manual description work, exception resolution and destination import. “Indexing included” is incomplete if each party expects another to supply the titles.

For corrected deliveries, keep the record ID and original source connection wherever the record remains the same. Request a change mapping showing the record ID, previous filename or location, replacement filename or location, reason and delivery version. Update the index as part of the change.

A corrected scan of ARC-0103 is still associated with ARC-0103; a newly discovered, distinct report needs its own identity under the agreed allocation rule. Agree how delivery versions identify replacements and who decides what staff should use. Do not delete apparent duplicates or overwrite files just because their descriptions match.

A naming and index brief you can copy

Adapt this brief with the people who own the records and destination. List unresolved choices explicitly so the provider can identify assumptions and price the requested work.

Retrieval tasks: Find [one known reference] and list [all records for a project].
Record boundary: One record means [document/folder and attachment rule].
Identity: Reuse [existing IDs] or allocate [archive series]; allocation owner [role].
Filename: [record ID]_[project code]_[approved type].pdf, subject to destination checks.
Index: [required columns], exact filename and [relative path if needed].
Sources: [register/version and source references]; disputes go to [records owner].
Capture scope: Provider to confirm [values captured, supplied or flagged].
Destination: [system/library]; mapping and import owner [role].
Changes: Preserve record identity, provide old-to-new mapping and update the index.
Design check: Find one record, list its project and open the right files in [destination].

Keep the agreed brief with the quote so later batches follow the same rules. A useful naming system remains understandable to the next person responsible for the archive, including when that person was not involved in the scanning project.

Use the document digitisation overview to discuss scanning, searchable files and the archive index as one scoped project.