What a Master Document Register Is, and What It Controls

By [AUTHOR_NAME], [AUTHOR_JOB_TITLE], TechTiera. Published [PUBLISH_DATE]. Last verified [VERIFIED_DATE].

Short answer: a master document register (MDR) is the controlled list of every document and drawing a project is required to produce, one row per document, carrying who owes it, what revision it’s at, what status it holds, when it was promised and when it actually arrived. It’s a planning and control instrument, not an inventory. Your folder structure records what happens to exist. An MDR records what should exist, whether it’s late, who owes it, and whether you’re allowed to build from it yet. That’s the whole difference, and it’s why a folder tree can never be a register no matter how well you name the folders.

a register knows about documents that don’t exist yet. a folder can’t.

The one-question test

Ask your system about a document that doesn’t exist yet. Pick a deliverable due in six weeks that hasn’t been submitted. If it can name that document, its discipline, who owes it, when it was promised and how late it is, you have a register. If the document simply isn’t there, and the only way to know it’s missing is that somebody remembered, you have a list of files.

A register is forward-looking: authored from the contract, with reality recorded against it. An index is backward-looking: populated by whatever people happened to save.

What is the MDR actually for?

Two jobs everyone recognises, and a third most teams aren’t resourced for. It defines the agreed scope of information down to the individual document, before anyone has drawn anything. It controls what may be used, because revision plus purpose of issue answers the only question a site engineer cares about: is this safe to work from, or is it somebody’s draft?

The third job is measurement. Planned dates against actual dates, by discipline and by contractor, turns “the contractor is behind” from an opinion into a defensible position. It cuts both ways, which is the honest part: review aging is the same measure pointed at your own organisation, and it’s frequently the real bottleneck.

On infrastructure and buildings work the same instrument has different names. Under ISO 19650, each task team produces a task information delivery plan (TIDP), collated into a master information delivery plan (MIDP), which the UK BIM Framework guidance describes as setting out what information is delivered, by whom, when and in what order (UK BIM Framework, Guidance Part F, Edition 1, September 2020). Same idea: plan the information, then track delivery against the plan.

MDR vs SMDR: who owns which register?

This trips up more projects than it should, and it’s rarely technical. It’s an ownership problem wearing an acronym.

• The MDR is the project-level register. One per project, owned by the party accountable for the complete deliverable set. Usually the owner’s document control team, with the EPC contractor maintaining their own consolidated view under contract.
• The SMDR is a supplier’s register. One per supplier or package, maintained by that supplier, covering only their scope and rolling up into the MDR. Package vendors (pumps, compressors, skids, switchgear) own the deliverable list for their own equipment, usually issued to them as a vendor document requirements list.

The honest part about the letters: SMDR gets expanded differently depending on who wrote the contract (supplier master document register, sub-supplier document register, other variants). It isn’t standardised, so your contract’s definitions clause is the only authority on your project. Read it before you build a template, because the template encodes an ownership decision.

The rule underneath matters more: one register is the register. Every other register is a feed into it, with a defined handoff (normally a transmittal) and a stated reconciliation cadence. Two registers with two owners and no precedence isn’t redundancy, it’s a dispute waiting for a handover date.

What fields does a real MDR carry, and why?

Template downloads give you columns without reasons, which is why registers end up half-populated. If you can’t name what breaks without a column, don’t add the column.

Field	What it holds	Why it exists
Document number	Unique controlled identifier, to the project convention (project, area, discipline, type, sequence).	The key tying every transmittal, comment sheet, revision and as-built record to one object. Without it, one document arrives three times under three filenames and gets reviewed twice.
Title	Human-readable, to an agreed naming standard.	Retrieval and de-duplication. Unenforced titles are how you get “P&ID Unit 200 rev C final (2)”.
Discipline	Process, mechanical, piping, civil and structural, electrical, instrumentation, HVAC, telecom.	Routes reviews to the right reviewers, and it’s the unit engineering managers manage in. Progress with no discipline split isn’t actionable.
Document type	P&ID, PFD, datasheet, calculation, specification, general arrangement, ITP, vendor manual, certificate, procedure.	Type drives the rules: mandatory metadata, review workflow, handover category, retention. One column, four downstream behaviours.
Responsible party	The contractor, vendor or discipline team that owes it.	Accountability. No owner column produces status meetings where a document is late but nobody is.
Revision	The controlled issue identifier, per the project’s revision scheme.	The field the whole discipline exists to protect. Which iteration am I looking at?
Status / purpose of issue	Issued for review, for approval, for construction, as-built, plus review outcome. Hold and superseded flags belong here too.	Revision says which iteration. Status says what you may do with it. Fabricating from an issued-for-review drawing is the classic incident, and it happens when status lives in a filename.
Planned submission date	Contractual or scheduled date for each planned issue.	The field a folder can never have. It’s how the register knows about documents that don’t exist yet.
Actual submission date and revision received	When it arrived, at what revision.	Planned against actual is the only honest progress measure. A register holding only actuals reports activity, never slippage.
Review cycle dates	Issued to reviewers, comments due, comments returned, resubmission due.	Review aging is often the real bottleneck. Without these dates you can’t defend, or defend against, a delay claim.
Transmittal reference (in and out)	The transmittal number that carried this revision, each direction.	The evidence link. “Who sent what, to whom, when, at which revision” should take seconds, not an afternoon in an email archive.
Contractual requirement flag	Whether it’s a contractual deliverable, and under which requirement or handover package.	Outstanding-document lists mix genuine blockers with items nobody will ever ask for. This flag lets you chase the ones that stop acceptance.
Link to the controlled document	A live reference to the current file, not a hand-typed folder path.	A register that names a revision it can’t open is a second source of truth, and the two will diverge. This one field decides whether the register decays.

Add as-built confirmation and a per-milestone progress weighting once handover and progress reporting are in scope. Weightings are contract-specific, so agree them once and write them down. For the register’s role at the end of the project, see what happens to the register at handover.

Register, document list, folder tree: three different things

These get used interchangeably, and the habit causes a large share of revision incidents.

• Folder tree

  An arrangement of files that exist. Where did we put it? No promised date, no owner, no approval, no concept of an absence. Folders named by discipline and revision look organised, which is exactly what makes them dangerous.

• Document list

  An inventory of files that exist, usually exported from the folder tree. What do we have? Useful for audits, but derived from reality, so anything missing from reality is silently missing from the list.

• Master document register

  A controlled plan of documents that must exist, with owner, promised date, revision, status and evidence. What do we owe, what’s late, who owes it, what may we build from?

Conflate them and three things go wrong. Missing documents become invisible, because a register generated from what exists can’t report an absence. Status becomes a filename convention, which nothing enforces and everyone eventually breaks. And lateness stops having a name attached to it.

Why does a spreadsheet register decay? (And when is it genuinely fine?)

Honest side first, because the reflexive answer here is usually vendor-shaped. A spreadsheet register is genuinely fine when one controller owns the file, one or two disciplines are in scope, the document count is in the hundreds rather than the tens of thousands, there’s a single contractor, nobody edits concurrently, and being wrong for a day is embarrassing rather than contractual. Plenty of projects have run that way and closed out cleanly.

What breaks it isn’t the spreadsheet. It’s concurrency, volume and consequence arriving together. Then four failures show up, roughly in order.

1. No link to the actual document. The register says Rev C. The drive holds Rev B in one folder and Rev D in another. Nothing connects them, so nothing reconciles them.
2. No enforced status transitions. Any cell can be typed into. “Issued for construction” can appear without an approval ever happening, and no mechanism could have stopped it.
3. Parallel copies. MDR_rev12_JS_final.xlsx lives in three inboxes and one of them is in today’s meeting. Merging is manual, so it stops under schedule pressure.
4. No audit trail, no row-level permissions. Who changed a status, when and why is unrecoverable. Meanwhile the contractor you emailed it to can read every other contractor’s rows.

What changes when the register and the repository are one system

The structural fix isn’t a better spreadsheet, it’s removing the gap the spreadsheet has to bridge. When the register row is the document record, four things stop being manual: revision is created by a controlled check-in rather than typed, so the register can’t claim a revision that doesn’t exist; status becomes a workflow outcome carrying a name, a date and a comment record; issuing a transmittal stamps its reference, recipients, date and revision back onto the affected rows; and overdue submissions, review aging, resubmission rate and handover completeness become queries instead of a Monday morning of copying between workbooks.

That’s the design principle behind TechTiera Engineering Content Hub, our engineering content solution built on Hyland Alfresco, and behind our engineering and asset information practice more broadly. Said plainly though, and we’d say the same in a meeting: if your controls are sound and the real problem is that nobody enforces the standard, software won’t fix that. It will just make the gap easier to see.

How do you inherit a broken MDR mid-project without stopping work?

Nobody writes about this and almost everybody has to do it. The register you’ve inherited is months out of date, partly populated, disputed, and load-bearing for a milestone you can’t move.

1. Freeze it before you fix it. Dated snapshot, declared the baseline of record, parallel edits stopped that day. You can’t reconcile a moving target.
2. Rebuild the “should exist” side from the contract, not the drive. Deliverable schedule, discipline scope and vendor requirements lists first, then compare against what exists. The other way round, every missing document stays missing.
3. Triage by consequence, not count. Documents someone could build from right now (today), documents blocking a milestone or acceptance (this month), documents nobody will ever request (record the exception and stop chasing).
4. Correct status before metadata. Revision and purpose of issue on documents in active use. A wrong title costs minutes. A wrong status builds the wrong thing.
5. Do not renumber. Changing the convention mid-execution invalidates every transmittal, comment sheet and drawing reference already issued. Let legacy and new numbering coexist with a cross-reference column.
6. Publish a weekly delta, including what you still don’t know. Trust returns faster from a visibly honest register than from one quietly corrected while everyone keeps a side copy.

Frequently asked questions

What’s the difference between an MDR and an SMDR?

The MDR is the project-level register covering the complete deliverable scope, owned by the party accountable for that scope. An SMDR covers one supplier’s or package’s scope, is maintained by that supplier, and rolls up into the MDR. Be careful with the acronym: SMDR is expanded differently across contracts, so your contract’s definitions clause is the authority. The rule that matters is that one register is authoritative and every other register is a feed into it with a defined handoff.

Is a master document register the same as a document list?

No, and treating them as the same causes a lot of revision incidents. A document list is an inventory of files that exist, so it can never report a document that’s missing. A register is authored from the contract before documents exist, and carries planned dates, owners and status alongside actuals. A list tells you what you have. A register tells you what you owe, what’s late, and what you’re allowed to build from.

Can I use a folder structure with revisions in the filenames instead?

You can store documents that way. You can’t control them that way. A folder tree has no owner field, no planned date, no enforced status and no concept of a document that hasn’t arrived. Revision in a filename is a convention, and conventions break at 6pm on a deadline. The specific risk is a superseded drawing nobody marked superseded, sitting in a folder looking exactly as current as the current one.

Is a spreadsheet MDR ever acceptable?

Yes, genuinely. One controller, one or two disciplines, a few hundred documents, a single contractor, no concurrent editing, no contractual consequence to being a day out of date: a spreadsheet handles that well. What breaks it is concurrency, volume and consequence arriving together, and the failure modes are consistent: no link to the actual document, no enforced status transitions, parallel copies, and no audit trail.

Should document control or project controls own the MDR?

Document control owns the register’s integrity: numbering, metadata, revision and status accuracy, transmittal records. Project controls owns what’s done with it: progress, weighting, forecast, contractor performance. The arrangement that fails is project controls keeping a separate progress spreadsheet derived from the register, because the two diverge within weeks.

Further reading

[BLOG_LIST]