英国給与計算の5月問題
P60データ入力の隠れたコスト
毎年5月、英国の給与部門はソフトウェア業界が20年にわたって存在しないふりをしてきた儀式を実行します。HMRCのP60年末証明書発行期限は5月31日——4月5日の年度末から8週間後です。2025年3月にHMRCが記録したPAYE雇用者3,020万人について、雇用主はどこかでP60を発行します。その部分は自動化されています。Sage、Xero、BrightPay、ADPは給与年度末処理中に証明書を生成します。しかし、その後に起こることは自動化されていません。P60のデータ——総支給額、総控除税額、国民保険(NI)拠出額、最終税コード——は、証明書からスプレッドシート、レポート、監査、そして給与ソフトウェアがそもそも供給するように設計されていない下流システムへ移動する必要があります。そして、その引き渡し時点で、担当者がExcelを開いてタイピングを始めます。

重要ポイント
- 英国の3,000万件以上のP60にわたり、給与専門家は5月に総支給額、控除税額、NI拠出額を証明書からスプレッドシートへ再入力することに時間を費やしています——タイピング自体はフィールドあたり6〜8秒かかり、疑問を持つには小さすぎると感じられます。
- 実際のコストはこれまでどの予算の単一項目にも載ったことがありません。修正メール、再発行された重複P60、HMRCのコンプライアンス照会、税務申告の修正、住宅ローンの申請遅延——それぞれが異なるコストセンターに吸収され、誤入力された1つの数字が6年間の修正期間にわたって実際にいくらかかるかを明らかにするために合算されることは決してありません。
- 一度だけ合算してみてください。管理者1名、断片的な入力に3日間、修正メール5通、再発行P60が2件、HMRC照会1件——この演算から浮かび上がる数字は、「P60発行」と「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発行」と「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入力の実態:項目別・時間別の詳細

「手動データ入力」という言葉は、給与ソフトウェアのマーケティングによって磨耗した抽象概念です。この言葉からは、5月の繁忙期に担当者が実際に机の上で何をしているのかは一切伝わりません。以下が実際の流れです。
従業員120名の企業で働く給与担当者は、5月6日に年度末報酬レポートを作成するために着席します。給与システム(例:Sage 50 Payroll)は、すでに全現職従業員分のP60を生成済みです。担当者はPDFバンドルをダウンロードします。しかし、財務部長が求めるレポートはP60そのものではありません。必要なのは、以下の列を含むスプレッドシートです:従業員名、NI番号、税コード、総支給額、総控除税額、従業員NI拠出額、雇用主NI拠出額。これらの一部の項目はP60に記載されています。雇用主NIはP60にはなく、給与システムのP32レポートに含まれています。従業員の年金拠出額もP60にはなく、最終の給与明細に記載されています。つまり、担当者は従業員ごとに3つのソース文書を照合する必要があります。
120名の従業員それぞれについて、担当者は以下を行う必要があります:PDFバンドル内で従業員を特定し、総支給額を読み取って給与システムの内部レポートと照合し、スプレッドシートに入力し、控除税額を読み取って入力し、NI拠出額を読み取って入力し、その後P32レポートに切り替えて雇用主NIを確認し、給与明細PDFに切り替えて年金拠出額を確認します。各項目には約6〜8秒かかります:画面上で数字を見つけ、正しい数字であることを確認し、入力し、見返して確認する。120名×従業員あたり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の数字の入力ミスは、スプレッドシート上にとどまらない。それは波及していく。
最も直接的な経路は、従業員の確定申告書への影響だ。会計士がP60の総支給額をクライアントのSA100に誤って入力すると、税額計算が誤ってしまう。HMRCのシステムは、提出された申告書と雇用主が提出したRTIデータを照合する。不一致があれば、コンプライアンスチェックが発動する。会計士は原本のP60を探し出し、転記ミスを特定し、申告書を修正し、クライアントに訂正内容を説明しなければならない。これらの各ステップはすべて無報酬となる。
次の経路は、HMRCのコンプライアンス機構そのものへの影響だ。HMRCの記録保持要件に基づき、雇用主は関連する税年度の終了後、少なくとも3年間は給与記録を保持しなければならない。HMRCが記録を検査し、従業員に発行したP60の数字と報告に使用した内部記録の間に不一致を発見した場合、雇用主は不十分な記録に対して最大£3,000の罰則に直面する。さらに、正しい数字を再構築する義務も生じる。監査証跡のない手入力のスプレッドシートでは、これは元のソース文書からすべてを再入力することを意味する。罰則の対象となるのは、計算を誤ったことではない。計算が正しかったことを証明できないことだ。誤入力が混入したスプレッドシートは、証明にはならない。
そして、従業員に直接影響を及ぼす連鎖もある。P60は、英国の従業員が住宅ローンの申請、税額控除の請求、ビザの更新において収入を証明するための主要な書類だ。誤った数字が記載されたP60を受け取った従業員、または2枚のP60の総支給額を合算する際に計算ミスがあった従業員は、融資機関やホームオフィスが確認を求めてきた最も不適切なタイミングでエラーに気づくことになる。P60を発行した給与部門には、修正版を「複写」と明記して発行する法的義務がある。手入力ミスによって発行された複写P60の1枚1枚が、給与チームが予算化していなかった時間を消費し、本来不要であったはずの修正作業に費やされることになる。
修正期間がこの問題をさらに悪化させる。HMRCは、元の提出から6税年度さかのぼって給与修正を受け付ける。2020/21税年度のP60の数字を2021年5月に入力し、2026年に修正した場合、その誤った数字は5年間、会社の記録に残り続けることになる。その間、その数字に依存したすべてのレポート、すべての監査、すべての住宅ローン申請は、誤った数字に基づいて構築されていたのだ。単一のエラーのコストは時間とともに複利で膨らみ、消えていくことはない。
手入力によるP60入力のコストは、入力時間ではない。それは修正時間、コンプライアンス上のリスク、そして測定不能な下流への影響——申告書の修正、住宅ローンの遅延、監査上の指摘——であり、そのすべてが1つのフィールドに1桁誤って再入力されたことに起因している。
給与ソフトウェアがこの問題を解決しなかった理由
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データ抽出の完全ガイドをご覧ください。
読むよりも実際に実行したい場合は、P60からExcelへの変換ツールが単一の証明書またはフォルダ全体を受け取り、上記と同じ列セットを返します。
コンプライアンスの時計は刻々と進んでいる
5月の繁忙期だけが、P60データを手入力でスプレッドシートに入力する際の唯一の締め切りではありません。HMRCの3年間の記録保存期間により、すべてのキーストロークは少なくとも2029年4月まで会社のコンプライアンス記録に残ります。6年間の修正期間により、2031年に発見されたエラーも、元のP60まで遡って追跡できなければなりません。ソースからセルへの監査証跡がない手入力のスプレッドシートは、そのレベルの精査に耐えることはできません。
罰則の仕組みは二元的で容赦ありません。HMRCが記録を要求し、雇用主がそれを提出できない場合、HMRCは税額を推定する可能性があります。その場合、雇用主は、自分たちが保有していないと認めた記録を使って、その推定が誤りであることを証明しなければなりません。記録は存在するがエラーが含まれている場合、雇用主は不十分な記録に対して£3,000の罰則に直面します。エラーがHMRCに報告された税額に影響する場合、追加の延滞罰則が適用されます。30日時点で未納額の1%から始まり、6ヶ月と12ヶ月時点で5%に上昇します。1つのP60に入力された給与総額の単純な入力ミスが、ビューローのクライアント基盤全体に波及し、複数の税年度に持ち越されることで、キーストロークのエラーが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の「Total Pay for the Year」とBrightPayが生成したP60の「Pay for the Year」が同じデータポイントを指していることを理解します。とはいえ、劣化したコピー、手書きの修正、非標準の紙テンプレートでは精度が低下する可能性があります。一般的なP60バッチ(既知の給与ソフトウェアからのデジタルPDFと、スキャンされた紙のコピーが混在)では、抽出精度によって手作業による入力作業の大部分が削減されますが、すべての例外ケースに対応できるわけではありません。
見逃すことのコスト
英国の給与業界は、PAYEの計算、RTI提出の処理、P60の期日通りの生成のための高度なインフラを構築してきました。しかし、P60と、データが実際に使用されるスプレッドシートとの間の橋渡しは構築されていません。報酬分析、監査準備、確定申告、住宅ローン申請、その他、年度末の給与データを構造化された形式で必要とするすべての下流プロセスにおいてです。
そのギャップは、毎年5月に給与担当者の手入力によって埋められています。1フィールドあたり6〜8秒の入力自体は十分に速く、誰も疑問に思いません。1〜4%のエラー率は、それぞれが孤立したミスであり、体系的なコストではないと感じられるほど低頻度です。修正、訂正、重複P60、再発行証明書などの報告業務は「通常業務」に吸収されます。3,000万枚のP60と数千の給与部門にわたる累積コストは、これまで測定されたことがありません。測定するには、ギャップが存在することを認める必要があるからです。
最初のステップはソフトウェアを購入することではありません。時間を数え、エラーを数え、5月の問題に数字を当てはめることです。給与管理者1人。断片的なデータ入力に3日間。誤った数字に関する従業員からの修正メール5通。再発行された重複P60が2枚。解決に午後を費やすHMRCの照会が1件。一度合計してみてください。そして、ギャップのコストが、それを埋めるコストよりも低いかどうかを判断してください。