How to Scan Business Cards into Excel, CSV or Google Contacts

“Just type them into Excel” is how business-card data actually dies: rows copied from a phone screen, phone numbers missing their country codes, one column called “name” holding three different name orders. This guide is the clean route from a pile of cards to a spreadsheet or Google Contacts you can actually use.

What’s the fastest way to get business cards into a spreadsheet?

Photograph them and let an AI do the structuring. A modern scanner extracts each card into named fields — family name, given name, company, title, phones by type, email, structured address — and then writes those fields into a CSV whose columns line up every single time.

With BizCardPro.AI the capture step is built for volume: lay several cards in one photo and each becomes its own contact, already cropped and deskewed. Thirty cards is a few photos, not an afternoon of data entry.

The export button then gives you three formats. Choosing correctly matters:

Destination	Format to use	Why
Excel / Google Sheets / Numbers	Spreadsheet CSV	Clean columns for sorting, filtering, mail-merge and CRM imports
Google Contacts	Google Contacts CSV	Matches Google’s import schema exactly — no field-mapping screen
iPhone / Android contacts	vCard (.vcf)	Preserves phone types and photos; one tap to add

How do I import business cards into Google Contacts?

1. Scan your cards and review the extractions against the card photos kept beside them.
2. Export as Google Contacts CSV.
3. Go to contacts.google.com, choose Import, and upload the file.
4. Google adds the contacts to your account — from there they sync to Gmail autocomplete and your Android phone automatically.

Because the file is written against Google’s own column schema (Given Name, Family Name, Organization, Phone 1 Type…), the import needs no manual mapping. Add a Google label during import (e.g. “HK Fintech Week 2026”) and the whole batch stays findable as a group.

Which fields matter most in the export?

Four details separate a usable export from a mess. Check that your scanner handles them:

• Split names. “Name: 山田太郎” as one blob is unsortable. You want family and given names in separate columns — correctly split even for surname-first CJK names, which is where most tools guess wrong.
• E.164 phone numbers. +81 3-1234-5678 survives every import on earth; “03-1234-5678” becomes a local mystery the moment you leave Japan. (More on how extraction works.)
• Native script AND romanization. Keep both columns. You’ll search “Yamada” on your laptop and paste 山田様 into the email greeting.
• Phone types. Mobile vs. office vs. fax matters when your CRM starts auto-dialing.

What goes wrong when spreadsheets meet contact data?

Two classic failure modes, both avoidable:

Excel eats your numbers. Open a CSV by double-clicking and Excel may treat phone numbers as numerics — stripping the leading + and zeros, or rendering them as 8.52981E+10. Import the file via Data → From Text/CSV and set phone columns to Text, or keep numbers in E.164 with the + prefix, which most modern spreadsheet apps preserve.

Re-imports multiply. Export your whole archive after every event and re-import the lot, and the same person lands in your spreadsheet four times by December. Export slices instead of everything: tag each batch by event and export only the new tag, so each import adds the people you actually just met. Your scanner archive stays the complete copy; the spreadsheet only ever receives what it needs.

What if the Chinese, Japanese or Korean names arrive garbled?

First rule: don’t save the file. Excel decodes a double-clicked CSV with the machine’s system code page unless the file begins with a UTF-8 byte order mark — which is how a good export still renders 山田太郎 as 山田太郎 on a Windows laptop. (BizCardPro.AI’s CSV carries that mark.)

What you see tells you whether it’s fixable. Accented Latin gibberish means the bytes are intact, just read with the wrong table: close the file without saving, then reopen it via Data → From Text/CSV with File Origin set to 65001: Unicode (UTF-8). Literal question marks mean the characters were destroyed in a conversion and only a fresh export brings them back — saving a garbled file is what turns the first case into the second. The full diagnosis and fix covers the legacy code pages and exporting so it never recurs.

Should I keep contacts in a spreadsheet at all?

A spreadsheet is a fine destination — for a mail-merge, a CRM import, an event report. It’s a poor home: no photos of the original cards, no reminders, no search across scripts, and every update is manual.

The workflow that holds up: keep the scanner’s archive as the source of truth (searchable in both scripts, originals attached, follow-up reminders doing their job), and export a fresh CSV whenever a spreadsheet is genuinely needed. Your data stays clean in one place, and every export is disposable.

Keeping the copies few is also a data-protection matter: contact details are personal data, so every spreadsheet a batch lands in is another place a deletion request has to reach — see is scanning business cards GDPR-compliant?.

Start with your current stack — the first 30 scans are free, no credit card.