100+ UK P60s vor dem 31. Mai
Eine Audit-Tabelle, keine manuelle Eingabe

Warum 100+ P60s ein grundlegend anderes Problem sind als ein einzelnes

Die Verarbeitung eines einzelnen P60 ist ein gelöstes Problem — seine Felder in Excel zu extrahieren erfordert Aufmerksamkeit, keine Werkzeuge. Sie öffnen das PDF, finden die gesetzlichen Felder, tippen sieben oder acht Zahlen in eine Zeile und machen weiter. Sobald jedoch Volumen ins Spiel kommt — 100 Mitarbeiter, drei Gehaltsabrechnungsanbieter, eine Handvoll ausgeschiedener Mitarbeiter aus übernommenen Firmen mit Papierzertifikaten — geht es nicht mehr um Geschwindigkeit, sondern um Struktur.

Für den Einzelzertifikatsfall reicht ein einmaliger P60-zu-Excel-Lauf; die unten genannten Probleme treten erst auf, wenn der Ordner groß genug ist, dass niemand mehr die Zeilen manuell prüfen kann.

Drei strukturelle Probleme treten bei 100+ Dokumenten auf, die bei Einzeldokumenten nicht existieren. Keines davon wird durch schnellere Dateiverarbeitung gelöst.

Jedes dieser Probleme lässt sich lösen, ohne für Mai zusätzliches Datenerfassungspersonal einzustellen. Die Lösung liegt in der Gestaltung des Batch-Workflows – von der Dateivorbereitung bis zum Spaltenschema – als wäre das Ergebnis keine Tabellenkalkulation, sondern ein Prüfprotokoll, das in sechs Monaten von jemandem gelesen wird, der die ursprünglichen Daten nicht erstellt hat.

Die Multi-Format-Realität: Sage ist nicht BrightPay ist kein 150-DPI-Scan

HMRC schreibt kein einheitliches P60-Layout vor. Vorgeschrieben ist der Inhalt: Gemäß Spezifikation RD1 muss eine Ersatz-P60 bestimmte Felder aufweisen – Name des Arbeitnehmers, NI Number, PAYE-Referenz, Gesamtvergütung des Jahres, insgesamt einbehaltene Steuer, Student Loan-Abzüge, endgültiger Steuercode und Arbeitgeberangaben – die visuelle Anordnung bleibt jedoch jedem Lohnabrechnungssoftware-Anbieter überlassen. Das Ergebnis ist, dass sich eine P60 von Sage 50cloud strukturell von einer P60 von BrightPay unterscheidet, die sich wiederum von einer QuickBooks Online Payroll-P60 unterscheidet, die anders aussieht als eine Moorepay-P60, die wiederum anders aussieht als eine IRIS-P60. Und das ist noch bevor gescannte Papierkopien von Mitarbeitern ins Spiel kommen, die ihre Originale verlegt haben.

Traditionelle vorlagenbasierte Extraktion – bei der Sie Rechtecke um Felder auf einer Beispiel-P60 ziehen – löst dies, indem eine separate Vorlage für jeden Lohnabrechnungsanbieter erforderlich ist. Fünf Anbieter pflegen, fünf Vorlagen pflegen. Ein Anbieter aktualisiert sein P60-Layout für das neue Steuerjahr – neue HMRC-Richtlinien, ein Rebranding, eine Formatänderung – und die Vorlage erzeugt stillschweigend falsch ausgerichtete Ausgaben. Die Lohnabrechnungsverantwortliche entdeckt dies erst, wenn der Abgleich nicht mit den FPS-Summen übereinstimmt.

Semantische Extraktion beseitigt das Problem der Vorlage-pro-Anbieter, indem sie das Dokument nach Bedeutung statt nach Position liest. Sie definieren die gewünschten Spalten einmal – „NI Number", „Total Pay for Year (£)", „Tax Deducted (£)", „PAYE Reference", „Final Tax Code" – und die KI lokalisiert jeden Wert auf jeder P60, indem sie versteht, was die Daten darstellen, nicht wo sie auf der Seite stehen. Eine Sage 50cloud-P60, eine BrightPay-P60, eine QuickBooks-P60 und eine gescannte Papier-P60 aus dem Jahr 2023 speisen sich in dieselben Spaltendefinitionen ein. Für eine ausführlichere Erläuterung der einzelnen Felder einer britischen P60 und wie sich jedes einzelne bei der Extraktion verhält, beginnen Sie mit dem Leitfaden zur Einzel-P60-Extraktion. Dieser Artikel knüpft dort an, wo jener aufhört: was passiert, wenn Sie aufhören, P60s einzeln zu betrachten.

Was dies im britischen Lohnabrechnungskontext besonders wertvoll macht, ist, dass die PAYE-Referenz – im Format 123/AB456 – über alle P60s desselben Arbeitgebers hinweg konsistent bleibt, unabhängig davon, welche Lohnabrechnungssoftware sie erstellt hat. Ein Unternehmen, das Sage für Festangestellte und BrightPay für Auftragnehmer einsetzt, wird P60s mit derselben PAYE-Referenz ausstellen, jedoch in zwei visuell unterschiedlichen Formaten. Semantische Extraktion liest den Wert, nicht das Layout. Die Spalte „PAYE Reference" in Ihrer Ausgabetabelle wird über beide Anbieter hinweg identisch befüllt und bietet Ihnen einen natürlichen Gruppierungsschlüssel für Multi-Provider-Batches.

Dateibenennung im großen Maßstab: Jede Zeile bis zu ihrer Quelle zurückverfolgbar machen

Die wichtigste Entscheidung mit der größten Hebelwirkung in einem Batch-P60-Workflow fällt, bevor Sie auch nur eine Datei hochladen: die Benennung der Quelldokumente. Wenn Ihre Ausgabetabelle 100 Zeilen hat und drei Monate später ein HMRC-Compliance-Beauftragter „die P60, die Zeile 47 zugrunde liegt" sehen möchte, darf die Antwort nicht „Ich muss die Tabelle mit meinem Downloads-Ordner abgleichen" lauten. Es muss ein Dateiname sein, den Sie sofort finden können.

Eine Namenskonvention, die der Audit-Rückverfolgbarkeit dient, umfasst drei Komponenten:

Das resultierende Dateinamensmuster – AB123456C_2025-26_sage.pdf – bettet den Audit-Trail direkt in den Dateinamen ein. Wenn Ihr Extraktionstool Dateinamen in der Ausgabe beibehält (ImageToTable.ai enthält standardmäßig eine Spalte „Dateiname" in Batch-Exporten), trägt jede Zeile in Ihrer Tabelle ihre eigene Herkunft. Kein externer Abgleich erforderlich.

Für Gehaltsabrechnungsteams, die Mitarbeiter über mehrere PAYE-Systeme hinweg verwalten – ein Umbrella-Unternehmen, das die Gehaltsabrechnung für 20 Kundenunternehmen durchführt, oder eine Gruppenstruktur, in der jede Tochtergesellschaft ihre eigene PAYE-Referenz hat – wird das PAYE-Referenzformat 123/AB456 zum natürlichen Batch-Gruppierungsschlüssel. Verarbeiten Sie alle P60s mit 123/AB456 in einem Batch, alle P60s mit 456/CD789 in einem anderen. Die PAYE-Referenzspalte in der Ausgabe jedes Batches dient als Dreh- und Angelpunkt, wenn Sie die beiden Tabellen später zusammenführen. Sie müssen nie raten, zu welchem Arbeitgeber eine Zeile gehört.

Ausgeschiedene, ehemalige Mitarbeiter und wer rechtlich eine P60 benötigt

Die HMRC-Regel ist eindeutig: Jeder Arbeitnehmer, der am 5. April des Steuerjahres in der Lohnabrechnung geführt wird, muss bis zum 31. Mai eine P60 erhalten. Das gilt auch für Arbeitnehmer, die im Laufe des Steuerjahres ausgeschieden sind – sofern sie am 5. April noch beschäftigt waren. Ein Arbeitnehmer, der am 30. März gekündigt und bis zum 4. April gearbeitet hat, erhält eine P60. Ein Arbeitnehmer, der am 31. März ausgeschieden ist, erhält keine. Die Unterscheidung ist wichtig, denn ein Fehler in beide Richtungen schafft ein Prüfungsrisiko.

Bei einer Charge von 100 P60s fallen die Grenzfälle von Ausgeschiedenen in vier Kategorien – und jede Kategorie ändert, was Sie in die Charge aufnehmen und was Sie anschließend prüfen:

Die Prüfungsfalle ist nicht das Fehlen einer P60. Es ist das Ausstellen einer P60 für jemanden, der keine erhalten sollte, oder das Nichtausstellen einer P60 für jemanden, der eine erhalten sollte. Beide Fehler wirken sich auf Ihren FPS-Abgleich aus, und eine HMRC-Compliance-Prüfung gemäß Compliance Handbook CH40000 wird die Diskrepanz schneller aufdecken als Ihre Lohnabrechnungssoftware.

Die praktische Absicherung besteht darin, eine abgeleitete Spalte hinzuzufügen – „P60-Status“ – in der die KI jedes Dokument basierend auf seinem Inhalt klassifiziert. Werte wie „Aktiv am 5. April“, „Ausgeschieden nach dem 5. April“, „Duplikat Vorjahr“ und „Keine P60“ ermöglichen es Ihnen, die Ausgabe vor dem Abgleich zu sortieren und Zeilen zu markieren, die überprüft oder ausgeschlossen werden müssen. Eine Spalte in der Extraktion spart die Stunde manueller Gegenprüfung, die sonst anfallen würde.

Prüfbereite Spalten für eine Tabelle mit 100 Zeilen gestalten

Die Spaltennamen, die Sie vor dem Hochladen eines Batchs festlegen, sind die folgenreichste Entscheidung im gesamten Workflow. Ein für einen Test-Batch mit fünf Mitarbeitern ausgelegtes Spaltenschema versagt bei 100 Zeilen oft, weil es volumenbedingte Grenzfälle nicht berücksichtigt – doppelte NI-Nummern über PAYE-Schemata hinweg, Steuerklassen, die sich im Laufe des Jahres geändert haben, oder Studentendarlehensabzüge, die auf mehrere Pläne aufgeteilt sind.

Ein Spaltenschema, das eine Prüfung mit 100 Zeilen übersteht, basiert auf drei Spaltentypen, die jeweils eine bestimmte Funktion in der Ausgabe erfüllen:

Für Lohnabrechnungsteams, die P60s über mehrere Arbeitgeber hinweg verwalten, dient eine Spalte „PAYE-Referenz“ gleichzeitig als Batch-Gruppierungsschlüssel und als Abgleichspivot. Filtern Sie die Ausgabe nach PAYE-Referenz, summieren Sie die Spalten „Gesamtvergütung“ und „Insgesamt einbehaltene Steuer“ und vergleichen Sie die Ergebnisse mit den Gesamtwerten der P35 (jährliche Arbeitgebererklärung) jedes Arbeitgebers. Die KI muss das Format einer PAYE-Referenz nicht verstehen – sie liest die Zeichenfolge, wie sie erscheint, und da britische PAYE-Referenzen ein einheitliches NNN/XXNNNNN-Muster verwenden (PAYE20005), ist die Ausgabe von Natur aus sortier- und filterbar.

Der Umgang mit Steuercodes verdient bei der Batch-Verarbeitung besondere Aufmerksamkeit. Der standardmäßige cumulative Steuercode für 2025-26 ist 1257L — was den persönlichen Freibetrag von £12.570 widerspiegelt — aber die Batch-Verarbeitung zeigt, wie viele Abweichungen vom Standard bei 100 Mitarbeitern auftreten. Ein Mitarbeiter mit einem K-Code (Gesamtabzüge übersteigen die Freibeträge) hat eine grundlegend andere steuerliche Behandlung als jemand mit 1257L. Ein Mitarbeiter, dessen P60 einen BR-Code (Basic Rate) zeigt, wurde wahrscheinlich auf einer zweiten Einkommensquelle besteuert. Ein Mitarbeiter mit NT (No Tax) hat möglicherweise ein P85 beim HMRC eingereicht, das den Nicht-Wohnsitz bestätigt. Fünf Mitarbeiter mit 1257L und einem „X"-Suffix wurden auf eine nicht-kumulative Basis (Monat 1) gestellt — was bedeutet, dass ihre Jahresbeträge möglicherweise keine Ganzjahresberechnung darstellen. Eine Spalte namens „Final Tax Code" macht all dies sichtbar. Eine zweite, berechnete Spalte namens „Tax Code Type" — in der die KI jeden Code als „Cumulative", „Non-Cumulative", „BR/D0/D1" oder „K Code" klassifiziert — verwandelt eine Tabelle mit Codes in eine Tabelle mit Steuersituationen, die mit einem Klick filterbar ist.

Zusammenführen von P60-Daten über mehrere Arbeitgeber und Steuerjahre

Die Batch-Extraktion erzeugt eine Tabelle pro Batch. Ein Gehaltsabrechnungsteam, das P60s über drei PAYE-Schemata verwaltet — jedes mit einer eigenen Referenz im Format 123/AB456 — erhält am Ende drei Tabellen. Der Merge-Schritt ist der Punkt, an dem sich das strukturelle Design Ihrer Extraktionsspalten auszahlt oder scheitert.

Wenn jeder Batch dieselben Spaltennamen verwendet — „NI Number", „Employee Name", „PAYE Reference", „Tax Year", „Total Pay for Year (£)", „Total Tax Deducted (£)" — lassen sich die drei Tabellen ohne Spaltenzuordnung vertikal stapeln. Die Spalte „PAYE Reference" in jeder Tabelle identifiziert, zu welchem Arbeitgeber jede Zeile gehört, sodass die zusammengeführte Tabelle nach PAYE-Referenz pivotiert werden kann, um Summen pro Arbeitgeber zu erzeugen. Das ist der gesamte Zweck der Standardisierung von Spaltennamen über Batches hinweg: Merge wird zu einem Anhängevorgang, nicht zu einer Spaltenzuordnungsübung.

Für die übergreifende Workflow-Frage — Dateiorganisation, Wahl des Batch-Ansatzes und Strukturierung der Ausgabe für die weitere Verwendung — der vollständige Batch-OCR-Workflow-Leitfaden behandelt Dateivorbereitung, Tool-Auswahl und Ausgabestrukturierung über mehrere Dokumenttypen hinweg. Das hier beschriebene P60-spezifische Spaltenschema fügt sich in diesen allgemeinen Rahmen ein.

Ein merge-spezifischer Sonderfall: Ein Mitarbeiter, der in zwei Batches mit derselben NI Number, aber unterschiedlichen PAYE-Referenzen erscheint. Das ist kein Fehler — es handelt sich um einen Mitarbeiter, der im selben Steuerjahr zwei Jobs hatte. Die P60 von Arbeitgeber A zeigt Einkommen und Steuern für ein Beschäftigungsverhältnis; die P60 von Arbeitgeber B zeigt Einkommen und Steuern für das andere. In einer zusammengeführten Tabelle sollten diese beiden Zeilen nicht aggregiert werden. Die Spalte „PAYE Reference" verhindert, dass Sie zwei P60s summieren, die separate Beschäftigungsverhältnisse darstellen. Ohne sie erzeugt eine naive SUMME von „Total Tax Deducted (£)" einen Wert, der weder mit der P35 des einen noch des anderen Arbeitgebers übereinstimmt — und eine HMRC-Abstimmung, die nicht aufgehen wird.

FAQ: Stapelverarbeitung britischer P60-Formulare