P60データ入力ミス5選：
給与調整を危険にさらす落とし穴

P60データ入力における転記の死角

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

しかし、給与計算ブログ、会計事務所のガイド、HMRCのアドバイスページでほとんど触れられていない、第二のカテゴリーの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組の数字が表示されます。「この雇用における支給額」は、この特定の雇用主からの総支給額です。「年間総支給額」には、P45から繰り越された前職の支給額が含まれます。「この雇用における税額控除額」は、この雇用主が控除したPAYE税です。「年間総税額」は、すべての雇用からの税を合計したものです。

Sageで印刷されたP60では、これら4つの数字が隣接する2列に表示される場合があります。Xeroで印刷されたP60では、縦に積み重ねて表示される場合があります。5年前に従業員が前の雇用主から持参した紙のP60では、まったく異なるレイアウトで表示される場合があります。1日に80枚のP60を転記し、証明書ごとに異なるレイアウト形式を行き来する給与担当者は、「この雇用における支給額」を「税額控除額」の列に一度だけ入力してしまいます。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の雇用主向けガイダンスでは、従業員が自分のプランを把握していない場合、学生ローン開始通知（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、2人目はプラン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データ入力の隠れたコストをご覧ください。