英国P60データ抽出の完全ガイド
— 給与チーム向け

P60データ抽出の実際の内容

P60データ抽出とは、年末証明書（End of Year Certificate）に記載された法定項目（従業員のNINO、雇用主のPAYE参照番号、この雇用における支払額、控除済み税額、国民保険料、最終税コード）を読み取り、会計年度ごとに従業員1人につき1行の構造化された列としてスプレッドシートに変換するプロセスです。証明書自体はHMRC仕様RD1に準拠しており、代替P60が備えなければならないすべての項目を規定していますが、視覚的なレイアウトは給与ソフトウェアプロバイダーの裁量に委ねられています。

この区別（データは必須、レイアウトは自由）こそが、抽出が一つのカテゴリとして存在する理由です。すべてのP60が同一であれば、テンプレートベースのOCRツールでも固定座標からBox 1からBox 6まで読み取ることができます。しかし、Sage 50cloudはNINOを右上に、PAYE参照番号を雇用主名の下の左下に太字で印刷するかもしれません。BrightPayはそれらを枠線付きセクションに並べて配置するかもしれません。IRIS Staffologyはすべてを縦に積み重ねるかもしれません。3つの証明書はすべて同様にHMRC準拠です。3つすべてに同じ法定項目が含まれています。そして3つすべてが、いずれか1つのために構築されたテンプレートを無効化します。

カスタム列抽出 — スプレッドシートに必要な出力列を定義し（「NINO」「この雇用における支払額」「控除済み税額」「NIカテゴリ文字」）、AIが各P60上の各値を、フィールドがどこにあるかではなくフィールドラベルの意味を理解することで特定する方式 — これにより、プロバイダーごとの設定なしで給与プロバイダー間の抽出が機能します。同じ列定義がSage P60、Xero P60、BrightPay P60、そして2023年に破綻した雇用主からのスキャン済み紙のP60も読み取ります。AIはテンプレートではなく意味によって読み取ります。

P60データ抽出が重要な理由

2003年所得税（PAYE）規則第67条に基づき、英国の全雇用主は4月5日時点で給与計算対象となる従業員全員にP60を交付しなければなりません。法定期限は5月31日です。証明書を生成した給与計算ソフトにとって、ここでワークフローは終了します。しかし給与計算チームにとっては、ここから3つの下流ワークフローが始まります。いずれも給与計算ソフトのP60生成機能では対応できません。

年末調整：FPSとの給与照合

複数の雇用主クライアントの年末調整を担当する給与計算代行機関は、全従業員のP60の数字が、Real Time Information（RTI）システムを通じてHMRCに送信された年末のFull Payment Submission（FPS）合計と一致することを確認する必要があります。照合作業は雇用主ごとに実施します。雇用主Aの全P60をスプレッドシートに抽出し、給与・税額の合計を代行機関自身のFPS抽出データと比較し、1ポンド単位で一致しない行を調査します。5社のクライアントで従業員150人の場合、750件のP60対FPSの比較が必要となり、1行の転記ミスが数カ月後にHMRCのコンプライアンスチェックで指摘される不一致を生み出します。このワークフローの詳細な手順については、英国P60データをExcelに抽出して給与照合する方法をご参照ください。

確定申告準備（1月期限、5月収集期間）

個人クライアントを担当する会計事務所は、1月31日の確定申告期限に向けて、銀行取引明細書、配当金支払証明書、P11DフォームとともにP60を受け取ります。同一課税年度に2つの雇用を同時に持つクライアントは、それぞれに雇用主のPAYE参照番号と「本雇用における給与額」が記載された2行のP60を提出します。これらはSA100税務申告書の雇用ページに直接対応し、雇用主Aの給与額が誤って雇用主Bの行に転記されるミスは、SA302照会の最も一般的な原因の一つです。英国給与計算の5月問題は、この転記作業が、会計士が全クライアントの年末書類で多忙を極める時期に集中することです。

収入確認の大規模対応

住宅ローン提供会社、賃貸業者、雇用審査会社、移民アドバイザーは、前年度の収入証明としてP60を日常的に要求します。確認作業は大量かつ限定的な項目（氏名、NINO、雇用主のPAYE参照番号、年間総支給額）に集中します。P60は申請者の雇用主が使用する給与計算プロバイダーから提供されるため、確認側はその形式を制御できません。そのため、抽出ツールが事前設定なしで任意のレイアウトを処理できるかどうかが、確認パイプラインの自動化の可否、つまり誰かが各PDFを開いて手動で数字を入力するかどうかを決定します。

P60抽出特有の課題

P60は給与明細や税務フォームと共通する抽出課題（形式の多様性、ラベルの不統一、スキャン文書とデジタル文書の品質差）を持ちますが、他の文書タイプではほとんど見られない3つの構造的問題も抱えています。抽出ワークフローを設定する前にこれらを理解しておくことで、6月に手動修正の二次対応が必要になるのを防げます。

複数の給与計算プロバイダー形式と単一の法定仕様

HMRCのRD1仕様書は、代替P60について「形式とレイアウトのバリエーション」を明示的に許可しています。Sageは法定証明書セクションを左揃えブロックで印刷し、PAYE参照番号を雇用主名の下に太字で表示します。BrightPayはNI詳細を枠線付きテーブルで区切ります。XeroはNINOを従業員住所ブロックの上に配置します。QuickBooks Onlineは税コードとNIカテゴリ文字を上部4分の1に横一列で表示します。Moorepayは3列グリッドを使用します。これら6つのレイアウトはすべて準拠していますが、テンプレートを共有するものはありません。

これは仕様の欠陥ではありません。英国の雇用主が何十年も異なる給与計算ソフトウェア（それぞれ独自の印刷エンジンを持つ）を使用してきたためであり、HMRCの規制姿勢はデータ内容を義務付け、視覚的レイアウトは義務付けないというものです。抽出における実際の影響は、Sage生成のP60で機能するテンプレートベースのアプローチが、BrightPayのP60では無意味な結果を生むことです。セマンティック抽出アプローチ（ピクセル座標ではなくフィールドの意味で読み取る）は、「この雇用における支給額」がページ上のどこに表示されても同じ意味を持つことを理解するため、単一の列定義ですべてのプロバイダーを処理できます。

退職者のP60：給与年度末に潜むエッジケース

2026年2月に退職した従業員が、同年4月5日時点で給与計算対象だった場合、退職時期にかかわらず、元雇用主はその従業員が働いた年度分のP60を発行する必要があります。元の会社がSageを使用し、転職先がXeroを使用している場合、新しい給与部門は普段扱わない形式のP60を管理することになります。さらに、前の雇用主がまだ紙の証明書を発行している場合（HMRCの規則で認められている介護・支援事業者や一部の免税団体）、P60は物理的な書類として届きます。それを誰かがスマートフォンで撮影し、給与部門にメールで送信します。その写真は、自社の給与システムから出力されたクリーンなデジタルP60と並んで、抽出処理の対象となります。

退職者のP60には年度をまたぐ影響もあります。2025年4月から2026年2月まで雇用主Aで働き、その後2026年2月から4月まで雇用主Bで働いた従業員は、同じ課税年度をカバーする2枚のP60を保有します。その年の課税所得総額は、両方の「この雇用での給与」の合計ですが、どちらのP60にもその合計は表示されません。計算は抽出後のスプレッドシートで行われ、両方のP60が正確に同じワークブックに抽出されることが前提です。どちらかの行で1桁の入力ミスがあれば、確定申告で最終的に発覚する誤った合計額が生じます。

年度をまたぐデータ：NIカテゴリ文字の問題

従業員の国民保険カテゴリ文字が年度途中で変更された場合（最も一般的なのは、年金受給年齢到達によるAからCへの変更）、P60には2つの異なるカテゴリ文字の下に2つの別々のNI行が表示されます。各行には独自の所得区分（LEL、LEL～PT、PT～UEL、UEL超）と従業員負担額があります。Sageでは、左側に文字ラベルを付けて2行を隣接表示します。Xeroでは、文字をセクションヘッダーとして別々のテーブルセクションに表示します。両方の行を単一の「NI合計」にまとめてしまう抽出システム（給与明細用に設計され、P60に後付けされたツールによく見られる）は、雇用主がRTI提出と照合するために必要なカテゴリ文字の内訳を失います。

NIカテゴリ文字のセットは限られています：A、B、C、F、H、I、J、L、M、S、V、X、Z。抽出されたスプレッドシートでこのセット以外の値があれば、転記ミスか抽出エラーです。ほとんどのP60が文字A（標準税率）を使用するため、NIカテゴリ列に「D」や「K」が混入した場合、簡単なExcel検証ルールで検出可能です。ただし、この検出は、抽出で文字が専用列に保持されている場合にのみ機能し、両方のNI行が1行に統合されて負担額が合計されている場合は機能しません。

従来手法 vs AIを活用したP60抽出

P60データをスプレッドシートに取り込む方法は3つあり、その選択によって、5月の給与処理期間がタイピングの連続になるか、ファイルのアップロードとエクスポートの流れになるかが決まります。

テンプレートベースのOCR — 従来の文書処理ツールで使われる手法 — は、文書画像上に矩形ゾーンを定義し、各ゾーン内でOCRを実行する仕組みです。A4ページ上の座標（530, 280, 700, 300）に従業員のNINOがあるSageのP60の場合、テンプレートはその矩形内に表示されるテキストを読み取ります。NINOが座標（400, 190, 600, 210）にあるBrightPayのP60では、空のセルまたは誤ったフィールド値が生成されます。英国の給与プロバイダーは根本的に異なるP60レイアウトを使用するため、テンプレートシステムにはプロバイダーごとに1つのテンプレートに加え、どのデジタルレイアウトにも一致しないスキャンした紙のP60用のフォールバックが必要です。さらに、プロバイダーが印刷形式を更新するたびに、テンプレートは静かに破綻します。

AI意味抽出はこのロジックを逆転させます。ページ上のデータがどこにあるかを定義する代わりに、スプレッドシートに必要な列名を入力して、どのデータが必要かを定義します。AIは文書全体を読み取り、税証明書の構造内での意味的役割に基づいて各フィールドを識別し、ピクセル位置に関係なく対応する列に入力します。SageのP60、BrightPayのP60、退職者の前雇用主からの紙のP60のスマホ写真はすべて、同じスプレッドシートに入力済みの行として生成されます。これは、AIが座標ではなく意味で照合するためです。これが位置ベース抽出から意味ベース抽出への根本的な転換です。

効率性の差は量が増えるほど顕著になります。P60を手動入力で1件あたり2分かけると、150人の従業員で5時間の集中転記作業が必要になります。これは、給与チームが最終EPSの処理、P32の照合、月末までに取締役会が期待するレポートの準備を同時に行う5月の時期に発生します。AI抽出では、同じ150件のP60を合計約15〜25分で処理します。手動アプローチの詳細な比較については、P60データ入力の隠れたコストをご覧ください。

抽出する主要なP60フィールド

P60には、ほとんどの抽出ワークフローで必要とされる以上のフィールドが含まれています。どのフィールドを抽出するかは、スプレッドシートが何にデータを供給するかによって決まります。ただし、フィールド自体はHMRCのRD1仕様で定義されており、各フィールドの目的を理解することで、出力が下流のタスクを解決するのか、新たな照合問題を生み出すのかが決まります。

スプレッドシート上では、150名分のP60を完全に抽出すると、すべてのNIバンドの内訳を含めた場合、およそ150行・20〜25列になります。列定義は税年度をまたいで再利用可能です。HMRCの法定フィールドセットは法改正があったときだけ変更され、変更時（2025-26年度仕様での法定新生児ケア給付の追加など）には、残りを再構築することなく新しい列を追加するだけで済みます。手作業での転記から抽出に移行する場合、列を定義する前に給与照合を危険にさらすP60データ入力ミス5選を読む価値があります。それぞれのミスは、抽出出力に組み込める列レベルのチェックに対応しています。

P60のバッチ処理を大規模に実行する

P60を1枚処理すること自体は問題ではありません。P60のフィールドを1枚分Excelに抽出するのは、自動化ではなく注意力の問題です。問題は規模が大きくなったときに発生します。従業員100名、給与プロバイダー3社、買収した会社の退職者からのスキャンされた紙のP60が数枚——この規模になると、構造上の課題は「このフィールドを読み取れるか」から「このスプレッドシートのすべての行が、正確に1つのソースドキュメントと正確に1つの税年度に遡れるか」へと変わります。

バッチ処理は、複数ファイルのワークフローを単一のアップロード＆エクスポート手順に集約します。Sage印刷、Xero印刷、スキャンした紙、スマホの写真など、すべてのP60 PDFを1つのバッチにドロップし、列名を一度定義すれば、各行が1つのP60に対応する統合スプレッドシートを受け取れます。5月31日の期限前に100枚以上のP60をバッチ処理することで、抽出はドキュメント単位の利便性から、給与チームのワークフローへと変わります。

150枚のP60を一度に処理する前に、バッチ固有の懸念事項が3つあります。

抽出したP60データのエクスポートと活用

抽出結果は、ダウンストリームのワークフローに合わせて出力する必要があります。P60データの主な出力先は3つあり、それぞれに異なる形式要件があります。

• Excel（XLSX） — 給与照合の標準形式。適切な列ヘッダー、標準化された日付形式（税年度は「2025-26」と表記）、数値として書式設定された数値フィールドで抽出データが届くため、P60抽出ハウツーガイドで紹介している検証用数式を、テキストとして保存された通貨値や結合セルに分割されたNINOを再フォーマットすることなく、すぐに適用できます。
• CSV — 給与ソフト、会計システム、または事務所独自の照合ツールへの一括インポート用。ほとんどの給与プラットフォームは報酬データのCSVインポートに対応しており、抽出でクリーンなCSVが得られれば、インポート前に手動でスプレッドシートをフォーマットする中間ステップを省略できます。
• JSON — カスタム統合、API駆動の検証パイプライン、またはRTI提出データ抽出との自動クロスチェック用。

Googleスプレッドシートで照合を行うチーム向けには、Googleスプレッドシートサイドバーアドオンが、エクスポートと再インポートのループを経ずに、抽出したP60フィールドをアクティブシートに直接書き込みます。スプレッドシート内からP60のPDFをアップロードし、列名を定義すれば、データは次の空行に配置されます。

P60データ抽出アプローチの選び方

P60抽出に重要な機能は、請求書抽出やレシートスキャンに重要な機能とは異なります。月に10,000件の請求書を処理するツールが、150件のP60にはまったく適さない場合があります。なぜなら、P60の構造（法定フィールド、NIカテゴリ文字の分割、離職者のエッジケース、年度跨ぎデータ）は、汎用抽出ツールが想定していない要求を生み出すからです。評価すべき観点は以下の通りです。

これらの評価軸はP60抽出に固有のものです。請求書処理に優れたツールでも、NIカテゴリ文字のテストで不合格になる可能性があります。給与明細を得意とするツールでも、退職者P60のエッジケースで苦戦するかもしれません。実際の書類（不完全なものも含む）を使ってテストし、本番ワークフローに導入する前に、ツールがあなたのチームが実際に受け取るP60業務（理想的なバージョンではなく）に対応できることを確認することが唯一の方法です。

よくある質問