給与照合を危険にさらすP60データ入力ミス5選
給与照合を危険にさらす

P60データ入力における転記の盲点

給与計算業界は長年にわたりP60のエラーについて議論してきましたが、そのほとんどは常にソフトウェア側に焦点を当てたものでした。年度中に適用された誤った税コード。給与計算システム内の誤ったNIカテゴリ文字。HMRCによってフラグが立てられたRTI提出。これらは処理エラーです。給与計算ソフトウェアが、入力されたデータが誤っていたため、または設定がずれていたために、誤った証明書を生成したものです。修正は給与計算システム内で行われます。

しかし、給与計算ブログ、会計事務所のガイド、HMRCのアドバイザリーページがほとんど言及しない、2番目のカテゴリのP60エラーがあります。それは、P60が正しく生成された後、人が証明書を読み、そのデータを照合スプレッドシートに入力する瞬間に発生するエラーです。年度末のFPS合計をP60出力と照合する給与計算代行機関は、ソフトウェアを修正しているのではなく、ソフトウェアの出力がHMRCへの提出内容と一致しているかを検証しているのです。ソース文書はP60です。転記先はスプレッドシートです。転記されるすべてのフィールドは、給与計算ソフトウェアの監査証跡では捕捉できないエラーの機会となります。なぜなら、給与計算システムは転記プロセスに関与していないからです。

これらのエラーは、処理エラーとは構造的に異なります。処理エラーは、給与計算システムが検証ルール（無効なNI形式、HMRCの記録と一致しない税コードなど）にフラグを立てたときに捕捉されます。転記エラーは、誰かがスプレッドシートのセルをP60のPDFと手動で比較したときに捕捉されます。誰もその比較を行わなければ、エラーはスプレッドシートに残り、照合レポートに反映され、最終的に従業員が自分の税コードが間違っていることに気づいたとき、または住宅ローンの貸し手が、P60の給与額が雇用主の検証と一致しないために申請を拒否したときに表面化します。

以下の5つの間違いは、形式検証を通過し、月末チェックを通過し、数か月後に表面化するものです。これらは「もっと注意深く作業を確認する」という問題ではなく、転記ステップ自体が根本原因であるワークフローの症状です。

間違いその1：NI番号の桁入れ替え — 誤った従業員を特定するエラー

国民保険番号の形式 — 接頭辞2文字、数字6桁、接尾辞1文字 — は、桁入れ替えエラーを自動的に検出できるように見えます。給与計算ソフト、Excelの検証式、RTI提出のいずれも、パターンに一致しない文字列は拒否します。しかし、形式チェックが実際に検出するのは、長さの誤り、数字があるべき場所の文字、無効な接頭辞（1文字目：D、F、I、Q、U、V、2文字目：D、F、I、O、Q、U、V）です。

検出できないのは、6桁の数字部分内での桁入れ替えです。QQ 12 34 56 C を QQ 12 43 56 C と入力しても、既存のすべての形式検証を通過します — 9文字、有効な接頭辞2文字、数字6桁、有効な接尾辞1文字。給与計算ソフトは受け入れ、HMRCのRTIシステムも受け入れます。そして、従業員の税およびNIデータは、HMRCの誤った記録に送られます — その記録はまったく別の人物のものか、HMRCの照合アルゴリズムが不一致を最終的にフラグするまで誰のものでもない可能性があります。

6桁の数字部分での1回の桁入れ替えにより、別の個人に属する有効なNI番号が作成されるか、発行されたNI番号に対応しないが形式検証は通過する組み合わせが作成されます。どちらの場合でも、下流での被害は提出の拒否ではなく、誤った本人確認を伴う黙認された提出です。従業員のP60データは他人の国民保険記録に反映されます。その他人の州年金受給額の計算には、他人の収入が組み込まれます。その他人の確定申告の事前入力には、勤務したことのない雇用主からの収入が表示されます。

接尾辞文字も、もう一つの隠れた複雑さです。4つの有効な文字 — A、B、C、D — は、NI番号が最初に発行された四半期に対応します。RTI以前に働いていた給与計算担当者は、NIカードが四半期ごとに届き、接尾辞が四半期のマーカーだったため、これを知っています。2020年にこの職業に就いた人は、四半期ごとの接尾辞システムについて聞いたことがないかもしれません。そのため、P60を転記して QQ 12 34 56 C を見ても、Cが「10月〜12月四半期に発行」を意味することを知らず、形式検証では接尾辞がA/B/C/Dまたはスペースであることのみをチェックし、NI番号の発行四半期と一致するかはチェックしないため、接尾辞が間違っていてもフラグを立てることはありません。

新しいクライアントを引き受け、NI番号が「数年間」間違っていたことを発見した会計事務所 — AccountingWEBで文書化 — は例外ではありません。これは、桁入れ替えエラーがシステムに入り、形式検証が「問題なし」と言ったときに起こることです。

間違いその2：税コードの入力ミス — 従業員の実際の損害につながるエラー

P60に記載された税コードは、単なる1257Lのような文字列ではありません。これは、その課税年度における従業員のPAYE計算の最終状態を示すもので、非課税枠を決定するコード番号と、W1またはM1という任意の基準指標（累積ベースか緊急ベース（非累積）のどちらでコードが適用されたかをHMRCに伝えるもの）の2つの重要な情報を含んでいます。

税コードで最も頻繁に発生する転記ミスは、1257Lを1258Lと入力することではありません。P60に1257L W1と表示されている場合に、基準指標を省略してしまうことです。スプレッドシートの列がコードのみを取得し、W1/M1の接尾辞を落としてしまうと、調整レポートは、この従業員が年度末に緊急税ベースであったという情報を失います。このデータを受け取った次の雇用主や、それをもとに確定申告書を作成する会計士は、標準の累積コードと見なし、W1/M1の問題がないものとして適用します。その結果、従業員の税金は、本来は繰り越されるべきではなかったコードに基づいて、翌課税年度に誤って計算されることになります。

実際の影響は仮定の話ではありません。監査コンサルティンググループのP60修正事例集には、マンチェスターに住むエマという従業員のケースが含まれています。彼女のP60には誤った税コードが表示されており、その結果890ポンドの過払いが発生し、修正されたP60とHMRCの還付手続きによって解決する必要がありました。これは、1つの証明書の1つのコードが間違っていたために、従業員の890ポンドが数ヶ月間HMRCに滞留したことを意味します。エラーが給与システムではなく転記によるもの（給与システムは正しいコードを生成したが、P60を転記した人物がスプレッドシートに誤って入力した）である場合、解決までの道のりは長くなります。雇用主は正しいP60を指摘できます。転記がエラーであり、原本が間違っているわけではありません。しかし、6ヶ月前に誤って転記した給与担当者が、9月に従業員からの電話に対応する人物であるとは限りません。

税コードの入力ミスは、確定申告のパイプラインにも波及します。会計事務所が、クライアントの書類から転記したP60データを使用してSA100税務申告書の雇用ページに入力する場合、申告書のコードが間違っていると、HMRCのRTIデータとの不一致が生じます。HMRCは申告書を調査対象としてフラグを立てる可能性があり、会計士がクライアントに送る次の連絡は、5月のタイプミスが11月のHMRCからの通知を引き起こした理由を説明することから始まります。

間違いその3: 総支給額と控除税額 — 1つの列を入れ替えるだけで全てが崩れる

同じ税年度に2つの仕事を持っていた従業員のP60には、時間に追われると混同しやすい2組の数字が表示されます。「Pay in This Employment」は、この特定の雇用主からの総支給額です。「Total Pay for Year」には、P45から繰り越された以前の雇用からの支給額が含まれます。この雇用における「Tax Deducted」は、この雇用主が控除したPAYE税です。「Total Tax for Year」は、すべての雇用からの税を合算したものです。

Sage印刷のP60では、これら4つの数字が隣接する2つの列に表示されることがあります。Xero印刷のP60では、縦に積み重ねて表示されることがあります。従業員が5年前の以前の雇用主から持ち込んだ紙のP60では、まったく異なるレイアウトで表示されることがあります。1日に80枚のP60を転記し、数枚ごとに異なるレイアウト形式を行き来する給与担当者が、「Pay in This Employment」を「Tax Deducted」の列に一度だけ入力してしまう。1行。1つの入れ替え。そしてその行には、£4,870の支給額に対して£31,200の税 — またはその逆で、£31,200の支給額に対して£4,870の税 — が表示されることになります。

最初の数字は自動チェック — 税対支給額比率 — をトリガーします。£4,870の支給額に対して£31,200の税が表示されているスプレッドシートの行を見れば、誰でも気づくでしょう。しかし、その逆 — £31,200の支給額に対して£4,870の税 — は、15.6%という妥当な実効税率です。比例性チェックを通過します。形式チェックも通過します。照合レポートに有効な行として組み込まれ、FPSデータとの合計行の照合はわずかにずれる程度 — 丸め誤差や小さなRTIタイミングの差に帰属できる程度のずれで、全行の完全な再監査をトリガーするほどの差ではありません。

この特定のエラーには、HMRC自身のソフトウェアにも文書化された類似例があります。ある税年度、HMRCのBasic PAYE Tools (BPT) ソフトウェアが生成したP60 PDFで、NI所得帯が入れ替わっていました — PDFにはRTI提出と一致しない誤った数字が表示されていました。これについてAccountingWEBで議論していた給与管理担当者は、自分たちのせいではないエラーの診断に「請求できない時間」を費やしたと述べています。HMRCの回答は、エラーはPDFにのみ現れ、拠出機関のデータには現れなかったというものでした — つまり、給与担当者が読んで転記しているPDFには、ソフトウェア提供者自身も気づいていないレイアウトエラーが含まれている可能性があるということです。

人間の転記ミスが、それ自体があいまいなソース文書のレイアウト — 似た数値を持つ2つの列、視覚的な区切りなし — と組み合わさると、誰かが個々の行を元のP60 PDFと照合するまで、そのエラーは事実上検出不可能になります。1日80行では、誰もすべての行を元のPDFと照合しません。

間違いその4：離職日不一致 — P45とP60の情報が食い違うケース

このミスは単一の書類で発生するわけではありません。同じ従業員を参照する2つの書類の間に生じます。3月に雇用主Aを退職し、4月に雇用主Bで勤務を開始した従業員は、2組のP60データに登場します。雇用主AのP60には3月の離職日までの給与が、雇用主BのP60には4月の入社日からの給与がそれぞれ記載されます。各証明書は単独では正しいものです。しかし、これら2つを合計して従業員のスプレッドシート行に転記する際には、誰も確認していない制約を満たす必要があります。すなわち、P45の離職日は次の雇用の開始日より前でなければならず、両方のP60にわたる総給与は年間の数値と一致する必要があります。

P45の離職日が誤って転記された場合（例えば、実際の2月28日を3月31日と入力した場合）、新しい雇用主は誤った税コードを適用します。なぜなら、P45は新しい雇用主が従業員の累積税額を判断するために使用する書類だからです。P45に実際より2週間遅い離職日が記載されていると、新しい雇用主の給与計算ソフトは、前の雇用からの非課税枠が2週間分多いと仮定した累積コードを適用します。その枠は従業員がすでに使用済みです。その結果、従業員はその年の残りの期間、過少課税となり、翌年の秋にHMRCから不足額の支払いを求める簡易査定通知書を受け取ることになります。

HMRCのガイダンスでは、誤った離職日の修正について、給与記録を正しい日付に更新し、次のFPSで修正を報告しないよう指示しています。これは重複した雇用記録を作成する可能性があるためです。しかし、このガイダンスは元のFPSを提出した雇用主に適用されます。転記ミスが給与計算業務代行会社の照合スプレッドシートで発生した場合（離職日が元のFPS提出時ではなくデータ入力時に誤って入力された場合）、代行会社には修正すべきFPSがありません。エラーはスプレッドシート内にのみ存在します。そして、そのスプレッドシートは代行会社の照合レポートに反映され、それが雇用主の承認につながり、結果として雇用主が修正済みP60を発行することになります。これは元のP60には存在しなかった問題を修正することになり、全員の時間を無駄にする修正ループを生み出します。

構造上のギャップは、文書間の検証です。給与計算ソフトウェアは単一の文書内でのみ検証を行います（P60のNI形式、P45の税コード形式など）。文書間での検証を行うシステムはありません。つまり、P45の離職日とP60の「本雇用における給与」の金額が従業員の総給与推移と整合しているかを確認するシステムは存在しません。この文書間チェックは、給与計算担当者が転記時に手動で行うべきものとされています。そして、処理量が時間の許容量を超えた場合、最初に省略されるチェックでもあります。

間違い5：学生ローンのプラン混同 — プラン1、2、4、5、または大学院?

この記事で取り上げる5つの間違いのうち、これは給与計算担当者の責任が最も少ないもの — そしてP60発行から数か月後に従業員からの苦情が最も多く寄せられるものです。英国の学生ローン返済制度には現在5つのプランタイプがあり、それぞれ返済しきい値が異なり、従業員のプランは、どこで学んだか、いつ卒業したか、どのようなコースを受講したかによって決まります。

その構成は次のとおりです：

HMRCの雇用主向けガイダンスには次のように記載されています：従業員が自分のプランを把握していない場合は、Student Loan Start Notice（SL1）を受け取るまで給与計算ソフトウェアでプラン5を使用してください。プラン5をデフォルトにすることは賢明な管理上のフォールバックですが、実際にはプラン1、2、または4に該当するのに雇用主に伝えなかったすべての従業員について、誤ったしきい値で控除が計算されることを意味します。プラン1の借入者（しきい値£26,900）がプラン5（しきい値£25,000）として扱われると、本来より£1,900の所得について早期に返済が始まり、9%で年間およそ£171の過剰控除になります。プラン4の借入者（しきい値£33,795）がプラン5（£25,000）として扱われると、£8,795の所得について過払いとなり、年間およそ£792になります。

このエラーの転記の側面はより微妙です。給与計算担当者がP60データを照合スプレッドシートに転記する際、P60には学生ローンの控除額 — ポンド単位の単一の数値 — が表示されます。どのプランがその控除を生じさせたかは表示されません。担当者は「学生ローン控除」というラベルのスプレッドシートの列に£1,200と入力します。数値は正しいです。プランは見えません。同じ給与で同じ£1,200の控除がある2人の従業員が異なるプランに該当する場合があります — 1人はプラン1、もう1人はプラン2 — そしてスプレッドシートは両者を同一に扱います。P60の控除合計をFPS合計と比較する照合レポートは一致します。控除額が正しいからです。エラーは金額にあるのではなく、P60が名前を挙げずに要約している給与計算システムに記録されたプランタイプにあります。

HMRCが従業員のローン種別を照合した際（実際に行われますが、SLCのデータがHMRCを経由して雇用主に非同期で届くため、数か月かかることがあります）、従業員が誤った種別で処理されていた旨の通知が雇用主に届きます。雇用主は過去の控除を修正する必要があり、従業員がSLCに還付を申請する場合もあります。MoneySavingExpertのMartin Lewis氏は、Plan 2返済額基準の凍結と過剰控除の広範な問題（変動所得者、早期返済開始者、デフォルトで誤った種別の従業員）を文書化しています。還付手続きはSLCを通じて行われ、給与計算経由ではありません。しかし、元の誤りはP60が要約する給与記録に存在し、種別を捕捉しない調整スプレッドシートがその誤りの不可視性を増幅させます。

AI抽出がエラーの性質を変える理由——単なる速度向上ではない

上記のすべてのミスには、トレーニングやチェックリスト、ダブルチェックでは表面的にしか対処できない根本原因があります。それは転記という工程そのもの——人がPDFを読み、そのデータをセルに入力する瞬間——です。この工程をなくせば、どんな検証式も捕捉できないエラーのカテゴリ全体が除去されます。

P60データを手入力ではなくAIで抽出すると、エラーの性質が変わります。NI番号は証明書から直接読み取られるため、ページとセル間での転記ミスが発生しません。税コードはW1/M1指標を含めて完全な形で抽出されます。これは、人が記憶して入力する内容ではなく、抽出が完全な文字列を保持するからです。給与と税額は、「この雇用での給与」対「年間総給与」のように、オペレーターが初めて見るレイアウトを空間的に辿るのではなく、意味的な意味に基づいて正しい列にマッピングされます。学生ローン控除は印刷された値として抽出され、種別の問題は転記の問題ではなく、給与システムの設定の問題になります。

これは、抽出がすべてのエラーを排除することを意味しません。残るエラーの種類が変わるのです。転記ミス（桁違い、列違い、サフィックス欠落）の代わりに、検証エラー（AIが印字不良の文字を誤読したか、年中にカテゴリ変更があった従業員のNIカテゴリ文字を誤った行からマッピングしたか）が残ります。これらの検証エラーは、オペレーターが入力と確認を同時に行うのではなく、抽出データを原本と照合するため、発見が容易です。オペレーターは転記者ではなく、レビュアーになります。レビュアーは、転記者が作り出すエラーを発見できるのです。

P60 PDFから調整可能なスプレッドシートへの完全なワークフロー（Sage、Xero、BrightPay、およびあらゆる給与プロバイダーのP60レイアウトで機能する列定義を含む）については、英国P60データをExcelに抽出するガイドをご参照ください。手動によるP60データ入力が給与年度末の構造的なボトルネックとなる広範な問題については、P60データ入力の隠れたコストをご覧ください。