The Parse-Clean Resume Standard, One Row per Field the Portal Autofills

This standard is for anyone uploading the same resume file to dozens of company portals in one week. It turns "parse-clean" into six field-level pass conditions and a pre-submit test of about 20 minutes. The test ends in a verdict that two graders would reach on their own. Fix the file once against it and you stop retyping garbled titles and dates on every application.

What does "parse-clean" mean for a resume file?

A resume file is parse-clean when a portal's parser puts your contact details and every title, employer and date into the matching form fields, in order, with nothing dropped, merged or misplaced. Whether a file is parse-clean depends on both the file and the portal. You grade it with the file's plain text and the portal's own preview, not with a third-party score.

Terms used throughout:

• Parser: the part of the portal that reads your uploaded file and pulls its text out into structured fields.
• Autofill: the step where the portal fills in its application form from the parser's output. You can usually edit the result before submitting.
• Triple: one title, one employer and one date range that belong together. Each role on your resume is one triple.
• Field map: your own list of every triple exactly as it appears in the source file. It is the answer key you grade the portal against.
• Parse preview: the autofilled application form the portal shows you before you submit.
• Plain-text extraction: all of the file's text copied into a plain-text editor. It shows the reading order a machine is likely to see.

Why not just use a checker score? The checker tools that rank in search each hand out one opaque number, and they disagree with each other about what the major portals extract. A score can't tell you which field broke. A row can. This standard has six rows, and each one passes or fails.

What this standard does not claim: no published protocol has tested whether two graders using a resume checklist reach the same verdict. Agreement here comes from the pass conditions themselves (exact string matches, month-level dates, file sizes read from file properties), not from a study. If you adopt it as team policy, have two people grade the same five files and compare results before you rely on it.

What does each portal say it fills, and what does it never fill?

Only two of the four major portals document anything specific. Workday publishes a list of fields its parser never fills, and Greenhouse publishes the causes of failed parses and its parse size limit. Everything about Lever and iCIMS comes from secondary summaries of their help content.

Fields filled and never filled

Size limits and failure behaviour

Three things follow from these tables.

1. Workday leaves Skills and Languages blank by design. Workday's admin guide page "Concept: Resume Parsing" says the parser does not auto-fill Skills, Languages, or any field the employer sets as hidden. No change to your file will fill them. The standard marks those rows "manual, always" instead of pass or fail.
2. Greenhouse can accept a file it will not read. Its upload limit is 40 times its parse limit. A file between 2.5 MB and 100 MB uploads successfully and fills nothing.
3. A Greenhouse parse can half-work. Greenhouse's "Unsuccessful resume parse" page says a parse can be partially successful: it fills some information and skips the rest. A partial parse looks like a success unless you count fields.

Workday is also reported to say that parsing results vary with resume format and word order. That is the closest any vendor comes to saying that layout changes what lands where.

Which portal should a volume applicant grade against first?

Grade against Workday first. In Refolk's index of professional profiles, US recruiters list Workday as a skill 4.4 times as often as Greenhouse. A volume applicant will therefore meet Workday's parse, with its blank Skills field and its lock after submission, more often than any other.

The counts are profiles in Refolk's index with Recruiter or Talent Acquisition titles, filtered by which portal they list as a skill. The ratios are worked out from those counts. Read this as skill tagging, not market share: it tells you which systems recruiters say they work in, not how many postings each system hosts.

The employer mix points the same way. In the sampled US Workday profiles, employers include Boeing, Lifepoint Health, San Diego State University and C&S Wholesale Grocers, which is enterprise, health and public-sector hiring. The Greenhouse sample includes Meta, Palo Alto Networks and YETI. If your target list leans toward large employers, hospital systems or universities, expect Workday on much of it.

The UK count is small (19 profiles), so I would not draw conclusions about which portals UK employers use from it. As you apply, note which system each application runs on and tally your own list. Your own target list is the sample that matters.

The six pass criteria, one row per parsed field

A file passes this standard only when all six criteria pass. One failure fails the file. Each row below names the field, the condition that counts as a pass, and the check that proves it.

Two more rows are never graded. On Workday, Skills and Languages are "manual, always": you type them on every application.

Contact block

• Pass: name, email and phone sit in the body of the page and are the first lines of the plain-text extraction.
• What it proves: the parser has a reliable anchor for your candidate record. In Greenhouse's recruiter-side bulk import, a resume with no identifiable email fails to attach at all, which shows how much weight the email carries.
• How it lies: contact details in a header, footer or text box can still show up in your extraction and then get skipped by the portal. Greenhouse lists contact details in those zones as a cause of failed parses. Move them into the body even if the extraction looks fine.

Title-employer-date triples

• Pass: the number of triples in the preview equals the number in your field map, and every one matches exactly.
• What it proves: your work history landed as separate roles, not as one merged block or a list with an employer missing.
• How it lies: a partial parse fills four of five roles and looks complete at a glance. Greenhouse's guidance names company names without an identifier such as "Inc." as a cause of trouble. Count the triples. Don't skim them.
• Nested promotions: no vendor documents what its parser does with two titles at one employer under a single date range. Give each title its own dates so every triple is complete whatever the parser does.

Section boundaries

• Pass: in the extraction, each heading (Experience, Education and the rest) starts a fresh block, and no role text appears under Education or the other way round.
• What it proves: the parser can tell where your work history ends. Greenhouse lists "no clear sections" as a cause of failure.
• How it lies: headings made as graphics or word art disappear from the extraction while the page still looks neatly sectioned. If a heading is missing from the plain text, the parser can't see it either.

Reading order

• Pass: the extraction reads contact, then each role in order, then education, with no lines from one section mixed into another.
• What it proves: to a machine, the file is effectively single column. Greenhouse lists columned layouts and tables as causes of failure.
• How it lies: a two-column design reads fine to you. One practitioner write-up gives the tell: if your email appears after your skills section in the plain text, you have found the column problem.

Links

• Pass: every URL you want read (portfolio, profile, code host) appears in the extraction as the full address, not just as link text.
• What it proves: the address survives as text, which is the only form a parser is sure to have.
• How it lies: a word like "Portfolio" with a hyperlink behind it shows up as just "Portfolio" in plain text. No vendor documents how its parser handles embedded hyperlinks, so this row relies on the extraction alone.

File limits

• Pass: file properties show under 2.5 MB, text highlights with the cursor on every page, and the file holds exactly one resume.
• What it proves: the file is under the strictest published parse limit (Greenhouse's) and contains real text. Lever's reported test: if you can't highlight the text with your cursor, it is likely not parseable.
• How it lies: the upload succeeds, which feels like a pass. It isn't (see failure mode 2 below). Text with spaces between the letters, such as a letter-spaced name, highlights fine, but Greenhouse lists it as a cause of failed parses.

Format is rarely the problem. Lever reportedly parses Microsoft Word (including .docx), PDF, RTF, Corel WordPerfect, HTML, MS Office HTML and OpenOffice files. Images are the problem: Greenhouse lists a resume uploaded as an image as a cause of failure.

One resume per file: SAP SuccessFactors' recruiter-side Mass Upload fails when one file contains more than one resume. Don't put several versions in one document.

How to run the parse test before each upload

Run the file checks once for each version of the file, then the preview checks once for each portal. The full sequence takes about 20 minutes for a new file and 5 to 10 minutes per application after that.

Why this order? Some guides run the plain-text test after uploading. Running it first is cheaper. A layout problem found in a text editor costs one edit. The same problem found in a preview costs a retyped form on every portal until you fix the file.

Lever reportedly has no preview for candidates (unverified). If there is no preview, step 5 can't be done, and the extraction and file checks have to carry the whole verdict.

PARSE-CLEAN GRADING SHEET
File: ____________  Version date: ________  Size (MB): ____
Portal: ____________  Grader: ____________

FILE CHECKS (once per file version)
[ ] Under 2.5 MB (from file properties, not the upload screen)
[ ] Text highlights on every page
[ ] Exactly one resume in the file
[ ] Extraction order: contact > roles > education, nothing interleaved
[ ] Every section heading present as text
[ ] Every URL present in full

FIELD MAP (source file)                 PREVIEW (portal)                RESULT
# | Title | Employer | MM/YYYY-MM/YYYY  | Title | Employer | Dates      | PASS/FAIL
1 |       |          |                  |       |          |            |
2 |       |          |                  |       |          |            |
3 |       |          |                  |       |          |            |
Triples in source: __   Triples in preview: __   (must be equal)

CONTACT   Name [ ]   Email [ ]   Phone [ ]   (exact match)
WORKDAY   Skills typed [ ]   Languages typed [ ]   Stale rows cleared [ ]

VERDICT: PASS only if every graded row passes.   PASS / FAIL
Failed rows and the fix made: ______________________________

If you tailor your resume for each posting, the field map is the part to protect, because every new version is a chance for a title or date to drift. Refolk writes each tailored version from the same underlying history, so the triples come from one record and aren't retyped per version, and one field map can grade them all. Run the extraction on each new file anyway, since layout can still shift between versions.

How this goes wrong: false passes and grader splits

Most failures under this standard are false passes. The grader sees something that looks like success and marks the row without checking the field that actually matters. Seven failure modes come up again and again.

1. Passing the Skills row on Workday

• Looks like: the grader sees a full skills section in the file and assumes it was parsed.
• Check: the Skills field on the portal form itself. The Workday parser never fills it, so it is "manual, always", and it is blank until you type in it.

2. Checking size against the wrong number

• Looks like: a 3 MB file uploads to Greenhouse and shows success, but none of its fields are parsed.
• Check: file properties under 2.5 MB, plus the parse message. Greenhouse's failure message says the resume has only been attached to the candidate.

3. Clean plain text, dropped fields

• Looks like: the extraction reads perfectly, yet the portal skips your contact details.
• Check: contact details must sit in the body, not in header or footer zones. The extraction can pick up text the portal ignores.

4. Treating a partial parse as success

• Looks like: the form fills in, so the grader moves on. In Greenhouse's own guidance, company names without an identifier can drop employers.
• Check: count parsed triples against source triples. Unequal counts fail the row, even if every triple that did appear matches.

5. Nested promotions

• Looks like: one employer with two titles and a single date range. No vendor documents how it parses this.
• Check: whether the preview shows one role or two. Fix the source by giving each title its own dates, then retest.

6. Stale pre-filled data

• Looks like: on a returning visit, the old profile merges with the new upload, so last year's rows sit beside this year's.
• Check: on Workday tenants, clear the pre-filled rows before comparing the preview with the field map.

7. Grader disagreement

• Looks like: one grader passes "Sr. Product Manager" against "Senior Product Manager" and the other fails it.
• Fix: pass only on an exact string match, with dates at month precision. If the file and the preview disagree, the preview gets corrected. The rule is not loosened.

What can still be fixed after you submit?

On Workday tenants, usually nothing you can fix yourself. Employers running Workday publish statements such as "You cannot change your application after submission," so the preview is the last point where a parse error is still yours to fix.

Withdraw-and-reapply rules differ by employer, even on the same platform. HCPSS tells candidates to withdraw and reapply if the posting is still open. Ohio State says that once you withdraw, you cannot reapply for the same position. Read the employer's own careers FAQ before withdrawing to fix a parse error. On the wrong tenant, a withdrawal turns a typo into a lost application.

The safest route after submitting is the one UW-Madison describes: a recruiter updates the application on your behalf. Whether candidates can edit after submitting on Greenhouse, Lever or iCIMS is not publicly documented, so assume they can't until the form shows you otherwise.

Subject: Correction to my submitted application, [Job title], [Requisition ID]

Hello [Recruiter name],

I applied for [Job title] ([Requisition ID]) on [date]. After submitting, I noticed that the portal's resume parse put some of my work history in the wrong fields. Candidates can't edit a submitted application, so I'm writing to ask whether you could correct it on your side, or tell me how you'd prefer I handle it.

Corrections:
- Role [n]: shown as "[parsed title], [parsed employer], [parsed dates]". Should read "[title], [employer], [MM/YYYY to MM/YYYY]".
- [Field name]: shown as "[parsed value]". Should read "[correct value]".

The attached resume file is correct and matches these values. Thank you for your time.

[Name]
[Email] | [Phone]

Keeping the standard current

Use the checklist below as the final gate for each file version and each portal. Re-check the two primary vendor pages whenever a portal starts behaving differently from what this standard predicts.

How to keep it accurate over time:

• Re-read the primary pages, not the checker tools. Workday's "Concept: Resume Parsing" is the only published never-filled list, and Greenhouse's "Unsuccessful resume parse" is the only published list of failure causes. If either changes, update the matching rows. Pages in search results disagree even on Greenhouse's limit: one notes that competitors quote 5 MB and 2 MB, and neither figure appears in Greenhouse's documentation.
• Treat secondary claims as hypotheses. The Lever upload limit and the lack of a Lever preview both come from secondary summaries. Confirm them the next time you apply through Lever, and record what you saw.
• Re-grade when the file changes, not when the posting changes. The file checks apply to a file version. A new layout, template or export means a new verdict.
• Ignore numbers without a method. A widely repeated "34% Workday error rate" has no methodology behind it. Don't build decisions on it.

Parsing affects more than form-filling. Greenhouse documents that its Talent Matching feature requires resume parsing, so a file that is only attached gives that feature nothing to work with. Once a file passes, keep it as the base for every tailored version. If you generate those versions in Refolk, grade the first one fully and spot-check the triple count on each one after it, so the work stays a one-time fix and not a cost on every application.