Screening
How to Measure What Your Resume Parser Loses
A resume parser that quietly drops qualified applicants can be caught with resumes you trust. Take thirty from people you hired and would hire again, submit them through your live apply flow the way a candidate would, then diff the parsed fields against the documents. Count every lost employer, date range, certification and missing section. The same losses run against every application nobody opened, and since these thirty already survived your funnel, treat what you find as a floor. The loss is a configuration problem rather than a candidate problem.
The takeNearly everything written about resume parsing is addressed to the candidate: drop the tables, kill the columns, rename the section headers. That puts the repair job on the one party with no visibility into the system and no way to check the result. It also lets an employer read a data-loss bug as a quality signal about a person. The employer is the only party who can hold the document and the parsed record side by side, which makes this the employer's measurement to run.
Where Olive fits
Open a role and see what the work shows
Olive is priced per attempt rather than per seat, and an attempt returns six evidenced findings about how one candidate worked with an AI assistant, each written by a person. Ten attempts a month are free, which is enough to run it beside a screen you are already measuring.
Rank your shortlistHow do you measure what the parser drops?
Reproduce the trip an application takes. Collect thirty resumes from people you hired in the last two years and would hire again, submit each one through your live application form as a test candidate, then open the parsed record beside the original document and mark every field the system got wrong, got partly, or never built at all.
Four details decide whether the exercise tells you anything.
- Use the live form, not the admin importer. Bulk upload and sourcing tools often run a different parse path than the candidate-facing one, and the candidate-facing one is the number you need.
- Use real hires. The ground truth has to be settled before the test starts, otherwise you are grading the parser against your own reading of a stranger's resume.
- Score per field, not per resume. A resume that lost one certification and a resume that lost eight years of employment history are not the same event, and a pass-fail tally hides which is which.
- Open a test requisition and delete the records afterward. These are real people's documents, and they are in your system for a measurement they did not agree to.
One pass takes a person about three hours. The output is a tally by field: employers, titles, date ranges, education, certifications, skills, contact details. Anything above a couple of losses in thirty on a field your searches require is a finding, because that field is a filter, and a filter running against empty boxes removes people silently.
What gets lost, and where?
Structure, not content. The losses cluster in four places: multi-column and table layouts that interleave text from two columns into a single line, section headings the parser does not recognise, date ranges written in a format it cannot read, and skills named differently in the document than in your own vocabulary. Every one of them is invisible from the recruiter's side, because the resulting record still looks complete.
| What broke | How it looks in the record | What to check |
|---|---|---|
| Two-column layout | Job titles attached to the wrong employer, or a sentence that reads as two half-sentences | Any resume whose original had a sidebar |
| Unrecognised heading | An empty Experience section on a candidate with fifteen years of it | Headings like Selected Engagements, Career History, Practice |
| Date format | Missing or zero-length tenures, which break every years-of-experience filter | Ranges written as 2019-22, Spring 2020, or with month names abbreviated |
| Vocabulary gap | A skills field that is populated but does not contain the string your search requires | Product names that changed, abbreviations, plurals |
The vocabulary gap is the one that produces the strangest results, because nothing failed. A designer who wrote Creative Suite does not match a required skill of Creative Cloud. A nurse who wrote RN does not match Registered Nurse. A platform engineer who wrote GCP does not match Google Cloud Platform. The record parsed correctly, the search ran correctly, and a qualified person is not in the result set. That failure mode is one reason a keyword filter can stop separating anyone without anybody noticing the day it happened.
The same structural losses land unevenly. Career changers and people returning after a break carry unusual section headings. International candidates carry date formats and qualification names your parser was not tuned on. None of that is a judgment about the person, and all of it arrives at a recruiter looking like a thin application.
Why is the loss the employer's problem?
Because the duty sits with the employer rather than with the vendor that built the parser. The Justice Department's plain-language ADA guidance for employers, issued May 12, 2022, says employers violate the ADA if their hiring technologies unfairly screen out a qualified individual with a disability, and it puts the repair on the employer: use an accessible test, or adjust the process instead 1.
That guidance is the agency's reading of existing ADA duties rather than a regulation, and it carries no penalty of its own. It also covers disability only. What it establishes for this exercise is the direction of responsibility, which the EEOC stated the same way in 2023: asked whether an employer is responsible for algorithmic hiring tools designed or administered by someone else, the answer given was "In many cases, yes," including where an outside vendor built the tool 2. That document was removed from the agency's site in January 2025 and never had the force of law, so quote it as what the EEOC said in 2023 and not as current guidance.
The wider point is that the surfaces candidates apply through are not reliable by default. WebAIM's February 2026 automated scan of one million home pages found detected WCAG 2 failures on 95.9% of them, an average of 56.1 errors per page 3. That is home pages rather than application forms, and automated checking catches only a subset of failures, so read it as a floor on a general condition rather than a measurement of your vendor. The conclusion it supports is narrow and useful: test the thing, do not assume it.
A parser is a data pipeline, and every data pipeline in your company has an owner and an error budget. This one processes the input to a decision about someone's job, which is a reason for it to be held to at least the standard of your billing exports.
Fix the vocabulary before you fix the filter
Fix your own vocabulary first, because it is the half you control and by far the cheaper half to change. The parser maps a document into fields; your searches and required-skill lists decide which strings count. When those two disagree the candidate disappears, and rewriting a required-skill list is a ten-minute edit against a vendor ticket that may take a quarter.
Build the synonym list out of the thirty resumes you just read. Every place a hire wrote something your search would have missed is a line in that list, and hires are the right source because you already know they were qualified. Add both spellings to the saved searches. Drop any required field the parser could not reliably fill, and move it to a question on the form instead, where the candidate types the answer directly and nothing has to be inferred.
Then look upstream at the text that seeds all of it. Your posting supplies the vocabulary a matching engine compares against, so the posting you wrote is what your matcher scores, and a requirement phrased in internal shorthand narrows the result set before anyone applies. Rewriting the posting fixes the search and the candidate's own wording at once.
If a meaningful share of applications lose structure on the way in, the resume is doing less work than the process assumes. That reopens a question the parser test cannot settle: whether the resume screen still predicts anything for the roles you hire, or whether the first real signal should come from something a candidate produces rather than something a parser reconstructs. That question gets sharper for early-career pipelines, where documents are increasingly assembled with help and carry less about the person than they used to.
Common questions
Is thirty resumes enough to trust the result?
Enough for the failure modes, which is the goal. Thirty gives you a rough rate with a wide interval around it, so report it as a mechanism rather than a percentage: two-column layouts break, this heading is unrecognised, this date format zeroes out tenure. If you want a defensible rate for a specific field, keep sampling that field until the count stabilises. Most teams stop before that, because the first thirty already produce a repair list.
Should we test with AI-written resumes too?
Not in this exercise. The back-test isolates one variable, whether your system reconstructs a known-good document faithfully, and a document of uncertain provenance destroys the ground truth that makes the test work. Run it with resumes from people you hired and can vouch for. How generated applications change what a resume is worth is a real question, and it is a separate one from whether your pipeline is losing data.
Can we require plain text or a specific template instead?
Offer it, do not require it. A plain-text option and a clear note about what the form parses well costs nothing and helps the candidates who read it. Requiring a template shifts the failure onto applicants who never see the result, and it filters for people who read application instructions closely rather than for people who can do the job. Fix the configuration, then tell candidates what helps.
Do the resume checker tools candidates buy tell us the same thing?
No. Those tools score a document against a generic parser and a generic scoring model, not against your system, your field requirements or your saved searches. A resume that passes one of them can still lose an employer in your pipeline, and one that fails can parse cleanly for you. The only instrument that answers the question is your own apply flow, because it is the one your applicants actually pass through.
The vendor says the parser is 98% accurate. Does that settle it?
Ask what was measured. Accuracy on which fields, on what corpus of resumes, scored by whom, and counted per field or per document? A per-document number averages a lost phone number against eight lost years of employment. A number measured on a curated benchmark corpus says little about the documents your roles attract. Ask for the field-level breakdown, then run your own thirty anyway, because the configuration is yours and so is the result.
References
- 1. Algorithms, Artificial Intelligence, and Disability Discrimination in Hiring ada.gov Supports the claim that the employer carries the duty when hiring technology screens out a qualified individual with a disability, and must adjust the process.
- 2. Select Issues: Assessing Adverse Impact in Software, Algorithms, and Artificial Intelligence Used in Employment Selection Procedures Under Title VII of the Civil Rights Act of 1964, Question 3 (archived capture, 2025-01-25) web.archive.org Supports the 2023 EEOC answer that an employer may be responsible for a selection procedure even where an outside vendor built it, with the withdrawal noted.
- 3. The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages webaim.org Supports the claim that the digital surfaces candidates pass through fail accessibility checks by default, so a vendor's pipeline has to be tested rather than assumed.
3 sources, numbered by first appearance. How Olive sources claims
General guidance for hiring teams. What works at one company and one volume may not transfer to yours.
Olive assesses how a person works with AI. It does not detect AI-written documents, and it never produces a score, a ranking, or a match percentage for a person. Candidates read the same report the employer reads.