How to Create Product Data Validation Rules Before New SKUs Reach the Store

A new SKU can look ready because it has a name, image and price. Then it reaches the live store and customers find a missing variant, an incorrect pack size, an unusable filter value or a product page that cannot support checkout.

The problem is rarely one missing field. It is usually the absence of a clear admission process. New catalogue records are imported, edited or approved without a consistent way to decide whether they are complete, commercially safe and suitable for publication.

This is where product data validation rules help. They turn catalogue quality checks into a repeatable gate before a new SKU reaches the storefront, feeds, marketplaces or paid campaigns.

This guide is for UK ecommerce catalogue managers, product onboarding teams, merchandisers and operations leads. It focuses on creating practical rules that can be automated where possible, reviewed by people where necessary and improved as the catalogue grows.

What product data validation rules should achieve

Validation rules should do more than confirm that a record has been imported. They should help the business decide whether the SKU is ready for the next stage.

A useful validation process should prove that:

• The SKU has a stable identity and does not duplicate an existing sellable item.
• Required product information is present for its product type.
• Variants, prices, stock and images relate to the correct item.
• Values use approved formats, units and vocabularies.
• The product can be displayed, filtered, sold and exported safely.
• Any unresolved exception has a named owner and decision.

Validation is therefore different from enrichment. Enrichment improves a product record. Validation decides whether the record is safe to progress.

Define the publication stages before writing rules

Rules work better when they are connected to clear catalogue stages. A product should not move directly from a supplier file or internal spreadsheet to live publication without an intermediate state.

A practical lifecycle might include:

1. Received: the source record has arrived but has not been assessed.
2. Normalised: identifiers, units and controlled values have been converted into the internal format.
3. Validated: automated checks have passed or exceptions have been accepted.
4. Enriched: customer-facing copy, imagery and merchandising information are ready.
5. Approved: an authorised owner has confirmed publication.
6. Published: the SKU is live on the intended channel.
7. Held: the record cannot progress because a blocking issue remains.

Keep validation status separate from publication status. A product can pass technical validation but still await commercial approval, photography or a launch date.

Start with identity and ecommerce SKU validation

The first rule group should confirm that the record represents a clear, sellable item. If identity is wrong, later field checks may be applied to the wrong product.

Check identifier quality

Depending on your catalogue, identity rules may cover SKU, GTIN, MPN, supplier reference, parent product ID and variant ID. For each identifier, decide whether it must be unique, stable, immutable or unique only within a particular supplier or product family.

Useful ecommerce SKU validation rules include:

• SKU is present and follows the approved format.
• SKU is unique within the relevant catalogue or supplier scope.
• GTIN or barcode values contain the expected number and type of characters where required.
• A variant SKU is linked to the correct parent product.
• Legacy identifiers are retained as aliases rather than silently discarded.
• Identifiers do not contain placeholder values such as “TBC”, “test” or “new item”.

Do not assume that a similar SKU means the same product. A different pack quantity, compatibility or configuration may require a separate sellable identity.

Separate required fields from useful fields

A common mistake is to make every catalogue field mandatory. That creates unnecessary delays and encourages users to enter inaccurate placeholders just to pass the form.

Classify attributes into three groups:

• Publication-critical: required before the SKU can be sold, such as SKU, product name, price, product type and a usable primary image.
• Category-required: needed for particular product types, such as size, material, voltage, compatibility or pack quantity.
• Enrichment fields: useful for comparison, SEO or merchandising but not essential for the first controlled publication.

This approach makes the rules proportionate. A voltage field may be mandatory for electrical equipment but irrelevant for a clothing product. A care instruction may be essential for one category and optional for another.

Build rules around product types and variants

One global validation rule rarely works for a broad catalogue. Product types should determine which attributes are expected and how they are checked.

For example:

• A clothing product may require size, colour, material and variant-level imagery.
• A technical component may require manufacturer reference, compatibility, dimensions and units.
• A bundle may require component relationships, bundle quantity and fulfilment treatment.
• A food or consumable product may require pack size, ingredients or storage information, subject to the relevant business requirements.

Variant rules should also confirm that parent and child records agree. A child variant should not introduce a colour, size or pack value that is missing from the approved attribute vocabulary. It should not inherit a price or image from the wrong parent.

HOFK’s guide to modelling product variants covers the wider distinction between catalogue products, variants, offers and stock records.

Validate formats, units and controlled values

A populated field is not necessarily a usable field. Catalogue systems need rules that check meaning as well as presence.

Useful catalogue quality checks include:

• Dimensions use one agreed unit system.
• Weights and capacities are numeric and within reasonable ranges.
• Currency and tax treatment are explicit.
• Colour, material, finish and product type use approved values.
• Dates use one consistent format.
• Boolean fields do not contain a mixture of “yes”, “Y”, “true” and “1” without a defined mapping.
• Customer-facing fields do not contain internal notes or supplier placeholders.

Range checks should be used carefully. A product that falls outside a normal range may be a genuine exception rather than an error. The rule should flag it for review rather than automatically changing the value.

Create severity levels for validation failures

Not every failed rule should block publication. Give each rule a severity so catalogue teams know what action is required.

A simple model is:

• Blocker: the SKU cannot be published safely, for example because the identifier is missing, the price is invalid or the variant cannot be matched.
• High: the product may be technically publishable but would create a significant customer, fulfilment or feed risk, such as missing compatibility information.
• Warning: the record can proceed with an owner’s approval, but the issue should be reviewed.
• Informational: the value is unusual or incomplete but does not prevent the intended publication route.

Severity should reflect business impact, not how difficult the rule is to implement. A small missing field can be a blocker if it affects checkout or fulfilment.

Keep proposed data separate from approved data

Incoming supplier or internal values should not silently overwrite trusted catalogue values. Store proposed values separately until the relevant rules and approvals have passed.

For material changes, retain:

• Current approved value.
• Proposed value.
• Source file, system or user.
• Date received.
• Validation results.
• Approval decision and owner.
• Publication date.

This makes the decision traceable. It also helps distinguish a source-data problem from a catalogue approval decision.

HOFK’s article on product attribute conflict management explains how field-level ownership and precedence rules can help when supplier and catalogue values disagree.

Design an exception queue that leads to decisions

A failed validation rule should create a useful next action, not another unmonitored spreadsheet row. The exception queue should show the affected SKU, rule, severity, evidence, owner and deadline.

Useful exception categories include:

• Duplicate or uncertain identifier.
• Missing required attribute.
• Invalid unit or controlled value.
• Variant relationship conflict.
• Price or stock inconsistency.
• Missing or unsuitable image.
• Channel-specific requirement not met.

Give each exception a clear outcome: approve, correct, reject, hold or escalate. “Review later” is not a useful status unless it has a named owner and date.

Test the rules with difficult products

Before applying validation across the catalogue, use a test set that reflects the records most likely to expose weaknesses.

Include:

• A simple single-SKU product.
• A product with multiple variants.
• A bundle or multipack.
• A product with missing supplier data.
• A discontinued or replacement product.
• A product with customer-specific pricing.
• A product intended for a merchant feed or marketplace.

For every test, record the expected result, actual result, validation messages and publication decision. A rule is not ready because it works on perfect data. It is ready when it handles difficult data predictably.

Monitor validation after launch

Rules need maintenance. Supplier formats change, product ranges expand and teams introduce new channels. Monitor the validation process itself so recurring problems become visible.

Useful measures include:

• New SKUs blocked by rule.
• Most common failure categories.
• Exceptions open beyond their target age.
• Manual overrides by user or supplier.
• Products published with incomplete enrichment.
• Feed or marketplace errors linked to catalogue data.

If one supplier repeatedly fails the same rule, improve the supplier specification or import mapping. If catalogue users frequently override a rule, check whether the rule is too strict or the business policy is unclear.

Product data validation rules checklist

Before allowing a new SKU to reach the live store, confirm that:

• The SKU and related identifiers are valid and appropriately unique.
• The parent product and variant relationships are correct.
• Required fields are defined by product type.
• Units, formats and controlled values pass validation.
• Price, stock, images and key specifications are present.
• Proposed values are separate from approved values.
• Blockers and warnings have different outcomes.
• Exceptions have owners, deadlines and decisions.
• Difficult product types have passed representative tests.
• Post-publication catalogue and feed checks are in place.

Where HOFK can help

Product onboarding often crosses ecommerce platforms, supplier feeds, PIM or ERP data, product templates, search, Merchant Centre and internal approval workflows. HOFK can help review the data model, build validation logic, improve catalogue workflows or connect product data more reliably across systems.

Relevant support may include ecommerce development, full stack development, automation and practical monitoring. The objective is not to add rules for their own sake. It is to give catalogue teams a dependable way to prevent avoidable product data problems before they affect customers.

Conclusion

Product data validation rules give ecommerce teams a controlled admission process for new SKUs. Start with identity, required fields, product-type requirements, variants, formats and commercial data. Then add severity levels, an exception queue, representative testing and post-publication monitoring.

The best validation process is not the one with the most checks. It is the one that blocks genuinely risky records, routes uncertain cases to the right owner and lets good products progress without unnecessary delay. That is the practical foundation of ecommerce SKU validation, catalogue quality checks and product data governance as a catalogue grows.

If your new products are still reaching the store through spreadsheets, unchecked imports or manual fixes, start with one product family and define the rules that would have prevented its last three catalogue errors.

Frequently asked questions

What are product data validation rules?

They are checks that confirm whether a product record is complete, correctly formatted, commercially usable and safe to publish across ecommerce channels.

What should ecommerce SKU validation check?

It should check SKU format and uniqueness, GTIN or manufacturer references where relevant, parent and variant relationships, placeholders and identifier consistency across connected systems.

Should every failed validation rule block publication?

No. Use severity levels. Missing identifiers, invalid prices or broken variant relationships may be blockers, while minor enrichment gaps may become warnings or follow-up tasks.

How can catalogue teams prevent bad supplier data reaching the store?

Store incoming values separately, normalise them, apply field-level ownership rules, validate changes before publication and route uncertain records to an exception queue.

How often should product validation rules be reviewed?

Review them when product ranges, suppliers, ecommerce platforms or feeds change. A regular catalogue governance review can also identify rules that are too strict, too weak or no longer relevant.