How AI resume parsing works — and where it fails
In short: A resume parser turns an unstructured document into fields: roles, dates, employers, skills, education. Large-language-model parsers do this far better than the keyword systems of a decade ago, but they still fail in predictable ways — on dates, on titles, on skills implied rather than stated, on non-standard careers and on formatting. The fix is not a better score; it is showing the reviewer the source passage beside every extracted field.
What parsing is
Parsing is extraction, not judgement. Given a PDF, a Word file or a pasted block of text, a parser produces a structured profile: a list of positions with employer, title, start and end dates; a list of skills; education; certifications; sometimes a short inferred summary. Everything downstream — matching against a job description, ranking, interview preparation — depends on that profile being right.
Older parsers used templates and keyword lists and broke on anything unusual. Current parsers are large language models prompted to read the document and fill a schema. They handle layout variety well, understand that "led a team of four analysts" implies people management, and can normalise "Sr. SWE" and "Senior Software Engineer" to the same role. That is a real improvement. It is also where the new failure modes come from.
Five ways it fails
1. Dates
Overlapping roles, "present", fiscal years, gaps, and dates written only as years all get normalised with some guess involved. A parser that reports "2019–2022" for a role listed as "2019–present (contract, part-time)" has silently changed the candidate's story. Our rule: every date field shows the text it came from, and ambiguous dates are flagged rather than resolved.
2. Titles versus responsibilities
Titles are inflated in some companies and deflated in others. A "Director" at a 20-person startup and a "Director" at a bank are not comparable, and a model that treats the title as the signal will mis-rank both. Better parsers extract scope indicators — team size, budget, reporting line — and leave the comparison to the reviewer.
3. Implied skills
"Built the reporting pipeline for the finance team" implies SQL, probably a BI tool, probably stakeholder management. Whether to infer those is a policy decision, not a technical one. Inferring too much creates skills the candidate never claimed; inferring nothing penalises people who write in prose rather than lists. We extract stated skills as stated and list inferred skills separately, marked as inferred.
4. Non-standard careers
Career breaks, portfolio careers, military service, immigration-related gaps, self-employment and academic roles are where parsers trained on conventional corporate resumes do worst — and where the legal and fairness risk is highest. A parser should be able to say "I could not structure this section" and hand it to a person, rather than forcing it into a schema.
5. Formatting and language
Two-column layouts, tables, headers read in the wrong order, scanned PDFs without a text layer, and resumes in a second language all degrade extraction. Many of these failures are silent: the profile looks complete and is simply wrong.
Why a score is the wrong output
Most screening products collapse the profile into a match percentage. The number hides every failure above. A reviewer who sees "72%" has nothing to check; a reviewer who sees "Skills: SQL (stated, p.1 line 14); Python (inferred from 'automated monthly reporting')" can confirm or correct in seconds, and the correction improves the next run.
This is the design principle behind our screening workflow: the agent produces the structured profile with citations and flags, a named reviewer confirms it, and only then does matching happen. The parser is a drafting tool, not a decision tool.
What to ask any vendor
- Does every extracted field show its source passage?
- How are ambiguous dates and gaps represented — resolved, or flagged?
- Are inferred skills separated from stated skills?
- What happens to a section the parser cannot structure?
- Can we measure parser accuracy on our own resumes before buying? (If the answer is no, that tells you something.)
We run exactly this measurement in week one of a recruiting pilot: a sample of your resumes, parsed, compared field by field against your recruiters' reading.
Run this on your own hiring data
A six-week recruiting pilot measures exactly these things — parser accuracy, reviewer agreement, time per application and compliance records — on your role family, with your reviewers, before you decide anything.