A master document register should identify every required deliverable and show its current controlled state. At minimum, record the document number, title, type, discipline, originator, current revision, status, planned and actual issue dates, responsible party and file location. Add project-specific fields only when someone will maintain and use them.
The master document register, often shortened to MDR, is the controlled index of project documents. It may begin as a deliverables plan before some files exist, then develop into the record used to manage reviews, revisions, issues and final handover.
The minimum MDR fields
| Field | What it answers |
|---|---|
| Document number | What unique controlled item is this? |
| Title | What does the document cover? |
| Document type and discipline | How should it be grouped and routed? |
| Originator | Which organisation owns its preparation? |
| Current revision | Which revision is presently controlled? |
| Status or purpose of issue | Is it for review, construction, information or as-built use? |
| Planned and actual dates | Was it delivered when required? |
| Responsible person | Who must take the next action? |
| File location or expected filename | How can the controlled file be found and checked? |
Oracle's Aconex document data model separates document number, title, discipline, revision, status, dates and file name. That separation matters. Packing several facts into one free-text column makes filtering easy to break and handover checks harder to defend.
Fields that depend on the project
Capital projects often add package, area, system, subsystem, contract, vendor, client document number, review code, transmittal number, confidentiality, retention class and as-built requirement. These can be valuable, but every extra field creates maintenance work.
Before adding a column, ask who owns it, when it changes and which decision it supports. If nobody can answer all three questions, the field is likely to become incomplete or misleading.
One row per document or one row per revision?
Both models can work, but they answer different questions. One row per document provides a clean view of the current state. One row per revision preserves history and makes previous issues easier to trace. Some teams maintain a current MDR plus a separate revision or issue history; others keep every revision in one system and filter for the current record.
Make the filename checkable
A register can be correct while the delivery folder is incomplete. If the MDR includes an expected filename, the project team can compare each register row with the files supplied. If filenames vary but document numbers remain controlled, the document number can be used as a more tolerant matching key.
Whichever rule is chosen, record it. A mixture of undocumented filename conventions produces false missing results and makes duplicates difficult to explain.
Prepare the MDR for handover
- Confirm the register covers the agreed contractual scope.
- Resolve blank document numbers, duplicate identifiers and unexplained statuses.
- Confirm the current revision and purpose of issue for each required deliverable.
- Check that withdrawn and superseded items are clearly distinguished from current documents.
- Compare the final register with the actual delivery folder.
- Record every accepted exception instead of silently deleting it from the report.
When Deliverable Preflight helps
Deliverable Preflight does not replace an MDR or decide whether a revision is technically approved. It performs the narrower final check between a CSV or XLSX register and a local Windows folder. It reports Ready, Missing, Unexpected and Ambiguous results, then exports the complete comparison for the handover record.
Use exact filenames when the MDR contains the agreed complete name, or document-number matching when descriptive filename text varies.
View Deliverable Preflight in Microsoft Store →Further reading
- Oracle: Aconex document fields and reporting data
- University of Queensland: Master Document Design Standards
Questions people ask
What is the purpose of a master document register?
It provides a controlled index of required project documents and shows their identity, revision, status, responsibility and delivery progress.
Should an MDR include filenames?
Including the expected filename or a reliable file location makes the final register-to-folder check much easier, although the contract may define a different required structure.
Is an MDR the same as a folder?
No. The register records what should exist and its controlled status; the folder or document system stores the actual files.