100枚以上の英国P60を5月31日までに
1つの監査用スプレッドシートに、手入力不要

P60が100枚を超えると、1枚とは根本的に異なる問題になる理由

P60を1枚処理するのは解決済みの問題です。フィールドをExcelに抽出するには、ツールではなく注意力が必要です。PDFを開き、法定のボックスを見つけ、7～8個の数字を行に入力し、次に進みます。しかし、100人の従業員、3つの給与計算プロバイダー、紙の証明書を持つ買収先企業の退職者など、量が増えると、問題はスピードではなく構造になります。

100枚以上の規模になると、1枚の文書では存在しない3つの構造的問題が発生します。どれも、ファイルをより速く処理することで解決するものではありません。

これらの問題にはそれぞれ、5月にデータ入力スタッフを増やす以外の解決策があります。それは、出力がスプレッドシートではなく、6ヶ月後に元のデータを作成しなかった誰かが読む監査記録であるかのように、バッチワークフロー（ファイル準備から列スキーマまで）を設計することです。

マルチフォーマットの現実：SageとBrightPayは150dpiスキャンではない

HMRCは単一のP60レイアウトを義務付けていません。義務付けているのは内容です。仕様RD1に基づき、代替P60には特定のボックス（従業員名、NI番号、PAYE参照番号、年間総支給額、年間総控除税額、学生ローン控除額、最終税コード、雇用主詳細）を表示する必要がありますが、視覚的な配置は各給与ソフトウェアベンダーに委ねられています。その結果、Sage 50cloudのP60はBrightPayのP60とは構造的に異なり、QuickBooks Online PayrollのP60、MoorepayのP60、IRISのP60ともそれぞれ異なります。さらに、原本を紛失した従業員から提供されるスキャンされた紙のコピーも加わります。

従来のテンプレートベースの抽出（サンプルP60上のフィールドの周りに矩形を描く方法）では、給与プロバイダーごとに個別のテンプレートが必要になります。5つのプロバイダーを維持するには、5つのテンプレートを維持します。プロバイダーが新しい課税年度向けにP60レイアウトを更新すると（新しいHMRCガイダンス、リブランド、書式変更）、テンプレートは黙って位置のずれた出力を生成します。給与管理者は、FPS合計との照合が合わないときに初めて問題に気づきます。

セマンティック抽出は、位置ではなく意味で文書を読み取ることで、プロバイダーごとのテンプレート問題を排除します。列を一度定義するだけで（「NI番号」「年間総支給額（£）」「控除税額（£）」「PAYE参照番号」「最終税コード」）、AIはデータが何を表すかを理解することで、ページ上のどこにあるかではなく、すべてのP60上の各値を特定します。Sage 50cloudのP60、BrightPayのP60、QuickBooksのP60、2023年のスキャンされた紙のP60はすべて、同じ列定義に取り込まれます。英国P60の個々のフィールドと、抽出時に各フィールドがどのように動作するかについての詳細な解説は、単一P60抽出ガイドから始めてください。この記事はその続きです。P60を1枚ずつ考えるのをやめたときに何が起こるかについてです。

英国の給与計算の文脈でこれが特に価値があるのは、PAYE参照番号（形式は123/AB456）が、どの給与ソフトウェアで作成されたかに関係なく、同じ雇用主からのすべてのP60で一貫していることです。正社員にはSage、契約社員にはBrightPayを使用している会社は、同じPAYE参照番号を持つが視覚的に異なる2つの形式のP60を発行します。セマンティック抽出は、レイアウトではなく値を読み取ります。出力スプレッドシートの「PAYE参照番号」列は、両方のプロバイダーで同一に設定され、マルチプロバイダーバッチの自然なグループ化キーを提供します。

大量ファイル命名術：各行を原典に遡れる仕組み

バッチP60ワークフローで最も効果的な判断は、ファイルをアップロードする前の「原典文書の命名方法」にあります。出力スプレッドシートに100行あり、3ヶ月後にHMRCコンプライアンス担当者が「47行目のP60を見せてください」と要求した時、「スプレッドシートとダウンロードフォルダを突き合わせる必要があります」では済みません。瞬時に特定できるファイル名が必要です。

監査トレーサビリティを実現する命名規則には、3つの要素が含まれます：

結果として得られるファイル名パターン — 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つのカテゴリに分類されます。各カテゴリによって、バッチに含める内容とその後の確認内容が変わります。

監査上の落とし穴は、P60を発行し忘れることではありません。発行すべきでない人にP60を発行すること、または発行すべき人に発行しないことです。どちらのエラーもFPS調整に波及し、コンプライアンスハンドブックCH40000に基づくHMRCのコンプライアンスチェックにより、給与計算ソフトウェアよりも早く不一致が明らかになります。

実用的な対策は、「P60ステータス」という推論列を追加することです。AIが各文書の内容に基づいて分類します。「4月5日在職」「4月5日以降退職」「前年度再発行」「P60非該当」などの値により、調整前に出力を並べ替え、レビューや除外が必要な行にフラグを立てることができます。抽出に1列追加するだけで、手動でのクロスチェックにかかる1時間を節約できます。

100行スプレッドシートの監査対応カラム設計

バッチアップロード前に定義するカラム名は、ワークフロー全体で最も重要な判断です。5名のテストバッチ用に設計したカラムスキーマは、100行では機能しないことがよくあります。これは、大量データ特有のエッジケース（PAYEスキーム間でのNI番号重複、年度途中の税コード変更、プラン別の学生ローン控除）を考慮していないためです。

100行の監査に耐えるカラムスキーマは、出力においてそれぞれ異なる機能を持つ3種類のカラムで構成されます。

複数の雇用主にわたってP60を管理する給与チームにとって、「PAYE参照」カラムはバッチグループ化キーと照合ピボットの両方の役割を果たします。PAYE参照で出力をフィルタリングし、総支給額と総所得税控除額のカラムを合計して、各雇用主のP35（雇用主年次申告書）合計と比較します。AIはPAYE参照の形式を理解する必要はありません。表示された文字列をそのまま読み取ります。英国のPAYE参照は一貫したNNN/XXNNNNNパターン（PAYE20005）を使用するため、出力は自然にソートおよびフィルタリング可能です。

バッチ規模での税コード処理には特に注意が必要です。2025-26年度の標準累積税コードは1257L（個人控除額12,570ポンドを反映）ですが、バッチ処理により100人の従業員のうち標準からどれだけ逸脱しているかが明らかになります。Kコード（控除合計が控除額を上回る）の従業員は、1257Lの従業員とは根本的に税務処理が異なります。P60にBR（基本税率）コードが表示されている従業員は、おそらく第二の収入源に対して課税されています。NT（非課税）の従業員は、HMRCに非居住を確認するP85を提出した可能性があります。1257Lで「X」サフィックスが付いた5人の従業員は、非累積（月1）ベースに設定されており、年度累計額が年間計算を表していない可能性があります。「最終税コード」という1つの列にこれらすべてが表示されます。「税コード種別」という2つ目の計算列では、AIが各コードを「累積」「非累積」「BR/D0/D1」「Kコード」に分類し、コードのスプレッドシートをワンクリックでフィルタリング可能な税務状況のスプレッドシートに変換します。

複数雇用主・複数税年度にわたるP60データの統合

バッチ抽出では、バッチごとに1つのスプレッドシートが生成されます。それぞれ独自の123/AB456形式の参照番号を持つ3つのPAYEスキームにわたってP60を管理する給与チームは、3つのスプレッドシートを扱うことになります。統合ステップは、抽出列の構造設計が実を結ぶか、崩壊するかの分岐点です。

すべてのバッチで同じ列名（「NI番号」「従業員名」「PAYE参照」「税年度」「年間総支給額(£)」「年間総控除税額(£)」）を使用していれば、3つのスプレッドシートは列の再マッピングなしに垂直に積み重ねられます。各シートの「PAYE参照」列は各行がどの雇用主に属するかを識別するため、統合されたスプレッドシートはPAYE参照でピボットして雇用主ごとの合計を算出できます。これがバッチ間で列名を標準化する目的のすべてです。統合は列マッピングの作業ではなく、追加操作になります。

より広範なワークフローの質問（ファイル整理、バッチアプローチの選択、下流での使用に向けた出力の構造化）については、完全なバッチOCRワークフローガイドで、複数の文書タイプにわたるファイル準備、ツール選択、出力構造化について説明しています。ここで説明するP60固有の列スキーマは、その一般的なフレームワークに組み込まれます。

統合に特有のエッジケースとして、同じNI番号だが異なるPAYE参照で2つのバッチに出現する従業員がいます。これはエラーではなく、同じ税年度に2つの仕事を持っていた従業員です。雇用主AのP60は一方の雇用の収入と税を示し、雇用主BのP60は他方の雇用の収入と税を示します。1つのスプレッドシートに統合された場合、これら2つの行は集計すべきではありません。「PAYE参照」列があるからこそ、別々の雇用を表す2つのP60を合計せずに済みます。これがないと、単純な「年間総控除税額(£)」のSUMは、どちらの雇用主のP35とも一致しない数値になり、HMRCの調整が成立しなくなります。

よくある質問：英国P60の一括処理