Stop chasing suppliers
for missing certificates.

Every Manufacturing Data Book (MDB) or Manufacturing Record Book (MRB) is, in the end, an assembly of documents that other people produced. The fabricator welds and tests; the foundry pours and certifies; the coating shop blasts and paints; the instrument supplier calibrates. Your job — as the quality manager, document controller or EPC project team — is to gather all of it into one coherent, approved, traceable dossier.

That gathering is what we mean by collecting supplier documents. It covers material test certificates (EN 10204 3.1 and 3.2), welding records and WPS/PQR, NDT and NDE reports, heat-treatment charts, hydrotest and FAT reports, painting and coating records, calibration certificates and declarations of conformity — each in the correct revision, each tied to the right item, each delivered before its milestone.

On a project of any size you are not chasing one supplier. You are chasing dozens, in parallel, each owing a different subset of documents — and the data book cannot close until the last one arrives.

Building the structure of a data book is straightforward. Writing the index, defining the chapters, agreeing the format — that is a day's work. The hard part, the part that slips schedules and triggers late nights before a shipment, is collection: getting every document, in the right revision, out of every supplier and into the book.

The reason it is hard is that the work depends on people you do not control. A supplier's document controller has their own queue, their own priorities, and no direct stake in your milestone. So the document arrives late, or in the wrong revision, or as an unreadable scan, or not at all — and you only discover the gap when you sit down to compile the book.

The cost is rarely a single dramatic failure. It is the steady drain: the follow-up emails, the status meetings, the spreadsheet reconciliation, the "can you resend that as a 3.2 instead of a 3.1" round trips. On a multi-supplier project this quietly consumes a large share of the quality team's week.

Almost every team starts the same way: a requirements list in Excel, sent to suppliers by email, with documents coming back as attachments that someone files on a shared drive and ticks off in the spreadsheet. It works — until it doesn't.

No single source of truth

The spreadsheet, the inbox and the shared drive drift apart within days. The document arrived but nobody updated the sheet; the sheet says "received" but the file on the drive is the wrong revision. Nobody can answer "what is still outstanding?" with confidence — so the answer becomes another round of emails.

The status is invisible to the supplier

Your supplier has no idea which of the eleven documents they owe you are still open, because that lives in your spreadsheet, not theirs. So they wait to be told, and you spend your time telling them — one email at a time.

The chase doesn't scale

With three suppliers, email works. With thirty, the document controller becomes a full-time chaser, and the risk of a missing certificate surfacing at the worst possible moment — the inspection, the shipment, the client audit — rises with every line item.

The structural fix is to stop treating the requirements list as something you own privately and chase against. Instead, make it a single shared list that both you and your suppliers work from — the same backbone the EPC's Vendor Document Requirements (VDR) list provides on large projects.

You define, once, exactly which documents each supplier owes: the item, the document type, the required revision, the format and the milestone. Each supplier then uploads directly against their own line items. The list stops being a thing you maintain by hand and becomes the place where collection actually happens.

The shift is subtle but decisive: the supplier is no longer emailing files into your inbox for you to sort. They are filling in the slots you defined, and the gaps are visible to both sides in real time.

Once collection runs against a shared list, the single most valuable thing you gain is visibility. Every document sits in a clear state, and the gaps stop being a surprise:

And the chase itself becomes automatic. Instead of the document controller manually writing "gentle reminder" emails, the platform sends the reminders for overdue items on a schedule. The human effort moves from chasing to reviewing — from "where is it?" to "is it right?".

Collection is not the goal in itself — the compiled, approved Manufacturing Data Book is. The advantage of collecting against a structured list is that the documents arrive already mapped to their place in the book. There is no second step of "now sort the inbox into the dossier".

1. Documents land where they belong. Each upload is tied to the requirement it satisfies, so the data book structure fills itself in as suppliers respond.
2. Reminders run themselves. Overdue items are chased automatically, so the team's time goes to reviewing documents, not writing follow-up emails.
3. Suppliers who also use the platform flow in directly. When your supplier builds their Vendor Data Book in the MDB Builder too, their documents arrive in your project without an email or a re-upload — the two sides of the same exchange finally meet.

When the last requirement turns green, the book is ready to compile and submit for approval — without the final-week scramble.