今月15名退職、P45も15枚
二重入力を不要にする退職者データベース構築

月次退職者と単発のP45は別問題

年次P60処理は年に一度だけです。4月5日時点の全従業員に発行されます。給与チームは5月に1週間確保し、バッチ処理を実行し、Full Payment Submissionと照合できます。対照的に、月次の退職者処理は給与カレンダーに恒常的に存在します。毎月、2人から20人の従業員が退職します。辞職、解雇、有期契約満了、定年退職などです。退職ごとにP45が発行されます。そして、すべてのP45はHMRCへの提出義務や退職者への手渡しだけでなく、人事がまったく別の目的で必要とするデータポイントでもあります。つまり、誰が、なぜ、いくらの給与で退職したのか、そしてその退職パターンに一貫性があるのかを把握することです。

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

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

スケールする4部構成のP45：各書類の行き先とよくある問題

P45は4つのパートで構成されています。バッチ処理ではこの区別が重要です。なぜなら、スケールした際のルーティングミスが修正の連鎖を引き起こすからです。手作業での一件ずつの処理では、この問題は表面化しません。

単一退職者のワークフローでは、4部構成のルーティングはチェックボックスで済みます。Part 1を提出、Part 1A/2/3を手渡す。しかし15人のバッチでは、ルーティングは追跡問題になります。FPS上で退職者として正しくマークされているか？すべてのPart 2と3が正しい従業員に紐づいているか——それとも、あるジョン・スミスのP45を別のジョン・スミスに渡してしまっていないか？退職者がP45を紛失した場合、再発行はできません（HMRCが明確に禁止）。提供できるのは収入証明書のみです。つまり、生成した唯一のP45 PDFが唯一の公式記録となります。紛失や誤配送は、取り返しのつかないエラーです。

バッチ処理における実用的な安全策は、P45を生成した瞬間に、すべてのP45データをスプレッドシートに取り込むことです——Part 1A/2/3を手渡す前に。このスプレッドシートが内部監査記録となります。各P45の内容、発行日、該当する退職者の証明です。元従業員が6ヶ月後に「P45の税コードが間違っていた」と連絡してきても、検証可能な行データがあります——給与システムにログインして「印刷したはず」という記憶に頼る必要はありません。

P45 PDFから退職者データベースへ：HMRCと人事の両方に役立つカラム設計

P45を一括アップロードする前に定義するカラム名は、ワークフロー全体で最も重要な判断です。給与計算コンプライアンスだけを目的としたカラムスキーマは、法定項目（総支給額、総税額、税コード、退職日）のみを取得し、そこで止まります。これでFPSに対するP45の検証は十分です。しかし、人事の退職分析には不十分です。人事が知りたいのは、どの部門で人員が流出しているのか、退職者に共通する税コードパターンは何か、高給取りの退職者と低給取りの退職者では退職理由が異なるのか、といったことです。

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

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

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

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

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

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

年末に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退職者フォームの一括処理