Über 100 britische P60-Bescheinigungen bis zum 31. Mai
Eine Prüftabelle, keine manuelle Eingabe
Gemäß Regulation 67 der Income Tax (Pay As You Earn) Regulations 2003 (SI 2003/2682) muss jeder britische Arbeitgeber jedem am 5. April beschäftigten Arbeitnehmer eine P60 aushändigen – und die Frist zum 31. Mai ist gesetzlich festgelegt, nicht in der Lohnsoftware. Die P60 selbst ist nicht der Engpass. Sage 50cloud, BrightPay, QuickBooks Online, Moorepay und IRIS erstellen in Sekunden konforme Bescheinigungen. Der Engpass ist, was danach passiert: Jemand muss über 100 dieser PDFs – plus eingescannte Papierkopien von Mitarbeitern, die ihre verloren haben, plus Screenshots aus dem HMRC-Portal – in einer Tabelle zusammenführen, die vor Monatsende mit den Jahresmeldungen abgeglichen wird. Bei zwei Minuten pro Bescheinigung für den manuellen Workflow – PDF öffnen, Box 1 bis Box 6 finden, in eine Tabellenzeile übertragen – verbrennt ein Unternehmen mit 150 Mitarbeitern fünf Stunden des Mai-Lohnfensters mit reinem Kopieren und Einfügen. Und das unter der Annahme, dass niemand mitten im Jahr die Lohnsoftware gewechselt hat, keine Mitarbeiter im März ausgeschieden sind und keine eingescannte P60 mit 150 DPI angekommen ist.
Wichtige Erkenntnisse
- Nach britischem Recht muss jeder Arbeitgeber jedem Arbeitnehmer bis zum 31. Mai eine P60 ausstellen – und für ein Unternehmen mit 150 Mitarbeitern, das mehrere Lohnabrechnungsanbieter nutzt, bedeutet „einfach die PDFs öffnen und in Excel kopieren“ fünf Stunden reine Übertragungsarbeit im geschäftigsten Monat des Lohnkalenders.
- Der eigentliche Engpass bei 100 Dokumenten ist nicht die Dateiverarbeitungsgeschwindigkeit – es ist das Spaltendesign: ein Satz Identitätsspalten (SV-Nummer + PAYE-Referenz), ein Satz Finanzspalten (Gehalt, Steuer, Sozialversicherung) und ein Satz Prüfspalten (Steuerklassentyp, SV-Kategorieprüfung), die zusammen jede Zeile prüfbar und jede Tabellenzusammenführung zu einem einfachen Anhängen machen.
- Definieren Sie dieses Spaltenschema einmal, wenden Sie dieselben Namen auf jede Charge an, unabhängig von Lohnabrechnungsanbieter oder Steuerjahr, und das Zusammenführen von 100 Zeilen von Sage mit 50 von BrightPay wird zu einem vertikal stapelbaren Vorgang – keine Spaltenneuzuordnung, keine anbieterspezifischen Vorlagen, kein Rätselraten, welche Zeile zu welchem Arbeitgeber gehört.
Warum 100+ P60 ein grundlegend anderes Problem ist als eines
Die Verarbeitung einer einzelnen P60 ist ein gelöstes Problem — das Extrahieren ihrer Felder in Excel erfordert Aufmerksamkeit, nicht Werkzeuge. Sie öffnen das PDF, lokalisieren die gesetzlichen Felder, tippen sieben oder acht Zahlen in eine Zeile und machen weiter. Sobald jedoch Volumen ins Spiel kommt — 100 Mitarbeiter, drei Gehaltsabrechnungsdienstleister, ein paar ausgeschiedene Mitarbeiter aus übernommenen Firmen mit Papierbescheinigungen — wird aus dem Problem kein Geschwindigkeits-, sondern ein Strukturproblem.
Drei strukturelle Probleme treten im Maßstab von 100+ auf, die es im Einzeldokument-Maßstab nicht gibt. Keines davon wird durch schnelleres Verarbeiten von Dateien gelöst.
1. Layout-Unterschiede zwischen Anbietern
Eine Sage 50cloud P60 zeigt Mitarbeiterdaten linksbündig mit der PAYE-Referenz fettgedruckt unter dem Arbeitgebernamen. Eine BrightPay P60 trennt den Bereich der gesetzlichen Bescheinigungen durch einen umrandeten Kasten. Eine QuickBooks Online P60 druckt die NI-Nummer oberhalb des Mitarbeiter-Adressblocks statt neben dem Namen. Für einen Buchhalter, der manuell überträgt, erfordert jedes Layout ein erneutes visuelles Scannen — um zu lokalisieren, wo welches Feld in dieser spezifischen Anbieterdarstellung sitzt, bevor er etwas eintippt. Bei 100 P60s, verteilt auf drei Anbieter, kostet allein dieses erneute visuelle Scannen — etwa 10 Sekunden pro Dokument zur Neuorientierung — 15 Minuten Totzeit, bevor auch nur ein einziger Tastendruck für die Übertragung erfolgt.
2. Zeilenherkunft im Prüfungsmaßstab
Wenn Sie 100 P60s in 100 Tabellenzeilen extrahieren, muss jede Zeile auf genau ein Quelldokument und genau ein Steuerjahr zurückverfolgbar sein. Wenn die Ausgabetabelle eine Spalte für "Gesamtvergütung" mit 38.450 £ enthält, aber keine Spalte, die angibt, von welchem Mitarbeiter-P60 dieser Betrag stammt, ist die Tabelle eine Prüfungshaftung — kein Prüfungsvorteil. Bei HMRC-Compliance-Prüfungen kann ein Prüfer die P60 anfordern, die einer beliebigen Zahl in Ihrem Abgleich zugrunde liegt. Ohne eine in die Extraktion selbst eingebaute Quellrückverfolgbarkeit pro Zeile gleichen Sie Tabellenzellen manuell mit PDFs ab — was länger dauert als die ursprüngliche Extraktion.
3. Ausnahmebehandlung bei Volumen
In einem Batch von 100 P60s werden drei bis fünf Grenzfälle sein. Ein Mitarbeiter mit einem Week-1/Month-1-Steuercode, weil er ohne P45 mitten im Jahr angefangen hat. Ein Ausgeschiedener, der von Januar bis März gearbeitet hat — am 5. April beschäftigt und daher anspruchsberechtigt auf eine P60 — dessen Bescheinigung jedoch von einem Gehaltsabrechnungsdienstleister erstellt wurde, den das Unternehmen nicht mehr nutzt. Eine eingescannte Papier-P60 aus einer Übernahme von 2023, bei der die PAYE-Referenz zum übernommenen Unternehmen gehört, nicht zum aktuellen. In einem manuellen Workflow fangen Sie diese einen nach dem anderen ab. In einem Batch-Workflow wird jede übersehene Ausnahme zu einer falschen Zahl in einer Abgleichtabelle, die die HMRC prüfen kann.
Jedes dieser Probleme hat eine Lösung, die nicht darin besteht, für Mai mehr Datenerfasser einzustellen. Sie bestehen darin, den Batch-Workflow — von der Dateivorbereitung bis zum Spaltenschema — so zu gestalten, als ob das Ergebnis keine Tabelle, sondern ein Prüfungsnachweis ist, der sechs Monate später 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, sondern nur den Inhalt: Gemäß Spezifikation RD1 muss eine Ersatz-P60 bestimmte Felder enthalten – Name des Arbeitnehmers, NI-Nummer, PAYE-Referenz, Gesamtvergütung des Jahres, insgesamt einbehaltene Steuern, Studienkreditabzüge, endgültiger Steuercode und Arbeitgeberdetails – die visuelle Anordnung bleibt jedoch jedem Payroll-Softwareanbieter überlassen. Das führt dazu, dass eine P60 von Sage 50cloud strukturell anders aussieht als eine von BrightPay, die wiederum anders aussieht als eine von QuickBooks Online Payroll, Moorepay oder IRIS. Und das ist noch bevor man eingescannte Papierkopien von Mitarbeitern berücksichtigt, die ihre Originale verlegt haben.
Die traditionelle vorlagenbasierte Extraktion – bei der man Rechtecke um Felder auf einer Beispiel-P60 zeichnet – geht damit um, indem sie für jeden Payroll-Anbieter eine separate Vorlage erfordert. Fünf Anbieter verwalten, fünf Vorlagen verwalten. Aktualisiert ein Anbieter sein P60-Layout für das neue Steuerjahr – neue HMRC-Richtlinien, ein Rebranding, eine Formatierungsänderung – produziert die Vorlage stillschweigend falsch ausgerichtete Ausgaben. Der Payroll-Administrator bemerkt dies erst, wenn der Abgleich mit den FPS-Summen nicht aufgeht.
Semantische Extraktion löst das Problem der Vorlagen pro Anbieter, indem sie das Dokument nach Bedeutung statt nach Position liest. Sie definieren die gewünschten Spalten einmal – „NI-Nummer", „Gesamtvergütung des Jahres (£)", „Einbehaltene Steuern (£)", „PAYE-Referenz", „Endgültiger Steuercode" – und die KI lokalisiert jeden Wert auf jeder P60, indem sie versteht, was die Daten repräsentieren, nicht wo sie auf der Seite stehen. Eine Sage 50cloud P60, eine BrightPay P60, eine QuickBooks P60 und eine eingescannte Papier-P60 von 2023 speisen sich alle in dieselben Spaltendefinitionen ein. Für eine ausführlichere Erläuterung der einzelnen Felder einer britischen P60 und wie sie sich bei der Extraktion verhalten, beginnen Sie mit dem Leitfaden zur Einzel-P60-Extraktion. Dieser Artikel setzt dort an: Was passiert, wenn Sie aufhören, P60s einzeln zu betrachten.
Was dies im britischen Payroll-Kontext besonders wertvoll macht, ist, dass die PAYE-Referenz – im Format 123/AB456 – über alle P60s desselben Arbeitgebers hinweg konsistent bleibt, unabhängig davon, welche Payroll-Software sie erstellt hat. Ein Unternehmen, das Sage für Festangestellte und BrightPay für Auftragnehmer verwendet, wird P60s mit derselben PAYE-Referenz ausstellen, jedoch in zwei visuell unterschiedlichen Formaten. Semantische Extraktion liest den Wert, nicht das Layout. Die Spalte „PAYE-Referenz" in Ihrer Ausgabetabelle wird anbieterübergreifend identisch befüllt und bietet Ihnen einen natürlichen Gruppierungsschlüssel für Chargen mit mehreren Anbietern.
Dateibenennung im großen Maßstab: Jede Zeile bis zur Quelle zurückverfolgen
Die entscheidende Weichenstellung in einem Batch-P60-Workflow erfolgt vor dem Hochladen einer einzigen Datei: die Benennung der Quelldokumente. Wenn Ihre Ausgabetabelle 100 Zeilen hat und drei Monate später ein HMRC-Prüfer "die P60 zu Zeile 47" sehen möchte, darf die Antwort nicht lauten: "Ich muss die Tabelle mit meinem Download-Ordner abgleichen." Es muss ein Dateiname sein, den Sie sofort finden.
Eine Namenskonvention für die Prüfbarkeit umfasst drei Komponenten:
Mitarbeiterkennung
Die NI-Nummer ist der natürliche Primärschlüssel für britische Gehaltsabrechnungen – sie ist eindeutig, dauerhaft und erscheint auf jeder P60. Als Dateinamenspräfix dient sie als sofortiger Suchschlüssel: AB123456C verweist direkt auf HMRC-Datensätze. Falls NI-Nummern nicht verwendet werden dürfen (Datenschutzrichtlinie), nutzen Sie die Mitarbeiter-Payroll-ID – fügen Sie aber eine Zuordnungstabelle hinzu.
Steuerjahr
Eine P60 deckt das Steuerjahr vom 6. April bis 5. April ab. Der Dateiname sollte das Jahr kodieren: 2025-26 oder FY2526. Dies verhindert das häufigste Batch-Chaos – die Vermischung von P60s aus 2024-25 und 2025-26 im selben Ordner, weil jemand sie sechs Monate auseinander im gleichen Verzeichnis gespeichert hat. Bei der Batch-Verarbeitung mehrerer Steuerjahre in separate Tabellen ist das Jahr im Dateinamen der einzige Schutz vor Vermischung.
Anbieter- oder Quellkennung
Nicht zwingend für die Tabelle selbst, aber unverzichtbar beim Abgleich. Ein Dateinamenssuffix wie _sage oder _bp verrät Ihnen drei Wochen im Mai, wenn jemand fragt, warum Box 5 in Zeile 23 den FPS-Daten widerspricht, dass Zeile 23 aus BrightPay stammt – das möglicherweise einen bekannten Export-Rundungsunterschied aufweist. Eine Anbieterkennung verwandelt eine unerklärliche Abweichung in ein bekanntes Verhaltensmuster.
Das resultierende Dateinamensmuster – AB123456C_2025-26_sage.pdf – bettet den Prüfpfad direkt in den Dateinamen ein. Wenn Ihr Extraktionstool die Dateinamen in der Ausgabe beibehält (ImageToTable.ai fügt standardmäßig eine Spalte "Dateiname" in Batch-Exporten hinzu), trägt jede Zeile in Ihrer Tabelle ihre eigene Herkunft. Kein externer Abgleich nötig.
Für Gehaltsabrechnungsteams, die Mitarbeiter über mehrere PAYE-Systeme verwalten – eine Dachgesellschaft, die die Gehaltsabrechnung für 20 Kundengesellschaften führt, oder eine Konzernstruktur mit eigener PAYE-Referenz pro Tochter – wird das PAYE-Referenzformat 123/AB456 zum natürlichen Batch-Gruppierungsschlüssel. Verarbeiten Sie alle P60s mit 123/AB456 in einem Batch, alle mit 456/CD789 in einem anderen. Die PAYE-Referenzspalte in der Ausgabe jedes Batches dient als Dreh- und Angelpunkt beim späteren Zusammenführen der beiden Tabellen. 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:
Am 5. April beschäftigt – danach ausgeschieden
Erhält eine P60. Die Bescheinigung deckt das gesamte Steuerjahr ab und muss in die Charge aufgenommen werden. Das Feld „Endgültiger Steuercode“ zeigt den zum Jahresende aktiven Code, auch wenn der Arbeitnehmer im Juni ausgeschieden ist.
Vor dem 5. April ausgeschieden – keine P60
Erhält eine P45, keine P60. Wenn der Lohnabrechnungsdatensatz aufgrund eines veralteten HR-Systemexports noch in Ihrer Charge erscheint, muss er vor dem Abgleich ausgeschlossen werden – seine Daten unterliegen einer anderen Meldepflicht.
Ehemaliger Mitarbeiter beantragt Duplikat
Die HMRC verlangt, dass Arbeitgeber auf Anfrage Duplikate von P60s ausstellen. Ein ehemaliger Mitarbeiter, der seine P60 für 2023-24 für einen Hypothekenantrag benötigt, wird sich an Sie wenden – und seine Bescheinigung wurde vor zwei Jahren ausgestellt, möglicherweise von einem Lohnabrechnungsdienstleister, den Sie nicht mehr nutzen. Die P60 enthält weiterhin dieselben gesetzlichen Informationen, existiert aber möglicherweise nur als gescanntes PDF oder in einem archivierten Sage-Backup.
Mitarbeiter übernommener Unternehmen
Wenn Unternehmen A Unternehmen B im Oktober übernimmt, benötigen die Mitarbeiter von Unternehmen B, die am vorherigen 5. April in der Lohnabrechnung waren, weiterhin eine P60 – ausgestellt von Unternehmen A als Rechtsnachfolger, aber möglicherweise unter Bezugnahme auf das PAYE-Schema von Unternehmen B für die Monate vor der Übernahme. Die ausgestellte P60 kann die alte PAYE-Referenz, die neue oder beide enthalten, je nach Struktur des TUPE-Übergangs. Die Aufnahme dieser P60s in Ihre Charge mit einer eigenen Spalte „Vorherige PAYE-Referenz“ erfasst die Komplexität in einer Zeile.
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:
1. Identitätsspalten – der zusammengesetzte Schlüssel, der jede Zeile eindeutig macht
NI-Nummer, Mitarbeitername, PAYE-Referenz und Steuerjahr. Zusammen bilden diese vier Felder einen zusammengesetzten Schlüssel: Keine zwei Zeilen in Ihrer Tabelle sollten dieselbe Kombination aufweisen. Die NI-Nummer allein reicht nicht aus – ein Mitarbeiter, der im selben Steuerjahr für zwei PAYE-Schemata gearbeitet hat (häufig in Konzernstrukturen), hat zwei P60s mit derselben NI-Nummer, aber unterschiedlichen PAYE-Referenzen. Die Aufnahme der PAYE-Referenz in den Identitätsblock verhindert, dass diese Zeilen kollidieren.
2. Finanzspalten – die Zahlen, die mit der FPS abgeglichen werden
Gesamtvergütung pro Jahr (£), insgesamt einbehaltene Steuer (£), Arbeitnehmerbeiträge zur NI (£), Arbeitgeberbeiträge zur NI (£), Studentendarlehensabzüge (£), gesetzliche Zahlungen (£). Jeder dieser Werte muss der entsprechenden Zeile in Ihrer vollständigen Zahlungsmeldung (Full Payment Submission) für das Steuerjahr entsprechen. Der häufigste Abgleichsfehler bei der Batch-P60-Extraktion ist eine Diskrepanz zwischen Feld 2 (insgesamt einbehaltene Steuer) auf einer P60 und dem YTD-Steuerbetrag aus der letzten FPS – meist weil die P60 eine manuelle Steuerklassenanpassung enthält, die nach Einreichung der letzten FPS vorgenommen wurde.
3. Prüfspalten – berechnete Quervergleiche, die Anomalien vor dem Abgleich aufdecken
Diese Spalten erscheinen nicht auf der P60, werden aber während der Extraktion berechnet, um Unstimmigkeiten sichtbar zu machen. Eine Spalte „Steuerklassenprüfung“, die nicht standardmäßige Codes markiert – alles andere als kumulative Codes wie 1257L, BR, D0, D1 – zeigt Ihnen sofort, welche Zeilen manuell geprüft werden müssen. Eine Spalte „NI-Kategorieprüfung“, die alles andere als Kategorie A (die Standardkategorie für beschäftigte Arbeitnehmer ohne Vertragsausschluss) markiert, macht Mitarbeiter der Kategorien B, C, J oder Z sichtbar – jede mit unterschiedlichen Beitragssätzen, die auf eine besondere Lohnabrechnungsregelung hindeuten können. Diese Prüfspalten verursachen keinen zusätzlichen Übertragungsaufwand, da die KI sie während desselben Extraktionsdurchlaufs befüllt, der auch die Finanzzahlen ausliest.
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.
Die Behandlung von Steuerkennzahlen verdient bei der Batch-Verarbeitung besondere Aufmerksamkeit. Der Standard-Kumulativcode für 2025-26 ist 1257L – basierend auf dem persönlichen Freibetrag von £12.570 – doch die Batch-Verarbeitung zeigt, wie viele Abweichungen vom Standard bei 100 Mitarbeitern existieren. Ein Mitarbeiter mit einem K-Code (Abzüge übersteigen Freibeträge) hat eine grundlegend andere steuerliche Behandlung als einer mit 1257L. Ein Mitarbeiter, dessen P60 einen BR-Code (Basissteuersatz) zeigt, wurde wahrscheinlich auf eine zweite Einkommensquelle besteuert. Ein Mitarbeiter mit NT (Keine Steuer) hat möglicherweise ein P85 an das HMRC eingereicht, das den Nicht-Wohnsitz bestätigt. Fünf Mitarbeiter mit 1257L und dem Suffix "X" wurden auf eine nicht-kumulative Basis (Monat 1) gesetzt – das bedeutet, dass ihre Jahresbeträge keine Ganzjahresberechnung darstellen. Eine Spalte namens "Endgültiger Steuercode" fasst all dies zusammen. Eine zweite, berechnete Spalte namens "Steuercode-Typ" – in der die KI jeden Code als "Kumulativ", "Nicht-Kumulativ", "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 hinweg
Die Batch-Extraktion erzeugt eine Tabelle pro Batch. Eine Lohnbuchhaltung, die P60s über drei PAYE-Systeme verwaltet – jedes mit einer eigenen 123/AB456-Referenz – erhält drei Tabellen. Der Zusammenführungsschritt ist der Punkt, an dem sich das strukturelle Design Ihrer Extraktionsspalten auszahlt oder scheitert.
Wenn jeder Batch dieselben Spaltennamen verwendet – "NI-Nummer", "Mitarbeitername", "PAYE-Referenz", "Steuerjahr", "Gesamtvergütung für das Jahr (£)", "Gesamtabgeführte Steuer (£)" – lassen sich die drei Tabellen vertikal ohne Spaltenzuordnung stapeln. Die Spalte "PAYE-Referenz" 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 erhalten. Das ist der gesamte Zweck der Standardisierung von Spaltennamen über Batches hinweg: Zusammenführung wird zu einem Anhängevorgang, nicht zu einer Spaltenzuordnungsübung.
Für die übergeordnete Workflow-Frage – Organisation von Dateien, Auswahl eines Batch-Ansatzes und Strukturierung der Ausgabe für die Weiterverwendung – deckt der vollständige Leitfaden zum Batch-OCR-Workflow die Dateivorbereitung, Tool-Auswahl und Ausgabestrukturierung für mehrere Dokumenttypen ab. Das hier beschriebene P60-spezifische Spaltenschema fügt sich in diesen allgemeinen Rahmen ein.
Ein zusammenführungsspezifischer Sonderfall: Ein Mitarbeiter, der in zwei Batches mit derselben NI-Nummer, aber unterschiedlichen PAYE-Referenzen erscheint. Dies ist kein Fehler – es ist ein Mitarbeiter, der im selben Steuerjahr zwei Jobs hatte. Die P60 von Arbeitgeber A zeigt Einkommen und Steuern für eine Beschäftigung; die P60 von Arbeitgeber B zeigt Einkommen und Steuern für die andere. In einer Tabelle zusammengeführt, sollten diese beiden Zeilen nicht aggregiert werden. Die Spalte "PAYE-Referenz" verhindert, dass Sie zwei P60s summieren, die separate Beschäftigungen darstellen. Ohne sie würde eine naive SUMME der "Gesamtabgeführten Steuer (£)" einen Wert ergeben, der weder mit der P35 von Arbeitgeber A noch mit der von Arbeitgeber B übereinstimmt – und eine HMRC-Abstimmung, die nicht aufgehen wird.
FAQ: Stapelverarbeitung britischer P60-Formulare
Funktioniert die Stapelextraktion auch mit gescannten Papier-P60s?
Ja – die semantische Extraktion liest den Textinhalt des Dokuments, nicht seine digitalen Metadaten. Ein 150-DPI-Scan eines Papier-P60 von 2022 liefert dieselbe strukturierte Ausgabe wie ein digital erzeugtes Sage-PDF von 2026, sofern der Text lesbar ist. Die Extraktionsqualität hängt von der Scan-Schärfe ab, nicht davon, ob das Dokument digital entstanden ist. Stark schiefe Scans, niedrig aufgelöste Kopien und handschriftlich ergänzte P60s können eine geringere Genauigkeit aufweisen – in diesen Fällen markieren die Prüfspalten (Steuercode-Prüfung, NI-Kategorie-Prüfung) die Zeilen, die manuell überprüft werden müssen.
Was passiert mit P60s, die Studienkreditabzüge enthalten?
Britische P60s enthalten einen eigenen Abschnitt für Studien- und Postgraduiertenkreditabzüge (Plan 1, Plan 2, Plan 4 und Postgraduiertenkredit). Das HMRC-Standardformat trennt diese nach Planart. Definieren Sie eine Spalte pro Plan – „Studienkredit Plan 1 (£)“, „Studienkredit Plan 2 (£)“, „Postgraduiertenkredit (£)“ – anstatt einer einzelnen Spalte „Studienkredit (£)“. Ein Mitarbeiter, der sowohl Plan 1 als auch Plan 2 zurückzahlt, hat zwei Werte ungleich Null; eine einzelne kombinierte Spalte macht es unmöglich zu unterscheiden, welcher Abzug zu welchem Plan gehört – wichtig für den Abgleich mit den von HMRC ausgestellten SL1/SL2-Start- und Stoppmitteilungen.
Kann ich P60s aus mehreren Steuerjahren in einem Durchgang verarbeiten?
Technisch ja – die KI extrahiert Daten aus jedem P60 unabhängig vom Steuerjahr –, aber es ist besser, nach Steuerjahr zu bündeln. Eine zusammengeführte Tabelle mit P60s von 2024-25 und 2025-26 erfordert, dass die Spalte „Steuerjahr“ zu 100 % korrekt ist, bevor ein jahresspezifischer Abgleich beginnt. Die Verarbeitung jedes Steuerjahres als separater Batch – mit dem Steuerjahr in einer Batch-Spalte statt einer dokumentweisen Erkennung – verringert das Risiko einer jahresübergreifenden Vermischung. Wenn Sie gemischte Jahre verarbeiten müssen, fügen Sie eine berechnete Prüfspalte hinzu, die jede Zeile markiert, bei der das Jahresendedatum nicht dem erwarteten 5. April des Steuerjahres entspricht.
Wie geht die Stapelextraktion mit gleichnamigen Mitarbeitern um?
Der Mitarbeitername wird nicht als eindeutiges Merkmal verwendet – die NI-Nummer ist es. Zwei Mitarbeiter namens „John Smith“ beim selben Arbeitgeber, aber mit unterschiedlichen NI-Nummern, erzeugen zwei verschiedene Zeilen mit demselben Namen, aber unterschiedlichen NI-Nummern und unterschiedlichen Finanzzahlen. Der Batch-Prozessor behandelt jedes Dokument unabhängig. Das Risiko liegt im Zusammenführungsschritt: Wenn Sie zwei Batches zusammenführen und nach Name sortieren, erscheinen die beiden John-Smith-Zeilen nebeneinander, und die Person, die die Tabelle prüft, übersieht möglicherweise, dass sie unterschiedliche NI-Nummern haben. Wenn Sie die NI-Nummer als erste Spalte in Ihrer Ausgabe platzieren – vor dem Mitarbeiternamen – wird sie zum visuellen Sortierschlüssel und verhindert namensbedingte Verwechslungen.
Was tun, wenn eine P60 die PAYE-Referenz nicht klar anzeigt?
Das HMRC verlangt, dass jede P60 die PAYE-Referenz des Arbeitgebers anzeigt – es handelt sich um ein Pflichtfeld gemäß RD1. Manche Lohnabrechnungssoftware druckt die Referenz jedoch in kleiner Schrift, versteckt im Abschnitt mit den Arbeitgeberdaten oder neben dem HMRC-Logo statt im Hauptteil des Zertifikats. Wenn das Layout eines bestimmten Anbieters die PAYE-Referenz regelmäßig unkenntlich macht, können Sie eine Spalte mit festen Werten hinzufügen – setzen Sie die PAYE-Referenz für diesen Batch manuell, anstatt auf KI-Extraktion zu vertrauen. Da die PAYE-Referenz für jede P60 in einem Batch mit einem Arbeitgeber identisch ist, deckt eine manuell gesetzte Spalte den gesamten Batch ab. Die Spalte "Dateiname" in der Ausgabe liefert weiterhin die Herkunft pro Zeile, auch wenn eine Spalte batchweise statt einzeln extrahiert wird.
Die P60-Frist am 31. Mai bleibt bestehen – und ebenso die Lücke zwischen dem, was die Lohnabrechnungssoftware erzeugt, und dem, was der Lohnabschluss erfordert. Die fünf Stunden zwischen „P60s sind ausgestellt“ und „die Tabelle gleicht mit der FPS ab“ sind ein strukturelles Problem, das Tastaturgeschwindigkeit nicht löst. Es ist ein Problem des Spaltendesigns. Definieren Sie Ihre Spalten einmal. Laden Sie den Batch hoch. Lassen Sie die Tabelle sich selbst befüllen.
Jetzt mit Ihren P60s testen