Best Way to Export Business Contacts: A Guide

Exporting a list of business contacts feels like the boring last step: click a button, get a file, move on. But the format you pick and the care you take in the first two minutes decide whether the next tool imports your data cleanly or quietly mangles it — dropping rows, scrambling accented names, or turning phone numbers into gibberish that no one notices until a customer complains. This is a small decision that causes big downstream pain when you get it wrong.

This guide walks through the export formats you will actually meet, the traps hiding inside each one, and how to move a contact list into a mail tool or a CRM without losing or corrupting anything. None of it is hard. It just rewards a little deliberateness before you commit the whole file.

CSV: the universal interchange format

CSV — comma-separated values — is a plain-text file where each line is a record and each field is separated by a delimiter. It has no fonts, no formulas, no types: just text. That plainness is exactly why it is the universal language for moving data between tools. Almost every CRM, mail platform, and spreadsheet can read and write it, which makes it the right default when your goal is to hand data from one system to another.

The same simplicity is where the traps live. Because a CSV carries no information about how it should be read, the program opening it has to guess — and it guesses wrong often enough to ruin a list. Here are the four failures that catch people most.

Encoding: UTF-8 or mangled accents

A CSV is just bytes, and the reader needs to know which character set those bytes represent. If your export is UTF-8 (the modern standard) but a spreadsheet opens it as some legacy regional encoding, every non-English character breaks: José becomes José, München becomes München, and Cyrillic or Arabic turns into a wall of symbols. Always export as UTF-8, and when you open a CSV, choose UTF-8 explicitly in the import dialog rather than trusting a double-click to guess. If you see garbled accents, do not fix them by hand — re-open the original with the correct encoding, because the underlying data was never actually wrong.

The delimiter trap: comma versus semicolon

The "comma" in comma-separated values is not universal. In many locales — including much of Europe and the Spanish-, German-, French-, and Portuguese-speaking world — the comma is the decimal separator (you write 3,50 not 3.50), so spreadsheet software there uses the semicolon as the CSV field delimiter instead. Open a comma-delimited file in a semicolon locale and every row collapses into a single mangled column; do the reverse and the same thing happens. This is not a rare edge case. It is the single most common reason a CSV "won't open properly." When you export, know which delimiter the file uses, and when you import, tell the tool explicitly instead of letting it auto-detect. If a file looks like one long smushed column, the delimiter is almost always the culprit.

Leading zeros: phone numbers and postal codes

Spreadsheets love to treat anything that looks like a number as a number, and numbers do not have leading zeros. So a postal code like 01234 becomes 1234, and a phone number that starts with a zero — as most national formats do — silently loses it. The data in the raw CSV is fine; the damage happens when a spreadsheet opens the file and "helpfully" reformats. The fix is to import these columns as text, not to open and re-save casually. Treat phone numbers, postal codes, and any ID as text from the moment they leave the export.

Scientific notation and truncated numbers

The same type-guessing produces a worse failure for long numbers. A phone number like 442071234567 can be turned into 4.42071E+11 — scientific notation — or truncated when the number exceeds the spreadsheet's precision limit, quietly replacing the last digits with zeros. Now the number looks plausible but dials nowhere. This is the most dangerous CSV trap precisely because it is invisible: the field is still full, still numeric, just wrong. Again, the defense is to keep phone numbers as text and to spot-check a few after any round-trip through a spreadsheet.

XLSX: types and sheets preserved

XLSX is the native spreadsheet format, and it solves most of what makes CSV fragile. It stores the type of each cell, so a phone number saved as text stays text — no scientific notation, no lost leading zeros. It carries encoding correctly, so accents survive. And it can hold multiple sheets, which is useful when you want to ship contacts on one tab and a short legend or notes on another.

That makes XLSX the better choice whenever a human will open the file: a colleague reviewing the list, a handoff to a partner, an export someone will read before acting on it. The tradeoff is that XLSX is a heavier, more structured format and is slightly less universal for machine import — some tools ingest CSV more reliably, and very large XLSX files can be slow. The rule of thumb: XLSX for people and for handoff, CSV when a machine on the other end will parse it.

PDF: for reading, never for importing

PDF is a presentation format. It is excellent for a clean, shareable snapshot of a contact list — something to attach to an email or hand to a client who just wants to look. It is a genuinely bad idea to use it as a data source. A PDF describes where text sits on a page, not what column a value belongs to, so getting structured data back out of one is a lossy, error-prone extraction that scrambles columns, merges fields, and drops rows. If someone hands you contacts as a PDF and asks you to import them, ask for the original CSV or XLSX. Do not try to reverse-engineer the table out of the PDF; you will spend longer cleaning it than the export would have taken.

JSON: when an API or a developer is involved

JSON is the format to reach for when the destination is code rather than a spreadsheet — an API that accepts contacts programmatically, or a developer wiring one system to another. It represents structure and types precisely, handles nested data cleanly, and is unambiguous about encoding. For everyday human-facing exports it is the wrong tool, and no one should be reading a contact list in raw JSON. But the moment an integration or an engineer enters the picture, it is the format that will save everyone the guessing games that CSV invites.

Field mapping: the step everyone rushes and regrets

Once you have the right format, the real work is field mapping: matching your columns to the fields the destination expects. This is the step people skip, and it is where imports quietly go wrong. Two columns named slightly differently — company versus organization, mobile versus phone — will not line up on their own, and a tool that can't find a field it wants either leaves it blank or refuses the row.

The most common snag is names. Your export may have a single full-name column, but many mail and outreach tools insist on separate first-name and last-name fields because they personalize on the first name. You will need to split "Maria Garcia Lopez" into parts — which is not trivial across cultures with multiple surnames or family-name-first ordering — or, going the other way, join first and last into a full name a CRM wants. Decide how you will handle this before you import, not row by row afterward.

The other thing to get right is a stable unique key. Pick one field that uniquely and durably identifies each contact — a company domain works well, or an internal ID if you have one — and keep it consistent across every export. When you re-import an updated list, the destination uses that key to recognize existing records and update them instead of creating duplicates. Without a stable key, every re-import is a fresh pile of duplicate contacts, and cleaning those up later is far more work than choosing the key now.

Importing into a mail or outreach tool

Mail and outreach tools have a narrow, predictable set of needs, and importing to them fails in predictable ways. They want a clean first-name field, because that is what fills the "Hi {{first_name}}" line — feed them a full name and every message reads "Hi Maria Garcia Lopez," which looks worse than no personalization at all. They expect one row per recipient; duplicate rows mean someone gets the same email twice. And they choke on merge-field gaps: if half your rows have no first name and your template opens with it, those sends either break or go out with an awkward blank. Before you import, make sure the personalization fields you actually use in your template are filled for every row, or have a fallback planned for the blanks.

Importing into a CRM

CRMs are stricter and more structured. Most run a dedup-on-import check, matching incoming rows against existing records by email, domain, or your unique key — which is precisely why a stable key matters, since a good match updates a record while a missed one duplicates it. They enforce required fields: a row missing something the CRM insists on will be rejected outright, and a big import can fail partway with half the list in and half rejected. And they separate objects: a company (or account) is a different thing from a contact (a person), and you often import them as two linked steps rather than one flat file. Check the destination's required fields and its company-versus-contact model before you start, so you are mapping into the right objects rather than discovering the structure mid-import.

Guardrails that save you every time

1. Test with a small sample first. Export ten rows, import them, and check the round-trip end to end before you move the full file. Two minutes here catches problems that would otherwise be baked into thousands of records.
2. Keep the original export untouched. Never edit your only copy. Work on a duplicate so that when something goes wrong — and eventually it will — you can go back to a clean source instead of reconstructing it.
3. Watch the row count across the move. Note how many contacts you exported and how many landed on the other side. A silent drop of a few hundred rows is easy to miss and is one of the most common import failures; the count is your simplest alarm.
4. Character-set check a few non-ASCII rows. After import, find a handful of records with accented, Cyrillic, or Arabic names and confirm they read correctly. If they are garbled, you caught an encoding problem before it reached a customer.

Which format for which job

• Moving data between tools: CSV, exported as UTF-8, with phone numbers and codes kept as text.
• A human will open or review it: XLSX, which preserves types and can carry multiple sheets.
• Reading or sharing a snapshot: PDF — and never as something to import from.
• An API or a developer is involved: JSON.

Getting a clean export is only half the battle; getting a clean list in the first place is the other half. A good lead source hands you well-structured contact data — proper columns, verified fields, sensible formats — so the export step is a formality rather than a rescue operation. If you want to start from a clean list built for exactly this, run a free search on JustLeadIt and export the results into your own tools.

Pick the format that matches the job, map your fields with a stable key, and test a small sample before you commit the whole file. Do that and the boring last step stays boring — which, when you are moving your business contacts, is exactly what you want.