Vendor Data Book
Builder.

When an EPC contractor purchases equipment for an industrial project, the deliverable is never just the hardware. It is the hardware plus a structured documentation package: the Vendor Data Book. The VDB demonstrates that the equipment conforms to the contract specification, that all material and inspection requirements were met, and that the operator has the information needed to install, commission and maintain the equipment over its lifetime.

Inside a typical VDB you will find: equipment data sheets, general arrangement and outline drawings, material test reports, welding documentation, NDT/NDE results, hydrotest and factory acceptance test certificates, painting and coating records, spare parts lists, installation, operation and maintenance (IOM) manuals, the Declaration of Conformity, and the inspection release certificate. Volume varies from 50 pages for a simple skid-mounted item to several thousand pages for a complex turbine package.

For an equipment supplier, the most important document in the contract is rarely the technical data sheet. It is the Vendor Document Requirements list (VDR) — attached to the Material Requisition (MR) and the Purchase Order — that defines exactly which documents must be delivered, in what revision sequence, by which milestone, and in what format.

A VDR typically lists 30 to 80 documents per equipment item, each tagged with a category (e.g. mechanical, instruments, electrical, certification), an action code (information only, approval required, certified for construction), and a set of milestones (with PO, before manufacture, before shipment, after FAT, with delivery). The supplier's Document Controller's job is to deliver each document against its assigned milestone — and to do so without missing a revision cycle.

EPC contractors take VDR compliance seriously. A late document can hold up an inspection. A missing revision can hold up a milestone payment. And in some cases, a complete non-conformance with the VDR can be grounds for delivery rejection — even when the equipment itself is perfect.

A typical mid-sized equipment manufacturer serves between five and fifteen EPC clients in any given year — often more. Each EPC has its own VDR template, its own document numbering scheme, its own transmittal format, its own vendor portal, and its own revision conventions.

The visible cost

The supplier produces, in effect, a slightly different documentation package for the same equipment for every client. A pump for Project A becomes the same pump for Project B with different cover sheets, different transmittal numbers, different bookmark hierarchy, different revision identifiers. The work is repetitive but cannot safely be skipped — each EPC's document controller checks.

The hidden cost

More damaging is the cognitive overhead. A Document Controller working across five EPC platforms holds five different mental models of "where does this document go". Errors creep in. The wrong revision is uploaded to the wrong portal. The transmittal references the wrong PO. The error is caught — usually — but the rework consumes a disproportionate share of time and trust.

The structural fix

The structural fix is to invert the relationship: maintain a single product documentation library on the supplier side, and treat every EPC's VDR as a view onto that library. The supplier's job becomes mapping incoming VDR rows to existing product documents — and the platform produces the rest.

For an equipment supplier, the documentation library is a long-term asset. A pump model that has been built fifty times has fifty FAT reports, fifty hydrotest certificates, and one stable set of GA drawings, IOM manuals, spare parts lists and material certificates. That stable set should be produced once and reused indefinitely.

A modern Vendor Data Book platform organises documentation around products, not projects. Each product has its own revision-controlled documentation set. When a new project arrives, the supplier links the relevant product, layers project-specific documents on top (FAT report, certificates of compliance, customer-specific tagging), and produces a compliant VDB in hours rather than days.

Over time this compounds. The fiftieth project for the same product line is dramatically faster than the fifth — not because the supplier got faster, but because the platform got more complete.

Documents in a VDR are tied to milestones. Missing a milestone is one of the most common sources of supplier liquidated damages. The five milestones that come up in almost every EPC contract:

A platform that tracks each document against its assigned milestone — and visibly flags upcoming and overdue deliveries — is the single most valuable feature for a supplier with multiple concurrent EPC projects.

The bar a Vendor Data Book platform must clear is practical, not theoretical. Three concrete capabilities make the difference between a tool that adds work and a tool that removes it:

1. VDR-driven structure. The supplier imports or maps the EPC's VDR; the platform creates the document slots automatically. The supplier doesn't recreate the structure for each project — it inherits it.
2. Product-centric library. Documents that belong to a product, not a project, live with the product. The next project for the same product line reuses them with a single click. The fiftieth FAT report for the same pump model takes minutes, not hours.
3. Cross-tenant delivery to EPCs that also use the platform. When the EPC uses the MDB Builder for their MRB, your VDB project flows directly into their workspace, clearly labelled as yours. The double upload goes away. The transmittal becomes implicit.