What to do when CV parsing fails or information is incomplete

When CV parsing fails, mark the document for manual review, preserve the original file, show which fields are unavailable, and ask a reviewer to verify the relevant evidence. Incomplete information is a gap to resolve, not proof that a candidate lacks the capability.

Use a visible fallback for failed or incomplete CV parsing so reviewers can resolve uncertainty without turning a missing field into a rejection decision.

Troubleshooting checklist · 8 min readAuthored by: Skilltage OÜPublished: Updated: Reviewed by: Janus JektvikFacts reviewed:

What does a CV parsing failure mean?

A parser failure means that the workflow could not reliably turn part or all of a submitted document into structured text. It may be caused by an image-only PDF, an unusual layout, a damaged file, a language or font issue, a password-protected document, or an extraction service interruption. It does not establish that the candidate lacks a qualification or experience.

Recruitment teams should keep that distinction explicit. The EU AI Act treats systems used to analyse or filter job applications as an employment-related use that may carry high-risk obligations, depending on the system and context. The ICO's recruitment-tool audit outcomes also highlight the need to understand data quality, transparency, and human oversight. This article is operational guidance, not a legal conclusion about a particular deployment.

Skilltage guidance: label the input state before interpreting any requirement result:

Input stateWhat the reviewer can concludeSafe next action
AnalysedThe available text was extracted and mapped to the review basisInspect source evidence and continue review
Partly analysedSome pages or fields are available; coverage is limitedIdentify the missing scope and verify it manually
Failed analysisThe workflow could not produce reliable structured textOpen the original document or request a supported replacement
Missing documentNo source was supplied for that materialRecord the gap and follow the approved clarification path

What should a reviewer do first?

Use this five-minute triage before reading a candidate outcome:

  1. Open the source file. Confirm that the file exists, can be opened, and contains the pages or sections expected from the application.
  2. Check the failure scope. Note whether the problem affects the whole document, a page, a table, a language segment, or only one application attachment.
  3. Separate unavailable from negative. Replace statements such as “does not have forklift experience” with “forklift experience not evidenced in the available text” until a person verifies the source.
  4. Choose a proportionate route. Retry once when the product documents a safe retry; otherwise send the item to manual review or request clarification through the recruiter-controlled process.
  5. Record the decision boundary. Keep the parser state, source checked, reviewer, and resulting human action visible to the team.

How should incomplete information appear in screening?

Do not collapse incomplete information into a single score or a negative status. For each approved requirement, show one of these states:

  • Supported: the source contains direct evidence that a reviewer can inspect.
  • Partial: relevant evidence exists but does not establish the complete requirement.
  • Not evidenced: the available material does not address the requirement.
  • Needs review: extraction, contradiction, or document quality prevents a reliable interpretation.

“Not evidenced” is a statement about the material currently available. It is not a statement about the person. A reviewer may decide that the gap is material, seek clarification, or continue with the evidence that is available; the product should not make that decision silently.

A practical fallback workflow

Apply this sequence to every failed or partial parse:

1. Preserve the original

Keep the submitted file and its provenance available to the authorised reviewer. Do not replace it with a copied text file that hides layout, tables, annotations, or missing pages.

2. Make the limitation specific

Record “page 2 table not extracted” or “PDF contains scanned images” rather than “candidate failed parsing”. Specificity tells the next reviewer what to check and avoids an inflated sense of certainty.

3. Retry only within a defined boundary

If a documented retry is available, use it once and retain the resulting state. Repeated retries can delay review without adding evidence. A retry that still fails should move to manual review, not to an automatic rejection or an invented completion state.

4. Verify requirement-level evidence

The reviewer should inspect the original document against the approved requirement. Record the excerpt, page or section, and whether the evidence is direct, partial, contradictory, or unavailable. Do not infer from a job title, filename, or formatting artifact alone.

5. Keep the human action explicit

Only an authorised reviewer should decide to progress, reject, request clarification, or close the application. A parsing status can inform that decision; it must not perform it.

Worked example: an image-only CV

An applicant uploads a scanned two-page CV. The parser returns a failed-analysis state. The reviewer opens the original and finds a clearly legible certificate and three years of relevant work, but cannot verify the dates in one blurred table.

The correct record is: “Certificate and role evidence verified from pages 1–2; dates in table need clarification.” The reviewer can request the missing dates or continue according to the role’s approved policy. The incorrect record is: “Candidate does not meet the experience requirement because parsing failed.”

Run this test with synthetic or approved examples:

  • An image-only CV creates a visible failed or needs-review state.
  • The original file remains available to the authorised reviewer.
  • A partial parse identifies the missing page, field, or section.
  • A missing field is not converted into a negative requirement result.
  • A retry has a documented limit and does not loop indefinitely.
  • Manual verification records the source location and reviewer action.
  • No candidate status or message changes without an explicit human action.

Limitations and decision boundaries

No parser can recover information that is absent, illegible, or never supplied. Manual review can also be inconsistent if reviewers use different requirements or do not record what they saw. Keep the approved criteria, source excerpt, uncertainty, and human action together so another reviewer can understand the decision.

Organisations remain responsible for their recruitment process, candidate information, accommodations, retention, and decisions. A fallback workflow is a control for uncertainty; it is not a guarantee of fairness, accuracy, or legal compliance.

Skilltage guidance: AI-assisted extraction should remain separate from human-selected candidate state. Use requirement-level evidence and visible document states to support review, while keeping progression, rejection, and candidate communication recruiter-controlled.

Next step

Take the last ten applications that needed a manual correction. For each one, record the source problem, the requirement affected, the evidence a reviewer used, and the final human action. Use the pattern to improve document guidance and fallback routing before adding a new automated rule.

Read the EU AI Act and the ICO recruitment-tool audit outcomes for external context. For related operational guidance, see how to use AI in CV screening without losing human control, how to align CV screening criteria with a hiring manager, and how to evaluate an AI recruitment tool.

References and provenance

Related resources

This is practical information, not legal advice. Skilltage supports human-reviewed decision support, not automated hiring decisions.

Want to see the workflow?

See how Skilltage keeps document states, requirement evidence, and human review actions visible in one workflow.

See evidence-first candidate review