Business card OCR at trade shows: what actually works when you have 300 cards and 4 hours
Business card OCR sounds like a solved problem. It is not.
The reason it's not solved is that "business cards" as a category on the trade show floor bears very little resemblance to the clean, uniform, single-language cards that OCR products were originally trained on. A Canton Fair vendor's card is a two-sided document, printed in gold ink on a dark background, with a company name in Simplified Chinese and English, a personal name in Pinyin and Chinese, an office address, a factory address, a WeChat ID, a WhatsApp number, a QQ number, an email, four different phone numbers, and a QR code with an embedded contact card that half the time doesn't match the printed text.
Feed that to a classical OCR pipeline and you get back a wall of text. Feed it to a well-designed LLM-backed pipeline and you get back a structured contact that can immediately go into a CRM. The difference is not incremental. It's the difference between the card being useful in a database and the card being a photo you'll have to re-type.
This post covers what actually goes wrong with OCR on real trade show cards, what "good" looks like, why LLM-based approaches beat classical OCR for this specific task, and what to look for in a scanner.
The problem, concretely
Sit down at your hotel after day 2 of Canton Fair and lay out the cards you collected. You will see, in some rough distribution:
- Cards in English and Chinese, with company name in both scripts
- Cards in English + Simplified Chinese + Traditional Chinese
- Cards in Korean, Japanese, Arabic, Turkish, Russian (a lot of Korean at HKTDC, Turkish at any electronics show, Russian at Global Sources)
- Cards printed with gold or silver foil on black or navy, essentially unreadable to consumer OCR
- Cards with WeChat IDs, WhatsApp numbers, and QQ numbers all treated as "just another phone number" by naive extractors
- Cards where the person's name is printed in Chinese only, with the English "call me Sylvia" written in Sharpie on the back
- Cards with a QR code that resolves to a WeChat contact card, and the printed text is subtly different (a nickname, an old phone number)
Now try to build a vendor CRM out of that.
A concrete example
Here's a real-shape card (details anonymized):
深圳天立音频科技有限公司
Sylvia Yu 余晓雨
Sales Manager | Overseas Dept
Mob/WeChat: +86 13923785487
WhatsApp: +86 13923785487
Tel: +86-755-2833-9928 ext.804
Email: [email protected]
Add: Building 5, No.128 Longcheng Ave, Longgang District,
Shenzhen, Guangdong, China
What a naive OCR pipeline returns:
{
"name": "Sylvia Yu",
"company": "Shenzhen Tianli Audio Technology Co., Ltd.",
"phone": "+86 13923785487 +86 13923785487 +86-755-2833-9928 ext.804",
"email": "[email protected]",
"address": "Building 5, No.128 Longcheng Ave, Longgang District, Shenzhen, Guangdong, China"
}
What a well-designed LLM-backed pipeline returns:
{
"company_name_en": "Shenzhen Tianli Audio Technology Co., Ltd.",
"company_name_zh": "深圳天立音频科技有限公司",
"person_name_en": "Sylvia Yu",
"person_name_zh": "余晓雨",
"title": "Sales Manager",
"department": "Overseas Dept",
"mobile": "+8613923785487",
"wechat": "+8613923785487",
"whatsapp": "+8613923785487",
"office_phone": "+8675728339928",
"office_ext": "804",
"email": "[email protected]",
"address": {
"street": "Building 5, No.128 Longcheng Ave",
"district": "Longgang District",
"city": "Shenzhen",
"province": "Guangdong",
"country": "China"
}
}
The naive output requires 30–90 seconds of manual cleanup per card. Multiply that by 300 cards and you're spending five hours in the hotel un-scrambling a database. The structured output is ready to use.
Why classical OCR still fumbles this
Classical OCR pipelines (Tesseract, ABBYY, iOS Vision, older versions of most commercial scanners) do two things in sequence: they extract text from the image, and then they use rule-based extractors (regexes, layout heuristics, dictionaries) to guess which piece of text is a phone number, which is an email, which is a name.
The extraction step is fine. Modern OCR reads printed text well, even in Chinese, even in mixed scripts.
The classification step is where it falls apart. Classical rules can't tell that "Mob/WeChat:" preceding a phone number means the number is both a mobile and a WeChat ID. They can't tell that a name in Chinese characters immediately preceded by an English name is the same person's name in a different script. They can't distinguish "Add:" from "Address:" and drop the address field entirely. They can't decide whether "Sales Manager | Overseas Dept" is one job title or two fields.
You can hand-craft rules for all of this. Vendors of "smart business card apps" have been doing exactly that for fifteen years. The rules break constantly on the long tail of card designs. The category never got solved, it got tolerated.
What LLM-backed OCR does differently
A vision-capable large language model (Groq's Llama-4-Scout, GPT-4o, Claude's Sonnet vision, Gemini Flash) does the extraction and classification in a single pass. You send it the image plus a prompt like "extract this business card into structured JSON with these fields..." and it returns a filled-out JSON.
What matters is that the model understands the semantics of a business card. It knows what a WeChat ID looks like. It knows that Chinese company names and English company names can co-exist. It knows that "Mob/WeChat" is a shared field. It knows that a phone number with ext. is an office phone, not a mobile. All of this is baked in from the training data.
Speed matters too. A card image sent to a modern hosted vision LLM (Groq's LPU-hosted Llama-4-Scout is currently the fastest) round-trips in about 300–500 milliseconds. GPT-4o Vision is closer to 1.5–2.5 seconds. Anthropic's Sonnet 4 vision is around 1–2 seconds. For a scanner where you take a photo and want a filled-out contact card before you put your phone back in your pocket, sub-second is the target.
| Approach | Latency | Chinese script | WeChat field | Bilingual names |
|---|---|---|---|---|
| Classical OCR + regex | ~200ms | Weak | Missed | Confused |
| iOS Vision + heuristics | ~150ms | OK | Missed | Confused |
| GPT-4o Vision | ~1500ms | Excellent | Extracted | Preserved |
| Claude Sonnet Vision | ~1200ms | Excellent | Extracted | Preserved |
| Groq Llama-4 Scout | ~450ms | Excellent | Extracted | Preserved |
The reason LLM-backed OCR wins on business cards isn't the OCR. It's the classification. The model already knows what fields a business card has and doesn't need to be told, one regex at a time, how to guess.
Hard cases: what still breaks
LLM OCR isn't magic. There are still card categories that trip it up:
- Extremely low-contrast cards. Silver foil on white, black embossed on black. The camera has to catch it in the first place. Increasing exposure and shooting flat at good angle solves most of this.
- Cards where two people share one card. Common at family-run factories. The model has to decide who's the primary contact. Better implementations return a list of contacts rather than one.
- Cards printed only in Chinese with no romanized names. The model can transliterate, but transliteration is not the same as the person's actual English name. Sylvia might be "Yu Xiaoyu" via Pinyin but her actual English name of choice is "Sylvia" which appears nowhere on the card.
- QR-code-only cards. A rising number of Chinese vendors have essentially blank cards with a WeChat QR code. The scanner has to also decode the QR, then follow it to the WeChat contact.
- Handwritten additions. A vendor writes their personal WeChat on the back in Sharpie because the printed one is the company account. Vision LLMs read this fine if the pen is clear, badly if it's messy.
Deduplication
The other thing your scanner needs to do is not duplicate. You will scan the same vendor twice. You will scan a card, forget you did, scan it again the next day at a different booth (Canton Fair vendors often have booths in multiple halls). A card scanner that just piles up records is not helping you.
Good deduplication matches on:
- Exact email match (highest confidence)
- Exact WeChat ID / phone number match
- Normalized company name match (strip Ltd., Co., etc.) + at least one shared contact detail
When it matches, it should merge: keep both cards' unique contact points but preserve one vendor record. The second card's photo becomes an additional card photo on the vendor, not a whole new vendor.
Bulk import: 30 cards at a time
The other feature that matters at scale: bulk import. You get back to the hotel and dump 30 loose cards on the desk. You want to lay them out on the desk, take one photo of all 30, and get 30 vendors back. Not scan them one by one.
This is where the LLM approach has a compounding advantage. A vision model can process a multi-card image in a single pass, returning an array of contact objects. Card detection, per-card cropping, per-card extraction, all in one shot. A well-tuned pipeline handles a photo of 20–40 cards in about the same time as a single card.
Alternatively: pick up cards from the camera roll. Any camera roll photo that looks like a card gets processed. If you shot booth photos with cards visible in them, those get picked up too.
Privacy: where does the card image go
A card image is a photograph of someone's personal contact information. Where it goes matters.
Look for a scanner that:
- Sends the image only to your own account backend, not to third-party ad networks
- Does not train future models on your images (or gives you an off switch)
- Encrypts images in transit and at rest
- Deletes the image on demand
Also: check whether the OCR provider's terms of service allow you to send third-party PII (a person's business card belongs to them, not to the vendor company). Most B2B providers explicitly allow this; some do not.
Putting it together
The workflow that actually works, distilled:
- Take the card, thank the vendor
- Scan it right there at the booth, one photo
- Structured contact populated in under a second
- Tag it immediately with the products you just discussed (photos already in your app)
- Move on to next booth
Skip step 3 or 4 and by day 4 you have a mess. Get all five in a five-second loop and by day 4 you have a clean vendor database you can start emailing that night. This is basically the whole game.
Show Sourcing runs a Groq-hosted Llama-4-Scout vision pipeline for card OCR, tuned specifically for the field shapes above (WeChat as a separate field, bilingual name preservation, address parsing, multi-card in one shot). Typical single-card parse time is around 0.5 seconds from tap to filled-out vendor record. Multi-card imports process 20 cards in about 2 seconds. Cards are stored with the vendor record so you can always fall back to the original photo if a rare field extraction was wrong.
If you found this useful, the Canton Fair prep checklist covers how this fits into a full show-floor workflow, and the landed-cost writeup covers what to do with all these vendors once you have them.