Resume parsing is software that reads a CV and turns it into structured fields (name, contact details, roles, dates, education and skills) so that a database can search and sort candidates. It works well on clean, conventional CVs and goes wrong on unusual layouts, ambiguous dates, non-standard job titles and mixed languages. The practical response is to test the parser on your own CVs, score it field by field, and keep a person checking before anything important depends on the output. This guide explains how parsing works, where it misreads candidates, and a 30-CV test you can run in an afternoon.
What a resume parser actually produces
A parser does three different jobs, and they carry different levels of risk.
| Layer | What it does | Example | Risk |
|---|---|---|---|
| Extracted | Copies what the CV says into a field | "Sr. Software Eng." at "Acme Ltd" | Low, but misreads happen |
| Normalized | Maps the text to a standard form | Title mapped to "Software Engineer (Senior)", date stored as 2021-03-04 | Medium, because the mapping can change the meaning |
| Inferred | Works out something the CV does not state | Total years of experience, seniority level, skills implied by a project | High, because it is a guess |
Commercial parsers mix all three. One vendor's developer documentation, for example, describes a data model with more than 50 extracted, normalized or inferred fields, returned as structured JSON or XML. When a field looks wrong, the first question is which layer produced it. An inferred field is a calculation, and treating it as a fact is a common way to end up with bad filters.
How parsing works, step by step
Different tools vary in the details, but most follow the same stages. One recruiting software vendor describes five:
- File to text. A PDF or Word file that contains real text is read directly. A scanned document or image goes through optical character recognition (OCR), which reads the shapes of letters and sometimes gets them wrong.
- Layout reconstruction. The software works out the reading order across columns, tables, text boxes, headers and footers. Researchers describe the extreme heterogeneity of resume layouts and content as a core challenge of the whole task.
- Section segmentation. It finds the sections, such as experience, education and skills. Headings vary a great deal, from "Work history" to "Where I have worked."
- Field extraction. It pulls out employers, titles, dates, degrees and skills, using fixed rules, trained models, language models, or a mix.
- Normalization. It maps titles, skills and locations to a standard list, and converts dates to a consistent format.
The important point is that these stages feed each other. If layout reconstruction mixes a sidebar with the experience section, every later stage works on scrambled input, and the output can look tidy while being wrong.
Where parsers misread candidates
These are the failure points that come up most often. The examples are illustrative.
| Problem | What goes wrong | Typical effect |
|---|---|---|
| Ambiguous dates | 03/04/2021 can mean 4 March or 3 April. "Present," missing months and overlapping roles confuse the logic | Wrong tenure, false career-gap flags, wrong years of experience |
| Job titles | Abbreviations ("Sr.," "Mgr"), company-specific titles and seniority inflation get mapped to the wrong standard title | Candidates filtered out of, or into, the wrong searches |
| Multi-column and designed layouts | A sidebar of skills gets merged into the experience lines, or sections appear in the wrong order | Fields assigned to the wrong job |
| Text boxes, tables, headers and footers | Contact details placed in a header can be dropped | Missing email or phone number |
| Non-English and mixed-language CVs | Language coverage varies by tool (the vendor documentation above lists 25 languages for CV parsing), and names written family name first can land in the wrong field | Wrong or missing names, poor extraction |
| Scanned files and images | OCR turns "Engineer" into "Engineor," which then fails to match a title list | Missing or unmatched fields |
| Skills | Similar words ("Java" and "JavaScript") get confused, and skills the person never claimed can be inferred | Inflated or wrong skill lists |
| Duplicate uploads | The same person parsed twice creates two records | Split history and duplicate outreach |
| Language-model parsers | The output reads fluently but can include a normalized title or detail the candidate never wrote | Confident errors that are hard to spot |
Dates deserve special attention because they feed so much else. The international standard for dates, ISO 8601, uses the order year, month, day (for example 2021-03-04) precisely because it is unambiguous to both people and machines. Check that any parser you use stores dates in a consistent, unambiguous form, and that your database does too.
Why this matters downstream
Parsed fields are the raw material for everything after them: searches, shortlists, duplicate checks, reports and outreach. A wrong start date changes the years of experience, which can push a strong candidate below a filter. A scrambled employer field can put a candidate in front of a client for a role they never held. If you automate shortlisting, the audit routine in this guide to candidate shortlisting automation only works if the data underneath it is sound. Parsing is the first place that data can go wrong.
Test a parser on your own CVs in an afternoon
Vendor demos use clean examples. The only reliable check is your own intake. Here is a method that takes a couple of hours.
Step 1: Build a test set of 30 CVs. Sample them from real recent intake, and mix them on purpose:
- 10 clean, conventional CVs
- 10 designed or multi-column CVs
- 5 non-English or mixed-language CVs
- 5 scanned or unusual files
Keep the set in a secure, access-controlled place, and only use CVs you are entitled to use this way. Do not upload candidate CVs to any tool you have not vetted.
Step 2: Write the answer key. For each CV, record the correct value of eight fields by hand: full name, email, phone, current job title, current employer, start date of the current role, highest education, and location. That is 240 values, which is why a sample of 30 is a practical size.
Step 3: Run the parser and line up the results. Export the parser's output next to your answer key in a spreadsheet.
Step 4: Score every field. Mark each as correct, wrong or missing. Then calculate accuracy by field and by CV group, not as one overall average. An illustrative result looks like this. The numbers are made up to show the format:
| Field (correct out of) | Clean (10) | Designed (10) | Non-English or mixed (5) | Scanned or unusual (5) |
|---|---|---|---|---|
| Name | 10 | 9 | 3 | 3 |
| 10 | 10 | 5 | 4 | |
| Current title | 9 | 6 | 2 | 2 |
| Current employer | 9 | 6 | 3 | 2 |
| Current role start date | 8 | 5 | 2 | 1 |
The overall average across those five fields is about 73%, which sounds acceptable. The table shows what the average hides: start dates are right only 16 times out of 30, and designed and non-English CVs are where most of the errors sit.
Step 5: Log the cause of each error. Use a short set of codes so patterns show up: layout, date format, abbreviation, language, OCR, inferred value, duplicate.
Step 6: Act on what you find. Common fixes include:
- Asking for a text-readable PDF or Word file at intake instead of images or scans.
- Adding simple validation rules, such as an email in a valid format, an end date that is not before the start date, a start date that is not in the future, and a name field that does not contain job-title words.
- Sending low-confidence or rule-failing parses to a person to check, instead of letting them flow straight into search.
- Asking the vendor for field-level results on documents like yours.
Step 7: Re-test after any change. Run the same 30 CVs again whenever the parser, its settings or your intake process changes, and refresh the sample every quarter.
Questions to ask a parsing vendor
- What is the accuracy for each field, on CVs like mine, and how was it measured?
- Which languages and file types are supported, and how are failures reported?
- Does the output include confidence scores or flags I can use for review?
- Where is the data stored, for how long, and is it used to train models?
- What contract covers the processing of candidate data?
On the last point, a provider that handles CVs on your behalf is usually a processor under data protection law. Article 28 of the GDPR requires that processing by a processor is governed by a contract, and that the processor acts only on the controller's documented instructions. This is general information, not legal advice, and it is worth confirming the arrangement with a qualified adviser.
The same test works outside recruiting
Turning documents into structured data is a common task far beyond CVs. Invoices, receipts, contracts, application forms and intake documents all go through the same stages (text extraction, layout, fields, normalization), and they fail in the same ways: unusual layouts, ambiguous dates, inconsistent naming and poor scans. The method for checking them is the same too. Take a representative sample that includes the awkward cases, write an answer key, score by field and by document type, log the cause of each error, and fix one thing at a time.
Common mistakes
- Testing only clean documents. The CVs that cause trouble are the ones a demo never includes.
- Trusting the overall average. A single accuracy figure hides weak fields and weak groups, so always look at the breakdown.
- Treating inferred fields as facts. Years of experience and seniority are estimates, and they should be labeled that way wherever they are displayed.
- Having no review path. Without a route for suspect parses, errors flow straight into searches and shortlists.
- Never re-testing. A parser update or a change in the kind of CVs you receive can shift the results without warning.
- Sending CVs to unvetted tools. Candidate documents are personal data, so check where they go before you test or use any new service.
Next step
Pick one parser or one batch of 30 CVs and run the test this week. If you would like an outside view of a document-processing or data-quality workflow in your business, whether in recruitment, finance or operations, you can book a short call. For more guides, see twelve processes you can automate in a recruitment agency, how to automate candidate sourcing without sounding like a bot, and the rest of the blog.
Sources
- Zhu et al., Layout-Aware Parsing Meets Efficient LLMs: A Unified, Scalable Framework for Resume Information Extraction and Evaluation (arXiv, October 2025)
- Textkernel developer documentation, CV/Resume and Job Parser
- TheHireHub.AI, AI resume parsing in 2026 (a vendor blog, used here only for its description of the process stages)
- ISO, ISO 8601 date and time format
- Regulation (EU) 2016/679, Article 28 (Processor)