A reused SKU points an old order at a different product

A SKU is a label with a lifespan, not a permanent identity

The failure mode is quiet: the SKU itself is valid, the current catalog resolves it cleanly, and a picker or integration confidently retrieves the wrong product. Shopify's product documentation recommends unique SKUs for inventory tracking precisely because the whole convention depends on one label meaning one item. When a merchant retires a product and hands its SKU to a successor, every historical reference to that label becomes ambiguous unless something else records which meaning applied when.

Archiving changes visibility, not history. On Shopify, archiving removes a product from active sale visibility, but that does not erase what old orders recorded, and it does not tell you which product an old order line referred to. Similarly, the inventory quantities on a current product detail page — available, committed, incoming, and the other states Shopify distinguishes — describe stock of today's product. None of them testifies about the identity of a line written before the SKU moved.

Read the order line as it was written, not as it resolves now

Start with the original order line snapshot: the product name, variant title, unit price, and SKU exactly as stored when the order was placed, plus the order date. If the platform stored a product or variant reference on the line alongside the SKU, that reference is stronger evidence than the SKU, because it points at a record rather than a label. Preserve the snapshot before anyone edits the order or 'corrects' the line to match the current catalog.

Resist the two easy shortcuts. Do not re-derive identity by searching the live catalog for the SKU; that returns the successor product by construction. Do not treat a matching price or a similar name between snapshot and current product as confirmation: a successor product may have a similar name or price, and neither proves historical identity. The snapshot tells you what the store believed it sold; the remaining work is finding out which catalog record that belief attached to on that date.

Rebuild the SKU's timeline from dated records

Look for the archived product or variant that held the SKU first and record its identity: name, variant details, and any archived identifiers. Then establish the boundary date on which the SKU moved, using whatever genuinely exists: catalog edit history, dated product exports, receiving records that show the old product stopping and the new one starting, or a documented SKU change log. The order date relative to that boundary is the actual decision input.

If the boundary cannot be dated, bracket it honestly. A last sale of the old product and a first receipt of the new one give an interval, not a date, and an order inside that interval stays unresolved. Record partial evidence as partial; a timeline with a gap is more useful than a confident timeline assembled from inference.

Decide whether the old order can still be interpreted

Three outcomes are legitimate. Interpretable: the snapshot and the dated timeline agree on one product, and the pick can be authorized against that product's identity, with the evidence attached to the order. Partially interpretable: the product family is clear but the variant or formulation-era is not, which stays unresolved until the missing detail is found. Unresolvable: the snapshot is thin and the boundary is undated, in which case the correct action is no pick and an escalation.

The catalog owner decides product identity questions; the fulfillment lead decides whether stock of the established product exists and can be allocated. Neither role should decide by shipping the current product as an 'equivalent' — this page establishes identity only, and makes no claim that two products sharing a SKU are interchangeable or suitable substitutes. If the customer must be asked what they purchased, that contact is a merchant support decision made under the merchant's own terms.

Stop the next collision without rewriting the past

Going forward, retire SKUs with their products and issue fresh ones, keep a dated SKU reassignment register if reuse ever occurs, and record old-to-new mappings where a successor relationship genuinely exists. Do not edit historical order lines to make them resolve to the current catalog; that converts a recoverable ambiguity into a permanent falsification.

If the reuse traces back to how the catalog or its integrations were set up and you want that concern scoped, a Prism consultation can discuss the storefront and catalog structure you describe. Keep internal exports and customer records out of the inquiry, and confirm scope, responsibilities, fees, and terms before any work begins.

Item-identity history sheet

Complete one sheet per affected old order. Enter only what dated records actually show; write unknown where the record is absent. The finding controls the pick decision, and unresolved means do not pick.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.