Handling Colour and Size Variants Correctly in a Bulk Sourcing Sheet

Ask any seller who's done bulk listing by hand which part of the process breaks most often, and a lot of them will say the same thing: variants. Not pricing, not translation — variants. Getting a product with 4 colours and 3 sizes correctly represented as 12 distinct, correctly-priced, correctly-imaged rows is harder than it sounds, and most of the failure happens quietly.

Where it goes wrong manually

A supplier's spec table for a multi-variant product is often inconsistent even within itself — colour names spelled two different ways across rows, a size chart that uses different units in different sections, variant-specific images mixed in with general product shots with no clear labeling of which image belongs to which variant. A human copying this into a spreadsheet by hand introduces errors at almost every row: a colour matched to the wrong image, a size tier priced the same as a different tier by a copy-paste mistake, a variant silently dropped because its row in the source table didn't look like the others.

What correct variant handling actually requires

Every variant needs to end up as its own row with its own SKU, its own price (if variant pricing differs — a larger size often costs more to source, which should show up as a different landed cost, not just a different display price), and the correct image attached to it specifically, not a generic "first photo in the gallery" default. Colour and size option values need to be normalized consistently across the whole product — not "Red" in one row and "red " with a trailing space in another, because that kind of inconsistency breaks variant grouping on the destination platform silently.

How this maps to export format differences

This is also exactly where the Shopify-vs-Flipkart structural difference bites hardest. Shopify wants all variants of one product grouped under a shared Handle with option columns (Option1/Option2). Flipkart's bulk format often wants size/colour represented through category-specific attribute columns instead. A variant structure that's correct for one destination isn't automatically correct for the other, even when it's the exact same physical product and the exact same variant data underneath.

Why this is worth getting right at the sourcing stage, not fixing later

A variant error caught during sourcing review costs a few seconds to fix. The same error discovered after export — a wrong image live on a storefront, or a size tier accidentally priced the same as a different one — costs a customer-facing correction, and sometimes a return from a buyer who got the wrong expectation set by a mismatched photo. Per-product, per-colour AI notes and consistent variant structuring at the sheet stage exist specifically to catch this before it becomes a live listing, not after.

Start free and source a multi-variant product to see how colour/size handling comes through automatically — see also bulk listing from supplier links for the fuller pipeline this fits into.

A concrete failure mode, step by step

A supplier's spec table lists four colours — Red, Blue, "Grey", and "Gray" — where the last two are meant to be the same colour, just inconsistently spelled across different rows of the supplier's own table (a common supplier-side inconsistency, not a translation artifact). Copied manually into a sourcing sheet without normalization, these become two separate variant options on export — meaning a Shopify listing that should have 4 real colour variants instead shows 5, with "Grey" and "Gray" as confusingly separate, nearly-identical options a customer has to puzzle over before realizing they're the same thing.

Multiply this kind of small inconsistency — a trailing space, inconsistent capitalization, a colour name translated two slightly different ways across different rows of the same product — across a 200-product batch with multiple variants each, and the cumulative cleanup cost of manually normalizing all of it after the fact is significant, far more than catching and normalizing it once, consistently, at the sourcing stage before it ever reaches an export.

Why image-to-variant mapping is the other half of this problem

A supplier photo gallery often mixes general product shots with variant-specific images in no clearly labeled order — five photos might include two generic angle shots and three colour-specific shots, with no metadata indicating which is which. Getting the Red variant correctly matched to an actual red product photo, rather than defaulting to whichever image happens to be first in the gallery, requires actually associating each image with the variant it depicts — not a cosmetic nicety, but the difference between a customer seeing the colour they're about to order versus seeing a different one and being surprised (and likely returning the order) when the wrong colour arrives.

A simple test worth running on any multi-variant batch

Before export, spot-check that every variant's listed price actually differs in the way you intended — a size upgrade that should cost more but shows the same price as the base size is one of the easiest variant errors to miss on a quick visual scan, because the row looks complete even though a number inside it is wrong.