5 P60-Dateneingabefehler, die
den Lohnabgleich gefährden

Die Transkriptionslücke bei der P60-Dateneingabe

Die Lohnbuchhaltungsbranche diskutiert seit Jahren über P60-Fehler – fast immer aus Softwaresicht. Falscher Steuercode im Laufe des Jahres. Falscher NI-Kategoriebuchstabe im Lohnsystem. RTI-Meldung vom HMRC beanstandet. Das sind Verarbeitungsfehler: Die Lohnsoftware hat ein falsches Zertifikat erstellt, weil die eingegebenen Daten falsch waren oder eine Konfigurationseinstellung nicht stimmte. Die Behebung erfolgt im Lohnsystem.

Es gibt jedoch eine zweite Kategorie von P60-Fehlern, die in Lohnbuchhaltungsblogs, Leitfäden von Buchhaltungsfirmen und HMRC-Hinweisen kaum erwähnt wird: Fehler, die nach der korrekten Erstellung des P60 auftreten – in dem Moment, in dem eine Person das Zertifikat liest und seine Daten in eine Abgleichstabelle eingibt. Ein Lohnbüro, das die Jahresend-FPS-Summen mit der P60-Ausgabe abgleicht, behebt keine Software – es überprüft, ob die Softwareausgabe mit den HMRC-Meldungen übereinstimmt. Das Quelldokument ist der P60. Das Transkriptionsziel ist eine Tabelle. Jedes transkribierte Feld birgt die Möglichkeit eines Fehlers, den kein Prüfpfad der Lohnsoftware erfasst, da das Lohnsystem nie an der Transkription beteiligt war.

Diese Fehler unterscheiden sich strukturell von Verarbeitungsfehlern. Ein Verarbeitungsfehler wird erkannt, wenn das Lohnsystem eine Validierungsregel auslöst – ein ungültiges NI-Format, ein Steuercode, der nicht mit den HMRC-Aufzeichnungen übereinstimmt. Ein Transkriptionsfehler wird erkannt, wenn jemand die Tabellenzelle manuell mit dem P60-PDF vergleicht. Wenn niemand diesen Vergleich durchführt, bleibt der Fehler in der Tabelle, fließt in den Abgleichsbericht ein und taucht schließlich auf, wenn ein Mitarbeiter bemerkt, dass sein Steuercode falsch ist – oder ein Hypothekengeber einen Antrag ablehnt, weil die Gehaltsangabe auf dem P60 nicht mit der Bestätigung des Arbeitgebers übereinstimmt.

Die fünf unten aufgeführten Fehler sind diejenigen, die die Formatvalidierung überstehen, Monatsendprüfungen bestehen und Monate später auftauchen. Sie sind keine „Arbeiten Sie sorgfältiger“-Probleme – sie sind Symptome eines Arbeitsablaufs, bei dem der Transkriptionsschritt selbst die Ursache ist.

Fehler #1: Vertauschung der NI-Nummer – Der Fehler, der den falschen Mitarbeiter findet

Das Format der National Insurance-Nummer – zwei Präfixbuchstaben, sechs Ziffern, ein Suffixbuchstabe – scheint Vertauschungsfehler automatisch abzufangen. Jede Lohnsoftware, jede Excel-Validierungsformel, jede RTI-Übermittlung weist eine Zeichenfolge zurück, die nicht dem Muster entspricht. Aber hier ist, was die Formatprüfung tatsächlich erkennt: Einträge mit falscher Länge, Zeichen an Stellen, wo Ziffern hingehören, ungültige Präfixbuchstaben (D, F, I, Q, U, V als erstes Zeichen; D, F, I, O, Q, U, V als zweites).

Was sie nicht erkennt, ist eine Vertauschung innerhalb des sechsstelligen Segments. QQ 12 34 56 C eingegeben als QQ 12 43 56 C besteht jede existierende Formatvalidierung – neun Zeichen, zwei gültige Präfixbuchstaben, sechs Ziffern, ein gültiger Suffixbuchstabe. Die Lohnsoftware akzeptiert es. Das RTI-System von HMRC akzeptiert es. Und es leitet die Steuer- und NI-Daten des Mitarbeiters zum falschen HMRC-Datensatz – einem Datensatz, der einer völlig anderen Person gehören könnte oder gar niemandem, bis der Abgleichsalgorithmus von HMRC die Diskrepanz irgendwann aufdeckt.

Eine einzige Vertauschung im sechsstelligen Segment erzeugt eine gültige NI-Nummer, die zu einer anderen Person gehört – oder eine Kombination, die keiner ausgegebenen NI-Nummer entspricht, aber die Formatvalidierung besteht. In beiden Fällen ist der nachgelagerte Schaden keine abgelehnte Übermittlung – es ist eine stillschweigend akzeptierte Übermittlung mit falscher Identitätsbindung. Die P60-Daten des Mitarbeiters landen im National Insurance-Datensatz einer anderen Person. Dessen Berechnung des staatlichen Rentenanspruchs beinhaltet die Einkünfte eines anderen. Dessen Vorausfüllung der Selbstveranlagung zeigt Einkommen von einem Arbeitgeber, für den er nie gearbeitet hat.

Der Suffixbuchstabe ist eine weitere Ebene versteckter Komplexität. Die vier gültigen Buchstaben – A, B, C, D – entsprechen dem Kalenderquartal, in dem die NI-Nummer ursprünglich vergeben wurde. Lohnbuchhalter, die vor RTI gearbeitet haben, wissen das, weil NI-Karten früher vierteljährlich kamen und das Suffix die Quartalskennung war. Jemand, der 2020 in den Beruf eingestiegen ist, hat vielleicht nie vom vierteljährlichen Suffixsystem gehört. Wenn er also eine P60 abschreibt und QQ 12 34 56 C sieht, weiß er nicht, dass C „ausgestellt im Quartal Oktober-Dezember“ bedeutet – und würde es nicht beanstanden, wenn das Suffix falsch wäre, weil die Formatvalidierung nur prüft, ob das Suffix A/B/C/D oder Leerzeichen ist, nicht ob es zum Ausstellungsquartal der NI-Nummer passt.

Die Wirtschaftsprüfungsgesellschaft, die einen neuen Mandanten übernahm und feststellte, dass die NI-Nummer „seit einigen Jahren“ falsch war – dokumentiert auf AccountingWEB – ist kein Einzelfall. Es ist das, was passiert, wenn ein Vertauschungsfehler ins System gelangt und die Formatvalidierung sagt: „Sieht für mich gut aus.“

Fehler Nr. 2: Falscher Steuerfreibetragscode – Der Fehler, der Mitarbeiter bares Geld kostet

Ein Steuerfreibetragscode auf einer P60 ist nicht einfach eine Zeichenfolge wie 1257L. Er stellt den endgültigen Stand der PAYE-Berechnung des Arbeitnehmers für das Steuerjahr dar und enthält zwei entscheidende Informationen: die Code-Nummer selbst, die den steuerfreien Betrag bestimmt, und einen optionalen Basisindikator – W1 oder M1 – der dem HMRC mitteilt, ob der Code auf kumulativer oder Notfallbasis (nicht kumulativ) angewendet wurde.

Der häufigste Übertragungsfehler bei Steuerfreibetragscodes ist nicht die Eingabe von 1257L als 1258L. Es ist das Weglassen des Basisindikators, wenn die P60 1257L W1 anzeigt. Wenn die Tabellenspalte nur den Code erfasst und das W1/M1-Suffix weglässt, verliert der Abgleichsbericht die Information, dass dieser Mitarbeiter zum Jahresende auf Notfallsteuerbasis war. Der nächste Arbeitgeber, der diese Daten erhält – oder der Buchhalter, der die Selbstveranlagung daraus erstellt – sieht einen Standard-Kumulativcode und wendet ihn an, als gäbe es kein W1/M1-Problem. Die Steuer des Mitarbeiters wird für das nächste Steuerjahr falsch berechnet, basierend auf einem Code, der nie hätte übertragen werden sollen.

Die realen Auswirkungen sind nicht hypothetisch. Das P60-Korrekturfallbuch der Audit Consulting Group enthält eine Mitarbeiterin namens Emma in Manchester, deren P60 den falschen Steuerfreibetragscode zeigte – das Ergebnis war eine Überzahlung von 890 £, die eine korrigierte P60 und einen Rückerstattungsprozess beim HMRC erforderte, um gelöst zu werden. Das sind 890 £ des Geldes der Mitarbeiterin, die monatelang vom HMRC einbehalten wurden, nur weil ein Code auf einer Bescheinigung falsch war. Wenn der Fehler beim Übertragen und nicht im Gehaltsabrechnungssystem liegt – das System generierte den korrekten Code, aber die Person, die die P60 übertrug, tippte ihn falsch in die Tabelle ein – ist der Lösungsweg länger. Der Arbeitgeber kann auf die korrekte P60 verweisen. Der Übertragungsfehler liegt vor, nicht das Quelldokument. Aber der Gehaltsabrechner, der vor sechs Monaten falsch übertragen hat, ist möglicherweise nicht die Person, die im September den Anruf des Mitarbeiters entgegennimmt.

Die falsche Eingabe des Steuerfreibetragscodes wirkt sich auch auf die Selbstveranlagung aus. Wenn eine Buchhaltungsfirma P60-Daten – übertragen aus Kundendokumenten – verwendet, um die Beschäftigungsseiten der SA100-Steuererklärung zu füllen, erzeugt ein falscher Code in der Erklärung eine Diskrepanz mit den RTI-Daten des HMRC. Das HMRC kann die Erklärung zur Prüfung markieren, und die nächste Kommunikation des Buchhalters mit dem Kunden beginnt damit, zu erklären, warum ein Tippfehler im Mai im November einen HMRC-Brief ausgelöst hat.

Fehler #3: Gesamtbezug und Abgeführte Steuer — Ein Spaltentausch, der alles zerstört

Eine P60 für einen Arbeitnehmer mit zwei Jobs im selben Steuerjahr zeigt zwei Zahlenpaare, die unter Zeitdruck leicht verwechselt werden. „Bezug in dieser Beschäftigung“ ist der Bruttolohn von diesem Arbeitgeber. „Gesamtbezug für das Jahr“ umfasst Bezüge aus früheren Beschäftigungen, die vom P45 übernommen wurden. „Abgeführte Steuer“ in dieser Beschäftigung ist die von diesem Arbeitgeber einbehaltene PAYE-Steuer. „Gesamtsteuer für das Jahr“ summiert die Steuer aus allen Beschäftigungen.

Auf einer mit Sage gedruckten P60 können diese vier Zahlen in zwei benachbarten Spalten erscheinen. Auf einer mit Xero gedruckten P60 können sie vertikal gestapelt sein. Auf einer Papier-P60, die ein Mitarbeiter vor fünf Jahren von einem früheren Arbeitgeber mitgebracht hat, können sie in einem völlig anderen Layout erscheinen. Ein Lohnbuchhalter, der an einem Tag 80 P60s überträgt und dabei zwischen verschiedenen Layout-Formaten wechselt, tippt einmal „Bezug in dieser Beschäftigung“ in die Spalte „Abgeführte Steuer“. Eine Zeile. Ein Tausch. Und diese Zeile zeigt nun 31.200 £ Steuer auf 4.870 £ Bezug — oder umgekehrt, 4.870 £ Steuer auf 31.200 £ Bezug.

Die erste Zahl löst eine automatische Prüfung aus — das Verhältnis von Steuer zu Bezug. Jeder, der in einer Tabellenzeile 31.200 £ Steuer auf 4.870 £ Bezug sieht, wird es bemerken. Aber das Gegenteil — 4.870 £ Steuer auf 31.200 £ Bezug — ist ein plausibler effektiver Steuersatz von 15,6 %. Es besteht die Verhältnismäßigkeitsprüfung. Es besteht die Formatprüfung. Es fließt als gültige Zeile in den Abstimmungsbericht ein, und die Gesamtzeilen-Abstimmung mit den FPS-Daten weicht leicht ab — nah genug, um auf Rundung oder eine kleine RTI-Zeitdifferenz zurückgeführt zu werden, nicht weit genug, um eine vollständige Neuprüfung jeder Zeile auszulösen.

Dieser spezifische Fehler hat ein dokumentiertes Gegenstück in der eigenen Software von HMRC. In einem Steuerjahr produzierte die HMRC-Software Basic PAYE Tools (BPT) P60-PDFs, bei denen die NI-Verdienstgrenzen vertauscht waren — das PDF zeigte falsche Zahlen, die nicht mit der RTI-Übermittlung übereinstimmten. Lohnbuchhalter, die dies auf AccountingWEB diskutierten, beschrieben, dass sie „nicht abrechenbare Zeit“ mit der Diagnose eines Fehlers verbrachten, der nicht ihrer war. HMRCs Antwort war, dass der Fehler nur im PDF auftrat, nicht in den Beitragsdaten der Agentur — was bedeutet, dass das PDF, das der Lohnbuchhalter liest und von dem er überträgt, Layoutfehler enthalten kann, die selbst der Softwareanbieter nicht bemerkt hat.

Wenn ein menschlicher Übertragungsfehler mit einem mehrdeutigen Quell-Layout kombiniert wird — zwei Spalten mit ähnlichen Zahlenwerten, ohne visuelle Trennung — wird der Fehler praktisch unentdeckbar, bis jemand die einzelne Zeile mit dem ursprünglichen P60-PDF abgleicht. Bei 80 Zeilen pro Tag gleicht niemand jede Zeile mit dem ursprünglichen PDF ab.

Fehler Nr. 4: Abweichendes Austrittsdatum – wenn P45 und P60 Unterschiedliches erzählen

Dieser Fehler tritt nicht in einem einzelnen Dokument auf. Er entsteht in der Lücke zwischen zwei Dokumenten, die denselben Mitarbeiter betreffen. Ein Mitarbeiter, der im März Arbeitgeber A verlassen und im April bei Arbeitgeber B angefangen hat, erscheint in zwei P60-Datensätzen. Das P60 von Arbeitgeber A zeigt den Lohn bis zum Austrittsdatum im März. Das P60 von Arbeitgeber B zeigt den Lohn ab dem Startdatum im April. Beide Bescheinigungen sind für sich genommen korrekt. Doch die Summe beider – übertragen in eine Tabellenzeile für den Mitarbeiter – muss eine Einschränkung beachten, die niemand prüft: Das Austrittsdatum auf dem P45 sollte vor dem Startdatum der nächsten Beschäftigung liegen, und der Gesamtlohn aus beiden P60s sollte den Jahreszahlen entsprechen.

Wenn das Austrittsdatum auf dem P45 falsch übertragen wird – z. B. 31.03 statt 28.02 – wendet der neue Arbeitgeber den falschen Steuerfreibetrag an, da das P45 das Dokument ist, anhand dessen der neue Arbeitgeber den kumulierten Steuerstatus des Mitarbeiters ermittelt. Zeigt das P45 ein zwei Wochen späteres Austrittsdatum als tatsächlich, verwendet die Lohnabrechnungssoftware des neuen Arbeitgebers einen kumulierten Code, der zwei zusätzliche Wochen Steuerfreibetrag aus der vorherigen Beschäftigung annimmt – Freibetrag, den der Mitarbeiter bereits genutzt hat. Der Mitarbeiter wird für den Rest des Jahres zu wenig besteuert und erhält im folgenden Herbst einen HMRC-Simple-Assessment-Brief mit der Aufforderung, den Fehlbetrag zu zahlen.

Die HMRC-Anleitung zur Korrektur eines falschen Austrittsdatums besagt: Aktualisieren Sie Ihre Lohnabrechnungsdaten mit dem korrekten Datum und melden Sie die Änderung nicht in Ihrer nächsten FPS – da dies einen doppelten Beschäftigungsdatensatz erzeugen könnte. Diese Anleitung gilt jedoch für den Arbeitgeber, der die ursprüngliche FPS-Meldung eingereicht hat. Wenn der Übertragungsfehler in der Abgleichstabelle einer Lohnabrechnungsstelle passiert – das Austrittsdatum wurde bei der Dateneingabe falsch getippt, nicht bei der ursprünglichen FPS – hat die Stelle keine FPS zu korrigieren. Der Fehler existiert nur in der Tabelle. Und die Tabelle speist den Abgleichsbericht der Stelle, der die Freigabe des Arbeitgebers speist, was dazu führen kann, dass der Arbeitgeber ein korrigiertes P60 ausstellt, das ein Problem behebt, das im ursprünglichen P60 gar nicht bestand – eine Korrekturschleife, die Zeit aller Beteiligten verschwendet.

Die strukturelle Lücke ist die dokumentenübergreifende Validierung. Lohnabrechnungssoftware validiert innerhalb eines einzelnen Dokuments – NI-Format auf dem P60, Steuerklassenformat auf dem P45. Kein System validiert über Dokumente hinweg – das heißt, kein System prüft, ob das Austrittsdatum auf dem P45 und der Betrag „Lohn in dieser Beschäftigung“ auf dem P60 mit dem gesamten Lohnverlauf des Mitarbeiters konsistent sind. Diese dokumentenübergreifende Prüfung soll der Lohnabrechner manuell beim Übertragen durchführen. Und sie ist die erste Prüfung, die wegfällt, wenn das Volumen die verfügbare Zeit übersteigt.

Fehler Nr. 5: Verwechslung der Studienkredit-Pläne — Plan 1, 2, 4, 5 oder Postgraduierten-Darlehen?

Von den fünf Fehlern in diesem Artikel ist dies derjenige, bei dem die Lohnbuchhalter am wenigsten schuld sind – und derjenige, der Monate nach Ausstellung der P60 die meisten Beschwerden von Mitarbeitern auslöst. Das britische System zur Rückzahlung von Studienkrediten umfasst mittlerweile fünf Plantypen, jeder mit einer anderen Rückzahlungsschwelle. Der Plan eines Mitarbeiters richtet sich nach Studienort, Abschlussjahr und Art des Studiengangs.

Die Matrix sieht wie folgt aus:

Die HMRC-Arbeitgeberleitlinie besagt: Wenn Ihr Mitarbeiter nicht weiß, in welchem Plan er sich befindet, verwenden Sie in Ihrer Lohnsoftware Plan 5, bis Sie eine Student Loan Start Notice (SL1) erhalten. Die Voreinstellung auf Plan 5 ist ein sinnvoller administrativer Notbehelf – bedeutet aber, dass jeder Mitarbeiter, der tatsächlich in Plan 1, 2 oder 4 ist, dies seinem Arbeitgeber jedoch nicht mitgeteilt hat, Abzüge auf Basis der falschen Schwelle erhält. Ein Plan-1-Kreditnehmer (Schwelle 26.900 £), der wie Plan 5 (Schwelle 25.000 £) behandelt wird, beginnt 1.900 £ früher mit der Rückzahlung als nötig – das sind bei 9 % etwa 171 £ Überzahlung pro Jahr. Ein Plan-4-Kreditnehmer (Schwelle 33.795 £), der wie Plan 5 (25.000 £) behandelt wird, zahlt auf 8.795 £ zu viel – rund 792 £ pro Jahr.

Die Übertragungsdimension dieses Fehlers ist subtiler. Wenn ein Lohnbuchhalter P60-Daten in eine Abgleichstabelle überträgt, zeigt die P60 einen Studienkreditabzugsbetrag – eine einzelne Zahl in ganzen Pfund. Sie zeigt nicht an, welcher Plan diesen Abzug generiert hat. Der Buchhalter gibt 1.200 £ in die Spalte „Studienkreditabzüge“ der Tabelle ein. Die Zahl stimmt. Der Plan ist unsichtbar. Zwei Mitarbeiter mit demselben Gehalt und demselben Abzug von 1.200 £ können in unterschiedlichen Plänen sein – einer in Plan 1, einer in Plan 2 – und die Tabelle behandelt sie identisch. Der Abgleichsbericht, der die gesamten P60-Abzüge mit den FPS-Summen vergleicht, wird übereinstimmen, da die Abzugsbeträge korrekt sind. Der Fehler liegt nicht im Betrag – sondern im im Lohnsystem erfassten Plantyp, den die P60 zusammenfasst, ohne ihn zu nennen.

Wenn HMRC irgendwann die Pläne der Arbeitnehmer abgleicht – was sie tun, und was Monate dauern kann, weil SLC-Daten asynchron über HMRC an Arbeitgeber fließen – erhält der Arbeitgeber eine Mitteilung, dass ein Arbeitnehmer im falschen Plan war. Der Arbeitgeber muss dann frühere Abzüge korrigieren, was dazu führen kann, dass der Arbeitnehmer eine Rückerstattung von SLC beantragt. Martin Lewis von MoneySavingExpert hat den Einfrieren der Rückzahlungsschwelle für Plan 2 und das allgemeinere Problem von Überzahlungen dokumentiert: Arbeitnehmer mit variablem Einkommen, Arbeitnehmer, die zu früh mit der Rückzahlung begonnen haben, und Arbeitnehmer, die standardmäßig im falschen Plan sind. Der Rückerstattungsprozess läuft über SLC, nicht über die Gehaltsabrechnung – aber der ursprüngliche Fehler liegt im Gehaltsdatensatz, den die P60 zusammenfasst, und die Abstimmungstabelle, die den Plantyp nicht erfasst, verstärkt die Unsichtbarkeit des Fehlers.

Warum KI-Extraktion das Fehlerprofil verändert – nicht nur die Geschwindigkeit

Jeder oben beschriebene Fehler hat eine gemeinsame Ursache, die Schulungen, Checklisten und Zweitprüfungen nur oberflächlich beheben. Die Ursache ist der Übertragungsschritt selbst – der Moment, in dem eine Person ein PDF liest und die Daten in eine Zelle eingibt. Das Entfernen dieses Schritts eliminiert eine ganze Kategorie von Fehlern, die keine Validierungsformel abfängt.

Wenn P60-Daten von KI statt von Hand eingegeben werden, verschiebt sich das Fehlerprofil. Die NI-Nummer wird direkt vom Zertifikat gelesen – keine Vertauschungsmöglichkeit zwischen Seite und Zelle. Der Steuercode kommt vollständig mit seinem W1/M1-Indikator an, weil die Extraktion die gesamte Zeichenfolge bewahrt, nicht das, was eine Person einzugeben gedenkt. Die Gehalts- und Steuerbeträge werden durch semantische Bedeutung den richtigen Spalten zugeordnet – „Gehalt in dieser Beschäftigung“ vs. „Gesamtgehalt für das Jahr“ – und nicht durch die räumliche Navigation des Bearbeiters über ein Layout, das er vor zehn Sekunden zum ersten Mal gesehen hat. Der Studentendarlehensabzug wird als gedruckter Wert extrahiert, und die Frage nach dem Plantyp wird zu einem Konfigurationsproblem des Gehaltssystems und nicht zu einem Übertragungsproblem.

Das bedeutet nicht, dass die Extraktion alle Fehler beseitigt. Sie verändert, welche Fehler übrig bleiben. Stellt von Vertauschungsfehlern – falsche Ziffer, falsche Spalte, weggelassenes Suffix – sind die verbleibenden Fehler Verifikationsfehler: Hat die KI ein schlecht gedrucktes Zeichen falsch gelesen? Hat sie den NI-Kategoriebuchstaben aus der falschen Zeile zugeordnet, wenn ein Arbeitnehmer einen Kategoriewechsel während des Jahres hatte? Diese Verifikationsfehler sind schneller zu erkennen, weil der Bearbeiter die extrahierten Daten mit dem Quelldokument vergleicht, anstatt gleichzeitig zu tippen und zu prüfen. Der Bearbeiter wird zum Prüfer, nicht zum Abschreiber – und Prüfer entdecken Fehler, die Abschreiber erzeugen.

Für den vollständigen Workflow – von P60-PDFs bis zur abstimmungsbereiten Tabelle, einschließlich Spaltendefinitionen, die mit Sage, Xero, BrightPay und jedem Gehaltsabrechnungsanbieter-Layout funktionieren – siehe unseren Leitfaden zum Extrahieren von UK-P60-Daten in Excel. Für das allgemeinere Problem der manuellen P60-Dateneingabe als strukturellen Engpass im Gehaltsabrechnungsjahresende siehe die versteckten Kosten der P60-Dateneingabe.