How to clean creator addresses before you ship (India: PIN, phone, RTO)
Creator addresses from DMs and forms arrive as one messy line. Here is how to split, validate and fix them for Indian shipping before they turn into RTOs.
Part of the complete guide to barter & creator order operations on Shopify.
Most creator addresses arrive the same way: typed into a DM on a phone, in one line, with whatever the creator remembered to include. Pasting that line into a single address field feels like it worked, right up to the moment the parcel comes back. This is a practical routine for catching the problem in the sheet instead of at the doorstep.
Why single-cell addresses break shipping
A shipping label is not a free-text field. The courier's system sorts on the PIN, routes on the city and state, and hands the delivery agent line 1 and a phone number. When an address arrives as one line, each of those pieces has to be guessed, by you or by the courier's software, and both guess wrong regularly.
The failure is quiet. The order goes through, the label prints, the parcel leaves. Then it sits at a hub because the PIN is missing, or the agent cannot find “near the temple”, or the phone rings out because it is a messaging-app number on a spare SIM. Four to seven days later it comes back as an RTO.
The anatomy of a shippable Indian address
Every field below has a job. If a field is empty or wrong, a specific stage of delivery fails.
| Field | What goes in it | What fails without it |
|---|---|---|
| Recipient name | The name on the door or the name security will recognise; not necessarily the handle | Last-mile handover in gated buildings |
| Address line 1 | Flat, house, plot or shop number plus building or street name | The agent cannot locate the door |
| Address line 2 | Area, sector, society, landmark | Slower delivery; usually not a hard failure |
| City | The city or town, spelled as the courier expects | Routing to the wrong hub |
| State | Full state name, matching the PIN | Serviceability checks and GST fields on the invoice |
| PIN | Exactly 6 digits, first digit 1 to 8 | Sorting; the parcel does not move |
| Phone | 10 digits starting 6 to 9, stored without +91; a number the recipient answers | Delivery attempts; unreachable means RTO |
Common failure patterns
After a few hundred creator addresses, the same handful of problems account for almost all failures.
Missing PIN
The most common by far. Creators know their area but often not their PIN, so they skip it. The store accepts the address anyway, and some couriers infer a PIN from the city, which is a coin toss in any large city with dozens of PINs.
Landmark-only line 1
“Opposite the metro station, blue building” is directions, not an address. It works for a friend calling from outside; it does not work for an agent with 80 parcels. Line 1 needs a number.
City and state swapped
“Bangalore, Bangalore” and “Karnataka, Bengaluru” both show up. Most systems accept them. Serviceability lookups and invoices do not. The PIN-to-state check below catches this.
Messaging-app number vs calling number
Many people keep messaging app on one SIM and take calls on another. The number you have been chatting on is not automatically the number the courier should call. Ask.
Stale address
A creator seeded in January may have moved by July. A one-line “still at this address?” before each batch is enough.
Formatting noise
Emoji, trailing commas, “India” in the city field, a PIN written as “56 0034”, a phone with +91 and a leading zero. None are wrong on their own; all break exact-match checks.
A validation routine you can run in a spreadsheet
You do not need a service to catch most of this. With the five address columns and a phone column in place, add these check columns and filter for any row that fails.
- PIN length and range. Strip spaces, then check the value is exactly six digits and the first digit is between 1 and 8. A formula that tests the length after removing non-digits does this.
- PIN matches state.Keep a small lookup tab mapping the first two digits of a PIN to a state or region (11 is Delhi, 40 is Mumbai and around, 56 is Bengaluru, 60 is Chennai, and so on). Compare the row's state against the lookup. A mismatch is either a typo in the PIN or a city-state swap.
- Phone normalised and valid. Remove everything that is not a digit, drop a leading 91 or 0 if the result is longer than ten digits, then check for exactly ten digits starting with 6, 7, 8 or 9.
- Line 1 contains a number.Test whether line 1 contains at least one digit or a token like “flat”, “plot” or “house”. It is a crude test but it catches landmark-only lines.
- City is not a state, state is not a city. Check the state column against a list of the 28 states and 8 union territories. Anything else is a swap or a typo.
- Duplicate phone. Two rows with the same normalised phone and different addresses need a human look before either is placed.
Add a single “ready” column that is true only when every check passes. That is the column the batch is placed from. The failing rows stay in the sheet with the reason showing, which is also the list of questions to send back to creators.
When to use an auto-parser vs ask the creator
Splitting a line into fields by hand takes about a minute per address with the checks. For 20 addresses that is fine. For 200 a week it is a role. An auto-parser, rules-based or an AI model, does the mechanical splitting in seconds: it finds a six-digit number and calls it the PIN, recognises state names, and separates the phone from the rest.
What a parser is good at:
- Splitting one line into line 1, line 2, city, state, PIN.
- Normalising phone formats and removing noise.
- Fixing city-state order and expanding common abbreviations.
- Flagging what it could not find, which is the useful output.
What a parser cannot do:
- Invent a PIN that was never provided. If it guesses one from the city, treat it as unverified.
- Know which of two phone numbers the creator answers.
- Turn “the blue building near the temple” into a flat number.
- Know the creator moved last month.
So: parse first, then ask for exactly what is missing. “Can you send your PIN code and flat number?” gets a reply in an hour. “Can you resend your full address?” gets the same line again, with the same gaps, two days later. Bulk-order tools built for this workflow usually do both: parse the sheet, then list the rows and fields that still need a human. The bulk-ordering guide covers where parsing sits in that flow.
How bad addresses drive RTO, and how to measure it
An RTO on a seeding parcel is expensive out of proportion to the parcel. You pay shipping both ways, the product often comes back opened, and the creator has waited two weeks for nothing. Re-dispatch is a third shipping charge. Rough arithmetic: at ₹80 to ₹120 each way for a small parcel, one RTO plus a re-dispatch is ₹250 to ₹350 in shipping alone, before product, packaging and time.
The share of RTOs caused by addresses is the part you control, so measure it separately. Couriers return a reason with every RTO. Bucket them:
- Address-caused: address incomplete, wrong PIN, unable to locate.
- Phone-caused: unreachable, number not in service, no response.
- Creator-caused: refused, not available after multiple attempts.
- Courier-caused: not attempted, misrouted, damaged.
The first two buckets divided by parcels dispatched is your preventable RTO rate. Track it monthly. Above a few percent means the pre-dispatch check is being skipped or the phone column is untrustworthy. Keep it alongside the other numbers in your weekly review; the seeding operations checklist describes where it fits.
Symptom to fix
| Symptom | Likely cause | Fix |
|---|---|---|
| PIN column empty or 5 digits | Creator skipped it or dropped a digit | Ask for the PIN specifically; do not infer from city |
| PIN and state disagree | Typo in PIN, or city-state swap | Check first two digits against the state lookup; confirm with creator if both look plausible |
| Line 1 has no number | Landmark or area written as the address | Ask for flat or house number and building name; move the landmark to line 2 |
| Phone is 12 or 13 digits | +91 or leading 0 included | Normalise to 10 digits in the sheet before placing |
| Courier reports unreachable | messaging-app number, not calling number | Ask which number they answer calls on; store both, ship with the calling one |
| Parcel delivered to old address | Saved address reused without confirming | One-line confirmation before every batch for returning creators |
| “India” in city, city in state | Form fields filled in the wrong order | Validate state against the 36-entry list; parser fixes the rest |
| Same phone on two rows, different addresses | Duplicate creator, or one creator ordering for two people | Hold both rows; confirm with whoever added them |
Collecting better addresses in the first place
Cleaning is cheaper than shipping twice; not collecting bad addresses is cheaper still. Three changes to the intake step remove most of the work:
- Use a form with separate fields, with PIN and phone required and length-checked on the form itself.
- Ask for the phone with the words “the number you answer calls on”.
- Ask for the flat or house number as its own field, so a landmark cannot stand in for it.
Creators will still send addresses in DMs. When they do, paste the line into the original-address column and let the parser and the checks do their work.
The pre-dispatch checklist
Before any batch of seeding orders is placed, every row should pass all of these:
- Original address stored untouched in its own column.
- Line 1 contains a house, flat, plot or shop number and a building or street.
- City and state filled, state is a real state or union territory.
- PIN is six digits, first digit 1 to 8, first two digits agree with the state.
- Phone is ten digits starting 6 to 9, confirmed as the calling number.
- Returning creator has confirmed the address is current.
- No other row in the batch or the placed tab shares the phone with a different address.
- Order will be prepaid with a ₹0 total, not COD. See 100% discount orders for the setup.
Rows that pass get placed. Rows that fail get a specific question to the creator and wait for the next batch. That is the whole discipline.
If parsing and placing these orders by hand is eating your week, you can try it free and see your own list cleaned and placed in minutes.
Frequently asked questions
What does a complete Indian shipping address need?+
A recipient name, address line 1 with a house, flat or plot number and building or street, an optional line 2 for area or landmark, city, state, a 6-digit PIN code, and a 10-digit mobile number the recipient answers. Missing any of the PIN, house number or working phone is the usual cause of a failed delivery.
Why do creator addresses sent over DM fail so often?+
They arrive as one line typed on a phone, often with the PIN missing, the city and state in the wrong order, and a landmark in place of a house number. Pasted into a single address field, nothing checks any of that, so the courier discovers the problem at the doorstep instead of you discovering it in the sheet.
How do you validate PIN codes in a spreadsheet?+
Check the PIN is exactly six digits and starts with a digit from 1 to 8. Then compare its first two digits against the state column using a small lookup table, since the first digits of a PIN map to a region. That catches the majority of typos and state-city swaps without any external service.
Should I use an auto-parser or ask the creator to resend the address?+
Parse first, ask second. An auto-parser handles the mechanical work of splitting a line into fields and flags what is missing. Ask the creator only for what the parser could not find, usually the PIN or a house number, with a specific question rather than a request to resend everything.
How do I measure how much RTO is caused by bad addresses?+
Tag every RTO with the courier's stated reason and bucket them: address incomplete, unreachable phone, refused, or other. Address and phone buckets are the part you can fix before dispatch. Track that share monthly against total seeding parcels; a rate above a few percent means the pre-dispatch check is being skipped.