You apply through German employer portals whose insides you never get to see. We send our CV templates through three commercial parsing engines — the same technology that sits inside the applicant tracking systems German employers run. We check ATS compatibility continuously and adjust the templates as soon as a measurement finds something. This page carries both halves: what we can prove, and what we cannot.
One email address in a narrow sidebar column, three commercial engines. This is how it arrived in each data set:
The number sits in almost every English-language guide on the subject, usually without a source. Here’s where it comes from.
The most-quoted figure in English-language job-search advice — with no study behind it
The real risk is quieter: your data arrives damaged, and nobody notices.
No system throws you out for using two columns. But if your email address lands incomplete in the data set, nobody can reply to you — and the recruiter does not see a defect, only an applicant who never got back to them. That is the class of damage we measure.
They buy it in — and largely from the same supplier. In the German-speaking core market, six of the nine systems we checked work with Textkernel; the international suites you will also meet here run partly on other engines, partly on their own build. You upload into these portals without ever seeing what happens next. This is the part you can see: every row carries its public source, and you won't find this list in any comparison article.
SuccessFactors reads with Textkernel by default — RChilli is installable as an add-on module. With Oracle it is exactly the other way round. So two companies on the same HR system can read your CV with different technology.
For you that has one practical consequence and one reassuring one. The practical one: “optimise separately for each system” does not work, because you don’t reliably know the system. The reassuring one: if you apply to ten companies, you’ll statistically land on the same software more than once — so one cleanly built document works more than once.
The errors arise in the document, not in the systems of these vendors. We are not grading any of them here.
A narrow sidebar column forces long values onto two lines. For you it’s invisible — in the PDF everything is right there in full. For a parser it is the most expensive line break in the whole document. That is what we provoke and measure. The table shows the hardest case we measured: one and the same address, broken at the hyphen, read by three engines. The sheet beside it shows, on one of our templates, what such a break point looks like. How we keep it out in daily operation is in section 05 — and where a break is allowed to stay, in section 07.
| Engine | Value received | Type of error |
|---|---|---|
| Engine A | [email protected] | hyphen swallowedlooks valid |
| Engine B | aarav@patel | cut off at the line breakincomplete |
| Engine C | (no value) | field discarded entirelyempty |
Engine A, B and C are three commercial parsers from exactly this market. Which engine sits inside which applicant tracking system is in the map above — and we deliberately attach no names to the measured values here.
The first case is the most expensive one. The address is syntactically valid and factually undeliverable: the recruiter cannot reply to you, and nobody finds out why. Phone numbers, by the way, arrived correctly everywhere — it hits the longest field in the narrowest container.
And before anyone reads this as a vendor comparison: none of the three comes off well here, and none of them is to blame either. The break sits in the document, the engines merely deal with it differently. One configuration and one snapshot are far too thin to grade a vendor.
A torn profile URL does not only cost its own field. It contaminates name detection: one engine read the first name out of a fragment of the LinkedIn URL instead of out of the document header.
The “Lin” comes from linkedin.com/in/… — the document was visually correct and unchanged. So a single break in the wrong place can spoil several fields at once.
The measurement isn’t designed as marketing but as a check on our own templates, and it runs continuously: the classes of error it makes visible run as blocking tests on every change. Here is what that looks like in practice.
A PDF stores text in the order it is drawn, not in the order you read it. With two columns, the two interleave. Our templates write the text stream in reading order: between the start of the document and the detected name there are 9 positions, not the 516 you get from naive drawing order
Email address and profile URL are set so that they do not wrap — with two documented exceptions, which are in section 07
The wrap check runs as a blocking test on every change and fires in both directions: on a new break just as much as on an expected one that suddenly disappears
If your addresses are too long for a narrow sidebar, the studio tells you while you are designing — and offers the single-column layout instead
That’s why we trust no badge — we see for ourselves what a measurement turns up.
Anyone who has never put their templates in front of real engines has never had the chance to find their own errors either. A seal without a published method says nothing about whether anyone ever looked.The most credible part of a measurement is the part where you turn out to be wrong. Two of our own assumptions did not survive it — and with only one engine, neither would ever have shown up.
“A break only hurts at the hyphen and at the dot, not at the @ sign”
We built a variant that breaks exactly there — and it got worse. One engine then returned no email field at all and additionally invented a website address out of the severed remainder.
Contact values must not break at all, no matter where.
“We have found two more defects in our templates”
A misread first name and torn job titles occurred with one engine only. The counter-check with the second read both correctly — they were quirks of that one engine, not document errors. The third then brought one of the two effects back after all.
A finding from a single engine is not a result, it is a hunch.
An “ATS-checked” badge based on a single tool says as much as a spelling test in a single language.
We've looked at what the common compatibility promises actually rest on. They fall into three patterns — and none of them contains measurement data.
“ATS-optimised templates”, “easier for an ATS to read” — no method, no data, no check anyone could follow
An in-house checker with “30 checks” that “reads like an ATS” — measured against an imitation, not against a real engine
Tested against unnamed parsers, without names, without method, without numbers — and partly disproven by third parties already
“When you submit your CV for a job, the ATS does not score it. The match rate in our own scanner is a visualisation tool.”From the disclaimer of one of the largest score providers · paraphrased
That’s remarkably candid — and it devalues the entire score category. There is no points total your CV achieves at the employer. There are only fields that arrive and fields that do not.
Without this section, this page would itself be just a claim. Three things we cannot evidence, and one loose end stays open in our own product.
The most popular question is: “does the system recognise my heading as work experience?” None of the three engines returns a section model for German-language documents — those fields stayed empty across all twelve German-language templates and were only populated for the English-language ones. So for the German market we can’t answer the question, and we don’t pretend to.
If you apply in English, that difference is real and in your favour: the same engines do produce a section structure for English documents. What a company then does with that structure is the next limit below — and it is not something we measured.
What a company does with the extracted data — filter, sort, rank — is a different layer and configured differently in every organisation. This measurement says nothing about it.
Default configuration, one test persona per template. Vendors change their models, and a different configuration can produce different results. Every single run against the engines is therefore a snapshot — the measurement PDF further down names the state it reflects.
On the four templates with a narrow sidebar, very long addresses do not fit on one line. In our test run that affects two of sixteen test profiles, each with addresses of around 39 characters. We deliberately decide against breaking the design for it: the look of those templates is the reason somebody picks them.
Instead, the studio tells you while you are designing that your address is too long for that sidebar — and offers you the single-column layout. You make the call, not us, and you make it beforehand rather than afterwards.
You need neither us nor a scoring tool for this, and no extra software either. Seeing your CV the way a machine reads it takes three steps you already know.
In whichever viewer you like — Preview, Acrobat or simply the browser
Ctrl + A, then Ctrl + C — on a Mac Cmd instead of Ctrl
Notepad, TextEdit, an empty document — anything without layout. What appears there is roughly what an applicant tracking system reads out of your file: your text stream, without the design
Is your email address there in one piece, or split across two lines?
Is your profile URL complete, including its very last character?
Does the content come column by column, or does it jump between columns?
Is your name at the very top, or does a fragment from the sidebar appear before it?
To be honest about it: this only imitates the simplest class of parser. Commercial engines additionally run a layout analysis and often assign columns correctly — so your copy-paste result tends to look worse than what arrives with them. But exactly the class of error this page is about — torn values in narrow columns — becomes visible this way. If everything is there cleanly and in a sensible order, you are on the safe side with the large majority of systems.
If you want to go deeper: the tool-based route — the same check on the command line — is in the measurement PDF further down. And if you want the practical rules for applying in Germany rather than the evidence behind them, they are in our guide on ATS in Germany.
The questions that keep coming up around ATS and CV parsing — answered with what we can evidence.
As a rule, yes. The popular rule “single column or it will not be read” is not what our measurement found in that severity: the engines with layout analysis assign columns correctly. The real risk is not the columns, it is the line breaks inside them — a narrow sidebar forces long values such as your email address onto two lines, and that is exactly where the errors happen. If you want a two-column design, make sure contact details stay on one line or sit in the wide column. Short addresses are more robust, and write profile URLs without the “https://www.” prefix — that saves twelve characters nobody needs.
The guide: do German companies use ATS?Going by everything that can actually be evidenced: almost never. Only around one per cent of companies in Germany let AI pre-sort applications. The much-quoted figure of 75 per cent of CVs being rejected goes back to a sales pitch from 2012, not to a study. The risk sits somewhere else: if your data arrives incomplete in the system, you will not be found in a search, or nobody can reach you. You are not filtered out, you are simply not findable.
Both work, as long as the text stays real text. A PDF saved as text is usually the safer choice because it protects your layout on the way. What matters is not the file format but what sits in the text stream — which is exactly what the self-check above shows you. The only genuine taboo is an image PDF or a scanned CV: there is no machine-readable text in those at all.
Mostly you don’t — and that matters less than it sounds. The domain of the application form often gives away the vendor, but the built-in engine is not necessarily the only one, and two companies on the same system can read with different technology. That’s why “optimise separately for each system” buys you little. What helps is a document whose values arrive complete in every engine.
Exactly as much as the method behind it — and that is almost never stated. In our own measurement we found two apparent defects that turned out, on the counter-check, to be quirks of a single engine. A badge based on one tool would have reported both as real errors. So don’t ask whether something was checked, ask with what, against what, and with what result.
Method, findings and limits as one coherent document — to pass on to colleagues, to use in career counselling, or to keep at hand when preparing your own applications.
Sharing welcome · cite with attribution
The same check this page documents runs on every change to our templates. You don’t have to think about text streams and line breaks — you only see the result.
Free to start · no credit card · servers in the EU