今月の離職者15名、P45も15枚
二重入力をせずに離職者データベースを構築

月次退職者は単発のP45とは異なる問題です

年間のP60業務は年に一度だけ発生します。4月5日時点で給与計算に載っているすべての従業員が対象となります。給与チームは5月に1週間を確保し、バッチを実行して、Full Payment Submissionsと照合することができます。一方、月次の退職者処理は、給与カレンダーにおける恒常的な業務です。毎月、2人から20人の従業員が退職します。辞職、解雇、有期契約の満了、定年退職などです。退職のたびにP45が発行されます。そして、すべてのP45はHMRCに送信し退職者に渡すコンプライアンス義務であるだけでなく、HRがまったく別の目的で必要とするデータポイントでもあります。誰が退職したのか、なぜ退職したのか、いくら支払われたのか、その退職がパターンに当てはまるかどうかを把握するためです。

単発のP45を処理するのは簡単です。そのフィールドをスプレッドシートに抽出するには、特別なツールではなく注意力が必要です。ほとんどの企業が実際に運用している月次サイクルで退職者を処理する瞬間に、単発規模では存在しない3つの構造的な問題が現れます。

毎月の退職者バッチは、年次のP60業務の縮小版ではありません。それは異なる問題です。P45は同時に、発行しなければならないコンプライアンス文書であり、アーカイブしなければならない給与記録であり、HRチームがまったく別の目的で必要とする退職データポイントでもあります。同じP45 PDFが3つの役割すべてを果たせます — 印刷するフォームとして扱うのをやめ、構造化データソースとして扱い始めれば。

P45の4つのパートを大規模に処理：どこに何が行き、何が問題になるのか

P45は4つのパートで構成されています。バッチ処理ではこの区別が重要です。なぜなら、大規模な処理で送付先を誤ると、手作業で1件ずつ処理する場合には隠れてしまうような、一連の修正作業が発生するからです。

単一の退職者処理では、4つのパートの送付先はチェックボックスのようなものです。パート1を提出し、パート1A/2/3を引き渡すだけです。しかし、15人のバッチ処理となると、送付先の管理が追跡の問題になります。FPSで退職者としてマークされたのは誰か？すべてのパート2と3が正しい従業員に一致しているか、それとも誰かがJohn SmithのP45を別のJohn Smithに渡してしまったのか？退職者がP45を紛失した場合、再発行はできません（HMRCが明示的に禁止しています）— 提供できるのは支給額明細書のみです。つまり、生成したP45のPDFが唯一の公式記録となります。紛失や誤送付は、取り返しのつかないエラーです。

バッチ処理における実際的な安全策は、すべてのP45のデータを生成時点でスプレッドシートに記録することです。パート1A/2/3が手元を離れる前に。そのスプレッドシートが社内の監査記録となります。各P45に何が記載され、どの日付で、どの退職者に対して発行されたかの証明です。元従業員が6か月後に「P45に記載された税コードが間違っていた」と連絡してきた場合、検証可能な行を提示できます。給与システムへのログイン情報と、印刷した記憶だけでは不十分です。

P45 PDFから退職者データベースへ：HMRCとHRの両方に役立つ列設計

P45の一括アップロード前に定義する列名は、このワークフロー全体で最も重要な決定事項です。給与計算のコンプライアンスだけを目的とした列スキーマは、法定項目（累計給与、累計税額、税コード、退職日）を取得してそこで終わります。これでFPSに対するP45の照合には十分ですが、HRの退職分析には不十分です。そこでは異なる問いが立てられます。どの部門で離職者が発生しているのか、退職者に共通する税コードのパターンは何か、高給与の退職者と低給与の退職者では退職理由が異なるのか、といった問いです。

両方の目的に応える列スキーマは、3つの階層で構成されます。第1階層でコンプライアンスを確保し、第2階層でHRが実際に使えるデータを提供し、第3階層でHMRCからの問い合わせになる前に異常値を浮き彫りにします。

単一のP45から法定項目（NI Number、税コード、総支給額と税額）を抽出する具体的な手順については、単一P45抽出ガイドで各項目を詳しく解説しています。本記事はその続編です。毎月15枚のP45を同じ列スキーマに取り込む場合に何が変わるのか、そしてそれを続けることで構築される長期的なデータベースについて説明します。

スキーマこそが、P45 to Excelの設定を毎月再利用可能にする要です。列を一度定義すれば、以降の退職者は同じヘッダーの下に1行として追加されるだけで、バッチ間の再マッピングは不要です。

複数部門の連携：HR通知とP45発行のギャップを埋める

P45の規定では「雇用終了日当日、または不当な遅延なく」とされています。しかし実際には、この一文の背後に連携の連鎖が隠れています。HRが退職届を受け取ります。ライン管理者が最終勤務日を確認します—数日後になることもあります。給与部門が正式な退職通知を受け取ります—ライン管理者の確認後になることも、その前になることもあり、会社のプロセスがHR主導か給与主導かによって異なります。給与部門は最終給与を処理し、SageまたはBrightPayで従業員を退職者としてマークし、P45を生成し、FPSを提出します。これらを経て初めてP45が存在することになります。「従業員が退職を申し出る」から「P45が生成される」までの時間は、同日から2週間まで幅があります。そしてその間、HRはまだP45データのないスプレッドシートに退職情報を記録済みなのです。

これが手動の退職データベースの隠れたコストです。異なる2つのシステムで、異なる2つのタイミングで、重複したデータ入力が発生します。HRは退職が確定した時点で、退職者の氏名、部門、退職理由、最終勤務日を入力します。給与部門はP45が生成された時点—1週間後—に、同じ氏名、NI Number、総支給額、総税額、税コードを入力します。この2つのデータセットが同じスプレッドシートで交わることはほとんどありません。その結果、HRの退職トラッカーは退職理由は分かっても収入は分からず、給与アーカイブは収入は分かっても退職理由は分からない、という状態になります。

バッチワークフローは、誰のプロセスも変えずに、データ取得のタイミングを変えることでこのギャップを解消します。給与部門がP45を生成し、HRが別途退職トラッカーを管理する代わりに、P45 PDFが両者の単一ソースになります。給与計算実行後—すべての退職者が処理され、すべてのP45が生成された後—に、その月のP45バッチをアップロードし、法定給与項目（P45自体から）とHRコンテキスト項目（推論列から）の両方を含むスプレッドシートに抽出します。抽出は1回だけ。両チームがデータを取得できます。HRチームは既に保有している退職届に基づいて退職理由の列を追加し、給与チームはFPSと照合して税額を検証します。両チームとも、同じNI Number、同じ退職日、同じ行を基に作業しています。

年度末に同様のアプローチでP60を処理している企業にとって、毎月のP45ワークフローも同じパターンに従います。列名を標準化し、月ごとにバッチ処理し、FPSと照合します。P60バッチ監査ワークフローでは、ファイル命名、列設計、複数雇用主のマージについて詳しく解説しています。列スキーマはドキュメント固有ですが、バッチアプローチは同一です。

クロスプロバイダーの現実：Sage、BrightPay、QuickBooks、そして年度途中に異動した退職者

HMRCは単一のP45レイアウトを義務付けていません。HMRCのRTI仕様に基づき、給与ソフトウェアは法定項目（雇用主PAYE参照番号、従業員NI番号、氏名、退職日、税コード、総支給額、総税額）を含む必要がありますが、視覚的な配置は各ベンダーに委ねられています。その結果、Sage 50cloud PayrollのP45はBrightPayのP45と異なり、QuickBooks Online PayrollのP45とも、MoorepayのP45とも見た目が異なります。従業員のNI番号は、あるものでは右上のボックスに、別のものでは従業員名の下に表示されるかもしれません。税コードは、あるものではPAYE参照番号の横に印刷され、別のものでは独立した枠線付きボックスに表示されます。

このレイアウトの違いは、手動バッチ処理において微妙ながらも大きなコストを生みます。給与管理者がSageのP45を読んだ後、BrightPayのP45を読むたびに、各フィールドを探すために視覚的に再スキャンする必要があります。企業が別の事業体を買収し、移行期間中にその給与ソフトウェアを引き継ぐ場合、3つの給与プロバイダーにまたがる15枚のP45を処理することになります。その視覚的な再スキャンには、1枚あたり約10秒かかります。1ヶ月分の退職者を処理する場合、転記のキー入力1回前に、数分間の無駄なスキャン時間が発生します。

セマンティック抽出は、プロバイダー固有の再スキャンを排除します。位置ではなく意味に基づいてドキュメントを読み取るからです。「NI番号」という列を一度定義するだけで、AIはSageのP45上のNI番号を、Sageがグリッド座標（x=72mm, y=38mm）に印刷することを知るのではなく、National Insurance番号の形式（英字2文字、数字6桁、英字1文字：AB123456C）を理解して特定します。BrightPayのP45、QuickBooksのP45、MoorepayのP45、そして従業員が紛失したスキャン済み紙のP45も、すべて同じ列定義に入力されます。出力列はプロバイダーに関係なく同一に設定されます。

このプロバイダーに依存しない動作は、年度途中で退職した従業員が現在とは異なる給与システムを使用していたという一般的なシナリオで特に価値があります。9月にSageからBrightPayに切り替えた企業では、退職者の中にSageで生成されたP45（9月以前の退職者）とBrightPayで生成されたP45（9月以降の退職者）が混在します。手動ワークフローでは、2つのP45レイアウトが異なる視覚的アプローチを必要とするため、給与管理者は各バッチを個別に処理します。セマンティック抽出バッチでは、両方を同じアップロードで処理できます。AIがレイアウトではなく値を読み取るからです。「PAYE参照番号」列は、P45を生成したソフトウェアに関係なく、同じ雇用主のすべての退職者に対して同一に設定されます。

月次P45バッチを退職者分析フィードに変える

多くの企業では、HRが手動で更新するスプレッドシートで退職者を管理しています。名前、部署、退職日、理由。これで「今月誰が辞めたか」は分かります。しかし、「エンジニアリング部門の退職者の平均総支給額は残留者と比べてどうか」「非累積税コードの退職者の割合が高いか」「第3四半期と第2四半期の退職者で税コード構成が異なるか」といった問いには答えられません。これらの問いに答えるには、給与計算部門だけが持つP45データ（給与と税額）と、HRだけが持つ部署や退職理由のデータを結合する必要があります。

月次P45バッチ抽出で、まさにその結合データセットが得られます。毎月、P45バッチを同じ列スキーマのスプレッドシートに抽出します。6ヶ月分で6つのスプレッドシートができます。列名が月ごとに同一なので、年間データセットに積み上げるのは追加操作だけで済みます。列の再マッピングやフィールドの調整は不要です。各バッチに固定値として「月」列を追加すれば、給与、税額、税コード、NI番号、退職日を含む6ヶ月分の退職者データが完成します。月別、税コード種別、総支給額帯別に検索可能です。

給与データだけでも、退職面談の記録では見えないことが分かります。BR（基本税率）税コードの退職者のクラスターは、副業を持っていた可能性を示唆し、退職前にすでに組織から経済的に離脱していた従業員群を浮き彫りにします。Kコード（控除額が控除額を上回る）の退職者のクラスターは、複雑な税務事情（社用車、現物給付）を持つ従業員を示し、その退職判断が給与不満ではなく福利厚生構造と相関している可能性があります。これらは退職面談では見えません。P45データに現れます。それを取得すれば。

月次バッチのリズムは、年次振り返りでは見逃すタイミングパターンも浮き彫りにします。1月（ボーナス後の退職）に退職者急増はあるか？4月（税年度末後、従業員がP60を待って退職）は？9月（夏後、新卒採用が既存社員を押し出す）は？単月のスナップショットでは答えられません。6ヶ月分の積み上げバッチなら可能です。パターンは、1つのスプレッドシートを分析するのではなく、データベースを月ごとに構築することで現れます。

FAQ：英国P45退職者フォームの一括処理