A supplier document requirements list (SDRL) is the list a buyer attaches to a purchase requisition or purchase order that tells a supplier exactly which documents to deliver, in what format, at what stage of the order, and for what purpose, for review, for information, for record, or as-built. On an instrument or control-system package it runs from the general arrangement drawing through the calibration certificate to the as-built loop wiring, and it is the document that turns a purchased transmitter or valve into something that can actually be installed, commissioned, and maintained. Some projects call the same list a vendor document requirements list (VDRL) or a supplier data requirements list; the terms describe the same requirement, not different documents.
Key takeaways
- The SDRL is a requirement list, not a tracking record. What has actually arrived, and its review status, lives separately in the vendor document register (VDR).
- It is attached to the material requisition and carried onto the purchase order, so it is a contractual obligation on the supplier, not a checklist someone hopes gets followed.
- Each row carries a document type, a review code, for review, for information, for record, or as-built, a format, and a due point tied to a project milestone.
- The tag list on the SDRL has to trace back to the instrument index. A document that arrives against the wrong tag, or at the wrong revision, is a documentation gap even when the physical equipment is fine.
- Final documentation, calibration certificates, as-built drawings, test reports, is the piece most often missing at mechanical completion, because it is the last thing a supplier produces and the easiest thing to defer.
What the SDRL controls
An SDRL row answers four questions for a single document: what it is, what it is for, what format it arrives in, and when it is due. The "what it is for" column is the one worth reading carefully, because a document marked for review carries an obligation to check it before proceeding, a document marked for information does not, and treating the two the same is where review effort gets wasted on documents nobody needed to act on, or skipped on documents that did.
The SDRL is drafted as part of the material requisition and issued to bidders with the inquiry, so it is priced into every bid rather than negotiated after the order is placed. A supplier that under-resources its document deliverables to win on price is exactly the gap the SDRL is meant to close before the fact.
The four review purposes
- For review. The document is a proposal. Someone on the buyer's side is expected to check it, comment, and return it before the supplier proceeds, typically a general arrangement drawing or a completed datasheet, before fabrication starts.
- For information. The document is a status update, not a request for action. Nobody is expected to comment before the supplier proceeds, and treating an information document as if it needed sign-off just slows the order down for no reason.
- For record. The document proves something already happened, a calibration was performed, a material was certified, a test was witnessed. It is filed, not reviewed line by line, unless the record itself looks wrong.
- As-built. The document reflects what was actually delivered, which can differ from what was originally proposed. It is the version every downstream document, the loop folder, the site asset record, should be built from, not the original for-review issue.
SDRL vs VDR vs MDR vs transmittal
Four documents get confused because they all sit near the same paperwork, and none of them does the others' job.
| Document | Question it answers | Who owns it | When it changes |
|---|---|---|---|
| SDRL | What must the supplier deliver, in what format, and by when? | The buyer, drafted by the discipline engineer as part of the requisition | Fixed at requisition; revised only by a formal order amendment |
| Vendor document register (VDR) | What has the supplier actually submitted, and what is its review status? | Document control, buyer or supplier side, whoever runs the submission log | Updated continuously, every submission and review cycle |
| Master document register (MDR) | What documents exist across the whole project, from every discipline and every supplier? | Project document control | Grows for the life of the project |
| Transmittal | What was sent, to whom, under what cover, and on what date? | Whoever is issuing documents at that moment | Created fresh for every despatch; never edited after issue |
The SDRL and the VDR are the pair worth distinguishing on sight. The SDRL is what was promised; the VDR is what actually turned up. A project that only maintains one of them cannot tell a late document from a document nobody ever asked for.
A worked SDRL extract
The rows below are synthetic, built for one transmitter and valve package, but the shape is representative of what an instrument SDRL carries.
| Document type | Review code | Format | Due |
|---|---|---|---|
| General arrangement drawing | For review | PDF and native CAD | With order acknowledgement |
| Instrument datasheet (completed) | For review | Before FAT | |
| Weight and dimension data | For review | PDF or spreadsheet | Before FAT |
| Hazardous-area certificate | For record | Before FAT | |
| Calibration certificate | For record | With shipment | |
| Material certificate | For record | With shipment | |
| Factory acceptance test report | For record | At FAT completion | |
| Installation and operating manual | For information | With shipment | |
| Spare parts list | For information | With shipment | |
| As-built drawings | For record | PDF and native CAD | For handover |
Two things stand out on a real extract like this. First, "for review" clusters early, before the vendor commits metal to a design, because that is the only point where a comment can still change something cheaply. Second, "for record" and "as-built" cluster at the end, because they document what was actually built and shipped, not what was proposed.
What goes wrong
- Documents that arrive but don't match the tag list. A datasheet or certificate submitted against the wrong tag, or against a tag that was later deleted from the P&ID, sits in the VDR looking complete while the actual tag has nothing.
- Revision drift. The SDRL is issued against one P&ID revision; the supplier's datasheet is built against an earlier one. Nobody notices until the instrument index and the as-bought datasheet disagree on a range or a material.
- "For information" documents nobody reviews. That is the correct behaviour for that review code, but only if the code was assigned correctly. A document that should have been marked for review, and was marked for information instead, ships a defect straight through.
- Final documentation arriving after mechanical completion. Calibration certificates and as-built drawings are usually the last items on the SDRL and the last thing a busy supplier produces, so they are the most common cause of an open item at handover.
Where it feeds the rest of the package
Every tag on the SDRL should already exist on the instrument index, and the technical requirement each document is checked against is the same one used in the technical bid evaluation. Once the equipment and its documents are on site, the loop-specific subset, wiring diagrams, calibration certificates, hook-up drawings, becomes part of the loop folder the commissioning team actually works from. On projects handing data over in a structured format, the SDRL's document types are also what get mapped onto the handover classification, which is the kind of structured document metadata CFIHOS exists to standardise across operators.
None of that works if the SDRL and the instrument index disagree on which tags exist. Reconciling the two before the requisition is issued is cheaper than discovering the gap when a document arrives for a tag nobody remembers ordering.