cvharbor editorial

Lebenslauf-Dateiformat: Was wirklich sauber ausgelesen wird

PDF und DOCX sind nicht zwei Varianten desselben Dokuments. Sie speichern Text auf unterschiedliche Weise, und genau dort verschwinden Lebensläufe im System. Was jedes Format enthält, wie drei verbreitete Bewerbermanagementsysteme damit umgehen, und welche Export-Einstellungen das Auslesen leise zerstören.

Eine .docx-Datei ist ein ZIP-Archiv aus XML-Dateien. Öffnet man sie mit einem Archivprogramm, findet man eine Ordnerstruktur: document.xml enthält den Text in Lesereihenfolge, versehen mit den zugewiesenen Formatvorlagen. Eine .pdf-Datei ist ein Seitenbeschreibungsformat: Sie speichert, wo jedes Zeichen auf einer festen Fläche gezeichnet wird, und die Textreihenfolge ist ein Nebeneffekt davon, wie das exportierende Programm diese Zeichenanweisungen geschrieben hat, keine Garantie. Aus diesem einen Unterschied folgt fast alles Weitere.

Was jedes Format tatsächlich enthält

DOCX speichert den Lebenslauf als strukturierten Text. Ein Parser öffnet das Archiv, liest document.xml und bekommt den Text in der Reihenfolge zurück, in der Word ihn geschrieben hat, inklusive Formatierung: was fett war, was eine Überschrift war, was in einer Tabellenzelle stand. Es gibt keine Unklarheit darüber, was als Text zählt, weil in dieser XML-Datei per Definition alles Text ist.

PDF speichert den Lebenslauf als Menge positionierter Zeichen. Eine sauber exportierte PDF aus Word, LibreOffice oder Google Docs enthält zusätzlich eine unsichtbare Textebene, die ein Parser ausliest. Eine gescannte oder abfotografierte PDF hat keine Textebene, sondern nur ein Bild von Zeichen, und ein Parser bekommt daraus nichts zurück, sofern nicht zusätzlich eine Texterkennung (OCR) läuft, was die meisten Bewerbermanagementsysteme beim Import standardmäßig nicht tun.

Was Personio, SAP SuccessFactors und Workday mit jedem Format machen

Diese drei Systeme decken einen großen Teil der Bewerberverwaltung im deutschsprachigen Raum ab, von mittelständischen Unternehmen bis zu internationalen Konzernen mit deutscher Niederlassung. Ihre öffentliche Dokumentation und Support-Hilfeseiten beschreiben ein ähnliches Grundprinzip mit unterschiedlicher Fehlertoleranz.

• Personio extrahiert Text aus der hochgeladenen Datei und speichert sowohl die Originaldatei als auch den extrahierten Text im Bewerberprofil. Recruiter durchsuchen den extrahierten Text, nicht die Originaldatei selbst; eine unlesbare Textebene bedeutet, dass die Bewerbung im System zwar vorhanden, aber praktisch unauffindbar ist.
• SAP SuccessFactors Recruiting nutzt einen internen Parsing-Dienst, der Felder wie Name, Arbeitgeber und Ausbildung in strukturierte Bewerberdaten überträgt. Bei komplexen Layouts mit mehreren Spalten oder Grafiken ist die Fehlerquote in der Praxis höher als bei einspaltigen Lebensläufen, ein Muster, das SAPs eigene Empfehlungen für Bewerberdokumente widerspiegeln.
• Workday, in Deutschland vor allem bei internationalen Konzernen im Einsatz, parst PDF und DOCX über denselben internen Dienst und zeigt der bewerbenden Person die ausgelesenen Felder zur Bestätigung vor dem Absenden. Der praktische Risikofall ist hier ein falsch oder leer ausgelesenes Feld, das vor dem Absenden übersehen wird, nicht eine automatische Ablehnung.

Keines der drei Systeme benachteiligt einen schlichten, einspaltigen Lebenslauf in PDF oder DOCX. Die Unterschiede zeigen sich nur an den Rändern: komplexe Layouts, unübliche Abschnittsnamen und Dateien ohne Textebene.

Word-Export-Einstellungen, die das Parsen zerstören

Ein in Word geschriebener Lebenslauf ist nach dem Export nicht automatisch sicher. Drei Einstellungen entscheiden, ob die Textstruktur beim Export erhalten bleibt.

1. Datei > Exportieren > PDF/XPS-Dokument erstellen, nicht Drucken > Als PDF speichern. Der Exportweg bettet eine echte Textebene mit Dokumentstruktur ein; manche Druckertreiber, besonders ältere oder herstellerfremde, rastern Teile der Seite stattdessen als Bild.
2. Kopf- und Fußzeilen. Diese liegen in Word in einem eigenen XML-Teil, getrennt vom Fließtext, und mehrere Parser lesen diesen Teil gar nicht mit. Kontaktdaten dort können für den Parser unsichtbar sein, selbst wenn die restliche DOCX-Datei sauber strukturiert ist.
3. Textfelder und SmartArt. Beide werden als frei platzierte Objekte gespeichert, verankert an einer Position auf der Seite statt im normalen Textfluss. Ein Jobtitel oder eine Skill-Liste in einem solchen Element kann von einem Parser, der den Fließtext der Reihe nach liest, komplett übersprungen werden.

Google Docs und LibreOffice: worauf es ankommt

Google Docs exportiert über Datei > Herunterladen > PDF standardmäßig eine saubere PDF mit Textebene, der zuverlässigere der beiden Exportwege für diesen Zweck.

• Der Download als Word-Dokument wandelt Google Docs' internes Format spontan in OOXML um, und mit Google's Tabellenfunktion erstellte Tabellen konvertieren gelegentlich mit zusätzlichen verschachtelten Zellen, die ein Parser als leere Felder zwischen den eigentlichen Inhalten liest.
• Mehrspaltige Layouts über Google Docs' native Spaltenfunktion (Format > Spalten) exportieren als echte PDF-Spalten, die spaltenweise von links nach rechts gelesen werden. Dasselbe Vermischungsrisiko wie oben beschrieben gilt hier, und tritt bei der Google-Docs-Spaltenfunktion häufiger auf als bei einem tabellenbasierten zweispaltigen Layout in Word.
• LibreOffice Writer exportiert über Datei > Exportieren als PDF standardmäßig eine PDF mit vollständiger Textebene und verhält sich in der Praxis ähnlich zuverlässig wie Word, mit derselben Einschränkung bei Textfeldern und frei platzierten Elementen.

LaTeX: sauberer Text, ungewöhnliche Struktur

Eine mit pdflatex oder xelatex kompilierte PDF bettet standardmäßig eine vollständige Textebene ein, das Problem "keine Textebene vorhanden" gescannter PDFs betrifft LaTeX-Dokumente also nicht. Das Risiko bei LaTeX-Lebensläufen liegt anderswo: verbreitete Vorlagen wie moderncv oder altacv bauen das Layout über absolute Positionierung mit Paketen wie tikz oder textpos auf, oder nutzen mehrspaltige Umgebungen. Solche Ansätze erzeugen eine PDF, deren interne Textreihenfolge deutlich von der visuellen Lesereihenfolge abweichen kann, weil LaTeX genau wie jedes andere Programm Zeichen an Koordinaten zeichnet. Eine schlichte, einspaltige Lebenslaufvorlage auf Basis der article-Klasse liefert eine deutlich zuverlässigere Textreihenfolge als eine zweispaltige Vorlage mit Seitenleiste.

Unser ATS-Check liest die Textebene Ihrer Datei genau so aus, wie es ein Bewerbermanagementsystem tun würde, und zeigt die Reihenfolge, in der der Text herauskommt. Lebenslauf prüfen

Welches Format am Ende zählt

Standardmäßig PDF, exportiert über den dedizierten Exportweg der Textverarbeitung statt über einen Druckertreiber. Sie behält das Layout überall bei, wo sie geöffnet wird, und eine korrekt exportierte PDF wird von allen drei genannten Systemen genauso zuverlässig ausgelesen wie DOCX. DOCX nur senden, wenn das Bewerbungsformular es ausdrücklich verlangt, etwa weil das Dokument intern noch mit Änderungsverfolgung weiterbearbeitet werden soll, nicht weil DOCX besser geparst würde.