UK P60データをExcelに抽出する方法
（給与照合用・2026年版ガイド）
毎年5月31日までに、英国の全雇用主は4月5日時点で給与計算対象となる従業員全員にP60を発行しなければなりません。つまり給与チームには、P60を生成・配布し、さらに人事システムが完全に統合されていない企業では、数十～数百の証明書に記載された同じ項目を手作業でスプレッドシートに転記して照合するための、約8週間の猶予があることになります。Sageで給与計算を行い、従業員150名、かつP60から給与ソフトへの自動連携がない中堅企業では、5月最終週に、印刷されたP60やメールで届いたP60 PDFから、給与額、源泉徴収税額、雇用主のPAYE参照番号をExcelに打ち込み直す作業に追われます。1枚あたり2分——各プロバイダーで微妙に異なるレイアウトから該当する欄を探し、NIカテゴリ文字を確認し、年間合計額がFPS提出データと一致するか照合する——これだけで、1時間単位が貴重な時期に、丸5時間もの純粋な転記作業が発生するのです。
重要ポイント
- 5月下旬の5時間：従業員150名の中堅企業では、印刷されたP60から給与額、NI番号、PAYE参照番号を照合用スプレッドシートに打ち込み直すだけで、丸1営業日を費やす。
- ボトルネックはタイピング速度ではない——すべての給与ソフト（Sage、Xero、BrightPay、QuickBooks）は、HMRCが義務付ける同じ項目を異なる視覚的レイアウトで表示するため、1桁を打ち込む前に、1枚の証明書につき25もの欄の位置を再確認する必要が生じる。
- 列を一度定義すれば——NINO、本雇用における給与額、源泉徴収税額、NIカテゴリ文字——同じ抽出列名が、あらゆる給与プロバイダーとあらゆる課税年度で機能する。なぜならAIがテンプレート上の位置ではなく、フィールドの意味を読み取るからだ。
P60に記載されている項目と、スプレッドシートで重要な理由
P60（正式名称：年末証明書）は、英国歳入関税庁（HMRC）が定める法定書類です。その内容は給与ソフトウェア設計者の提案ではなく、HMRC仕様書RD1で法律により定められており、代替P60レイアウトが特定の課税年度に必ず記載すべきすべての項目が定義されています。課税年度は4月6日から翌年4月5日までで、フォームの各項目は従業員ごとにその12か月間すべてを対象とします。
各法定項目の名称だけでなく、その目的を理解することが、抽出したスプレッドシートがフルペイメント申告書（FPS）データとの照合を一発で通過するか、午後いっぱいクロスリファレンスに費やすかの分かれ目です。以下は、給与照合作業で重要な項目を、その下流機能ごとにグループ化したものです。
本人確認・参照項目
- 従業員NINO — 国民保険番号。形式は英字2文字、数字6桁、接尾辞英字1文字（例：QQ 12 34 56 C）。HMRCのクロスリファレンスにおける従業員識別キーとして機能します。
- 雇用主PAYE参照番号 — 形式は
NNN/AAAAAAAA（3桁の税務署番号、スラッシュ、最大10文字の英数字）。各P60行を正しい雇用主エンティティに紐付けます。 - 事業所/給与番号 — 社内従業員識別子。任意ですが、同姓同名の従業員がいる場合に便利です。
給与・税額
- この雇用における給与 — この雇用主での年間総給与額。確定申告で使用される金額です。
- 控除された税金 — この雇用から控除されたPAYE所得税の総額。FPSの年度末合計と直接照合できます。
- 年間総給与額と年間総税額 — 以前の雇用と現在の雇用を合算したもの。同じ課税年度に複数の仕事をしていた従業員にとって重要です。
- 最終税コード — 例：1257L。Week 1またはMonth 1の表示が付く場合があります。年度末に適用された緊急課税区分を示します。
国民保険の詳細
- NIカテゴリ文字 — A、B、C、F、H、I、J、L、M、S、V、X、Zの限定セットから1文字。拠出率を決定します。
- 所得帯 — 最低所得限度額（LEL）、LELと一次基準額（PT）の間、PTと上限所得限度額（UEL）の間、UEL超の所得。各カテゴリ文字ごとに個別表示。
- 従業員負担額 — PT超の所得から実際に控除されるNI。
法定給付と控除
- 法定産休給付（SMP）、法定育休給付（SPP）、法定共同育児給付（ShPP）、法定養子給付（SAP）、法定親族死亡休暇給付（SPBP）、法定新生児ケア給付（SNCP） — それぞれ個別に表示。従業員が該当年に受給した場合のみ表示され、空白は「該当なし」を意味し、「該当したが0円」とは異なります。
- 学生ローン控除 — プラン1、プラン2、またはプラン4の返済額（ポンド単位）。
- 大学院ローン控除 — 学部学生ローンとは別に、異なる基準額で控除。
このフィールドセットの実際的な結果として、150人の従業員のP60抽出スプレッドシートは、NI帯域の細分化の程度に応じて、150行と約20～25列になります。そのグリッドへの手動入力（各証明書の各ボックスを探し、値を入力し、NI文字を再確認する）に5時間かかります。AIによる文書抽出は、ピクセル座標ではなくセマンティックに証明書を読み取ることで、探索と入力を不要にします。
コア抽出の原則：スプレッドシートに必要な列（「NINO」「本雇用における給与」「控除済み税額」「NIカテゴリ文字」）を指定すると、AIは各P60上の各値を、ページ上の位置ではなくフィールドの意味を理解して特定します。同じ列定義は、Sage、Xero、QuickBooks、BrightPay、その他任意の給与ソフトウェアの代替P60レイアウトでも機能します。AIがフォームテンプレートではなくラベルのセマンティクスを読み取るためです。
同じP60データでも給与計算ソフトによって見た目が異なる理由
すべてのP60が同じボックス位置、同じラベル配置、同じフォントで印刷されていれば、テンプレートベースのOCRツールで抽出は簡単に解決できる問題です。しかし、HMRCのRD1仕様書は代替フォームの「形式やレイアウトのバリエーション」を明示的に認めており、主要な給与計算ソフト各社はその許可をそれぞれ異なる形で活用しています。
Sage Payrollは従業員のNINOを右上の象限に、PAYE参照番号をその下の別ブロックに印刷するかもしれません。Xero Payrollはそれらを横並びに配置するかもしれません。BrightPayは3列グリッドを使用するかもしれません。IRIS Staffologyはすべてを1列に縦積みするかもしれません。用紙サイズ、インクの色、ボックスの配置はすべて雇用主またはソフトウェアプロバイダーの裁量に委ねられており、唯一の制約はすべての法定項目が1枚の用紙に記載されなければならないことです。
これは仕様のバグではありません。雇用主は何十年もの間、それぞれ独自の印刷エンジンを持つ異なる給与計算ソフトを使用してきたためであり、HMRCのアプローチは視覚的なレイアウトではなくデータ内容を義務付けるものだからです。抽出を行う側にとっての結果は、給与計算プロバイダーごとにP60が同じ基礎データスキーマのレイアウトバリエーションとなること、そしてSageのレイアウトで学習したテンプレートベースの抽出ツールはXeroのものでは機能しないということです。
NIカテゴリ文字のセクションは、この問題を実際の時間コストとして顕在化させます。従業員のNIカテゴリ文字が年度途中で変更された場合（例えば、年金受給年齢到達によりAからCへ）、P60は異なるカテゴリ文字の下に2つの別々のNI行を表示しなければなりません。Sageはこれらを左側に文字ラベルを付けた2つの隣接行として印刷するかもしれません。Xeroは文字をセクションヘッダーとした別々のテーブルセクションとして印刷するかもしれません。「列1にNI文字がある行」を探すテンプレートは一方の形式をキャッチしても他方を見逃します。意味ベースの抽出 — 位置ではなく意味で読み取る — は、「NIカテゴリ文字」が視覚的な表示方法に関係なく列の値であることを理解するため、両方のレイアウトを処理できます。
P60抽出ワークフローの設定
手動でのP60転記を置き換えるワークフローは3つのステップで構成され、設定ステップ（列の定義）は一度行えば、すべての税年度、すべての給与計算プロバイダー、すべての従業員バッチで再利用できます。
出力列を定義する
抽出したいフィールド名を、スプレッドシートの列見出しとして表示したい形式で入力します。照合用ワークブックの場合、実用的な初期セットは次のとおりです：従業員名、NINO、雇用主PAYE参照番号、最終税コード、この雇用での給与、控除された税金、年間総給与、年間総税金、NIカテゴリ文字、従業員NI拠出金、学生ローン控除、大学院ローン控除、法定出産手当、法定父親手当、雇用主名。これはカスタム列抽出です：出力スキーマを定義すると、AIが各ドキュメントのフィールドを列にマッピングします。AIはテンプレートの位置ではなく意味的な意味でマッチングするため、同じ列名がすべての給与計算プロバイダーのP60レイアウトで機能します。
すべてのP60 PDFを一括アップロードする
フォルダ全体をドロップします。150のPDF、Sage印刷、Xero印刷、および古い給与年度のスキャンされた紙のP60が混在しています。バッチ処理はこれらすべてを1つのジョブで処理します。各ファイルは独立して処理され、すべての結果が1つの統合スプレッドシートにマージされます。ファイルは給与計算ソフトからのPDFエクスポート、印刷されたP60のスキャン、または証明書のスマホ写真でも構いません。AIは3つの入力タイプすべてを処理します。
エクスポートと検証
Excelファイルをダウンロードします。従業員ごと、税年度ごとに1行、列は定義した順序で表示されます。次のセクションで説明する検証チェックを実行して、元のP60と照合する価値のある行を特定します。エクスポートは、給与計算照合ツールに直接インポートするためのCSV、またはAPI駆動の監査ワークフローを使用するチーム向けのJSONとしても利用できます。
このワークフローは、任意の従業員数と任意の給与計算プロバイダーの組み合わせで機能します。列定義は税年度をまたいで再利用可能です。HMRCの法定フィールドセットは、法改正があった場合のみ変更されます（2025-26年度仕様での法定新生児ケア給付の追加など）。その場合は、残りの部分を再構築することなく、新しい列を定義に追加するだけです。
年末に元が取れる3つのP60抽出ワークフロー
P60の抽出作業は、大きく3つのパターンに分類され、それぞれバッチの形状と出力の重点が異なります。ワークフローに適した出力構造を選ぶことで、単なる「データ抽出ツール」が、毎年5月にチームが実際に使うものに変わります。
確定申告準備（3月～5月の期間）
個人顧客を抱える会計事務所は、1月31日の確定申告提出期限に向けて、銀行取引明細書、配当金支払通知書、P11DとともにP60を受け取ります。複数の雇用を同時に持つ顧客は、同じ課税年度に2つ以上のP60行を生成します。このワークフローで重要な列は、「年間総支給額」「控除済み税額」「国民保険番号」「雇用主PAYE参照番号」で、これらはSA100税務申告書の「雇用」ページに直接対応します。パートタイムの仕事を2つ持つ顧客は2行を生成し、各P60の「年間合計」列が、申告書に個別に入力する必要のある数値を示します。
これはP60抽出において最もボリュームの多い期間です。なぜなら、事務所が最も多くの顧客書類を最も短い時間で処理するからです。ここで手動入力を置き換えることは、時間を節約するだけでなく、SA302照会の最も一般的な原因、つまりあるP60の給与額を別の雇用の行に入力してしまう転記ミスを排除します。
給与計算代行機関のFPS提出との照合
複数の雇用主顧客の年末処理を行う給与計算代行機関は、各従業員のP60の数値が、HMRCに送信された年末の完全な給与支払報告書（FPS）の合計と一致することを確認する必要があります。照合は雇用主ごとに実行します。雇用主AのすべてのP60をスプレッドシートに抽出し、給与と税額の合計を、代行機関自身のその雇用主のFPS抽出データと比較します。列の配置が差異を意味あるものにします。P60の「この雇用での給与」列がFPSの「総給与」列の隣にあれば、差異の計算式は行ごとに1回の減算で済みます。
このワークフローでは、国民保険カテゴリ文字列が特に重要です。従業員のカテゴリが年度途中でAからCに変わった場合、P60には異なるカテゴリで2つのNI行が表示されます。代行機関の照合では、総拠出額がFPSと一致することを確認するために両方の行が必要です。両方の行を1つの数値にまとめた「NI合計」列だけでは、HMRCが数か月後に指摘する可能性のあるカテゴリ文字の不一致が隠れてしまいます。
収入確認のスケール対応
住宅ローン提供者、賃貸業者、雇用審査会社、移民アドバイザーは、前年度の収入証明としてP60を日常的に要求します。この確認ワークフローは大量処理かつ狭いフィールドに特化しています。氏名、国民保険番号、雇用主PAYE参照番号、年間総支給額です。その他の法定項目（法定支給額、学生ローン控除、国民保険の階級別内訳）は出力に参考データとして残りますが、確認の判断は支給額と、それを実在の事業体に結びつける雇用主参照番号に基づきます。
このワークフローでは、馴染みのない給与計算プロバイダーからのP60が頻繁に登場します。申請者が、確認担当者が一度も見たことのないニッチな給与システムを使用する雇用主のP60を持ち込む可能性があります。そのため、事前設定なしで任意のレイアウトを処理できる抽出ツールの能力こそが、確認パイプラインを自動化できるか、誰かが各PDFを開いて手動で数字を入力しなければならないかを決定します。
抽出したP60データを給与計算スプレッドシートに反映する前の検証
高い抽出精度であっても、オペレーターは後続の調整や確認チェックに対して、妥当性の確認を行う義務があります。以下のチェックはP60に特化しており、Excelで列ごとに実行します。すべての行のすべてのフィールドを監査する必要はありません。これらは、元のP60と照合する価値のある数行を浮き彫りにするための形状チェックです。
| チェック項目 | 確認内容 | Excel数式（2行目、下方向にドラッグ） |
|---|---|---|
| 国民保険番号の形式 | 英字2文字、数字6桁、末尾に接尾英字1文字（A～D）。無効な先頭文字：D、F、I、Q、U、V。2文字目にOは不可。 | =AND(LEN(A2)=9,NOT(ISERROR(SEARCH("??######?",""&A2)))) — 非準拠行をフラグ |
| PAYE参照番号の形状 | 数字3桁、スラッシュ、最大10文字の英数字。 | =AND(LEN(B2)>=5,ISNUMBER(VALUE(LEFT(B2,3))),MID(B2,4,1)="/") |
| 国民保険カテゴリ文字の所属 | A、B、C、F、H、I、J、L、M、S、V、X、Zのいずれかである必要があります。これ以外はデータ品質フラグです。 | =NOT(ISERROR(MATCH(C2,{"A","B","C","F","H","I","J","L","M","S","V","X","Z"},0))) |
| 税額と支給額の比率 | ほとんどの税コードでは、控除された税額は支給額の約10～30％であるべきです。この範囲外の行は、より詳細な確認が必要です。自動的に誤りとは限りませんが、元の文書と照合する価値があります。 | =AND(D2/E2>0.1,D2/E2<0.3) — 外れ値に条件付き書式設定 |
| 法定支給額の空欄とゼロの区別 | 空欄セルは空欄のままにすべきです。ゼロは、フォームにゼロが印刷されている場合にのみ表示されるべきです。空欄を強制的にゼロに変換すると、雇用主の国民保険調整で架空の還付額が発生します。 | 空チェック列に条件付き書式ルールとして =ISBLANK(F2) を適用 |
| 学生ローンプランの妥当性 | 控除が存在する場合、プランタイプを借り手の既知のプランと照合します。プラン1の借り手に対するプラン2の控除は、抽出エラーまたは給与計算コードエラーの可能性を示します。 | 手動クロスリファレンス。予期しないプランコードがある行をフラグ |
このチェックリストが絵空事ではなく実用的である理由は、抽出されたデータがすでに列構造化されているからです。各行には元のファイル参照が含まれているため、フラグが立った行は元のP60にワンクリックでアクセスできます。手作業による転記では、このような列レベルのチェックを企業規模で維持することは決してできず、抽出こそが検証パスを現実のものにするのです。
P60とW-2の違い：英国・米国チームが知っておくべきこと
英国の給与チームが初めて米国の税務フォーム抽出ツールに触れる場合、あるいは米国企業に英国子会社がある場合、P60は実質的に英国版W-2なのかとよく尋ねられます。簡単に言えば、両者は同じ機能（年度末の従業員所得証明書）を果たしますが、構造、フィールドセット、およびその後の使用方法が異なり、抽出設定に影響を与えます。
W-2は、連邦賃金（Box 1）、社会保障賃金（Box 3）、メディケア賃金（Box 5）、および州レベルの内訳を20の番号付きボックスで報告します。すべて暦年（1月1日～12月31日）を対象とします。P60は、4月6日から4月5日までの課税年度の課税所得とPAYE税を報告し、国民保険はカテゴリ文字と所得帯で表示され、定率控除ではありません。W-2には、NIカテゴリ文字、法定給与の内訳、学生ローン計画の区分はありません。P60には、州レベルの報告や社会保障/メディケアの区分はありません。
抽出における影響は、2つのフォームタイプに異なる列定義が必要になることです。W-2の列セットはすべての米国雇用主のW-2で機能し、P60の列セットはすべての英国給与プロバイダーのP60で機能します。しかし、2つの列セットは識別フィールド以外で重複せず、P60を異なるボックス番号のW-2として扱うと、抽出後の大幅な再フォーマットが必要なスプレッドシートが生成されます。
両方を扱う企業は、米国側のワークフローについてはW-2および1099税務フォーム抽出の完全ガイドを参照し、フォームタイプごとに個別の列定義を使用してください。バッチ処理のアプローチ（ファイルのアップロード、列の定義、スプレッドシートのエクスポート）は同じですが、列名は市場固有です。
NI vs FICA：英国の国民保険（NI）は米国のFICAとは異なります。NIには、拠出率を決定する複数のカテゴリ文字、異なる閾値を持つ所得帯、および従業員の年間計算構造（給与期間ごとではない）があります。米国のフォームで「NI」という列名や英国のフォームで「Social Security」という列名を使用すると、意味のない結果が生成されます。市場固有のフィールド名を使用してください。
よくある質問
スマホで撮影した紙のP60からデータを抽出できますか？
はい。AIが対応します。印刷されたP60をスマホで撮影した場合でも、照明が不均一だったり少し傾いていたりするスキャン画像でも、証明書の文字が肉眼で読める状態であれば問題ありません。これは、従業員が以前の雇用主から紙のP60を持参し、給与チームがそれをデジタル化して照合スプレッドシートに取り込む必要がある一般的なシナリオに対応します。
異なる課税年度でも抽出は機能しますか？
はい。HMRCの法定P60フィールドセットは課税年度間で安定しており、2018-19年度から2025-26年度までのすべてのP60に同じフィールドが表示され、わずかな追加（2025-26年度に法定新生児ケア給付が追加されました）のみです。現在の課税年度用に構築された列定義は、過去の年度のP60でも修正なしで機能します。課税年度自体はフォームに印刷された値として表示され、抽出列として含めることで、同じスプレッドシート内の異なる年度の行を区別できます。
同じ課税年度に従業員が複数の雇用主からP60を持っている場合はどうなりますか？
各P60は出力スプレッドシートの個別の行になります。2つの仕事を持つ従業員は、雇用主ごとに1行ずつ、合計2行が生成されます。雇用主PAYE参照列により、どのP60がどの雇用主からのものかが区別されます。各P60の年間総支給額と年間総税額の数値には合計が含まれますが、この雇用先での支給額と控除済み税額の列には、その特定の雇用主からの数値のみが報告されます。これは設計上の意図です。HMRCのP60仕様では各雇用を独立した証明書として扱い、抽出では行をマージしようとせずにその構造を維持します。
年度途中のNIカテゴリ文字の変更はどのように処理されますか？
課税年度中に従業員のNIカテゴリ文字が変更された場合（最も一般的なのは、年金受給年齢に達したことによるAからCへの変更）、P60には異なるカテゴリ文字の下に2つの別々のNI行が表示されます。抽出では両方の行が保持されます。NIカテゴリ文字列には両方の文字が含まれ（抽出ツールの出力形式に応じて、別々の行または区切り値として）、収入帯列には分割された金額が表示されます。これは正しい動作です。両方の行を単一の「NI合計」数値にまとめると、雇用主がRTI提出と照合する際に重要なカテゴリ文字の内訳が失われます。
手書きのP60や注釈付きの証明書も読み取れますか？
AIは印刷されたテキストを高精度で処理します。機械印字の代替フォームも含みます。印刷されたP60への手書き注釈（例：給与管理者が鉛筆で修正したもの）は、信頼度が低くなる可能性があり、手動確認が必要です。現在、P60専用の手書き最適化モードは提供していませんが、印刷物やデジタル生成の証明書では良好に機能します。
従業員のP60データは抽出中に安全ですか？
P60には、NINO、給与額、雇用主参照情報などの機密性の高い個人データが含まれます。責任ある抽出プラットフォームは、転送中および保存中のファイルを暗号化し、アップロードされた書類をAIモデルのトレーニングに使用せず、処理後、定められた保存期間内にソースファイルを自動削除します。給与データ用の抽出ツールを評価する際は、従業員の書類をアップロードする前に、これらのセキュリティ条件を確認してください。
抽出データをExcelではなくGoogleスプレッドシートに直接出力できますか？
はい。Excel（XLSX）およびCSVエクスポートに加えて、抽出結果はGoogleスプレッドシートアドオンを介して直接Googleスプレッドシートに書き込むことができます。つまり、スプレッドシートで調整を行う給与チームは、サイドバーからP60のPDFをアップロードし、列を定義して、スプレッドシートから離れることなく構造化データをアクティブシートに追加できます。
P60調整を5月28日に終えるか、6月第一週に持ち越すかの差は、5時間のタイピング作業です。列を一度定義すれば、あとはスプレッドシートが自動入力します。
初めてのP60一括抽出サンプルファイルでのテストは登録不要。ファイルは自動削除され、安全に処理されます。