If you sell on more than one marketplace, you've probably noticed that no two platforms hand you a shipping label the same way. One gives you a clean 4x6 thermal label. Another bundles the tax invoice onto the same page. A third prints your product's real SKU nowhere on the label at all. This isn't random - each platform's PDF export reflects a different internal system, and understanding exactly how they differ is the difference between a smooth packing process and a slow, error-prone one.
Everything below is drawn directly from parsing real label and invoice PDFs from each platform while building this tool - not general assumptions about how e-commerce "probably" works.
E-commerce fulfillment in India: why this matters at scale
India's online retail market is built on a multi-channel reality: a single small or medium seller routinely lists the same catalog across three, four, even five marketplaces at once, because each platform reaches a different customer base and relying on one is a real business risk. That decision multiplies every operational detail. A format quirk that costs ten seconds per order on one platform doesn't happen once a day - it happens on every order, on every platform, every single day the business runs.
A seller shipping fifty orders a day across three marketplaces isn't running one fulfillment workflow - they're running three in parallel, each with its own label size, its own invoice placement, and its own way of hiding (or not hiding) the one piece of information a packer actually needs: which product goes in the box. Manual handling of that complexity is exactly where mis-picks, wasted thermal paper, and profit blind spots come from - not from any single mistake, but from the same small inconsistency repeated hundreds of times a month.
The root cause: five platforms, five internal systems
A shipping label PDF is generated by whichever backend system a marketplace uses for logistics, and that system was built independently by each company. There's no shared standard. Concretely, across the five platforms this tool supports, we've found three separate axes of difference:
- Physical size - most platforms print a 4x6 inch thermal label, but Myntra issues labels as full A4 sheets, meant for a regular printer rather than a thermal roll printer.
- Invoice placement - Amazon and Meesho typically keep the tax invoice as a separate page in the same PDF; Flipkart frequently prints the packing slip and the invoice on the exact same physical sheet, one below the other.
- What's actually printed on the label - some platforms print your real product SKU directly on the label. Amazon's own label doesn't - more on that below.
Amazon: the label doesn't show your real SKU
Amazon's printed shipping label shows a generic item type - something like "UNDERPANTS" or "T-SHIRT" - rather than your actual seller SKU. The real SKU exists in the PDF, but only on the separate invoice page, printed inside the item table in parentheses immediately before the HSN code.
The practical effect: if you print only the label (the normal workflow, since the invoice is a legal document you don't need to hand over physically in most cases), whoever is packing the order has no way to tell which specific product variant to put in the box - just a generic category. For a seller with several similar SKUs (say, three colourways of the same t-shirt), that's a direct mis-pick risk on every single order, not an occasional one. The invoice item table also carries the order quantity and unit price alongside the SKU, all packed into the same row - useful for accounting, but not something a packer can glance at quickly on a busy shift. This tool's Amazon mode reads the real SKU off the invoice page and stamps it onto the cropped label automatically, specifically to close this gap.
Flipkart: the invoice rides along on the label sheet
Flipkart frequently outputs a single sheet containing both the packing slip and the tax invoice, stacked vertically on one page. Printed as-is on a 4x6 thermal roll, that sheet either gets cut off mid-invoice (losing information) or the printer scales the whole thing down to fit, shrinking the actual label along with it.
There's a real, measurable cost to printing the invoice section unnecessarily too. If an unstripped invoice section adds even two extra inches of thermal roll per label - a conservative estimate given a full tax invoice's usual length - that's roughly 166 extra feet of thermal paper burned through per 1,000 orders, printing information that in most cases doesn't need to leave the warehouse floor as a physical document at all. This tool detects the invoice section by its text markers ("Tax Invoice", GSTIN references, declaration language) and crops it away, leaving only the actual shipping label. A footer marker - the "Not for resale" line printed at the very bottom of the packing slip itself - acts as a safety floor, so the crop can never accidentally cut into the real label content even if the invoice section's boundary is hard to pin down exactly.
Meesho: bulk multi-order files and a granular fee breakdown
Meesho suppliers typically download a single PDF covering an entire day's shipments rather than one label per download, which is efficient for printing but means any formatting problem in the file compounds across every order in that batch at once, not just one. Meesho's payment report is also unusually granular for a settlement document: it breaks a payout down into named, lettered components - logistics fee, ads facilitation fee, penalty, and others - that sum arithmetically into a total, rather than showing just one lump "fees" figure the way some platforms do. That level of detail is genuinely useful for spotting exactly where money went, but only if something actually reconciles it against your product cost - the report itself has no concept of what an item cost you to source.
Myntra: A4 labels built for a fashion-return-heavy category
Myntra issues shipping labels as full A4 pages rather than compact thermal labels, which means a thermal-printer workflow built around Amazon or Flipkart doesn't translate directly - the output size itself has to change per platform, not just the cropping logic. Printing an A4-formatted label on a thermal roll (or vice versa) either leaves large blank margins or clips content, so this tool crops Myntra labels down to just their real content while keeping the A4 page size intact, matching what the platform actually expects a seller to print on.
Fashion and apparel as a category structurally carries a higher return rate than most other e-commerce verticals, largely driven by size and fit rather than product defects - a well-documented pattern across the fashion e-commerce industry generally, not specific to any one platform. That makes accurate return and RTO tracking (covered further down) especially important for apparel sellers specifically, since a meaningful share of orders on any given day are likely to come back.
Snapdeal: order and payment data combined into one file
Snapdeal bundles order details and payment/settlement data into the same exported file rather than issuing them as two separate reports the way Meesho does. That's convenient for a seller who just wants one download, but it means a profit calculation for Snapdeal has to parse that single file two different ways - once for order details like SKU and listed price, and again for settlement details like the final amount actually paid out - rather than matching rows across two separate uploads. Snapdeal's packing slip also already prints the seller's SKU code directly in its item table, unlike Amazon, which is why sorting a batch of Snapdeal labels by SKU for efficient picking is possible without any extra data recovery step.
GST, HSN codes, and why the invoice can't just be deleted
Under India's GST framework, a registered seller making a taxable sale is required to issue a compliant tax invoice - it's a legal document, not an optional extra the platform bolted on. That invoice carries the HSN (Harmonized System of Nomenclature) code for each product, which is what classifies the item for tax purposes and determines the applicable GST rate. This is exactly why the invoice can't simply be deleted from the PDF: it needs to exist and be retrievable, even though a warehouse floor printing thermal labels has no practical use for a full A4-style legal document on every single package. The tension between "the invoice must exist" and "the label must be lean" is what produces the combined-sheet and separate-page formats covered above - it's a real constraint each platform is working around, not an arbitrary design choice.
COD vs Prepaid: why it's printed prominently on every label
Whether an order was paid for in advance (Prepaid) or will be paid on delivery (Cash on Delivery, COD) directly changes what the delivery agent needs to do at the doorstep - collect payment, or simply hand over the package - so labels print this status prominently, usually near the top. It's common enough across formats that this tool relies on it as one of the signals for telling a shipping label apart from other page types when scanning a multi-page PDF, alongside markers like "Delivery Address" and "AWB" (Air Waybill, the tracking number assigned to the shipment by the courier).
The cost that's easy to miss: not knowing your real margin
Label formatting is the visible problem. The less visible one is that none of these platforms' reports tell you your actual profit on an order - only your revenue and their deductions. Meesho's payment report, for example, breaks a settlement down into a series of lettered fee components (logistics fee, ads facilitation fee, penalty, and so on, arithmetically summed into a total), but it has no concept of what the product cost you to make or source. Without separately tracking that cost per SKU and reconciling it against what was actually paid out - not what was listed as the selling price, which can differ significantly from the final settlement - there's no way to know whether a given order was profitable at all.
It gets more specific than that: a returned, cancelled, or RTO'd order shouldn't be charged its product cost in a profit calculation at all, since the inventory itself isn't lost - only orders that actually shipped and weren't returned should have their cost of goods applied. Get that detail wrong and every profitability number downstream is wrong too, usually optimistic in a way that hides a real loss.
"Return" and "RTO" aren't the same event, and treating them identically muddies the picture further. A return is customer-initiated - the package was delivered and the buyer sent it back afterward. An RTO (Return to Origin) means the courier couldn't deliver it at all - the customer refused it, wasn't reachable, or the address was wrong - so it comes straight back without ever changing hands. Both mean the sale didn't complete, but they carry different costs (an RTO usually means paying for shipping in both directions with zero revenue at all, while a return at least means the order was briefly delivered), which is why a serious profit calculation needs to recognise both cases specifically rather than lumping every non-delivered order into one bucket. That reconciliation logic - cost of goods only applied where it's actually owed, return vs. RTO vs. cancellation all handled distinctly - is exactly what our Meesho & Snapdeal Profit Calculator automates.
What this adds up to
None of these are cosmetic annoyances. A missing SKU on a label is a mis-pick waiting to happen. An unstripped invoice is wasted thermal paper on every order, every day. A profit calculation that doesn't distinguish delivered orders from returned ones isn't a profit calculation - it's a guess. Each platform's PDF export reflects a genuine internal difference in how that marketplace operates, and handling each one correctly is what separates a fast, accurate fulfillment process from a slow, error-prone one.
This site automates each of these fixes per platform - see the dedicated guides for Amazon, Flipkart, Meesho, Myntra, and Snapdeal, or jump straight into cropping your labels.