Variation ID, product ID, style code and SKU ID in Meesho, explained.
Four identifiers sit around every Meesho listing. Meesho assigns two (product ID and variation ID) and you assign two (style code and Seller SKU ID). Here is what each one names, where it shows up, and how they fit together.
Variation ID in Meesho is Meesho’s own identifier for one size or colour option inside a listing; product ID is Meesho’s identifier for the whole listing. Style code is the code you give in the bulk sheet to group variations of one design, and Seller SKU ID is your own code for each variation. One product, many variations, one SKU per variation.
- Product ID and variation ID are generated by Meesho; you cannot choose them and should not build stock on them.
- Style code (style ID) is yours: it groups the size and colour rows of one design into one product in the bulk sheet.
- Seller SKU ID is yours: one unique code per variation, the key that ties orders, inventory and settlements to your shelf.
- Hierarchy: catalog > product (product ID, style code) > variation (variation ID, SKU ID). A kurti in 2 colours and 3 sizes is 1 product, 6 variations.
- The three mistakes that hurt: reusing a style code across products, renaming a SKU after orders exist, and blank variation attributes.
One product, six variations, four kinds of ID
A kurti in two colours and three sizes. The left node carries the two product-level identifiers; each leaf carries the two variation-level ones.
The four identifiers, compared
Field labels in the Supplier Panel and the bulk template shift from time to time; these are the usual ones.
| Field | Assigned by | Identifies | Where you see it | Example |
|---|---|---|---|---|
| Product ID | Meesho | One listing as a whole, across all its sizes and colours | Catalog page, product URL on the buyer app, order details, exports | a long numeric ID Meesho generates |
| Variation ID | Meesho | One size or colour option inside a listing | Catalog and inventory views, some exports, order details | a numeric ID, one per variation |
| Style code / Style ID | You | One design, grouping all its variation rows into one product | Bulk catalog upload sheet | KURTI01 |
| Seller SKU ID | You | One sellable variation, one physical unit on your shelf | Upload sheet, inventory page, order details, payment sheets, label | KURTI-BLU-M |
Which identifier does each job, and what goes wrong when they are mixed up
Most identifier problems are not Meesho bugs. They are one field used for a job it was never meant to do.
Three guides that build on these identifiers
How to upload a catalog on Meesho
Single upload versus bulk sheet, where the style code and Seller SKU ID fields live, and how to fill one row per variation without QC rejections.
Category and attribute selection
Choosing the right category decides which variation attributes exist. Blank or wrong attributes are the usual reason a variation cannot be told apart.
SKU mapping across marketplaces
Your SKU is the constant; each marketplace's IDs are the variable. Map one internal SKU to Meesho, AJIO and Amazon so one stock count serves all three.
Sellers search for these four terms separately because the panel, the bulk sheet, the order page and the label each show a different one. They are easier to understand together, as two layers: the product, and the variations inside it.
The two identifiers Meesho assigns: product ID and variation ID
When a catalog clears QC and goes live, Meesho creates its own bookkeeping for it. The product ID is Meesho’s number for one product as a whole: the cotton kurti, in every size and colour you listed under it. It is the ID that the buyer app uses in the product URL, the one the catalog page shows against the listing, and the one that appears on order details and in most exports. Beneath that, Meesho creates a variation ID for every individual size or colour option. Six variations, six variation IDs. You do not type either of these anywhere; they appear after the listing is created, and you cannot change them. Their job is to let Meesho’s own systems tell one option from another without relying on your naming, which is why they look like long numbers rather than readable codes.
The practical consequence is that these two IDs are lookups, not working keys. They are exactly what you quote in a support ticket about a listing, and what you match on when an export from the panel needs to be lined up against a catalog. They are the wrong thing to build your stock system on, for two reasons. First, they mean nothing outside Meesho: the same kurti on AJIO or Amazon has entirely different identifiers there. Second, they are created after the fact, so you cannot print them on a shelf label before the listing exists. The code that travels with the physical unit has to be yours.
The two codes you assign: style code and Seller SKU ID
The style code, which the bulk template sometimes labels Style ID, is a grouping key. In a bulk upload sheet you fill one row per variation, and Meesho needs a way to know that the blue-S row, the blue-M row and the pink-L row are all the same design. The style code is that way: every row with the same style code becomes one product with several variations. Think of it as the seed from which Meesho grows the product ID. It matters only at upload time, and it is not shown to buyers. In a single (non-bulk) catalog upload you usually will not be asked for it at all, because you add the variations inside one form and the grouping is implicit.
The Seller SKU ID is different in kind. It is your permanent code for one sellable variation, the thing a packer picks off the shelf. You enter it per variation at upload, in the bulk sheet or in the single-upload form, and Meesho stores it against that variation so it appears on order details, inventory pages and payment sheets from then on. It is the only one of the four identifiers that names a physical unit, and the only one you can carry across marketplaces unchanged. If you have not yet settled on a naming pattern, our guide to SKU ID in Meesho covers how to structure one that stays readable at a few hundred products.
How they fit together: a kurti in three sizes and two colours
Take a cotton kurti sold in blue and pink, each in S, M and L. That is one design, six sellable variations. Here is what each layer of the bulk sheet and the live listing looks like once it is done right.
- Style code (yours, one value):
KURTI01, written on all six rows of the sheet so Meesho groups them into one product. - Product ID (Meesho’s, one value): generated when the listing goes live, shown on the catalog page and in the buyer-app URL.
- Seller SKU IDs (yours, six values):
KURTI-BLU-S,KURTI-BLU-M,KURTI-BLU-L,KURTI-PNK-S,KURTI-PNK-M,KURTI-PNK-L, one per row. - Variation IDs (Meesho’s, six values): generated one per variation, each mapping to exactly one of your SKU IDs.
Each row also carries its own inventory number and its own attribute values for colour and size. When a buyer orders the pink medium, the order shows your KURTI-PNK-M, Meesho’s variation ID for that option, and the product ID for the listing, and the inventory for that one row drops by one. The other five are untouched. That is the whole point of the hierarchy: the product level is what the buyer browses, the variation level is what actually ships.
And the catalog above them all
One more layer sits above the product, and it explains a term you will meet in the panel: the catalog. On Meesho, a catalog is the unit you upload and the unit QC approves, and it can hold one product or several related ones, for example the same kurti design in four prints uploaded together. The panel usually shows a catalog identifier of its own against each upload. So the full hierarchy reads catalog, then product, then variation: a catalog groups products, a product ID names one product, a variation ID names one option inside it, and your SKU ID names that same option from your side. In practice you will spend most of your time at the variation level, because that is where stock and orders live, and reach for the catalog identifier only when an upload is stuck in QC or a support agent asks which upload you mean.
Where each one shows up in a normal day
On the catalog page in the Supplier Panel you will usually see the product ID against each listing, with the variations and their Seller SKU IDs one level down. In the bulk upload sheet you see the two codes you own, style code and Seller SKU ID, alongside the attribute columns; the Meesho IDs do not exist yet at that point. On order details you typically see the product name, the variation (colour and size), the quantity and your SKU ID, with product and variation identifiers available in the exported order sheet. On the shipping label the prominent number is the sub order number, which identifies one item of one order, together with the product description, size and, in the usual label format, your SKU. The sub order number is not a fifth product identifier; it changes with every order and belongs to the order, not the product. It is the right key for tracking a parcel or raising a ticket about a specific shipment, and the wrong one for counting stock. When a packer scans a label, the useful path is label to SKU to shelf.
On the payment sheet, each line is a sub order, and it carries your SKU. This is where the identifier discipline pays back in rupees: a settlement line that names a clean, unique SKU can be traced to an exact variation and checked. One that names a reused or ambiguous SKU cannot, and a charge you cannot attribute is a charge you cannot dispute.
Common mistakes, and why they cost money
The first is reusing a style code across different products. Because the style code is a grouping instruction, putting a kurti and a palazzo under KURTI01 tells Meesho they are one product. The result is either a QC rejection or, worse, a live listing whose colour options include a palazzo, with the wrong images against some sizes. One design, one style code; a new design gets a new code even if it is a close cousin. The second is changing a Seller SKU ID after orders exist. The field can often be edited, but every shipped order, every payment line and every stock record was written against the old code, and the history splits in two. If a SKU was wrong, create the correct variation, move stock to it and let the old one run to zero. The third is blank variation attributes: a row with no size or colour value becomes an option Meesho cannot label, so the buyer sees an empty choice and you cannot tell which unit sold. Choosing the right category up front decides which attributes exist, which is why our guide on category and attribute selection sits before the upload guide rather than after it.
Two smaller ones round out the list. Using one SKU for two variations means an order for either decrements the same count, so you oversell one while sitting on the other; our guide on inventory sync and overselling walks through how that plays out. And treating Meesho’s product ID as your stock key means the moment you list the same kurti on a second marketplace you have two unrelated numbers for one shelf. Every one of these mistakes is cheap to avoid at upload and expensive to unwind after a few hundred orders.
Using the identifiers across marketplaces
If you sell the same products on Meesho, AJIO and Amazon, the four identifiers on this page become twelve, because each marketplace has its own product and variation numbers. The only thing that stays constant is the code you control: your SKU. The discipline is simple to state and worth doing early. Keep one internal SKU per physical variation, use it on every marketplace’s listing, and map each marketplace’s own IDs to it rather than the other way round. Then one stock count can serve every channel, an order from any of them decrements the same unit, and a settlement from any of them can be traced back to the same variation. Our guide on SKU mapping across marketplaces covers the mechanics, and catalog hygiene and completeness covers keeping the attribute side clean as the catalog grows. For the upload itself, start with how to upload a catalog on Meesho.
Sources & further reading
Field labels in the Supplier Panel and the bulk template change from time to time; confirm the current names in your own panel.
Identifier mistakes that break inventory, and the fix for each
In the bulk sheet, every row sharing a style code becomes one product. Put a kurti and a palazzo under the same style code and Meesho builds one listing with mixed variations, wrong images on some sizes and a catalog QC failure or, worse, a live listing that confuses buyers. One design, one style code, always.
Orders, payment sheets and your own stock records are keyed on the old code. Renaming it splits the history in two and makes reconciliation guesswork. Fix SKUs before the first order; after that, create a new variation and retire the old one.
A row with no size or colour value becomes a variation Meesho cannot label, so the buyer sees an empty option and you cannot tell which unit sold. Every variation row needs its distinguishing attributes filled in, even if there is only one colour.
If size M and size L share one SKU, an order for either decrements the same count and you oversell one while sitting on the other. Every variation needs its own SKU ID, and the pattern should make the difference visible at a glance.
Product ID names the listing on Meesho, not the unit on your shelf, and it means nothing on AJIO or Amazon. Key your inventory on your own SKU and map the marketplace IDs to it, so one stock count serves every channel.
The sub order number on a label identifies one item of one order, and it changes with every order. It is the right key for tracking a parcel and for support tickets, not for stock. Match it back to the SKU on the order, then to your shelf.
Your SKU is the key; Robnu keeps orders, stock and money on it
Naming your identifiers well is your job at upload time, and no tool can do it for you. Keeping every order, every stock movement and every settlement line pointed at the right variation afterwards is where a system earns its keep. Robnu is the agentic OMS for Meesho, AJIO and Amazon sellers: it syncs orders from each marketplace, runs the daily processing and returns work, and reconciles each payment statement against what actually shipped, all keyed on your SKU rather than on any one marketplace’s ID. When a settlement line names KURTI-PNK-M, Robnu can tell you whether the amount is right, which is the whole reason the code needed to be clean in the first place.
Free for every seller right now, and forever free under 25 orders a day when paid pricing launches. See Robnu for Meesho or the full order management system overview.
Meesho identifiers, answered
Variation ID is the identifier Meesho assigns to each individual size or colour option inside a listing. You never type it; Meesho generates it when the catalog goes live. It is what Meesho uses internally to tell a size-M blue kurti from a size-L blue kurti, and it appears in catalog and inventory views, some exports and order details. Your Seller SKU ID is your own code for the same variation, so the two usually map one to one.
Product ID is Meesho's identifier for one product as a whole, covering every size and colour beneath it. It is generated by Meesho, not chosen by you, and you will usually see it on the catalog page, in the product URL on the buyer app, and on order details. One product ID sits above several variation IDs. It is useful for support tickets and for matching an export to a listing, but it is not something to build your own stock system on.
Style code, sometimes labelled Style ID, is a code you provide in the bulk upload sheet to group all the size and colour rows of one design into a single product. Every row that shares a style code becomes one product with several variations. Meesho does not generate it; you do. Reusing one style code across two different designs merges them into one product, which is a common upload mistake.
Seller SKU ID is your own code for one sellable variation, a specific size and colour. You enter it per variation during catalog upload, and Meesho stores it against that variation so it appears on orders, inventory pages and payment sheets. It should be unique across your whole catalog, uppercase, with no spaces. It is the only one of the four identifiers that you control and that names one physical unit on your shelf.
Think in layers. A style code groups rows into one product. Meesho gives that product a product ID. Each size or colour row inside it becomes a variation, and Meesho gives each one a variation ID. You give each variation a Seller SKU ID. So one style code corresponds to one product ID, and each variation ID corresponds to one Seller SKU ID. A kurti in two colours and three sizes is one style code, one product ID, six variation IDs and six SKU IDs.
Technically the field can often be edited, but it is a bad idea once orders have shipped. Order history, payment sheets and any inventory or reconciliation system you use are keyed on the old code, so the trail breaks. If a SKU was wrong, the safer path is usually to create the correct variation, move stock to it, and let the old one run down to zero rather than rename it under live orders.
The shipping label carries Meesho's sub order number, which identifies one item of one order, along with the product description, size and usually your SKU. Order details in the Supplier Panel typically show the product name, variation, quantity and your Seller SKU ID, and exports include product and variation identifiers. For matching an order to stock, your SKU ID is the field to use; for talking to Meesho support, the sub order number and product ID are what they look up.
Related seller guides
More on the operations, money and claims that decide whether a marketplace catalogue actually makes money.
SKU ID in Meesho: Meaning, Example, Variation ID and Product ID (2026)
SKU ID in Meesho means your own code for one product variation. Learn what SKU ID, variation ID, product ID and style code mean, with a seller SKU ID example.
Meesho Bulk Listing Excel Sheet: Columns, Rules and Errors (2026)
The Meesho bulk listing Excel sheet column by column: the rules that make an upload pass, the ten errors that fail it, and where the real template comes from.
Meesho Branded Packaging Code: Policy & Support 2026
Meesho's branded packaging policy lets eligible sellers ship in their own brand identity within the rules. Here is what the branded packaging code covers, who qualifies, and how it sits alongside mandatory BP-TP.
AJIO catalog and listing quality: images, attributes, QC
Shot discipline, attribute completeness, size charts and QC rejection loops, why listing data decides whether AJIO shoppers ever find your products.
Courier partners on Indian marketplaces: forward & reverse shipping
Who ships your Meesho and AJIO orders, how the forward and reverse legs work, and where courier freight and RTO deductions quietly cost sellers money.
Meesho Label Size and Format: Print It Right (2026)
The Meesho label size and format explained: thermal 4x6 versus A4 laser, why barcodes go blurry or cut off, how to handle the PDF, batch printing, and how a clean scannable barcode prevents rejected pickups and RTO.
Meesho Order Processing: From Order to Handover (2026)
Meesho order processing explained end to end: new order, accept, label and invoice, pack, ready to ship, manifest, courier pickup, delivery or RTO, and settlement. Learn each SLA stage and where sellers lose time and money.
How to Download the Meesho Shipping Label (2026)
How to download the Meesho shipping label from the Supplier Panel, for one order or in bulk. Where it lives, the print settings that stop rejected parcels, what the label contains, and common problems.