Product data validation checklist for ecommerce catalogs: checking supplier data before it goes live

A supplier sends a spreadsheet of 400 new items. Some weights are in pounds and some in kilograms, a handful of barcodes are one digit short, three images are the supplier logo on a white square, and the cost on a dozen rows is higher than the suggested retail price. A merchandiser can catch most of this, but only by reading every row, and the launch date does not move. The usual result is that the data goes live with the problems still in it, and they surface later as returns, wrong shipments and customer service tickets. This guide is for retailers of roughly 20 to 200 people with a few hundred to a few thousand SKUs on Shopify, Adobe Commerce or a PIM.

Why does supplier product data go wrong?

Supplier data is written for the supplier's own systems, not yours. Each supplier names columns differently, packs several facts into one cell, changes formats between seasons and sends images from whatever folder was handy. Your own catalog adds a second layer of rules: required attributes by category, naming conventions, approved values and channel requirements.

The ecommerce platform is rarely the safety net people assume. Shopify's product CSV import, for example, treats Title as the only required column for a new product, which means an item with no barcode, no weight and no category can import without complaint (Shopify Help Center). The platform checks that the file is structurally valid. Whether the product is complete enough to sell is your job.

What should you check before a product goes live?

Product data validation is the set of tests a record must pass before it is published. The tests fall into a few groups, and each has a different owner when it fails.

Seven check groups cover most supplier data problems. Some are fully mechanical, while others need a document or a picture to be read, and that is where AI earns its place.

How do you validate a GTIN?

A GTIN is valid when its length is right and its last digit matches a check digit calculated from the digits before it. Following the GS1 US manual method (GS1 US):

1. Check the length. Google Merchant Center accepts GTINs of 8, 12, 13 or 14 digits.
2. Set aside the last digit, which is the check digit, and take the digits before it.
3. Multiply those digits by 3 and 1 in alternating order, starting with 3 on the rightmost of them.
4. Add the results to get a sum.
5. Subtract the sum from the nearest equal or higher multiple of ten. The result is the check digit, and it must equal the last digit of the GTIN.

For the GTIN-13 6291041500213, the digits before the last one are 629104150021. Multiplying from the right by 3, 1, 3, 1 and so on gives a sum of 57, and 60 minus 57 is 3, which matches the last digit.

Which product data checks are rules, and which need AI?

Plain rules handle more than people expect. A GTIN, the global trade item number printed as a UPC or EAN barcode, ends in a check digit calculated from the other digits, so a script can reject a mistyped code instantly. Google Merchant Center, for example, accepts GTINs of 8, 12, 13 or 14 digits (plus formats it converts) and asks that the check digit be present and correct, noting that missing or incorrect values can limit a product's visibility (Google Merchant Center Help). Required-field tests, approved-value lists and margin thresholds work the same way: fixed logic, no AI needed, and cheaper and more predictable for it. AI helps where the input is messy or the judgment is fuzzy. Google's own image guidance, for example, excludes watermarks, added logos, placeholder images that say "coming soon" and generic graphics that do not show the actual product (Google Merchant Center Help), which takes an image reader to enforce.

A sensible design runs the rules first, then uses AI only on what the rules cannot decide, and records which check produced each finding. That keeps results explainable when a supplier asks why a row was rejected.

What should AI do with a failed record?

Rejecting a file and emailing the supplier is the cheapest option and sometimes the right one. But many failures have a likely fix, and the workflow can prepare it.

A good validation workflow sorts each finding into one of three outcomes:

1. Auto-correct. A deterministic fix with no ambiguity, such as trimming spaces, converting pounds to kilograms when the unit is stated, or standardizing case. These are logged but need no review.
2. Propose and review. A likely fix that changes meaning, such as mapping a color, filling a category from the title, or splitting a combined size field. The merchandiser sees the original value, the proposed value and the reason.
3. Return to supplier. Missing or contradictory facts that only the supplier can resolve, with a drafted request that lists exactly which rows and fields need attention.

Returning a record to the supplier matters more than it looks. A request that names the row, the field and the problem gets answered faster than "please review your file," and the answers come back in a form the next run can check.

What should a merchandiser still approve?

Validation should shrink the merchandiser's review to the decisions that need judgment. Five categories belong with a named person.

Classification and taxonomy. Which category a product sits in affects search, filters, tax treatment and sometimes shipping rules. A workflow can suggest a category and show the reasoning, but the merchandiser confirms it.

Pricing exceptions. Rules can flag a margin below threshold or a cost change beyond tolerance. Whether to accept the cost, negotiate or adjust the retail price is a commercial decision.

Regulated and restricted products. Claims such as organic, hypoallergenic, child safe or flame resistant, along with age-restricted and hazardous items, need documentary proof and a person accountable for publishing them.

Customer-facing copy. Generated descriptions can save hours, but they describe the product to a buyer. Every line should trace to supplier data, and a person approves it.

Overrides. When a supplier insists a barcode is correct or an image is final, someone with authority decides whether to make an exception, and the override is recorded.

Illustrative example: Consider a specialty retailer that adds a few hundred items each season from about thirty suppliers, each using a different spreadsheet layout. A workflow reads each supplier's file, maps it to the retailer's template and runs the checks. Eleven barcodes fail the check digit and are returned to the supplier with the row numbers. Forty color values are normalized automatically, and six are proposed for review because the supplier's name does not match any approved color. Four images are flagged as placeholders. Two items show cost above the planned retail price and go to the buyer for a pricing decision. The merchandiser opens one review queue with the proposed changes, approves most in a few minutes, and the clean records are published to the platform without being retyped.

How does validated data reach the platform?

Where the checks sit in the flow decides how much they save. The best position is between the supplier submission and your system of record, not inside the ecommerce platform after the data has already been imported.

A typical flow has a staging area where supplier files land, the validation and enrichment workflow, a review queue for proposed changes, and an approved record that is written to the PIM, ERP item master or ecommerce platform through its API or import tool. The workflow should keep the original supplier value beside the approved value, so you can answer "where did this number come from" months later.

Decide early which system owns each attribute. If the ERP owns cost and the PIM owns descriptions, the workflow must not write cost into the PIM just because it is in the supplier file. Ownership rules are boring to define and expensive to skip.

How do you know product data validation is working?

Three measures tell you more than the number of rules you have built.

First pass acceptance rate is the share of supplier records that pass all checks without correction. It tells you where supplier education or template changes would help most.

Time from submission to live shows whether the review queue is shortening or lengthening the launch cycle, and where items wait.

Downstream errors traced to catalog data counts the returns, wrong shipments and customer contacts that start with a bad weight, size or description. This is the number that connects catalog work to money, and it overlaps with the exceptions covered in Retail order exceptions: how to automate the triage without losing the customer.

Record a baseline before you start. Without one, a lower error count after launch could just reflect a quieter season.

How do you start with product data validation?

1. Pick one supplier or one category with enough volume to matter and a known history of data problems.
2. Write down the rules your merchandisers apply in their heads, and agree which ones are hard failures and which are warnings.
3. Run the checks in shadow mode on the next incoming file, comparing the findings with what the team catches by hand.
4. Add the review queue and the supplier feedback message once the findings look right, and name who approves each category of change.
5. Test the whole path on real files, including the awkward ones, before publishing anything automatically. How to test AI before it touches your operations lays out that testing approach.
6. Expand to the next supplier only when the first is running with few corrections.

How Kastling approaches catalog data checks

Kastling treats catalog validation as one workflow to understand before anything is built, as part of the AI Integration & Automation service. That starts with a free discovery call. For retail operations, a separately scoped paid audit is common next, reviewing how supplier data arrives today, which systems hold the catalog and where errors are costing time.

The checks connect to the ecommerce platform, PIM or ERP you already use rather than replacing them. Rule-based tests handle what can be decided mechanically, AI handles messy inputs, and a named merchandiser approves classification, pricing exceptions and customer-facing claims. We agree up front how success will be measured, such as first pass acceptance rate or time from submission to live, and we test the workflow against real supplier files before it goes into daily use.