Product catalog maintenance: when the description becomes the truth

A product catalog is not a list of items. It is the record that decides what a customer sees, what the warehouse picks, what the invoice charges, and what the accountant reports. When the catalog drifts, the divergence is not visible in any one place — it appears as a price that does not match the shelf label, a stock count that does not match the order, or an invoice that refers to a product that no longer exists.

What must the catalog record contain?

The identifier (not an internal code that changes with every import), the name and description the customer reads, the price at the time of the transaction (not the price in the spreadsheet that was last updated), the unit of measure, the supplier reference, and the link to the stock location. Each of those is a separate fact; combining them into a single row that mixes text and numbers loses the ability to query any one of them.

The description is not marketing copy. It is the record of what the customer receives: size, material, unit, and any difference between variants. A description that only names the product is not a record; it is a label.

Where does catalog maintenance go wrong?

When it is done in the system that displays the product, not in the system that holds the record. Changing the display updates what the customer sees, but it does not update what the warehouse picks or what the invoice references. The result is a product that looks correct to the buyer and is wrong to every other system.

The fix is a single source: one record that feeds the display, the stock module and the invoice. Changes happen once, and the same change reaches every system that reads the record. That requires the link to exist and be checked, not assumed.

What must the update process include?

A request that names the change, an approval that names who decided and why, and a record of what was changed (not just the new value, but the old value it replaced). Without the old value, a change is irreversible: nobody can confirm whether the new price is correct or whether the previous price was the error.

The approval must be a named decision. A change approved by a process without a name is not traceable; it is a modification with no explanation.

When is it safe to skip the process?

When the change is a correction of an obvious error — a misspelled name, a wrong unit — and the cost of recording the correction exceeds the cost of repeating it. Even then, the correction needs a single entry that says what was wrong, what was changed, and who confirmed it. Without that, the correction hides the original error rather than fixing it.

Where this goes wrong

• The catalog is updated in the display system, not in the source. The price changes for the customer but not for the warehouse or the invoice.
• The update records only the new value, not the old one. A price change cannot be verified six months later.
• The description is marketing copy that does not match the item being delivered. The customer receives something different from what was described, and the record has no explanation for the difference.

What this does not cover

This does not define the rules for product photography, marketing descriptions, or customer-facing content — those are separate decisions with their own timelines. It also does not cover supplier catalog imports; see automated-data-onboarding for that.