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

P60データ抽出とは

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

この「データは必須、レイアウトは自由」という区別こそが、抽出が独立したカテゴリーとして存在する理由です。もしすべてのP60が同一の外観であれば、テンプレートベースのOCRツールでBox 1からBox 6を固定座標から読み取れます。しかし、Sage 50cloudはNINOを右上、PAYE参照番号を雇用主名の下に太字で左下に印刷するかもしれません。BrightPayはそれらを枠線付きセクションに並べて配置するかもしれません。IRIS Staffologyはすべてを縦に積み重ねるかもしれません。これら3つの証明書はすべてHMRCに準拠しており、すべて同じ法定項目を含んでいます。そして、いずれか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を実行します。Sage P60で従業員のNINOがA4ページの座標(530, 280, 700, 300)にある場合、テンプレートはその矩形内のテキストを読み取ります。BrightPay P60でNINOが座標(400, 190, 600, 210)にある場合、空のセルか誤ったフィールド値が生成されます。英国の給与プロバイダーは根本的に異なるP60レイアウトを使用するため、テンプレートシステムはプロバイダーごとに1つのテンプレートと、デジタルレイアウトに一致しないスキャン紙P60用のフォールバックが必要です。さらに、プロバイダーが印刷形式を更新するたびに、テンプレートは静かに破綻します。

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

効率の差は量が増えるほど顕著になります。手動入力でP60あたり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の一括バッチ処理

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

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

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業務（理想的なバージョンではなく）に対応できることを確認することが唯一の方法です。

よくある質問