When Excel drops the zero from a ZIP code

A ZIP code can be damaged before it reaches the upload page. If a spreadsheet treats the column as numbers, 02601 becomes 2601. Exporting that sheet to CSV preserves the damage.

The useful clue is the country. US ZIP codes have five digits, so bulk can restore a missing leading zero when it knows the value is a US postal code.

These are illustrative normalization examples, not lookup results:

• 2601 with country US becomes 02601.
• 968 with country US becomes 00968.
• 2000 with country AU stays 2000.
• 2601 without a country stays 2601.

The country can come from the row's country column or from the country selected for the job. A three- or four-digit numeric code gets padded to five only with US context. Four digits are a normal postal code in several other countries, so adding a zero to every short value would create another problem.

This happens before duplicate counting. If a US column contains both 2601 and 02601, they resolve to the same lookup value and are counted once for that check.

Your original cell stays in the output. The added parse_ fields carry the lookup result, so you can see what arrived in the file and what it resolved to.

Keeping postal codes as text is still the useful habit when building a spreadsheet. When an export has already removed the zero, bulk can repair this particular case without making you rebuild the file first.