CV parsing explained: how your ATS reads a resume

CV parsing converts an uploaded resume file into structured candidate data: contact details, work history, education, skills, and languages, in seconds rather than minutes of typing. Good parsers read PDF and Word files across languages, survive imperfect layouts, and deduplicate by email so the same person never becomes two records.

What fields does a CV parser extract?

The skills row is where parsers differ most. Weak ones only lift the literal skills section; strong ones infer skills from what the person actually did in each role. That distinction feeds straight into how candidate matching works, because a skill the parser missed is a match the engine cannot make.

Can CV parsing handle every language?

Mainstream languages parse well; the long tail does not. For EU recruiting, the practical bar is solid Dutch, German, French, and English handling, including the mixed-language CV, since a Dutch CV with English job titles is the normal case rather than the exception. Specific things to test with any vendor:

• Date conventions: 1-3-2024 and 3/1/2024 are different days in different countries.
• Local education systems and degree abbreviations, which rarely translate one to one.
• Names with diacritics, and transliterated names that appear in two spellings.
• CVs that switch language halfway, usually at the skills section.

A vendor demo should run on your real CV mix, not on their polished sample files.

Where does CV parsing fail?

Every parser fails somewhere, so here is the honest list:

1. Two-column and creative layouts. Text extraction can read columns in the wrong order and scramble work history.
2. Scanned or photographed CVs. Image files need character recognition first, and quality follows the quality of the scan.
3. Tables and text boxes. Content placed inside design elements gets skipped by weaker extractors.
4. Unusual dates and gaps. Phrases like “2019 to now”, sabbaticals, and overlapping roles confuse timeline logic.
5. Headshots, logos, and graphics. Decoration the parser must ignore, and sometimes does not.

The design consequence: parsing must always be correctable. The candidate record should show the original CV next to the extracted data so a recruiter can fix a wrong field in seconds. A parser that hides its source document is a parser you cannot audit.

How does deduplication by email work?

The email address acts as the natural key. When a CV arrives, whether uploaded by a recruiter, submitted through an apply form, or imported in bulk, the system checks whether a candidate with that email already exists. On a match, the new application attaches to the existing record: history accumulates on one profile instead of splitting across duplicates. You immediately see that this person also applied last year, which stage they reached, and what notes were left.

Recruitifly deduplicates by email at intake and during migration imports, which is what keeps a transferred database clean instead of doubled. One limit worth knowing: people legitimately use multiple addresses, so good systems also flag near-matches, the same name and phone under a new email, for a human merge decision rather than merging silently.

What happens after the CV is parsed?

Parsing is the front door to everything else. The structured profile becomes searchable, so you can find every candidate with payroll experience near Utrecht in one query. It feeds matching and pipeline scoring, and it pre-fills what candidates would otherwise retype in application forms. Parsing quality therefore caps the quality of everything downstream. When you evaluate an ATS, upload twenty of your own recent CVs, including the ugly ones, and inspect the resulting profiles field by field; the features overview shows where parsing sits in Recruitifly’s flow.

Recruitifly is in private beta. Bring your strangest CVs and see how the parser holds up: talk to us to join.