英国給与計算の5月問題
P60データ入力の隠れたコスト

誰も予算化していない5月問題

P60は任意ではありません。2003年所得税（PAYE）規則 第67条に基づき、すべての雇用主は4月5日時点の全従業員にP60を提供する義務があります。期限は5月31日です。これを逃すと、HMRCから初回罰金300ポンドに加え、未発行の日ごとに1日60ポンドが課されます。年度末の提出ラッシュ（最終FPS、最終EPS、P32の調整）を乗り越えた給与部門にとって、5月は回復の月ではありません。第二の締切なのです。

従業員100人の企業の場合、最新の給与ソフトウェアを使えばP60の発行自体は数分で完了します。「P60を生成」をクリック。ダウンロード。配布。終了。人件費が発生するのは、誰かが給与ソフトウェアでは想定されていない目的でP60データを使用する必要があるときです。取締役会向けの年次報酬レポートの作成、総勘定元帳との給与総額の照合、監査用データの準備、あるいは——ここで作業量が爆発的に増えます——前職から証明書を持ち込んだ従業員のP60情報を統合する場合です。

30の中小企業顧客（平均従業員数15人）を抱える中規模の給与代行機関は、毎年5月に450枚のP60を処理します。80人の顧客の確定申告を処理する会計士は、それぞれからP60の数値を入手する必要があります。給与ベンチマークを計画する人事部門は、全従業員の年度末給与総額を必要とします。これには、年度途中に入社し、P60に現在の雇用主での勤務分のみが記載されている従業員も含まれます。つまり、同一課税年度に2つの仕事を掛け持ちした場合の総額ではありません。これらのシナリオのいずれにおいても、P60は存在します。データはページ上にあります。しかし、それをスプレッドシートに取り込む——行ごと、フィールドごと、雇用主ごとに——のは、依然として手作業です。

紙のP60はどこから来るのか

すべてのP60が同じ給与システムからクリーンで機械可読なデータとして届けば、手入力の問題は存在しないでしょう。しかし、それは別の国の話です。英国では、P60の状況は、どの給与ソフトウェアベンダーも修正するインセンティブを持たない構造的要因によって分断されています。

前の雇用主は依然として紙で発行する。 2025/26課税年度中に転職した従業員は、退職時にP45を旧雇用主に渡しますが、4月5日には、旧雇用主はその従業員が働いていた期間分のP60を発行します。HMRCのルールでは、雇用ごとに個別のP60が発行されます。旧雇用主が紙ベースの申告を行っている場合、またはオンライン申告が免除されている場合（介護・支援事業者、一部の宗教団体、特別な事情による免除を受けた事業者）、そのP60は物理的な書類として届きます。従業員はそれを新しい給与部門に渡し、誰かが数字を手入力します。

複数の仕事は複数のP60を意味する。 2つのPAYEの仕事（フルタイムの仕事と週末の仕事、または本業とサイドビジネスからの役員報酬）を持つ従業員は、2つの別々のP60を受け取ります。それぞれに表示されるのは、その特定の雇用からの収入のみです。住宅ローン申請、税額控除の請求、確定申告に必要な従業員の年間総収入をまとめるには、誰かが2つの数字を足し合わせ、必要な場所にその合計データを入力しなければなりません。仕事Aの給与システムは仕事BのP60を参照できません。仕事Bの給与システムは仕事Aを参照できません。その橋渡しは、電卓とキーボードです。

買収により給与システムが異なる。 2024年に子会社を買収した企業が、現在も2つの給与プロバイダー（親会社はSage、買収した会社はBrightPay）を運用している場合があります。両方のプロバイダーがP60を生成します。両方とも、独自の形式、独自のフィールドラベル、独自のレポートダッシュボード用に構造化されたP60を生成します。連結後の事業体全体の総人件費を単一の統合ビューで必要とする財務ディレクターは、スプレッドシートを開き、互換性のない2つのエクスポートからのデータのマージを開始します。あるいは、より一般的には、P60のPDF自体からデータをマージします。なぜなら、エクスポート形式の違いが大きすぎて、自動マッチングには5月に誰も着手する時間がないITプロジェクトが必要になるからです。

ビューローのクライアントはあらゆる形式でファイルを持ち込む。 給与ビューローや会計事務所は、これらすべての断片化の力が交差する場所に位置しています。単一のビューローが、4つの異なる給与システムを使用する40のクライアントの給与を処理する場合があります。クライアントが年度途中で切り替えた以前の給与プロバイダーからP60データを持ち込む場合、またはビューローのクライアントの従業員が確定申告のために前年度のP60の数字を必要とする場合、ビューローはPDF、スキャンされた紙のコピー、HMRCの個人税務口座からのスクリーンショット、そして時には誰かの配偶者がファイルキャビネットで見つけてテキストで送ってきたP60の写真を受け取ります。ビューローの仕事は、それらすべてを正確な数字に変換することです。そして、ビューローのツールは、ほとんどの場合、データ入力係です。

手動P60入力の実態：項目ごと、1分ごとの詳細

「手動データ入力」という抽象的な言葉は、給与ソフトウェアのマーケティングによってすり減らされています。5月の繁忙期に、担当者が実際に机で何をしているのかは、何も語られていません。以下が実際の流れです。

従業員120名の企業で、給与管理担当者は5月6日に着席し、年度末報酬レポートを作成します。給与システム（例：Sage 50 Payroll）は、既に全現職従業員のP60を生成しています。担当者はPDFバンドルをダウンロードします。しかし、財務部長が求めるレポートはP60そのものではありません。以下の列を含むスプレッドシートです：従業員名、NI番号、税コード、総給与額、総控除税額、従業員NI拠出額、雇用主NI拠出額。これらの一部はP60に記載されています。雇用主NIは記載されておらず、給与システムのP32レポートにあります。従業員の年金拠出額もP60にはなく、最終給与明細に記載されています。そのため、担当者は従業員ごとに3つのソース文書を照合する必要があります。

120名の従業員それぞれについて、担当者は以下を行う必要があります：PDFバンドル内で従業員を特定し、総給与額を読み取り、給与システムの内部レポートと照合し、スプレッドシートに入力し、控除税額を読み取って入力し、NI拠出額を読み取って入力し、次に雇用主NIについてはP32レポートに、年金拠出額については給与明細PDFに切り替えます。各項目には約6〜8秒かかります：画面上で数字を見つけ、正しい数字であることを確認し、入力し、確認のために見返す。120名の従業員、1人あたり7項目で、合計840項目。1項目7秒として、純粋な転記に98分。実際には、前職からのP60が2枚ある従業員、スキャンされたテンプレートから生成されたため検索がうまくいかないPDF、そして午後2時の取締役会にレポートが間に合うかと尋ねる常務取締役からの中断を考慮すると、約3時間かかります。

給与計算代行会社の場合、規模が数字をより際立たせます。30社のクライアントにわたる450名の従業員で、同じ7項目、同じペースを想定すると、生の転記に約6時間かかります — 中断のないタイピングだけで丸一日以上です。しかし、代行会社は中断のない時間帯を得られません。クライアントからのP60、P32、P11D、そして2026年4月6日から施行された新しい必須の給与計算ベネフィットに関する質問の電話の合間に、クライアントファイルをバッチで処理します。断片的な注意が1週間にわたって分散されると、6時間のデータ入力は、開始と停止を繰り返す丸2日間の作業になり、コンテキストスイッチのたびにエラー率が上昇します。

手動データ入力のエラー率に関する研究は、訓練されたオペレーターで1％から4％の範囲に収束しています。英国の給与計算の文脈では、業界調査によると、約20％の給与計算に少なくとも1つのエラーが含まれています — データフィールドの20％ではなく、給与計算実行全体の20％です。450名の従業員を抱える代行会社の場合、フィールドレベルのエラー率1％は、P60シーズンごとに4〜5件の誤入力された数字を意味します。それぞれが種です。

英国の給与計算におけるエラー連鎖

P60の数字を一文字間違えると、その影響はスプレッドシートに留まりません。連鎖的に広がります。

最も直接的な経路は、従業員の確定申告書への影響です。会計士がクライアントのSA100にP60の総支給額を誤って入力すると、税額計算が間違います。HMRCは提出された申告書と雇用主が提出したRTIデータを照合します。不一致があればコンプライアンスチェックが発動されます。会計士は元のP60を探し出し、転記ミスを特定し、申告書を修正し、クライアントに説明しなければなりません。これらの作業はすべて無報酬です。

次の経路は、HMRCのコンプライアンス機構そのものです。HMRCの記録保存要件に基づき、雇用主は給与記録を該当する課税年度終了後少なくとも3年間保存する必要があります。HMRCが記録を調査し、従業員に発行したP60の数字と報告に使用した内部記録に不一致を発見した場合、雇用主は不適切な記録として最大3,000ポンドの罰金に加え、正しい数字を再構築する義務を負います。監査証跡のない手入力スプレッドシートの場合、元のソース文書からすべてを再入力する必要があります。罰金の理由は計算ミスそのものではなく、計算が正しかったことを証明できないことです。キー入力ミスが混入したスプレッドシートは証拠になりません。

さらに、従業員に直接影響する連鎖もあります。P60は、英国の従業員が住宅ローン申請、税額控除申請、ビザ更新の際に収入を証明するための主要書類です。誤った数字が記載されたP60を受け取った従業員、または2つのP60の総支給額を誰かが足し算する際に計算ミスがあった従業員は、貸し手やホームオフィスが確認を求める最悪のタイミングでエラーに気づきます。P60を発行した給与部門は、「複写」と明記した修正版を発行する法的義務があります。手入力ミスが原因で発行される複写P60はすべて、給与チームが予算化していなかった時間を費やし、本来不要だった修正に充てられることを意味します。

修正期間がこの問題をさらに悪化させます。HMRCは元の提出から6課税年度さかのぼって給与修正を受け付けます。2020/21課税年度のP60の数字を2021年5月に誤って入力し、2026年に修正した場合、その誤った数字は5年間会社の記録に残り続けます。その間、その数字に依存したすべてのレポート、監査、住宅ローン申請が誤った数値に基づいて作成されていたことになります。単一のエラーのコストは時間とともに増大し、決して消えません。

給与計算ソフトがこの問題を解決できなかった理由

Sageは1981年に設立され、英国の約半数の企業の給与計算を処理しています。Xeroは統合給与計算機能を備えた帳簿管理プラットフォームで、英国に5,200以上の顧客を持ちます。BrightPayはビューロー市場で支配的です。ADPは英国事業を持つ多国籍企業向けに給与計算を運用しています。英国の給与計算ソフトウェア業界は成熟し、資本も潤沢で、HMRCのRTIシステムと深く統合されています。それなのに、なぜ2026年になっても給与計算の専門家がP60データを手作業で打ち直しているのでしょうか？

それは、給与計算ソフトがP60を生成するために作られており、読み取るためではないからです。Sage Payrollは法定のレイアウトでP60を作成し、自社データベースから総支給額、控除税額、NI拠出額、税コードなどのフィールドを入力し、証明書を配布します。これは確実に行います。しかし、どの給与計算プラットフォームも設計上、システム外のP60データを取り込み、下流で使用できるように構造化することはできません。給与計算の専門家が、別の雇用主、別の給与計算プロバイダー、または紙の証明書からP60データを自分のレポート環境に取り込む必要がある場合、給与計算ソフトは何も提供できません。データはPDFや紙の上にあります。システムはそれを読み取れません。「データが存在する」と「データが私のスプレッドシートにある」の間のギャップは、依然としてキーボードを打つ人間です。

これは、市場を問わず給与明細処理に影響を与える同じ構造的問題です。米国における同等の問題については、会計事務所向けW-2および1099データ抽出に関する記事で取り上げていますが、同じパターン（標準化されたフォーム、互換性のないシステム、手動再入力）に従います。英国の文脈での違いは、P60の標準化により、手動入力がより合理的に感じられることです。フィールドは常に同じで、レイアウトは決まっているため、入力は小さな作業に思えます。しかし、その小さな作業を従業員数、ソースシステム数、そして間違えた場合の下流への影響で掛け合わせて初めて、問題の規模が見えてきます。

ここで、生成ではなく抽出のために設計された別のカテゴリのツールが状況を変えます。すべてのP60が給与計算システムの入力チャネルを通じて届くことを要求する代わりに、セマンティック文書抽出は各フィールドの意味を読み取ります。必要な列を一度定義します。「総支給額」「控除税額」「NI拠出額」「税コード」「PAYE参照番号」。AIは、Sage、Xero、HMRC指定の手書きの紙テンプレート、あるいは従業員が引き出しから見つけた2019年の証明書のスキャンコピーなど、バッチ内のすべてのP60から各値を特定します。定義した列名はそのままで、ソース形式は問いません。テンプレートも、雇用主ごとの設定も不要です。ファイルをアップロードすれば、スプレッドシートが得られます。ステップバイステップのワークフローについては、給与計算照合用の英国P60データをExcelに抽出するガイドをご覧ください。

迫り来るコンプライアンスの時計

P60データを手入力でスプレッドシートに転記する場合、5月の繁忙期だけが唯一の期限ではありません。HMRCの3年間の記録保存義務により、すべてのキーストロークは少なくとも2029年4月まで会社のコンプライアンス記録として残ります。6年間の訂正期間があるため、2031年に発見されたエラーでも、元のP60まで遡って追跡可能でなければなりません。ソースからセルへの監査証跡がない手入力のスプレッドシートでは、そのレベルの精査に耐えられません。

罰則体系は二者択一で容赦ありません。HMRCが記録を要求したにもかかわらず、雇用主が提出できない場合、HMRCは税額を推定する可能性があります。その場合、雇用主は、自ら存在しないと認めた記録を使って、その推定が誤りであることを証明しなければなりません。記録は存在するが誤りが含まれている場合、雇用主は不適切な記録として3,000ポンドの罰金に直面します。その誤りがHMRCに報告された税額に影響する場合、追加の延滞税が適用されます。未納額の1%（30日経過時点）から始まり、6ヶ月および12ヶ月時点で5%に上昇します。1つのP60の総支給額を1桁誤って入力した場合、それがビューローの顧客ベース全体に波及し、複数の課税年度にわたって繰り越されると、キーストロークの誤りが5桁の負債に膨れ上がる可能性があります。

それでも、ほとんどの給与計算チームにとって、P60データを手入力するという判断にこうしたリスクは織り込まれていません。リスクが測定されたことがないからです。データ入力自体のコストは目に見えません。「給与計算処理」に埋もれ、給与所得者の役割に吸収され、予算の項目として現れることは決してありません。訂正のコストも同様に吸収されます。監査によってそのギャップが露呈したとき、つまりHMRCが「この数字を証明せよ」と求め、その証明がトレーサビリティのないスプレッドシートだったとき、初めてコストが現実のものとなります。その時点で、手入力が偽りの節約だったと判断するには遅すぎます。

複数のソース（異なる給与計算システムを使用する従業員、ビューローのクライアント、修正申告用の過去年度の証明書）からP60を収集する必要がある組織では、コレクションリンクを使用して、抽出前の書類受付を一元化し、「従業員に紙のコピーを追跡する」というステップをワークフローから完全に排除できます。

よくある質問

給与ソフトのエクスポート機能でP60データを取得できないのはなぜですか？

給与ソフトは、自社で給与を支払っている従業員のP60データのみをエクスポートできます。別の雇用主、以前の給与プロバイダー、または紙ベースのシステムで給与を支払われた従業員のP60データはエクスポートできません。また、自社の給与データであっても、エクスポート形式がダウンストリームのレポートに必要な構造と一致することはほとんどありません。フィールド名が異なり、列のレイアウトが合わず、別モジュールにある雇用主のNIや年金拠出金がエクスポートに含まれない場合もあります。エクスポートすることと、使用可能なデータを得ることは同じではありません。

P60を遅延して発行した場合の罰則は何ですか？

HMRCは、初回罰金として300ポンドに加え、P60が未発行の状態が続く1日ごとに60ポンドを課す可能性があります。罰則が科される可能性は、遅延の理由と、それがどれだけ早く是正されるかによって異なります。迅速に修正された正当なエラーは、体系的な障害や繰り返しの遅延発行よりも罰金を科される可能性が低くなります。

雇用主はP60記録をどのくらいの期間保管する必要がありますか？

HMRCの記録保管要件に基づき、関連する課税年度の終了から3年間です。つまり、2025/26課税年度のP60は、少なくとも2029年4月まで保管する必要があります。HMRCは過去6課税年度に遡る修正も受け付ける可能性があるため、修正の可能性が少しでもある場合は、実質的な保管期間はより長くなります。

P60に年金拠出金は表示されますか？

いいえ。P60には、総支給額、総控除税額、国民保険料、および従業員の最終的な税コードが表示されます。年金拠出金は、課税年度の最終給与明細に表示され、P60には表示されません。これが、手動入力が広く行われている構造的な理由の1つです。給与専門家が実際に必要とするすべてのフィールドをカバーする単一のレポートは存在せず、データはP60、P32、および最終給与明細に分散しています。

従業員が同じ課税年度に2つの仕事をしていた場合、P60は1枚ですか、2枚ですか？

2枚です。雇用主ごとに1枚ずつです。各P60は、その特定の雇用からの支給額と控除額のみを報告します。従業員は、確定申告やその他の目的のためにこれらの数値を組み合わせる責任があります。従業員の当年データを処理する給与専門家にとって、これは現在の雇用主からのP60が年度の一部のみをカバーしており、全体像を把握するには、以前の雇用主のP60またはP45の数値と手動で統合する必要があることを意味します。

AIは本当に、さまざまな給与システムのP60フォーマットに対応できるのか？

P60はHMRCが定めたレイアウトに従っているため、他の書類よりも標準化されています。違いは給与ソフトのレンダリングに起因します。つまり、フォントの違い、フィールド位置の微妙な差異、雇用主ロゴの有無などであり、構造上の違いではありません。最新のAI抽出はフィールドラベルを意味的に読み取ります。Sageで生成されたP60の「年間総支給額」と、BrightPayで生成されたP60の「年間支給額」が同じデータ項目を指していることを理解します。ただし、劣化したコピー、手書きの修正、非標準の用紙テンプレートでは精度が低下する可能性があります。一般的なP60のバッチ（既知の給与ソフトからのデジタルPDFと、数枚のスキャン紙コピーが混在）の場合、抽出精度により手作業による入力作業の大部分は不要になりますが、すべての例外ケースに対応できるわけではありません。

見逃すことのコスト

英国の給与業界は、PAYEの計算、RTI提出、P60の期日通りの発行のための高度なインフラを構築してきました。しかし、P60と、データが実際に使用されるスプレッドシート（報酬分析、監査準備、確定申告、住宅ローン申請など、年次給与データを構造化形式で必要とするあらゆる下流プロセス）との間の橋渡しは構築されていません。

そのギャップは、毎年5月、給与担当者による手入力で埋められています。1フィールドあたり6～8秒の入力速度は十分速いため、誰も疑問に思いません。1～4%のエラー率は、それぞれが孤立したミスであり、システム的なコストではないように感じられます。修正、訂正、重複P60、再発行証明書などの対応は「通常業務」に吸収されます。3000万枚のP60と数千の給与部門にわたる累積コストは、これまで測定されたことがありません。なぜなら、測定するにはギャップの存在を認める必要があるからです。

最初のステップはソフトウェアを購入することではありません。時間を数え、エラーを数え、5月の問題に数字を当てることです。1人の給与管理担当者。断片的なデータ入力に3日間。従業員からの誤った数字に関する5通の修正メール。再発行された2通の重複P60。解決に午後を費やす1件のHMRC照会。一度合計してみてください。そして、ギャップのコストが、それを埋めるコストよりも低いかどうかを判断してください。