What this tool checks
A packing desk makes two expensive mistakes with shipping labels. The first is printing the same label twice and shipping the same order twice — the courier is paid twice, the stock leaves twice, and the marketplace pays you for one. The second is shipping an order that was never going to be accepted. This tool looks for both, but it treats them very differently, and that difference is worth understanding before you read a report.
Duplicates are facts. The same waybill number on two pages is not a matter of opinion, and the tool states it plainly. Return risk is not a fact.A shipping label carries no delivery history — nothing printed on it tells you whether that buyer has refused parcels before. So the tool reports named signals and never a score. There is no percentage, no risk rating, and no traffic light, because cancelling a real order on the strength of a number the tool invented is a worse outcome than shipping a doubtful one.
The two kinds of duplicate
Not every duplicate means the same thing, so they are reported separately and ranked by how much evidence there is.
- Reprint— the same waybill (AWB) appears on more than one page. One parcel, printed twice. This is wasted paper and a packing error waiting to happen, and it is the most certain finding the tool produces.
- Repeated order ID— the same order ID appears twice under two different waybills. That usually means a genuine second parcel, which is fine. Where no waybill could be read at all, the tool says so rather than guessing, because an unreadable label could be either case and must not outrank something known.
The most common way duplicates appear is the least dramatic: the same label PDF added to the batch twice, often under two filenames after a re-download. The tool catches that across files, not just within one.
The signals, and what they mean
The second half of the report names things worth a human look. Two of them — a plain COD order, and several orders sharing a pincode — are shown as context only. They print alongside an order flagged for another reason, but never flag one on their own. That is not a matter of taste: on real batches, plain COD alone flagged 15 of 36 Meesho orders and 9 of 18 Flipkart orders, which tells a seller they sell COD rather than where to look. A signal that fires on half a normal batch is noise.
What does flag on its own is more specific: a high-value COD order, an address that repeats across separate orders, the same SKU going to one address more than once, an address block too short to be deliverable, and any pincode on a list you supply yourself.
The COD value threshold
High value is a rupee figure you set, not a percentile of the batch. A percentile always flags something, even on a day when nothing deserves attention. The default is ₹500. Leaving the box at 0 or blank switches the check offrather than setting a floor of zero — otherwise every COD order in the batch qualifies. The check applies to COD only: a large prepaid order is already paid for and is never flagged.
Your own pincode list
This is the one input built from real delivery outcomes rather than guesswork, and it is the honest answer to “returns cannot be predicted from a label”. Paste the pincodes that have actually cost you returns, in whatever shape you have them. They are matched exactly— a bad experience with one PIN does not condemn a whole district — and the list stays in your browser.
Reading a clean result
A batch with nothing wrong should not look like a batch that failed to run, so every check reports one of four states: it found something, it ran and found nothing, it was switched off, or it could not run because the labels do not carry that field. Meesho labels in particular often print no payment mode at all, which means COD checks genuinely cannot run on part of a batch — and being told that is more useful than a silent pass.
What happens to the addresses
Grouping orders by address needs a way to tell two addresses apart, not a copy of them. The tool converts each address block into a short fingerprint — a one-way hash — and compares those. The report identifies rows by order ID, never by customer name or street, so a screenshot of your results does not carry a buyer’s address in it. You already hold the labels; the report does not need to repeat them. Files are processed on our server and discarded, as described in our privacy policy.
Where this fits in a packing routine
Run this before printing, not after. The natural order is to check the batch here, then split it by courier for handover, then crop the labels down to what the printer needs. If a label prints faint or scans badly, re-render it rather than reprinting from the marketplace, which is itself a common source of duplicates.