Free master document register template for Excel.
A ready-to-use MDR that tracks every deliverable a project owes, from the ones already accepted to the ones nobody has started, by number, discipline, revision, status, and planned and actual dates. Download it, fill in your own deliverables over the example set, and you have a working register in minutes. No email, no form.
.xlsx and .csv · 16 columns · Dropdowns for discipline, type, milestone, status, and review code · Example project included · No email required
Every column an MDR needs.
The template starts from document-control practice rather than a blank grid. Sixteen columns cover the deliverable, the party who owes it, the milestone it is due at, the planned and actual dates, and the code the reviewer returned.
The Discipline, Document type, Milestone, Status, and Review code columns carry dropdowns, the header row is frozen, and a second sheet explains how to fill each column.
Read what a master document register is- 01Document number
The controlled number that identifies the document for the life of the asset. Reserve the number when the deliverable is planned, long before the document arrives.
- 02Title
What the document covers, written the way it reads on the document itself.
- 03Project or asset
The project, site, or asset the deliverable belongs to.
- 04Discipline
The discipline that owns it, picked from a dropdown of Architectural, Structural, Civil, Mechanical, Electrical, Hydraulic, Fire, Process, Instrumentation, Survey, Geotechnical, Quality, Safety, or General.
- 05Document type
Drawing, specification, calculation, datasheet, report, manual, procedure, certificate, schedule, model, or plan, picked from a dropdown.
- 06Responsible party
The contractor, consultant, or discipline lead who owes the document. A deliverable with no named party is a deliverable nobody chases.
- 07Contract or package
The contract, package, or work order the deliverable is called up under, so the register can be filtered to one contractor's obligations.
- 08Milestone
The project milestone the document is due at, picked from a dropdown of Concept design, Detailed design, Issued for construction, Commissioning, Handover, or Operations.
- 09Revision
The revision this row records, for example A, B, C, or 0. It stays blank while the deliverable is still planned.
- 10Status
Where the deliverable sits, picked from a dropdown of Planned, In progress, Issued for review, Commented, Revised and reissued, Accepted, Superseded, or Cancelled.
- 11Planned issue date
The date the contract or the programme says the document is due. This column is what makes the register a deliverables list.
- 12Actual issue date
The date it was really issued. The gap between planned and actual is the slippage, read straight off the row.
- 13Review code
What the reviewer returned, picked from a dropdown of Not reviewed, 1 Approved, 2 Approved with comments, 3 Revise and resubmit, or 4 For information.
- 14Transmittal reference
The transmittal the document was issued under, so every issue is traceable.
- 15File location
Where the file lives once it arrives.
- 16Notes
Anything else worth recording against the row.
Fill the register from the deliverables list, not the inbox.
Six steps keep the register reliable. Work down them as the contract is signed and the documents come in, and the register stays a true picture of what is owed, what is late, and what has been accepted.
Open a row for every deliverable, before any of them arrive
Work through the contract, the scope of work, and the deliverables schedule, and give each document a row while its status is still Planned. A register that lists only what you hold cannot tell you what is late.
Reserve the number when you plan the document
Build every number to the same numbering scheme and issue it at planning time, so the number on the register is the number the document arrives with, and the register sorts and filters cleanly from day one.
Name the party who owes each document
Fill the responsible party and the contract or package it is called up under. Filter on those two columns and the register becomes a list of what each contractor still owes you.
Take the planned issue date from the programme
Fill the planned issue date and the milestone from the programme rather than the calendar. Sort on the planned date and the register becomes the chase list for the next month of deliverables.
Record the actual issue date and the transmittal
On the day a document is issued, fill the actual issue date and the transmittal it went out under. The two date columns sit side by side, so the slippage on every deliverable reads off the row.
Record the review code and reissue what is coded 3
Write the code the reviewer returned against the row. Anything coded 3 needs a new revision, so raise it, reissue it, and set the earlier row to Superseded. Keep the old row, so the review history stays on the record.
A spreadsheet MDR works, until it does not.
A register like this is quick to start, everyone can read it, and it holds the whole deliverables list on one page. It keeps working until two things happen: the planned dates stop being maintained, and the revision on a row is no longer the revision in the folder. When the fortnightly progress report takes a morning of manual comparison, that is the sign to move the record into document control software.
A planned row becomes the document when it arrives, so the register never points at a number that no file matches.
Run each document from draft to review to approved through a configurable workflow, with reviewers set per stage, so the review code is the outcome of the workflow rather than a typed letter.
Planned and actual dates sit on the record, so what is overdue and who owes it is a view rather than a fortnightly manual comparison.
Build a handover package and validate it against the manifest, so a deliverable the register says is owed and never arrived is caught on upload.
Lunr is document control software built for the record. It numbers documents on the way in, runs each one through the review workflow that sets its code, and keeps every deliverable under one controlled register, so the register can never drift from the file.
Questions about master document registers.
What an MDR is, what the letters stand for, how it differs from a document register, the columns it needs, and how to read the late list off it.
- What is a master document register?
- A master document register, or MDR, is the controlled list of every document a project or asset must produce and hold, recording each document's number, title, discipline, type, responsible party, revision, status, planned issue date, and actual issue date in one place. Because it carries planned deliverables as well as documents already received, it answers what is owed, what is late, and what has been accepted. This template gives you that register in Excel, with a CSV copy for any other tool.
- What does MDR stand for in engineering?
- MDR stands for master document register. On an engineering, procurement, and construction project it is both the index of the document record and the deliverables list agreed with each contractor, so a row exists for a specification nobody has written yet. Some organisations call the same artefact a master deliverables register or a supplier document requirements list, and use it to track progress against the programme rather than only to file what has arrived.
- What is the difference between a master document register and a document register?
- A document register records what you hold. A master document register records what you are still owed as well, so every planned deliverable has a row from the day the contract is signed, with a planned issue date against it and a status of Planned until it arrives. That is the difference between an index of the record and a list of deliverables. On most projects the drawing register and the document register are filtered views of the MDR rather than separate lists kept alongside it.
- What columns does a master document register need?
- At a minimum, an MDR needs the document number, title, discipline, document type, responsible party, revision, status, planned issue date, and actual issue date. A register that is worked rather than filed also carries the contract or package the deliverable sits under, the milestone it is due at, the review code the reviewer returned, and the transmittal it was issued under. This template ships sixteen columns, including a file location and a notes column.
- Who keeps the master document register?
- The document controller keeps it, with the project manager and the discipline leads agreeing the deliverables list that seeds it and the planned dates that drive it. On an EPC job the contractor maintains its own register and reports against the owner's. The register only stays reliable while one clear owner books documents in, updates the status, and keeps the planned dates aligned with the programme, rather than several people editing copies of the file.
- How do you track late deliverables in an MDR?
- Keep the planned issue date and the actual issue date in separate columns and never overwrite the planned one. Sort on the planned date, filter the status to anything other than Accepted, and what is left is the late list, with the responsible party named on each row. Reforecasting by editing the planned date hides the slippage the register exists to show, so record the new date in the notes and leave the original in place.
- Does the template work in Excel and Google Sheets?
- Yes. The .xlsx file opens in Excel with the header styling, the header row frozen, and the Discipline, Document type, Milestone, Status, and Review code dropdowns in place. The .csv copy opens anywhere, including Google Sheets and any other spreadsheet tool, and holds the same columns and example rows without the formatting.
For the documents already in hand rather than the ones still owed, use the document register template. For the drawings among them, use the drawing register template, and for what left the office, the transmittal register template.
Outgrown the spreadsheet MDR?
Book a walkthrough with someone who knows what a transmittal and an as-constructed drawing are, and watch Lunr run a deliverable from planned to accepted on one record.
10M+ documents under management · Hosted in Australia and the US · SAML · Full audit trail · Export anytime
- entity
- Lunr Labs Pty Ltd
- location
- Melbourne AU
- workspace
- documents.lunr.app
- rev
- 2026