One SKU, Several Names: Building a Product Master Across Business Systems

A product may have one name in your accounting software, another in the warehouse spreadsheet and a third on a marketplace. Different names are manageable. The problem begins when teams cannot establish whether those records represent the same stock item, a different variant or a different pack quantity.

SKU master data management means maintaining product identity and controlling how other systems refer to it. For an Indian manufacturer, distributor or multichannel seller, start with one stable internal identity per distinct stock item, supported by explicit mappings, units and ownership.

The structure below is a recommended starter design, not a mandatory standard. It can begin in a controlled workbook before moving into an ERP or dedicated master-data tool.

1. Separate product identity from its display name

Use the internal SKU as the durable reference. Keep product titles, supplier descriptions and searchable aliases separate.

Shopify’s SKU guidance describes SKUs as internal inventory-tracking codes and distinguishes them from barcodes. Your internal reference should therefore not depend on listing wording or be treated as interchangeable with every external identifier.

Adopt a short identity policy:

• Assign distinct SKUs when items must be stocked, picked or replenished separately.
• Track warehouse location separately; moving the same item should not create another identity.
• Keep changing prices, supplier names and promotional wording out of SKU codes.
• Correct spelling in descriptions rather than issuing new identities.
• Never recycle retired SKUs for different items.
• Preserve useful old names as searchable aliases, not authoritative matching keys.

Use a family identifier to group variants without treating the family itself as sellable stock. In a hypothetical shirt catalogue, one family could contain separate size-and-colour SKUs.

Before merging apparent duplicates, compare specifications, size, colour, net content, packaging and interchangeability. Similar names are not enough. If the physical distinction remains unresolved, leave the records separate pending review.

2. Start with five linked tables

Avoid one oversized sheet containing every supplier code, listing, price and stock balance. Use five linked tables or workbook tabs, connected by the internal SKU.

Keep inventory balances and channel prices in their operational records. This master establishes what an item is; it should not become a second, manually maintained stock ledger.

For a spreadsheet pilot, protect identifier and conversion columns, use dropdowns for controlled values, and restrict structural edits to the steward. Validate that every mapped or component SKU exists in the product master before activation.

3. Make external identifiers resolve in context

Do not assume a supplier code or seller SKU is unique across every partner and account. Use a scoped matching key:

Source system + account or partner + identifier type + identifier value

The lookup should return one internal SKU and an explicit selling unit for the relevant effective date. If a code is reused across selling units, include the unit in the lookup only when the incoming transaction reliably supplies it. Otherwise, resolve the coding ambiguity before activation.

Hypothetical example: a distributor stocks 500 ml bottles under internal SKU `ITM-00421`.

This assumes cartons are a selling unit of bottle stock. If sealed cartons must be managed as distinct stock items, define a separate identity and the corresponding packing or unpacking movements.

Keep listing IDs, seller SKUs, supplier codes and GTINs in separate typed rows or fields. Assess applicable Global Trade Item Number requirements independently when products or packs change; an internal SKU decision does not settle that assessment.

Store identifier values as text to preserve leading zeros. Allow several external identifiers to reference one item, but block overlapping active mappings with conflicting items or quantity interpretations. Never infer pack quantity from a listing title.

4. Make units explicit at every hand-off

Choose one stock unit per item and express conversions in one direction:

Stock quantity = transaction quantity × conversion factor

In the hypothetical example, one carton contains 12 bottles, so two cartons represent 24 bottles. Record that factor against the item’s carton configuration—not a universal unit called “carton”.

Keep four concepts separate:

• Bottle capacity: 500 ml, a product attribute.
• Stock unit: bottle.
• Selling unit: carton of 12 bottles.
• Selling price: maintained through the pricing process, not inferred solely from quantity conversion.

Define whether fractional quantities are allowed. Individual bottles may require whole quantities; material stocked in kilograms may need decimals. Specify how invalid quantities are held for correction rather than silently rounded.

For variable-weight goods, define how actual weight is captured instead of forcing a fixed pieces-to-kilograms factor. When pack quantity changes, create an effective-dated configuration and assess whether a separate stock identity is needed. Preserve the conversion used on earlier orders and returns.

5. Decide how bundles consume stock

Before activating a bundle, choose its operating model:

Confirm how your systems implement the chosen model. Name the system responsible for each stock movement so a sale does not deduct both a stocked parent and the same components again.

Define cancellation, partial-return, damaged-component replacement and disassembly handling. In particular, distinguish a cancellation before picking from one after stock has moved. A returned kit should not automatically become fully available stock before its contents are checked.

Version the component list. Previous orders and returns should retain the composition sold at the time, not inherit today’s bundle definition.

6. Assign ownership by field

Appoint one accountable steward to resolve disagreements, then assign field responsibilities:

For an Indian business, reserve tax-related fields for finance review where needed. Do not guess HSN classifications or rates from similar product names.

Name the authoritative system for each field as well as its owner. For example, a proposed setup might let the ERP own stock units and a catalogue tool own marketing descriptions. Avoid uncontrolled two-way overwrites: each receiving system should know which values it may change locally and which it must accept from the authority.

7. Control changes before they reach live transactions

Use a request → review → test → activate → confirm workflow.

Apply stronger review to identity, conversion, tax and bundle changes than to display-text corrections. Record the old value, proposed value, reason, effective date and affected systems.

Before activation, ask:

• Does this change alter what an existing SKU means?
• Which open orders, purchase orders or returns are affected?
• Will historical transactions retain their original units and composition?
• Which downstream systems must receive the update, and who confirms receipt?
• What happens if only some systems accept the change?

For a partial update, define whether affected transactions will be held or the previous configuration restored. Do not let systems process conflicting meanings silently.

Retire records rather than deleting them indiscriminately. Close old mappings with validity dates and retain their history. A saved master record is not confirmation that every downstream system received the change.

8. Pilot a complete transaction, not just an import

Choose a small product family containing a variant, a carton sale and a bundle. Reconcile existing codes and resolve ambiguous mappings before connecting live order flows.

Test purchase receipt, channel order, picking, invoicing, cancellation and return. For each hand-off, record the expected SKU, transaction unit, conversion, stock movement and actual result. Include an unmapped-code test and a conflicting-mapping test: both should enter a review queue, not be matched by product name.

Use these recommended acceptance criteria:

1. Every pilot identifier resolves to one intended item and selling unit.
2. Unit conversions produce the expected stock quantity.
3. Each intended stock movement occurs once, with no duplicate bundle deduction.
4. Returns use the original order’s conversion and bundle composition.
5. Approved changes reach all affected systems, with failed updates visible to an owner.

Track missing mappings, duplicate identities, conversion exceptions and failed updates as internal checks—not assumed evidence of savings.

Start with one product family and one accountable steward. Expand after the full transaction test passes and exceptions have named owners. The aim is not identical wording everywhere; it is a dependable answer to what was bought, sold, moved or returned.