How to Scan Business Cards into SAP C4C and S/4HANA (No Integration Needed)

The trade fair ends and you fly home with 120 Visitenkarten in a conference lanyard pouch. Somewhere in that stack are the six accounts that justify the booth — and every one of them has to exist in SAP as a contact before anyone can work it. The status quo is a colleague typing them in. That is where the search for a Visitenkartenscanner for SAP C4C usually begins.

This guide is the honest version of that answer: what actually gets cards into SAP Sales and Service Cloud (C4C) or S/4HANA, and the field mapping that makes the import work the first time.

Is there a business-card scanner that plugs straight into SAP C4C?

Not this one. BizCardPro.AI has no SAP integration — no connector, no API, no Zapier recipe, and nothing promised on a roadmap here. If a native SAP integration is a hard requirement for your procurement, that is a straight no.

For the job most people actually have, it turns out not to matter. A trade-fair stack is a one-directional batch load of a few dozen records that happens a handful of times a year. SAP already has a first-class path for exactly that shape of work — file-based data import — and it has a property an unattended API connector does not: a human looks at the data before it becomes master data. Most SAP administrators prefer it that way. The scanner’s job, then, is not to talk to SAP. It is to produce the clean file SAP wants.

What the export actually contains

Every batch exports as a spreadsheet CSV with these columns:

Column	Holds
ID	Internal record id from the scanner archive
Name (Native)	The name as printed, in its original script
Name (Romanized)	The Latin-script rendering of the same name
Company (Native)	Company name in its original script
Company (Romanized)	Latin-script company name
Job Title (Native)	Title as printed
Job Title (Romanized)	Latin-script title
Email Address	Email from the card
Phone Numbers	Numbers from the card, normalised to international E.164
Website URL	Web address from the card
Address (Native)	Postal address in its original script
Address (Romanized)	Latin-script postal address
Uploaded At	When the card was scanned

Two properties of that file matter more than the column list. Phone numbers are normalised to E.164 (+49 89 1234567), so the country is never ambiguous. And the file is UTF-8 with a byte order mark, which is what keeps Müller from becoming Müller and 山田太郎 from becoming 山田太郎 when the file passes through a German-locale Windows machine on its way to SAP.

The field mapping

This is the part worth bookmarking. Field labels differ between releases and tenants, so treat the middle column as the destination to look for rather than a literal string:

BizCardPro.AI CSV column	Typical SAP contact destination	Notes
Name (Romanized)	First Name + Last Name	Split into two columns before import — see below
Name (Native)	Extension field, or the name field on a locally maintained record	Keep it if you want 名刺 names searchable in their own script
Company (Romanized)	Account (the account the contact belongs to)	The account normally has to exist first
Company (Native)	Account extension field or note	Optional, but useful for Asian suppliers
Job Title (Romanized)	Job Title (free text)	C4C also has a coded Function list — map to free text unless you maintain those codes
Job Title (Native)	Extension field or note	Optional
Email Address	E-Mail	Also your best deduplication key
Phone Numbers	Phone / Mobile	May carry more than one number per card — see below
Website URL	Web Site	On the contact or, more usefully, the account
Address (Romanized)	Street, Postal Code, City, Country	Must be split into components
Address (Native)	Extension field or note	Keep for shipping and for correspondence in-country
ID	Not mapped	Useful as your own reconciliation key against the scanner archive
Uploaded At	Not mapped, or a “captured on” custom field	Worth keeping as consent-provenance evidence

For S/4HANA the same source columns apply, only the destination changes shape: contacts become business partners — a person business partner related to the organization business partner as a contact person — loaded through whichever data-migration tooling your team already uses. Confirm the template and the mandatory fields with whoever owns business partner master data, because those vary far more between systems than the mapping above does.

The workflow, step by step

1. Batch-scan and verify. Photograph the cards — several per photo is fine — and check each extracted field against the card image kept beside it. A misread caught here costs seconds; the same misread inside master data costs a change request.

2. Export the spreadsheet CSV. One file per event batch, not your whole archive. Tag the batch by event first (Hannover Messe 2026) so the export is exactly the people you just met.

3. Reshape the file into your SAP template. Split names into first and last, split the one-line address into street, postal code, city and country, decide which phone column each number belongs in, drop the columns SAP has no home for.

4. Reconcile the accounts. Match the company column against the accounts already in SAP, create the genuinely new ones, and fix spelling variants so contacts attach to the right parent instead of spawning near-duplicate companies.

5. Import five rows as a test. Use the data import your tenant provides — the Data Workbench in SAP Sales and Service Cloud, the migration tooling your team already uses for S/4HANA. Tool names and menu paths move between releases, so confirm the current path with your administrator rather than trusting any click-path you read online, including this one.

6. Check the test rows, then load the rest. Open those five contacts. Are the umlauts and CJK characters intact, the phone country codes present, the account assignment right? Only then run the full file.

The five things that actually break the import

One name column, two SAP fields. SAP wants first and last name separately. Splitting on the last space works for Anna Bergmann and fails for van der Meer, Kim Min-jun and every surname-first CJK name. Because the scanner detects the name order per card, romanized names come out in the right order to split — but eyeball the CJK and Dutch rows before you import, not after.

The plus sign. E.164 is the right format to start from, but two things attack it. Excel will happily treat +49891234567 as a formula or a number and eat the plus — keep the column as text. And some SAP phone models store the country dialling code in its own field; if your template has a separate country-code column, split the value there rather than pushing the whole string in.

Encoding and delimiters. The export’s UTF-8 byte order mark is what makes CJK open correctly in Excel, but a few strict parsers read it as part of the first header, showing your ID column as something odd. That is cosmetic and that column is not mapped anyway. The genuinely destructive move is opening the CSV by double-click in a German-locale Excel and re-saving: you can lose the characters and gain semicolon delimiters in one keystroke. Upload the exported file itself. If you must edit it, use Data → From Text/CSV — the full diagnosis and fix for garbled CJK and umlauts is here.

Accounts before contacts. A contact with no matching account either fails the import or lands orphaned. Do the account reconciliation as its own step; it is where the real thinking is.

Duplicates multiply quietly. Deduplicate in the spreadsheet, sorted by email and by company, before the file goes anywhere near SAP. Two cards from the same firm are normal at a fair, and the second row is what creates a second account. Import event-sized slices; never re-export the whole archive into SAP a second time.

Why the multilingual part matters here specifically

The SAP installed base skews heavily toward German industrial firms — and those firms’ trade-fair stacks are not monolingual. A Hannover or Düsseldorf hall produces German cards alongside Japanese 名刺, Chinese 名片 and Korean 명함 from suppliers and customers whose names generalist OCR reliably mangles: surname and given name in the wrong fields, no romanization, or characters that arrive as question marks and can never be recovered from that file.

SAP itself is perfectly happy holding Unicode. The failure happens upstream, in the capture and the export. Keeping native script and romanization as separate columns is what lets a sales rep in Stuttgart search “Yamada” on a German keyboard while the correspondence template still addresses 山田様 correctly — and it is why the mapping table above has a native and a romanized row for every human-readable field.

What this workflow does not do

It is a snapshot, not a sync. Nothing flows back: change a phone number in SAP and the scanner archive will not know, and vice versa. That is the trade-off of the file route, and for Visitenkarten scannen after an event it is a fair one — the cards do not change after the fair either.

Two habits keep it clean. Treat SAP as the system of record from the moment the import succeeds, and keep the scanner archive as the capture log, with the original card photos and follow-up reminders doing their work in the days before anything reaches master data. And remember that every copy of a contact list is personal data with a deletion obligation attached — worth reading is scanning business cards GDPR-compliant? before the file lands in a third shared drive.

If your destination is a spreadsheet, Google Contacts or a phone rather than SAP, the shorter route is scanning business cards into Excel, CSV or Google Contacts.

Test the mapping with your own cards before the next Messe — the first 30 scans are free, and the full CSV export is included from the first one.