The honest overview
Excel is, for better and worse, the default tool for building Manufacturing Data Books. An estimated four out of five fabricators we have spoken with use a combination of Excel for the index, a shared folder for the documents, a desktop PDF merger for assembly, and email or WeTransfer for delivery and review.
The reasons are simple. Excel is already installed on every machine. It has zero procurement friction. Anyone can customise it without IT involvement. And for a small fabricator producing a handful of MDBs per year, that familiarity is real value.
But there is a point at which Excel stops scaling. That point is reached sooner than most quality teams realise — and once it has been crossed, the cost is mostly invisible because it is absorbed into other budgets. The same hours, project after project, never measured because they look like normal overhead.
Where Excel still wins
A fair comparison starts with where Excel is genuinely the right answer.
- Very low project volume. If you produce fewer than ten MDBs per year, the overhead of learning, configuring and maintaining a dedicated platform may outweigh its benefit. Excel is fine.
- One-off, non-repeating projects. If your MDBs are all unique and bear no resemblance to each other, the structural advantage of a templated platform is reduced.
- Single-person operations. If one person is the entire quality team and there are no suppliers to coordinate, the collaboration features of a platform are unused.
- No external review cycles. If your clients accept the MDB without comment, the online review portal isn't relevant for you.
If three or more of these apply to your situation, Excel is probably still the right tool. If none or one apply, the next sections are likely to be uncomfortable reading.
Where Excel fails
When Excel fails in MDB workflows, it fails for the same five structural reasons every time:
- No native file storage. The Excel tracker references files; the files live in folders. The two drift out of sync the moment someone moves, renames, or forgets to copy a file.
- No real revision control. "Save as Rev_B" is the entire mechanism. The previous version is preserved only if someone remembered to copy it first. When the auditor asks why a section was changed and by whom, the answer is rarely complete.
- No supplier collaboration. Suppliers send files by email or WeTransfer. Someone — usually the Document Controller — manually downloads, renames, copies into the correct folder, and updates the Excel tracker. Each handoff is a chance for mismatch.
- No automatic PDF assembly. Final assembly is done with a desktop PDF tool: drag, merge, bookmark, renumber. A 500-page MDB takes hours of attention. Insert one new document late in the cycle and the bookmarks are off again.
- No audit trail. Years after handover, when someone needs to know which welder welded which joint and what NDT was performed, the answer must be reconstructed from email archives and folder modification dates. Sometimes it is. Often it isn't.
None of these problems is fatal in any single project. They accumulate. They produce the slow tax of admin overhead that quality teams describe as "just how the work is"— until it isn't.
Side-by-side comparison
The table below summarises ten dimensions where the two approaches diverge.
| Area | Excel-based workflow | MDB Builder platform |
|---|---|---|
| Initial setup time | 30 min — open last project's spreadsheet, save-as, edit titles | 3 min — pick sector + applicable codes, structure is generated |
| MDB structure | Free-form — every project starts a new opinion about how to organise it | Code-driven — structure aligned with ASME, PED, EN 1090, NORSOK |
| Document storage | Network folder, separate from the tracker — drifts out of sync over time | Single source of truth — every document lives in one place, indexed |
| Supplier collaboration | Email and WeTransfer — supplier sends files, someone copies them in manually | Secure invitation link — supplier uploads directly, no account required |
| Revision control | File names with _Rev_A, _Rev_B suffixes — easy to lose track | Built-in IFR → IFA → Approved with a complete audit trail |
| PDF assembly | Manual — open Adobe Acrobat, drag PDFs, add bookmarks, renumber, merge | One click — server-side, with cover page, TOC and bookmarks generated |
| Client review | Email a 600 MB PDF, wait two weeks, receive scanned redlines, decode them | Secure online review with inline annotations and per-chapter approvals |
| Audit trail | Whatever you can reconstruct from email and the latest spreadsheet save | Every change is time-stamped, attributed and queryable for years |
| Multi-unit serial production | Copy-paste hundreds of cells, hope nothing breaks | Common chapters and per-unit chapters, with configurable numbering |
| Cost | $0 in software · 200-500 hours per year of admin time absorbed elsewhere | Free for first 3 projects · Paid tiers from a fraction of the time saved |
Try the alternative on your next project.
Free for your first 3 projects · No credit card required.
Migrating from Excel — what to expect
Most teams do not switch overnight. They run a parallel project — one MDB on Excel, the next on the platform — and compare. The honest expectation:
What is harder at first
Resisting the urge to keep updating the Excel tracker 'just in case'. Trusting the platform to be the source of truth requires a small leap. Once made, the leap is rarely undone.
What is faster from day one
Initial structure setup. Inviting suppliers. Generating transmittals. Producing the final PDF. Reviewing online. Even on the first project, these tasks save half a day each.
By the second or third project, the templates are tuned, the team's mental model has shifted, and the savings compound quickly. Most quality teams that complete a fair comparison do not return to Excel for documentation that scales beyond a single page.
Frequently asked questions
Is Excel actually used to build Manufacturing Data Books?
Yes — Excel is the most widely used MDB-tracking tool in fabrication and engineering today, despite never having been designed for the job. A typical MDB process uses Excel for the document register, a network folder for the actual files, a desktop PDF tool for assembly, and email or WeTransfer for delivery. The combination is universal precisely because it has zero per-seat cost and no procurement hurdle.
Where does Excel still win?
Excel wins on three counts: it is already installed everywhere; the learning curve is effectively zero; and it can be customised by any individual without IT involvement. For very small fabricators producing a handful of MDBs per year, the overhead of a dedicated platform may outweigh its benefits. The break-even point is typically around 10-20 MDBs per year, after which the lost time on tracking, merging and reviewing makes a purpose-built platform an obvious investment.
Where does Excel fail in MDB workflows?
Excel fails on five structural points: (1) no native file storage — documents live in folders that drift out of sync with the tracker, (2) no real revision control — a workbook saved-as becomes the new single source of truth, with the previous version lost, (3) no supplier collaboration — suppliers email or WeTransfer files which someone manually copies into the right folder, (4) no automatic PDF assembly — every MDB requires manual page-numbering, bookmarking and merging, and (5) no audit trail — by the time you need to know who changed what and when, the answer is typically lost.
Can I migrate my existing Excel-based MDB process?
Yes. The MDB Builder allows you to import an existing Excel-based MDB index by recreating it as a structured project, then collecting documents into the new structure. Most teams keep their first project on Excel as a baseline and run the next project entirely on the platform — comparing the time and quality outcomes side by side before committing fully.