The SDI your customer actually wants back, history and all

Two lists get confused on every project, partly because the industry’s acronyms invite it. The VDRL, and its cousins VDR, VDDR, SDDR, is the customer’s list of required document codes: which types of document the order owes. It arrives from them; you receive it, you do not maintain it. The SDI, the supplier document index, sometimes called the MDR, is yours: the index of the actual documents, one line each, and the customer wants it back, in their layout, on their schedule. The R in that acronym family stands for requirements in some and register in others, which is why spelling out which list is meant saves arguments.

What makes the SDI expensive is not the list of lines. It is what each line has to carry. A reviewer looking at the index wants the story of each document at a glance: current revision, current status, when it first went out, on which submittal, when it came back, when it went again. Some layouts want calculated values too, days outstanding with the reviewer being the classic. And the whole thing has to be in the customer’s format, sometimes their own Excel workbook, because their document control department files what you send.

Now count the maintenance. Every submittal that goes out touches the history of every document on it: a submittal carrying a hundred documents means a hundred lines of the index need a new entry saying those documents went on that submittal. Every return touches them again. Maintained by hand, the index is either a standing job or it is quietly wrong, and a wrong index is worse than none, because the customer reads it as your record of the truth.

There is also a cadence trap. The index is a report, produced on demand or on the schedule the customer sets. It is not something that accompanies every submittal, and building your process as if it were multiplies the work for no one’s benefit.

The honest way to produce it is the way you would produce any report: from live data. If every send and every return is recorded against the document when it happens, the index is a query in the customer’s layout, not a document anyone maintains.

That is what the SDI is in DocBoss: generated from the live document list, in the customer’s format, PDF or their own spreadsheet, with the full submittal history behind every line, dates, submittal references, and calculated columns such as days outstanding. Changed values are highlighted so the reviewer sees what moved since the last issue, which is normally why they asked for the index on a schedule in the first place. Producing it costs the click, whichever week they want it.

Their list tells you what the order owes. Your index tells them where every one of those documents stands. Keep the two apart, and make the second one free to produce.