TL;DR
- The core decision: whether the parsed record is a convenience or a basis for decisions, because those need different levels of trust.
- When doing nothing is right: when a person reads every application and the parsed fields are just a preview.
- What has to be true: anything consequential gets checked against the document rather than the extracted version.
- How the options split: by whether parsing saves effort or replaces judgement.
- Decision rule: if a parsing error would remove somebody without anybody noticing, don't filter on that field.
- Outcome to expect: the same speed, fewer invisible exclusions, and a record you can defend.
The Summary That Didn't Match
Somebody opens a candidate record before a call. The summary says four years of experience, a degree in one field, and three skills listed as tags.
Then they open the actual CV and find eleven years of experience, because the parser only picked up the roles formatted consistently and skipped a section laid out in two columns. The degree is right. One of the three skills isn't mentioned anywhere in the document, and appears to have been inferred from a company name.
This particular candidate is fine, because a person opened the CV. What's unsettling is the implication: the parsed record was wrong in three ways, and if nobody had opened the document, all three would have stood. If a filter had been applied to years of experience, this person would have been removed before anyone looked, and nobody would ever have known.
Best tools for Applicant Tracking (ATS)
That's the shape of the problem. Parsing converts an unstructured document into fields, and every step of that conversion can lose or invent something. The conversion is usually good and it's never perfect, because CVs are documents people design themselves with no agreed format, and a parser is making educated guesses about which text means what.
None of that matters much if the parsed version is a convenience: a preview that saves somebody retyping, always backed by the document. It matters enormously if the parsed version is what gets searched, filtered and ranked, because then a parsing error becomes an invisible exclusion. The person is removed, nobody sees it happen, and there's no signal anywhere that anything went wrong.
So the useful reframe is that the parsed record is an interpretation, not a transcription. Treat it as a first draft that a person confirms before anything consequential depends on it.
When You Genuinely Do Not Need to Act Yet
Your current setup is genuinely fine. A person reads every application, the parsed fields are a convenience, and nothing is filtered automatically. At that point parsing errors cost a moment of confusion and nothing else.
Friction is starting to show. Somebody noticed a summary that didn't match a CV, or a candidate mentioned their details were wrong, or a search returned obviously incomplete results. Worth investigating, because it tells you how much the extracted version can be trusted, which you'll need to know before volume grows.
It has become a real cost. Volume has reached a point where reading everything is no longer possible, so something is filtering, and that something is working on extracted data. Now the accuracy question has consequences rather than being an annoyance.
The edge case that forces it. You use parsed fields to exclude candidates automatically, or to rank them, or to report on your applicant pool. All three convert a convenience into a decision-making input. Automated processing that affects individuals is treated differently in different places and the position has been changing, so establish what applies where you hire with local advice before relying on it.
Five Questions This Reader Asks at 11pm
How does resume parsing actually work? Software reads a document and tries to identify which text corresponds to which field: name, contact details, employer, job title, dates, education, skills. It does that by recognising patterns and structure, which works well on conventionally formatted documents and less well on anything unusual. The output is a structured record that looks authoritative and is a set of inferences.
How accurate is it? Good enough to save typing and not good enough to make decisions from unchecked. Accuracy varies by document, and the failures aren't randomly distributed: they cluster on particular layouts and particular kinds of career history. That's the important part, because it means errors aren't spread evenly across your applicant pool.
What formats break it? Anything that isn't a single column of conventional text. Tables, multi-column layouts, headers and footers, text inside images, unusual date formats, and any document where visual design carries meaning. Documents produced by design tools are frequently worse than plain ones, which is an odd incentive to create.
Should we filter on parsed fields? Be careful, and be specific about which fields. Filtering on something the candidate entered directly is reasonable. Filtering on something a parser inferred means the filter is applied to a guess, and the people it removes never appear anywhere you'd look. If you do it, check what a filter removed rather than only what it kept.
Do candidates need to format CVs differently? Many believe they do, and there's a real effect. That's worth knowing because it means your parsing quality partly determines who you see: people who know to submit plain, conventionally structured documents are advantaged over people who don't, which has nothing to do with whether they'd do the job well.
Where Parsing Breaks
The failures are predictable enough to be worth knowing specifically, because knowing them tells you which fields to distrust.
| Document feature | What the parser does with it | The consequence for the candidate |
|---|---|---|
| Two-column layout | Reads across columns, mixing sections | Roles merged or lost entirely |
| Tables for dates or skills | Frequently ignores or mangles them | Experience appears shorter than it is |
| Headers and footers | May read them as content | Stray text in unexpected fields |
| Text inside an image or logo | Cannot read it at all | Missing information nobody sees |
| Unusual date formats | Misreads or skips the range | Gaps or wrong duration calculated |
| Job titles that are not standard | Cannot map to a known role | Poor matching against any criteria |
| A career break, described plainly | Reads as a gap or a parsing failure | Duration miscalculated, sometimes penalised |
| Non-linear career history | Sequence confused | A summary that misrepresents the person |
The first row does the most damage and is the most common. Multi-column CVs are popular because they look organised, and they're exactly the layout most likely to be read in the wrong order, producing a record where a job title from one column attaches to dates from another. The resulting summary is coherent, plausible, and wrong, which is the worst combination because nothing about it looks broken.
The seventh row is worth thinking about separately. A career break, whatever its reason, appears in parsed output as a gap in dates, and any calculation of total experience treats it as absence. Where that calculation feeds a filter, the effect falls on a specific and identifiable group of people. How that interacts with your obligations differs by jurisdiction and it's worth establishing rather than discovering.
The sixth row is the quiet one. Job titles vary enormously between organisations, and a parser mapping an unusual title to a standard category will sometimes map it wrongly and sometimes not at all. Any matching or ranking built on top of that inherits the error.
Five Diagnostic Questions You Can Self-Assess Against
Have you compared a parsed record against its document? Take ten recent applications and check the extracted fields against the actual CVs. This takes half an hour and it's the only way to know what your parsing quality actually is, which is otherwise a matter of assumption.
Which fields does anything automatic depend on? List them. Years of experience, education level, skills tags, location. Each one is a place where a parsing error becomes a decision, and each should be checked specifically rather than trusted collectively.
What happens to a document the parser can't read? There should be a route: flagged for a person, or the raw document surfaced. If an unreadable document simply produces an empty record that then fails every filter, you have a candidate silently excluded by a file format.
Has anybody looked at what a filter removed? Not what it kept. Reviewing a sample of excluded applications is the only way to find out whether a filter is doing what you intended, and almost nobody does it because the excluded aren't in any view.
Do you know which parsed fields feed reporting? If you report on the composition or qualifications of your applicant pool from parsed data, the errors propagate into numbers that get presented. Those numbers inherit every systematic parsing failure, which makes them confidently wrong in a consistent direction.
Six Things Parsing Is Used For, Reviewed
Saving candidates from retyping their CV
Extracting the document into the application form so somebody doesn't enter their history twice. It earns its place completely, and it's the use where errors cost least, because the candidate sees the result and can correct it.
Where it falls short is when the correction step is missing or awkward. If parsed fields populate silently and the candidate never sees them, you've collected errors with their name on. If the correction interface is tedious, people fix the obvious mistakes and leave the rest.
Show candidates what was extracted and let them edit it easily. This is the single highest-value use of parsing and it's the one where accuracy problems solve themselves, because the person who knows the truth is right there.
There is a design trap worth avoiding here. Presenting the extracted fields as a long form to correct reproduces exactly the problem parsing was meant to solve, and candidates who have just uploaded a document will not enjoy being shown a screen of half-right fields to fix. Showing a compact summary with an obvious way to correct anything wrong is the version people actually use, and most of the time there is nothing to change.
Making applications searchable
Turning documents into records you can query. It earns its place because searching a pool is genuinely useful, particularly for revisiting past applicants when a new role opens, and because searching document text alone is imprecise.
Where it falls short is confidence in the results. A search returns what matched, and there's no indication of what should have matched but didn't because the relevant text was in a table. Absence of results reads as absence of candidates, which is a different thing.
Use it, and treat a search as a way of finding people rather than as a complete answer. Where a search matters, search the document text as well as the parsed fields.
The distinction becomes important when you are looking for somebody specific you remember rather than browsing. A search across parsed fields alone will miss a person whose relevant experience sat in a table, and the failure is silent: you conclude they are not in the system and go looking externally for somebody you already had.
Filtering against required criteria
Removing applications that don't meet stated requirements. It earns its place at high volume, where somebody has to reduce the pool and the alternative is reading everything, which isn't available.
Where it falls short is that the filter operates on inferences. A criterion applied to a parsed years-of-experience field removes people whose experience the parser undercounted, and nobody sees it. The exclusions are systematically biased toward particular document formats and career shapes rather than randomly distributed.
If you filter, prefer fields the candidate entered directly over fields that were inferred. Check a sample of what was excluded. And establish what automated exclusion means where you hire, because the rules differ by jurisdiction and have been changing.
There is also a question of how many criteria you apply at once, which compounds in a way people underestimate. Each individual filter looks reasonable and each has an error rate, and applying several in sequence means a candidate only survives if every one of them read their document correctly. The combined effect is considerably more aggressive than any single criterion appears, and nobody sees the total.
Ranking or scoring applicants
Ordering a pool by an estimate of fit. It earns its place as a way of deciding what to read first when you can't read everything, which is a real problem and a reasonable thing to want help with.
Where it falls short is the gap between ordering and deciding. A ranking that puts people in a sensible order is useful. A ranking that in practice determines who gets read, because nobody reaches the bottom of the list, has become a decision mechanism without anybody choosing that. It also compounds every parsing error underneath it.
Treat ranking as sorting rather than selecting, and make sure somebody occasionally reads from the bottom. Establish what applies where you hire, since automated evaluation affecting individuals is regulated differently in different places.
Reading from the bottom is also the only practical test of whether the ranking is any good. If the applications at the bottom are consistently unsuitable, the ordering is working and you can trust it more. If they include people who should obviously have been higher, the ranking is sorting on something other than what you care about, and that is worth knowing before it has quietly determined a year of hiring.
Populating the employee record at hire
Carrying details across when somebody is hired, so nothing gets retyped. It earns its place because retyping at the point of hire is a genuine source of errors that land on a new employee's records.
Where it falls short is that parsed data is exactly the wrong quality for an employee record, which needs to be correct rather than approximately right. A name misparsed from a CV becomes a name on a payroll record.
Use the handover and confirm the details with the person. They're now an employee, they're available, and they'll happily correct their own record. This is the one place where asking somebody to check their details is entirely reasonable.
Do it as part of something they are already doing rather than as a separate request, because a standalone message asking a new hire to verify their record competes with everything else in their first week. Attaching it to a step they have to complete anyway gets it done, and it is the cheapest possible moment to catch an error that would otherwise sit in the employee record indefinitely.
Reporting on the applicant pool
Producing numbers about who applied, their qualifications or their backgrounds. It earns its place where you need to understand your pool and reading every application isn't feasible.
Where it falls short is that every systematic parsing failure becomes a systematic reporting error. If certain document formats parse badly, and those formats correlate with anything at all, your reporting misrepresents the pool in a consistent direction. That's worse than noisy data, because it's wrong in a stable way that looks like a finding.
Be cautious about presenting these numbers as fact. Where reporting on your applicant pool touches obligations about monitoring or equal opportunity, what's required and permitted differs by jurisdiction, so take local advice rather than building from what the system happens to produce.
Where such reporting is required of you, it is usually better served by asking candidates directly than by inferring from documents, because a voluntary declared answer is both more accurate and more defensible than something extracted by software. How that must be collected, kept separate and used differs by jurisdiction, which is precisely why it belongs with local advice rather than with whoever configured the parser.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| A person reads everything | Under one hundred applications | Any | None | Treat parsing as a preview |
| Parsed summary did not match a CV | Any | Any | Unknown accuracy | Compare ten records against documents |
| Volume exceeds reading capacity | Over five hundred | High volume | Something must reduce the pool | Sort rather than exclude |
| Filtering on inferred fields | Any | Any | Invisible exclusions | Filter on candidate-entered fields |
| Ranking determines what gets read | Any | Any | Sorting became selecting | Read from the bottom sometimes |
| Unreadable documents producing empty records | Any | Any | Excluded by file format | Flag for a person |
| Parsed data populating employee records | Any | Any | Wrong quality for the purpose | Confirm with the person at hire |
| Reporting built on parsed fields | Any | Any | Systematic errors as findings | Caveat heavily, take local advice |
| Automated exclusion in use | Any | Any | Rules differ by jurisdiction | Establish the position before relying on it |
The fourth row is the distinction that matters most in this whole article. A field the candidate typed into a form is something they asserted. A field a parser extracted is something software inferred. Filtering on the first is a reasonable use of information somebody gave you. Filtering on the second means your exclusions depend on document formatting, and the people removed have no idea it happened.
The fifth row is the one that creeps up on organisations. Ranking is introduced as a convenience to decide reading order, everybody agrees it's just a sort, and within a few months nobody reads past the first page because there's never time. The mechanism hasn't changed and its function has, and nothing marked the transition.
When a Filter Becomes a Decision
There's a line between narrowing a list and excluding somebody, and it's worth being precise about where it falls, because the practical difference is small and the consequences aren't.
Narrowing means somebody remains reachable. A search that surfaces certain candidates first still leaves the rest findable. A sort that puts likely matches at the top still has a bottom that somebody could read. In both cases a person could look at anybody, and the tool is helping them allocate attention.
Excluding means somebody is gone. A filter that removes applications below a threshold means those people are not in the pool anybody reviews. Nobody will read them, nobody will notice they're missing, and the only record that they applied is in a place nobody opens.
Three things determine which side of the line you're on, and none of them is about the technology.
Whether the removed are still reachable. Can somebody get to a list of what was filtered out, easily, without asking for a report? If not, exclusion is effectively permanent regardless of what the system technically retains.
Whether anybody looks. A pool that's technically reviewable but never reviewed is excluded in practice. This is where ranking quietly becomes selection, and the transition is invisible because no setting changed.
Whether the criterion was asserted or inferred. Excluding on something the candidate stated is a use of their own information. Excluding on something parsed from their document means the criterion was applied to a guess, and the guess fails more often for particular formats and career shapes.
The practical position that avoids most difficulty is to prefer sorting over excluding wherever volume allows it. At genuinely high volume nobody reaches the bottom of the list either way, so the difference in outcome is small, and the difference in your ability to answer a question about a specific application is considerable.
Where you do exclude, two habits are worth building. Review a sample of what was removed, periodically, by a person, because that's the only feedback loop this mechanism has. And establish what applies where you hire, since automated processing that affects individuals is treated differently in different places, several regimes have been changing, and some require things like disclosure or a route to human review. That's a question for local advice rather than for a configuration screen.
The review does not need to be large to be useful. Twenty excluded applications, read properly by somebody who knows the role, will tell you within an hour whether the filter is removing people you would have wanted to see. If it is, the finding is usually specific: one criterion doing most of the damage, or one document format failing consistently, both of which are fixable once somebody has actually looked.
Where Parsing Goes Wrong in Practice
| The failure | How it shows up | What would have to change |
|---|---|---|
| Parsed record trusted without the document | Decisions on an interpretation | Open the CV before anything consequential |
| Filtering on inferred fields | Exclusions nobody can see | Filter on what candidates entered |
| Unreadable document, empty record | Silent exclusion by file format | Flag for a person to open |
| Ranking treated as a sort, used as a filter | Nobody reads past the first page | Read from the bottom occasionally |
| Parsed data into employee records | Errors on a payroll record | Confirm with the person at hire |
| Reporting from parsed fields | Systematic errors presented as findings | Caveat, and check against documents |
The third row is the failure with the least excuse and the least visibility. A document the parser couldn't read produces a record with empty fields, and empty fields fail every criterion. The candidate is excluded not for anything about them but because of how they saved a file, and there's no signal anywhere that this happened.
The first row is the habit that prevents most of the rest. Opening the document before doing anything consequential costs seconds and catches the errors that matter, because the errors that matter are the ones affecting a decision and those are exactly the moments when somebody is already looking at the record.
What to Put in Writing
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| Which fields are parsed and which are entered | Whoever configures the system | Before any filtering | Filtering on inferences unknowingly |
| What happens to an unreadable document | Whoever runs hiring | Before the next search | Exclusion by file format |
| Whether criteria sort or exclude | Whoever runs hiring | At configuration | Sorting quietly becoming selection |
| Who reviews a sample of exclusions, and when | Whoever runs hiring | Before relying on filters | The only feedback loop being absent |
| That details are confirmed at hire | Whoever handles offers | Before the first hire | Parsing errors on employee records |
| What automated processing means where you hire | HR, with local advice | Before relying on it | Obligations discovered afterwards |
The first row sounds administrative and is the one that changes behaviour. Most people configuring a filter have no idea whether the field they're using came from the candidate or from a parser, because the interface presents both identically. Labelling them makes the distinction visible at the moment it matters.
If your system will not let you label them, the fallback is a short written list kept alongside whoever configures searches. It is less elegant and it works, because the decision being protected is made by a small number of people a small number of times, and a list they can check is enough.
Questions to Ask Before You Commit
On accuracy. Have you compared parsed records to documents? A bad answer is that the vendor says it's accurate.
On source. Did the candidate type this or did software infer it? A bad answer is that it doesn't matter.
On exclusions. Who has looked at what was removed? A bad answer is nobody.
On unreadable files. What happens to a document that won't parse? A bad answer is that it's rare.
On ranking. Does anybody read past the first page? A bad answer is that they could.
On obligations. What applies where we hire? A bad answer is that it's just a filter.
On compounding. How many criteria apply at once? A bad answer is that each one is reasonable.
What Getting This Wrong Costs
The first cost is the candidate removed for a reason unrelated to their suitability. Somebody whose CV was laid out in two columns, or who described a career break plainly, or who saved a file in an awkward format, gets excluded by a mechanism that was assessing document structure rather than capability. They never know, you never know, and the only evidence is an application in a place nobody opens.
The second cost is that these exclusions aren't random. Parsing failures cluster on particular formats and particular career shapes, which means the effect falls unevenly across your applicant pool in ways that may correlate with things you'd care about. How that interacts with your obligations differs by jurisdiction and is worth establishing properly rather than discovering when somebody asks.
The third cost is the decision made on a summary that was wrong. A parsed record looks authoritative, presents cleanly, and gets used by people who are busy. When it undercounts experience or attaches the wrong title to the wrong dates, the person reading it forms a view of the candidate that the actual document wouldn't support, and they may never open the document because the summary answered their question.
That last point is the mechanism worth understanding. A summary is not neutral: it answers the question the reader had, which removes the reason to look further. A record showing insufficient experience does not prompt anybody to check whether the extraction was right, because the record has already explained why this person is not worth more time. Errors in the pessimistic direction are therefore far less likely to be caught than errors in the optimistic one.
So before relying on any of this, do the half-hour check. Take ten recent applications and compare the parsed fields against the documents. You'll learn more about your own process from that than from any vendor claim, and you'll find out whether the fields your filters depend on are ones you can depend on.
Pick the ten deliberately rather than at random, including at least two documents that look unusual, because those are the ones that will tell you something.
When You Are Ready to Go Further
None of this needs new software. It needs ten records checked against their documents, a label distinguishing parsed fields from entered ones, and a route for documents the parser can't read.
Then look at the filters. Prefer criteria applied to what candidates typed over criteria applied to what was inferred, and prefer sorting to excluding wherever volume allows. Both changes cost nothing and remove most of the invisible failures in this area.
After that, build the feedback loop that doesn't exist by default: somebody reviewing a sample of excluded applications, periodically. It's the only mechanism that can tell you whether a filter is doing what you intended, and it's the thing nobody sets up because the excluded are, by definition, the population nobody sees.
HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.
Frequently Asked Questions
What is resume parsing?
Software reading a CV and identifying which text corresponds to which field: name, contact details, employers, job titles, dates, education, skills. It does that by recognising structure and patterns, which works well on conventionally formatted documents and less reliably on anything unusual. The property that matters is that the output is a set of inferences rather than a transcription, even though it presents as a clean structured record. Treating it as a first draft that a person confirms, rather than as fact, prevents almost every problem in this area.
How accurate is resume parsing?
Good enough to save typing, not good enough to make decisions from unchecked, and the important part is that errors aren't randomly distributed. They cluster on particular layouts, such as multi-column designs and tables, and on particular career shapes, such as non-linear histories or documented breaks. That clustering means a filter applied to parsed data doesn't remove a random sample of people, it removes people whose documents or careers have particular characteristics, which is a different and more consequential thing.
What CV formats break parsing?
Anything that isn't a single column of conventional text. Two-column layouts are the most common problem, because the parser reads across columns and merges unrelated content, producing a record that's coherent and wrong. Tables holding dates or skills are frequently ignored. Text inside images can't be read at all. Headers and footers sometimes get read as content, and unusual date formats produce miscalculated durations. Documents from design tools are often worse than plain ones.
Should you filter candidates on parsed fields?
Be careful, and distinguish between fields the candidate typed and fields software inferred. Filtering on an asserted answer is a reasonable use of information somebody gave you. Filtering on a parsed field means your criterion is applied to a guess, and the people removed have no idea and appear nowhere anybody looks. Prefer sorting to excluding where volume allows, since at high volume the practical difference in outcome is small while the difference in your ability to answer a question about an application is considerable.
What happens when a CV cannot be parsed at all?
In most default configurations it produces a record with empty fields, and empty fields fail every criterion, so the candidate is silently excluded for how they saved a document rather than for anything about them. This is the failure with the least excuse and the least visibility. The fix is a route: unreadable documents get flagged for a person to open, rather than falling into the pool as an empty record that quietly fails everything downstream.
Does resume parsing affect who gets seen?
Yes, in a way worth being deliberate about. Candidates who know to submit plain, conventionally structured documents are advantaged over those who don't, which has nothing to do with whether they'd do the job. Parsing failures also cluster on career shapes such as documented breaks or non-linear histories, where duration calculations go wrong. Where such effects touch equal opportunity obligations, what applies differs by jurisdiction, so establish the position where you hire rather than assuming it's purely technical.
Should parsed data populate the employee record?
Only as a starting point that the person confirms. Parsed data is exactly the wrong quality for an employee record, which needs to be correct rather than approximately right, and a name or date misparsed from a CV becomes an error on a payroll record. The good news is that this is the easiest place to fix it: the person has just been hired, they're available, and confirming their own details is entirely reasonable to ask. Use the handover, then verify.
Can you report on your applicant pool using parsed data?
With caution, because systematic parsing failures become systematic reporting errors. If certain document formats parse badly and those formats correlate with anything, your numbers misrepresent the pool in a stable direction, which is worse than noise because it looks like a finding. Where reporting on applicants touches monitoring or equal opportunity obligations, what's required and permitted differs by jurisdiction, so take local advice rather than building reporting from whatever the system happens to produce.
The parsed record is an interpretation. Check the document before anything depends on it.
And look at what your filters removed, because nobody else will.
