100件以上の英国P60を5月31日までに
監査用スプレッドシート1枚に、手入力なしで
2003年所得税（給与からの源泉徴収）規則のRegulation 67（SI 2003/2682）に基づき、英国のすべての雇用主は4月5日時点で給与計算対象の各従業員にP60を提供する義務があり、5月31日の期限は給与ソフトウェアではなく法律で定められています。P60自体がボトルネックではありません。Sage 50cloud、BrightPay、QuickBooks Online、Moorepay、IRISはいずれも数秒で準拠した証明書を生成します。ボトルネックはその次の段階です。つまり、100件以上のそれらのPDF（紛失した従業員からのスキャン紙媒体、HMRCポータルのスクリーンショットも含む）を、月次終了前に年間のFull Payment Submissionと照合する1枚のスプレッドシートに統合する作業が必要になります。証明書1件あたり2分の手動ワークフロー（PDFを開き、Box 1からBox 6を特定し、スプレッドシートの行に転記）では、150人の会社は5月の給与計算期間の5時間を単純なコピー＆ペーストに費やすことになります。しかも、年度途中で給与ソフトウェアを変更していない、3月に退職者が出ていない、スキャンされたP60が150 DPIで印刷されていない、という前提での話です。
重要なポイント
- 英国法では、雇用主は各従業員に5月31日までにP60を発行する義務があります。複数の給与プロバイダーを利用する150人の会社の場合、「PDFを開いてExcelにコピーするだけ」という作業は、給与計算カレンダーで最も忙しい月に5時間もの単純な転記作業を意味します。
- 100件規模での真のボトルネックはファイル処理速度ではなく、列の設計です。つまり、ID列（NI Number + PAYE Reference）、財務列（給与、税金、NI拠出）、検証列（税コード種別、NIカテゴリチェック）の3セットを用意し、すべての行を監査可能にし、スプレッドシートのマージを単純な追加操作にすることです。
- その列スキーマを一度定義し、給与プロバイダーや税年度に関係なくすべてのバッチに同じ名前を適用すれば、Sageの100行とBrightPayの50行のマージは垂直に積み重ね可能な操作になります。列の再マッピング、プロバイダー別テンプレート、どの行がどの雇用主に属するかという推測は不要です。
100枚以上のP60が1枚とは根本的に異なる問題である理由
P60を1枚処理するのは解決済みの問題です — その項目をExcelに抽出するには、ツールではなく注意力が必要です。PDFを開き、法定欄を探し、7〜8個の数字を1行に入力して、次へ進みます。しかし、ボリュームが加わると — 従業員100人、給与計算プロバイダー3社、紙の証明書を持った買収企業の退職者数名 — 問題は速度ではなく、構造に関するものになります。
証明書が1枚だけのケースでは、一回限りのP60からExcelへの変換で十分です。以下の問題は、フォルダが大きくなり誰も目視で行を確認できなくなって初めて発生します。
100枚以上の規模になると、単一ドキュメントの規模では存在しない3つの構造的問題が現れます。いずれも、ファイル処理を高速化しても解決しません。
1. プロバイダー間のレイアウトの相違
Sage 50cloudのP60は、従業員情報を左揃えで表示し、PAYE参照番号を雇用主名の下に太字で表示します。BrightPayのP60は、法定証明書セクションを枠線で囲んで区切ります。QuickBooks OnlineのP60は、NI番号を従業員の氏名の隣ではなく、住所ブロックの上に印刷します。手動で転記する給与管理者にとって、各レイアウトは視覚的な再確認を必要とします — 入力を始める前に、このプロバイダーの表示形式で各欄がどこにあるかを確認する必要があります。3つのプロバイダーに分かれた100枚のP60では、この視覚的な再確認コストだけで — 1枚あたり約10秒の方向確認 — 転記のキー入力1回前に、15分の無駄な時間を消費します。
2. 監査規模での行の出所
100枚のP60を100行のスプレッドシートに抽出する場合、各行は正確に1つのソースドキュメントと1つの税年度にトレース可能でなければなりません。出力されたスプレッドシートに「総支給額」列があり、£38,450という数字が入っていても、どの従業員のP60からその数字が生じたかを特定する列がなければ、そのスプレッドシートは監査の資産ではなく、監査上の負債です。HMRCのコンプライアンスチェックでは、調査官はあなたの照合表の任意の数字の根拠となるP60を要求できます。抽出自体に1行ごとのソースのトレーサビリティが組み込まれていなければ、スプレッドシートのセルをPDFと手動で照合することになり — これは当初の抽出よりも時間がかかります。
3. ボリューム時の例外処理
100枚のP60のバッチでは、3〜5枚が例外ケースになります。P45なしで年度途中に入社したため、Week 1 / Month 1税コードの従業員。1月から3月まで働いた退職者 — 4月5日に雇用されていたためP60を受け取る権利がある — だが、その証明書は会社がもはや使用していない給与プロバイダーによって生成された。2023年の買収による紙のP60で、PAYE参照番号が現在の会社ではなく、買収した事業体に属している場合。手動のワークフローでは、これらを1つずつ見つけ出します。バッチワークフローでは、見逃した例外はすべて、HMRCが監査できる照合スプレッドシートの誤った数字になります。
これらの問題にはすべて、5月のデータ入力スタッフを追加雇用せずに済む解決策があります。その解決策とは、バッチワークフローを設計する際に、出力先がスプレッドシートではなく監査記録であるかのように設計することです。つまり、ファイルの準備から列スキーマに至るまで、6か月後に原本を作成しなかった誰かが読む監査記録として設計するのです。
複数フォーマットの現実：SageとBrightPayは150DPIスキャンとは別物
HMRCはP60のレイアウトを単一に定めているわけではありません。定めているのは内容です。specification RD1に基づき、代替P60には特定の欄（従業員名、NI Number、PAYE参照番号、年間総支給額、年間総控除税額、学生ローンの控除額、最終税コード、雇用主情報）を表示する必要がありますが、視覚的な配置は各給与ソフトウェアベンダーに委ねられています。その結果、Sage 50cloudのP60はBrightPayのP60とは構造的に異なり、QuickBooks Online PayrollのP60とも異なり、MoorepayのP60とも、IRISのP60とも異なります。さらに、原本を紛失した従業員から提供されるスキャン済みの紙のコピーが加われば、なおさらです。
従来のテンプレートベースの抽出（サンプルP60のフィールドの周囲に矩形を描く方法）では、各給与プロバイダーごとに個別のテンプレートが必要になるため、この問題に対応します。5つのプロバイダーを維持するなら、5つのテンプレートを維持する必要があります。プロバイダーが新しい税年度に向けてP60レイアウトを更新すると（新たなHMRCガイダンス、リブランド、フォーマット変更）、テンプレートは静かにずれた出力を生成します。給与管理者がこの問題に気付くのは、FPS合計との照合が一致しなくなったときです。
セマンティック抽出は、位置ではなく意味でドキュメントを読み取ることで、プロバイダーごとのテンプレート問題を排除します。必要な列を一度定義するだけで（「NI Number」「年間総支給額（£）」「控除税額（£）」「PAYE参照番号」「最終税コード」）、AIはデータが何を表しているかを理解することで、各P60上の各値を特定します。つまり、ページ上のどこにあるかではなく、データの意味を理解するのです。Sage 50cloudのP60、BrightPayのP60、QuickBooksのP60、2023年のスキャン済み紙のP60 — すべて同じ列定義に取り込まれます。UKのP60の個々のフィールドと、抽出中に各フィールドがどのように動作するかについての詳細な解説は、単一P60抽出ガイドから始めてください。この記事はその続きから始まります：P60を一つずつ考えるのをやめたときに何が起こるか、です。
UKの給与処理の文脈でこれが特に価値があるのは、PAYE参照番号（形式は123/AB456）が、どの給与ソフトウェアで作成されたかにかかわらず、同じ雇用主からのすべてのP60で一貫しているためです。正社員にはSage、契約社員にはBrightPayを使用している会社は、同じPAYE参照番号が記載されているものの、視覚的に異なる2つの形式のP60を発行することになります。セマンティック抽出は、レイアウトではなく値を読み取ります。出力スプレッドシートの「PAYE参照番号」列は、両方のプロバイダーで同じように入力され、複数プロバイダーのバッチをグループ化する自然なキーとなります。
ファイル命名のスケール化：すべての行をソースまで追跡可能にする
バッチP60ワークフローにおいて最も効果的な決定は、ファイルをアップロードする前に行われます。それは、ソース文書の命名方法です。出力スプレッドシートに100行あり、3か月後にHMRCのコンプライアンス担当者が「47行目の基となるP60を見せてください」と求めた場合、「スプレッドシートをダウンロードフォルダと照合する必要があります」という回答では不十分です。すぐに特定できるファイル名が必要です。
監査トレーサビリティに役立つ命名規則には、次の3つのコンポーネントが含まれます。
従業員識別子
NI番号は、英国の給与記録における自然な主キーです。一意で永続的であり、すべてのP60に表示されます。これをファイル名のプレフィックスとして使用すると、即座に検索キーが得られます。AB123456CはHMRCの記録に直接マッピングされます。NI番号を使用できない場合（データ保護ポリシー）、従業員の給与IDを使用しますが、マッピングテーブルを追加してください。
税年度
P60は4月6日から4月5日までの税年度を対象としています。ファイル名には、どの年度かをエンコードする必要があります。2025-26またはFY2526です。これにより、最も一般的なバッチ再編成の災害を防ぐことができます。つまり、6か月間隔で同じディレクトリに保存されたために、2024-25年度と2025-26年度のP60が同じフォルダに混在してしまうことです。複数の税年度のファイルを別々のスプレッドシートにバッチ処理する場合、ファイル名の年度だけが相互汚染を防ぐ唯一の手段です。
プロバイダーまたはソースタグ
スプレッドシート自体には必須ではありませんが、照合の際には非常に貴重です。_sageや_bpのようなファイル名のサフィックスは、5月の3週間後に誰かが23行目のBox 5の数字がFPSデータと矛盾している理由を尋ねたとき、23行目がBrightPayからのものであることを示します。BrightPayには既知のエクスポート丸めの違いがある可能性があります。プロバイダータグは、説明のつかない異常を既知の動作パターンに変えます。
結果として得られるファイル名パターン — AB123456C_2025-26_sage.pdf — は、監査証跡をファイル名自体に埋め込みます。抽出ツールが出力でファイル名を保持する場合（ImageToTable.aiにはバッチエクスポートにデフォルトで「ファイル名」列が含まれています）、スプレッドシートのすべての行には独自の来歴が含まれます。外部の相互参照は不要です。
複数のPAYEスキームにわたって従業員を管理する給与チーム（20のクライアントエンティティの給与を管理するアンブレラ会社、または各子会社が独自のPAYE参照を持つグループ構造）の場合、PAYE参照形式123/AB456が自然なバッチグループ化キーになります。123/AB456を持つすべてのP60を1つのバッチで処理し、456/CD789を持つすべてのP60を別のバッチで処理します。各バッチの出力のPAYE参照列は、後で2つのスプレッドシートをマージする際のピボットポイントとして機能します。行がどの雇用主に属するかを推測する必要はありません。
退職者・元従業員・P60の法的発行対象者
HMRCのルールは明確です。課税年度の4月5日時点で給与計算対象となっているすべての従業員は、5月31日までにP60を受け取る必要があります。これには、課税年度中に退職したものの、4月5日時点で在籍していた従業員も含まれます。3月30日に辞職し、4月4日まで勤務した従業員はP60を受け取ります。3月31日に退職した従業員は受け取りません。この区別は重要であり、どちらかの方向で誤ると監査上のリスクが生じます。
100件のP60バッチにおいて、退職者のケースは4つのカテゴリに分類されます。各カテゴリによって、バッチに含める内容とその後の確認内容が変わります。
4月5日在職 → その後退職
P60を受け取ります。証明書は全課税年度を対象とし、バッチに含める必要があります。「最終税コード」欄には、6月に退職した場合でも、年度末時点で有効だったコードが表示されます。
4月5日以前に退職 → P60なし
P60ではなくP45を受け取ります。古いHRシステムのエクスポートにより、退職者の給与記録がバッチに残っている場合、調整前に除外する必要があります。そのデータは別の報告義務に属します。
再発行を求める元従業員
HMRCは、雇用主に対し、求めに応じてP60の再発行を義務付けています。住宅ローンの申請で2023-24年度のP60が必要な元従業員から連絡がある場合があります。その証明書は2年前に発行され、現在は利用していない給与計算プロバイダーによるものかもしれません。P60の法定情報は変わりませんが、スキャンしたPDFやアーカイブされたSageのバックアップとしてのみ存在する可能性があります。
買収企業の従業員
A社が10月にB社を買収した場合、前年の4月5日時点で給与計算対象だったB社の従業員は、後継雇用主であるA社からP60を受け取る必要があります。ただし、買収前の月についてはB社のPAYEスキームを参照する可能性があります。発行されるP60には、TUPE移転の構造に応じて、旧PAYE参照、新PAYE参照、またはその両方が記載される場合があります。これらのP60を「旧PAYE Ref」専用列とともにバッチに含めることで、複雑さを1行で捉えることができます。
監査上の落とし穴は、P60を発行し忘れることではありません。発行すべきでない人にP60を発行すること、または発行すべき人に発行しないことです。どちらのエラーもFPS調整に波及し、コンプライアンスハンドブックCH40000に基づくHMRCのコンプライアンスチェックにより、給与計算ソフトウェアよりも早く不一致が明らかになります。
実用的な対策は、「P60ステータス」という推論列を追加することです。AIが各文書の内容に基づいて分類します。「4月5日在職」「4月5日以降退職」「前年度再発行」「P60非該当」などの値により、調整前に出力を並べ替え、レビューや除外が必要な行にフラグを立てることができます。抽出に1列追加するだけで、手動でのクロスチェックにかかる1時間を節約できます。
100行スプレッドシートの監査対応カラム設計
バッチアップロード前に定義するカラム名は、ワークフロー全体で最も重要な判断です。5名のテストバッチ用に設計したカラムスキーマは、100行では機能しないことがよくあります。これは、大量データ特有のエッジケース（PAYEスキーム間でのNI番号重複、年度途中の税コード変更、プラン別の学生ローン控除）を考慮していないためです。
100行の監査に耐えるカラムスキーマは、出力においてそれぞれ異なる機能を持つ3種類のカラムで構成されます。
1. 識別カラム — 各行を一意にする複合キー
NI番号、従業員名、PAYE参照、課税年度。これら4つのフィールドが複合キーを形成します。スプレッドシート内で同じ組み合わせの行が存在してはいけません。NI番号だけでは不十分です。同一課税年度に2つのPAYEスキームで働いた従業員（グループ構造でよくあるケース）は、同じNI番号でも異なるPAYE参照を持つ2枚のP60が発生します。識別ブロックにPAYE参照を含めることで、これらの行の衝突を防ぎます。
2. 財務カラム — FPSと照合する金額
年間総支給額(£)、年間総所得税控除額(£)、従業員NIC(£)、雇用主NIC(£)、学生ローン控除額(£)、法定支給額(£)。これらのすべてが、課税年度のFull Payment Submissionの該当行と一致する必要があります。バッチP60抽出における最も一般的な照合エラーは、P60のBox 2（総所得税控除額）と最終FPSのYTD税額の不一致です。これは通常、最終FPS提出後に手動の税コード調整が適用されたために発生します。
3. 検証カラム — 照合前に異常を検出する計算済みクロスチェック
これらのカラムはP60には表示されませんが、抽出中に計算され、不一致を表面化させます。「税コードチェック」カラムは、非標準コード（1257L、BR、D0、D1などの累積コード以外）にフラグを立て、どの行を手動レビューすべきかを即座に示します。「NIカテゴリチェック」カラムは、カテゴリA（適用除外制度に加入していない被雇用者の標準カテゴリ）以外にフラグを立て、カテゴリB、C、J、Zの従業員を表面化させます。これらはそれぞれ異なる拠出率を持ち、特別な給与取り決めを示す可能性があります。これらの検証カラムは、AIが財務数値を読み取る同じ抽出パス中にデータを入力するため、転記作業は一切発生しません。
複数の雇用主にわたってP60を管理する給与チームにとって、「PAYE参照」カラムはバッチグループ化キーと照合ピボットの両方の役割を果たします。PAYE参照で出力をフィルタリングし、総支給額と総所得税控除額のカラムを合計して、各雇用主のP35（雇用主年次申告書）合計と比較します。AIはPAYE参照の形式を理解する必要はありません。表示された文字列をそのまま読み取ります。英国のPAYE参照は一貫したNNN/XXNNNNNパターン（PAYE20005）を使用するため、出力は自然にソートおよびフィルタリング可能です。
バッチ規模では、税コードの取り扱いに特に注意が必要です。2025-26年度の標準的な累積税コードは1257Lです（£12,570の個人控除額を反映）。しかし、バッチ処理を行うと、100人の従業員のうち標準からどれだけ多くの逸脱があるかが明らかになります。Kコード（控除額が控除額を上回る）の従業員は、1257Lの従業員とは根本的に異なる税務処理を受けます。P60にBR（基本税率）コードが表示されている従業員は、おそらく2つ目の収入源に対して課税されています。NT（非課税）の従業員は、非居住を確認するP85をHMRCに提出した可能性があります。1257Lで「X」サフィックスが付いた5人の従業員は、非累積（月1）ベースに置かれています。つまり、その年の累計額が年間通算の計算を表していない可能性があります。「最終税コード」という1つの列に、これらすべてが表示されます。2つ目の計算列「税コードタイプ」では、AIが各コードを「累積」「非累積」「BR/D0/D1」「Kコード」に分類し、コードのスプレッドシートを税務状況のスプレッドシートに変換して、ワンクリックでフィルタリングできるようにします。
複数の雇用主と税年度にわたるP60データの統合
バッチ抽出では、バッチごとに1つのスプレッドシートが生成されます。3つのPAYEスキーム（それぞれ独自の123/AB456形式の参照番号を持つ）にわたってP60を管理する給与チームは、3つのスプレッドシートを手にすることになります。統合ステップは、抽出列の構造設計が成果を生むか、崩れるかの分岐点です。
すべてのバッチで同じ列名（「NI番号」「従業員名」「PAYE参照」「税年度」「年間総支給額（£）」「年間総控除税額（£）」）を使用していれば、3つのスプレッドシートは列の再マッピングなしで縦に積み重ねられます。各シートの「PAYE参照」列は、各行がどの雇用主に属するかを識別するため、統合されたスプレッドシートはPAYE参照でピボットして、雇用主ごとの合計を算出できます。これがバッチ間で列名を標準化する目的のすべてです。統合は列マッピングの作業ではなく、追加操作になります。
ファイルの整理、バッチアプローチの選択、下流での使用に向けた出力の構造化といった、より広範なワークフローの質問については、完全なバッチOCRワークフローガイドで、複数のドキュメントタイプにわたるファイル準備、ツール選択、出力の構造化について説明しています。ここで説明するP60固有の列スキーマは、その一般的なフレームワークに組み込まれます。
統合に固有のエッジケースが1つあります。同じNI番号で異なるPAYE参照を持つ2つのバッチに登場する従業員です。これはエラーではありません。同じ税年度に2つの仕事を持っていた従業員です。雇用主AのP60は一方の雇用の収入と税を示し、雇用主BのP60はもう一方の雇用の収入と税を示します。1つのスプレッドシートに統合された場合、これら2つの行は集計すべきではありません。「PAYE参照」列があることで、別々の雇用を表す2つのP60を合算することを防げます。これがないと、「年間総控除税額（£）」の単純な合計は、どちらの雇用主のP35とも一致しない数値になり、HMRCの調整が成立しません。
よくある質問：英国P60の一括処理
スキャンした紙のP60でも一括抽出は可能ですか？
はい — セマンティック抽出は文書のデジタルメタデータではなく、テキストコンテンツを読み取ります。2022年の紙のP60を150 DPIでスキャンしたものでも、2026年のデジタル生成されたSage PDFと同じ構造化出力が得られます（テキストが判読可能な場合）。抽出品質は、文書がデジタル原稿かどうかではなく、スキャンの鮮明さに依存します。大きく傾いたスキャン、低解像度のコピー、手書き注釈のあるP60では精度が低下する可能性があります。その場合、検証列（税コードチェック、NIカテゴリチェック）が手動レビューが必要な行にフラグを立てます。
学生ローン控除があるP60はどうなりますか？
英国のP60には、学生・大学院ローン控除（プラン1、プラン2、プラン4、大学院ローン）専用のセクションがあります。HMRC標準のP60形式では、これらがローン種類別に区分されています。「学生ローン（£）」という1列ではなく、ローン種類ごとに「学生ローン プラン1（£）」「学生ローン プラン2（£）」「大学院ローン（£）」の列を定義してください。プラン1とプラン2の両方を返済している従業員は2つのフィールドが非ゼロになり、1列にまとめると、HMRCが発行するSL1/SL2開始・停止通知との照合時に、各控除がどのプランに該当するかを区別できなくなります。
複数の課税年度のP60を1つのバッチで処理できますか？
技術的には可能です — AIは課税年度に関係なくあらゆるP60からデータを抽出します — が、バッチは課税年度ごとに分けることを推奨します。2024-25年度と2025-26年度のP60を混在させたスプレッドシートでは、年度別の照合を開始する前に「課税年度」列が100%正確である必要があります。各課税年度を個別のバッチとして処理し（課税年度を文書ごとの検出ではなくバッチレベルの列にエンコード）、年度間のデータ混入リスクを低減します。どうしても年度を混在させる場合は、年度末日が当該課税年度の4月5日と一致しない行にフラグを立てる計算検証列を含めてください。
同名の従業員がいる場合、一括抽出はどう処理しますか？
従業員名は一意の識別子として使用されません — NI番号がその役割を果たします。同じ雇用主で異なるNI番号を持つ「John Smith」という2人の従業員は、同じ名前だが異なるNI番号と異なる金額データを持つ2つの別個の行として出力されます。バッチプロセッサは各文書を独立して処理します。リスクはマージ段階にあります：2つのバッチをマージして名前順に並べ替えると、2つのJohn Smith行が隣接して表示され、レビュー担当者がNI番号が異なることを見落とす可能性があります。出力の先頭列（従業員名の前）にNI番号を配置することで、視覚的なソートキーとなり、名前による混乱を防げます。
P60にPAYE参照番号が明記されていない場合は？
HMRCはすべてのP60に雇用主のPAYE参照番号の表示を義務付けており、これはRD1に基づく法定項目です。ただし、一部の給与計算ソフトでは、参照番号が小さな文字で雇用主詳細欄に埋もれたり、証明書本体ではなくHMRCのロゴの隣に印刷されたりすることがあります。特定のプロバイダーのレイアウトでPAYE参照番号が常に不明瞭な場合は、固定値の列を追加し、AI抽出に頼らずにそのバッチのPAYE参照番号を手動で設定できます。単一雇用主のバッチではすべてのP60でPAYE参照番号が同一であるため、1つの列を手動設定するだけでバッチ全体をカバーできます。出力の「ファイル名」列は、1つの列をバッチ設定しても各行の出所を提供します。
5月31日のP60期限は変わりません。そして、給与ソフトが生成するものと給与照合に必要なものとの間のギャップも変わりません。「P60が発行された」から「スプレッドシートがFPSと照合される」までの5時間は、キーボードの速さでは解決できない構造的な問題です。これは列設計の問題です。列を一度定義してください。バッチをアップロードしてください。スプレッドシートに自動で入力させてください。
P60でお試しください