How Resume Screening Software Reads Your CV

• A screening system does two things with your CV. It converts the document to plain text, then maps pieces of that text onto database fields: name, phone number, employer, job title, start and end dates, degree, skill. Almost everything that goes wrong goes wrong inside one of those two steps.

• Neither step involves judgment. The judging happens afterwards, when a recruiter searches those fields or a filter somebody configured runs against them.

Step one: your document becomes plain text

• Textkernel's parser documentation, written for the recruiting systems that call its API, [states the step plainly](https://developer.textkernel.com/tx-platform/v9/resume-parser/overview/parser-output/): the parser converts documents to plain text before analysis, and reports the length of that text back to the system that called it.

• Reading order therefore decides everything. Jobscan describes the failure precisely. Instead of finishing the contents of one cell before moving to the next, the parser slices horizontally across the whole page, so a job title from the left column lands beside an unrelated skill from the right. Running a design-heavy resume through one major system left [the skills section, the contact details and the work-sample links absent](https://www.jobscan.co/blog/resume-tables-columns-ats/) from the stored record.

• Greenhouse [accepts .doc, .docx, .pdf, .rtf and .txt](https://support.greenhouse.io/hc/en-us/articles/360052218132-Supported-formats-for-resumes-cover-letters-and-other-candidate-uploads) files up to 100 MB. Textkernel's documentation says essentially any resume format works and [compression formats do not](https://developer.textkernel.com/tx-platform/v10/faq/), so a zipped folder is the one upload guaranteed to arrive as nothing. The other guaranteed failure is an image: a scan, a photograph, or a PDF exported as a picture of a page.

Step two: the text becomes fields

• This is the half that most formatting advice skips. Textkernel's published parser output lists what the engine is trying to fill in.

• Contact information: name, phone numbers, email addresses, postal address, web addresses. Phone numbers are returned in three shapes, including a normalized one.
• Position history: job title, organization, employment dates and description, plus calculated metadata such as a normalized version of your title.
• Education: school name, degree type from high school through postdoctorate, school type, and whether you graduated.
• Skills: each one with how long you used it, when you last used it, and where it sits in a skills taxonomy.
• Licences and certifications, with issue dates and validity periods.
• Languages, both the language your document is written in and the ones you speak.

• That list is a specification for your CV. Every field on it is something a recruiter can search or filter, and a skill with no dates attached is a thinner record than the same skill sitting inside a dated role.

What the parser does with each element

• Santa Clara University's career center is the source for two of those rows: these systems [typically do not read headers and footers](https://www.scu.edu/careercenter/toolkit/job-scan-common-ats-resume-formatting-mistakes/), and custom headings such as Professional Journey or Core Competencies are the ones it tells students to drop.

Dates do more work than they look like they do

• The parser calculates from your dates as well as storing them. Textkernel's output includes normalized job titles, position identifiers, and for every skill the duration of use and the date it was last used. All of that is derived from the dates in your work history.

• Santa Clara's guidance names the exact mistake that breaks it: running Jun. 2020 to Present in one role and 2020/06 to Present in another, because inconsistent date formats lead to errors in parsing. Pick MM/YYYY or Month Year and hold it down the whole page.

What the parser does not do

• It decides nothing. Extraction produces a record, and a person decides what happens to the record.

• That decision is where candidates are actually lost. In the Harvard Business School and Accenture study [Hidden Workers: Untapped Talent](https://www.hbs.edu/ris/Publication%20Files/hiddenworkers09032021_Fuller_white_paper_33a2047f-41dd-47b1-9a8d-bd08cf3bfa94.pdf), more than 90 percent of employers said they use their recruiting system to initially filter or rank candidates, and 88 percent agreed that qualified high-skills candidates get vetted out because they do not match the exact criteria written into the job description. For middle-skills roles that figure was 94 percent.

• A clean parse puts an accurate record in front of that filter and has no influence on how the filter was set. [Why an ATS rejects qualified candidates](/spaces/why-ats-rejects-qualified-candidates) covers the setting, which is the part the employer controls and the part we think should change.

Read your own extracted text

• Open your CV, select everything, copy it, and paste it into a plain text editor. What appears is close to what the parser hands over.

• Check it against the field list above. Is your phone number in there? Do your job titles sit next to their own employers and dates? Does every role carry a start and an end in the same format? Is there a block of text whose heading has vanished?

• Whatever is missing from that text file is missing from the employer's database, and following up through the same form will not put it back. [ATS-friendly resume format](/spaces/ats-friendly-resume-format) has the layout rules that fix each failure, and [how to get past the ATS](/spaces/how-to-get-past-the-ats) covers the rest of the application.