1月のP45ラッシュ
英国給与処理サバイバルガイド

誰も予定していなかった1月のスパイク

英国の従業員離職率は年間約34%で、CIPDによる年次人口調査の分析によると、毎年約27.4%の労働者が新しい雇用主に移り、6.6%が労働市場から去っています。PAYE対象者が約3,300万人であることから、転職者だけで年間約900万枚のP45が発行されています。しかし、この離職は暦年を通じて均一ではありません。すべての給与実務者が知っているように、それは特定の時期に集中し、1月がそのピークです。

このタイミングは偶然ではありません。英国の雇用主の多くは1ヶ月、役職によっては3ヶ月の予告期間を設けています。クリスマス休暇中に退職を決意した人——オフィスパーティーの後、ボーナスが入った後、2週間の家族との時間で自分が仕事に何を求めているかが明確になった後——は、1月の最初の週に辞表を提出します。その予告期間は1月中続き、最終給与とP45の発行日は1月下旬か2月上旬になります。一方、後任として入社する新入社員は、以前の雇用主からのP45を持参します——異なる給与ソフトウェア、異なるレイアウト、異なるフィールド配置で作成された書類です——そして、それらのP45はすべて、最初の給与計算の前に読み取り、新しい雇用主の給与システムに転記し、検証する必要があります。400人の現場作業員と35%の年間離職率を持つ建設会社は、年間約140枚のP45を処理することになり、そのうち不釣り合いな数が第1四半期に集中します。30の中小企業クライアントと合計450人の従業員を抱える給与計算代行会社は、複数の業界、複数の給与ソフトウェア出力、複数のP45フォーマットにわたって、同じパターンの凝縮版に直面することになります——どれも標準化されていません。

量だけが問題ではありません。給与チームは年間を通じて量を処理しています。1月が特別なのは、その量が12月の圧縮された処理期間からの遅れ作業と衝突するからです。CIPPのデータによると、12月の短い月は給与部門にタスクを前倒しさせ、他のタスクを延期させます。「1月の給付年度の更新も12月の作業負荷を大幅に増加させる」とCIPPは12月の給与レポートで指摘しています。給付年度の更新、P11D処理、税コードの更新はすべて、標準的な1月の給与計算に上乗せされます。退職者のP45の波は、もともとタイトだった月の真ん中に、しかも双方向から同時に押し寄せます。

双方向問題：離職者と入社者が同じ週に発生する

P45は、英国の雇用主が同一ワークフロー内で作成と消費の両方を行う唯一の給与文書です。従業員が退職する際、雇用主は2003年所得税（PAYE）規則第36条に基づきP45（正式名称「退職者の詳細」）を発行します。ソフトウェアは4部構成の証明書を生成します。第1部は最終給与支払報告でRTIを通じてHMRCに送付され、第1A部、第2部、第3部は従業員に渡ります。発行側はほぼ自動化されています。Sage Payroll、BrightPay、Xero Payroll、Iris、Moorepayはすべて標準機能としてP45を生成し、課税年度開始日（4月6日）から退職日までの年度累計額を計算し、正しい税コード基準を適用して証明書を作成します。

受取側では自動化が途絶えます。新入社員が前職のP45を持参したり、別の給与ソフトで生成されたPDFをメールで送ってきた場合、誰かがその書類を開き、5つの項目を探し出して新しい雇用主の給与システムに入力しなければなりません。その5項目とは、退職日、当該課税年度の総支給額と総所得税額、退職時の税コード、国民保険番号、学生ローン控除状況です。いずれか一つでも誤って入力すると、新入社員の最初の給与明細が不正になり、その修正はソフトウェアベンダーではなく給与チームの机に回ってきます。HMRCは給与記録を最低3年間保管するよう義務付けており、不適切な記録は推定税額請求と最大3,000ポンドの罰金につながる可能性があると警告しています。

1月には、この受取側の負担が倍増します。通常は週に2～3件の新入社員P45を処理する給与管理者が、1月の第2週には15件を処理する可能性があります。12月の離職者が、今度は別の会社の1月の新入社員になるからです。1件あたり2～3分かけて転記と確認を行います。英国の給与管理者の給与中央値は約29,750ポンド（総額）で、雇用主負担のClass 1国民保険（5,000ポンドの第2閾値を超える部分に15%）と自動加入年金拠出を加えると、時間あたり約21ポンドの負荷コストになります。つまり、P45一件あたり約70ペンスの労力です。このコストは小さいため、ほとんどの組織で予算化されておらず、まさにそれがP45データ入力が適切にコスト評価されてこなかった理由です。しかし、1月に4～5回の給与期間にわたって週15件のP45が発生する場合、画面上のPDFとシステム内の給与記録の間には自動化の層がなく、時間は刻々と過ぎていきます。

P45が手作業から脱却できない5つの項目

2013年、RTIによって雇用主からHMRCへのP45の電子的な送信が実現しました。現在、すべての給与ソフトウェアはFull Payment Submissionを通じて退職者データをHMRCに直接送信しており、P45のPart 1は事実上不要になっています。しかし、RTIは雇用主間の連携には何の影響も与えませんでした。新しい雇用主に同じデータを伝えるPart 2とPart 3は、今も紙またはPDF文書として人手による読み取りを前提としています。これらは機械可読性を考慮して設計されたものではありません。さらに、HMRCがP45に含むべきデータ項目を指定する一方で、レイアウトについては規定していないため、各給与ソフトウェアベンダーが独自のP45フォーマットを設計しています。

Sage 50 Payrollが生成するP45とBrightPayのものでは、税コードの位置が異なります。XeroのP45 PDFはIrisのものとは見た目が違い、MoorepayのレイアウトはFreeAgentのものとは異なります。重要な5つの項目—退職日、支給額累計、税額累計、税コード、国民保険番号—はすべての証明書に記載されていますが、その位置、フォントサイズ、ラベルの文言、他のデータ項目との近接性は、ソフトウェアベンダーごと、バージョンアップデートごと、さらには雇用主が設定するテンプレート設定ごとに異なります。30の異なるクライアント企業からP45を受け取る給与代行機関は、30種類の異なるレイアウトに直面する可能性があり、すべてに共通する唯一の保証は、人間が項目を見つけて手入力しなければならないということです。

このレイアウトの多様性こそが、給与計算の他のすべての部分がソフトウェア化された現在でも、P45処理の自動化が進まない理由です。従来のOCRは各フィールドがページ上のどこにあるかを事前に把握する必要があります—これは位置ベースのアプローチであり、異なる給与プロバイダーのP45が届いた瞬間に機能しなくなります。テンプレートベースの抽出ツールでは、レイアウトのバリエーションごとに個別の解析ルールを構築・維持する必要があり、置き換えるはずだった手入力を凌ぐ管理負担が生じます。このボトルネックは構造的なものです。P45データはフィールドレベルでは標準化されています（HMRCがフィールドを定義）が、レイアウトレベルでは標準化されておらず、それはソフトウェア市場に委ねられています。

この状況を変えるのは、セマンティック抽出です。つまり、各フィールドがどこにあるかではなく、何を意味するかを理解することで文書を読み取る方法です。特定のP45テンプレートのA列7行目にある「Tax Code」を探すようにツールをプログラムする代わりに、セマンティック抽出ツールはラベル—「Tax Code at Leaving」「Tax code」「Tax Code (at date of leaving)」など—によってフィールドを識別し、その位置に関係なく隣接する値を抽出します。ImageToTable.aiがカスタム列抽出と呼ぶこのアプローチは、英国の給与エコシステムにおけるP45の実際の動作方法—同じデータ、異なるレイアウト、標準化なし—に初めて対応した抽出方法です。抽出したい列名（退職日、支給額累計、税コード、国民保険番号、学生ローン状況）を入力するだけで、AIがラベルの意味を理解し、ページ上のどこにあっても各値を特定します。

税コードの入力ミスが実際に生むコスト

税コード1257Lは、従業員が2025/26年度に標準の個人控除額£12,570を全額受け取れることを意味します。これは、1つの仕事で調整がないほとんどの従業員に適用される標準コードです。'L'の接尾辞は標準の非課税個人控除を示し、数字の1257は控除額を10で割った値です。給与担当者が誤って1275Lと入力すると（2桁の入れ替え）、給与ソフトは個人控除額を£12,750と解釈し、従業員は年間で£180多く非課税控除を受けることになります。HMRCのシステムは最終的に不一致を検出し、修正コードを発行しますが、それまでに従業員は数ヶ月間税金を過少に支払っている可能性があります。過少支払いは将来の調整された税コードを通じて回収され、従業員の給与明細に警告なしに表示されます。すると従業員は給与部門に電話し、手取り額が減った理由を問い合わせることになります。

これは仮定の話ではありません。AccountingWEBフォーラムには、P45のデータ入力ミスが複数の給与期間に波及した実際の事例が掲載されています。ある給与計算事務所は、前職のSage CSVエクスポートからP45の年度累計額をBrightPayに入力し、数ヶ月後にクライアントがHMRCから£2,390を請求されていたことを発見しました。これは、P45の数字が二重計上された累積税額と正確に一致していました。HMRCの対応は「解決に1年以上かかる」異議申し立ての提出でした。ミスを引き起こした2分間の入力はすでに発生しており、修正には1年を要しました。

手動データ入力のエラー率は、文書の品質、時間的プレッシャー、オペレーターのレイアウト習熟度に応じて、フィールドあたり1%から4%の範囲です。5つのP45フィールドで、フィールドあたり1%のエラー率の場合、任意のP45に少なくとも1つのミスがある確率は約5%です。1月に週15件のP45を処理する場合、統計的に月に少なくとも1件のエラーがほぼ確実に発生します。そして税コードフィールドに生じたエラーは、給与明細が間違っていることが判明するまで表面化しません。エラーに気づいた従業員が給与部門に電話します。給与担当者は元のP45を確認し、転記ミスを発見して修正を開始します。HMRCが関与します。70ペンスのコストで済んだはずの2分間のデータ入力が、今や3つのデスク、複数のメール、そして数週間に及ぶフォローアップを消費しています。これらは予算化されておらず、コストセンターのレポートにも可視化されず、すべてはたった1桁の入力ミスに起因しています。

手動P45処理の真のコスト — 人件費、エラー修正、コンプライアンスリスク、そして従業員一人あたり£3,000の記録保管ペナルティ — が詳細に分析されました。1月の給与チームにとって、この枠組みで関連する部分は受領側です。新しいスターターから届くすべてのP45は手動転記作業であり、すべての転記作業にはエラー確率が伴い、1月はその量とエラー率を上げる時間的プレッシャーの両方を増幅させます。

1月のP45サイクルを断ち切る

1月のP45山積み問題に対する構造的な解決策は、人員増や残業ではありません。12月ですでに手一杯の給与チームに、1月の急増を残業で吸収する余裕はありません。解決策は、転記ステップを完全に排除することです。P45のデータ — 退職日、支払済額、税額、税コード、NI番号、学生ローン状況 — はすでに証明書に印刷されています。給与管理者の役割は、作成ではなく検証であるべきです。抽出されたデータを確認し、原本と一致することを確認し、給与システムにインポートします。2ステップではなく1ステップで、エラーリスクを伴うステップ — タイピング — が排除されます。

ここで、テンプレート不要のAI抽出がP45処理のワークフローを変えます。特定のP45レイアウト上の各フィールドの位置を知る必要がある位置ベースのOCRとは異なり、セマンティック抽出は各フィールドラベルの意味を理解することで文書を読み取ります。Sageが生成したP45は税コードをある場所に配置し、BrightPayが生成したP45は別の場所に配置します。人間の読者は両方を本能的にナビゲートします — 「Tax Code」や「Tax Code at Leaving」をスキャンし、隣接する値を読み取ります。セマンティック抽出も同じことを行います。座標ではなく意味によってフィールドを特定します。これが、複数のソースからのP45を単一の操作でバッチ処理することを可能にする中核メカニズムです。各給与ソフトウェアの出力形式ごとにテンプレートを作成する必要はありません。必要な列をシステムに指示するだけで、レイアウトに関係なく各文書上の一致するデータを見つけます。

バッチ処理の側面は、特に1月にとって重要です。1週間に15、20、または30枚のP45が届く — 退職者用に発行が必要なフォームと、新入社員用に入力が必要なフォームが混在 — 場合、それらを1枚ずつ処理しても時間的プレッシャーの問題は解決しません。すべてを単一のバッチ操作で抽出し、各行が完成したP45データレコードである1つのスプレッドシートに結果を統合することで、1週間分の分散したタイピング作業が、半日分のレビュー作業に変わります。バッチP45処理ワークフロー — 複数のフォームから同時に退職者データベースを構築する — は、入社側にも同様に適用できます。退職者用のデータベースを生成する同じ抽出実行で、入社者用の新規スターター設定シートも生成できます。なぜなら、5つのコアフィールドは両方向で同一だからです。

タイピングに頼らない1月の給与ワークフロー

各P45 PDFを個別に開き、5つの項目を読み取り、給与ソフトに切り替えて5つ入力し、それを30回繰り返す代わりに、抽出ツールを使えば、1月の業務を3つのブロックに再編成できます。

時間計算は単純です。手動入力で1件あたり2分かかる場合、新入社員30人のP45処理に1時間のタイピングが必要で、後でエラー修正が発生すればさらに時間がかかります。バッチ抽出なら、同じ30件のP45をアップロード、抽出、1つのスプレッドシートにまとめるまで数分で完了。残りの1時間は検証とインポートに充てられます。これは本来必要な作業であり、給与担当者はタイピングの合間ではなく、しっかりと実施できるようになります。

退職者側でも、同じ抽出ワークフローが別の目的に役立ちます。生成されたP45の数値が従業員とHMRCに送付される前に正しいか確認するためです。退職者のP45 PDFを給与システムの記録と一括抽出して自動クロスチェックを行います。P45の退職日はシステムと一致しているか？年度累計の支給額と税額は整合しているか？このチェックをRTI提出前に実行することで、給与ソフトのデータと証明書の内容の乖離を防ぎ、HMRCのFPS処理に到達する前に不一致を発見できます。P45退職者データをExcelに抽出するステップバイステップガイドでは、このワークフローを詳細に解説しており、Week 1/Month 1基準の表示や学生ローンプランタイプなどの具体的なフィールドマッピングや一般的なエッジケースもカバーしています。

1月が問題を露呈する月である理由

年間11か月間、手作業によるP45処理は軽微な管理上の摩擦に過ぎません。数分の手間、数枚の書類、たまに発生する被害が出る前に発見されるエラー。しかし1月になると、それは摩擦からボトルネックへと変わります。処理量が急増し、時間的プレッシャーが強まり、エラー率が上昇し、修正作業（HMRCへのメール、修正FPS提出、従業員の給与明細照会）が2月と3月に食い込みます。問題は常に構造的なものでした。P45データはフィールドレベルでは標準化されていますが、レイアウトレベルではされておらず、雇用主間の引き継ぎは、自動化された給与エコシステムの中で、依然として人間による転記連鎖に依存しています。1月は、最も不都合なタイミングでその亀裂を露呈させるのです。

より深い問題は、英国の給与チームが今なお手作業でP45を処理している理由が、スキルやツールの不足にあるのではなく、最近まで利用可能だったツール（テンプレートベースのOCR、ゾーン抽出）が、フォーマットごとの設定を必要とし、自動化が本来置き換えるべき手作業よりも遅くなってしまったことにあります。給与計算代行会社が、5種類の異なる給与パッケージを使用する30社のクライアントからP45を受け取る場合、30の抽出テンプレートを作成・維持するだけで、それ自体がフルタイムの仕事になります。セマンティック抽出はこの障壁を取り除きます。AIがどのソフトウェアで印刷されたかを問わず「退職時の税コード」の意味を理解するため、バッチ内のすべてのP45に1つの列定義を適用するだけで済むのです。

来年の1月に備える給与チームにとって、問題は手作業によるP45データ入力が持続可能かどうかではありません。処理量の数字がすでに答えを出しています。問題は、転記ミス、修正サイクル、同じ5つのフィールドを何度も入力する管理上の負担の累積コストが、非入力型ワークフローへの切り替えコストを上回る時点がいつかということです。コストの枠組みはすでに存在します。ツールも存在します。残された唯一の変数は、入力をやめてレビューに切り替える決断です。そして1月は、他のどの月よりも、来年の退職者ラッシュが来る前にその決断を下すべき理由を示しています。

よくある質問

退職者に対して、英国の雇用主はどのくらいの速さでP45を発行しなければなりませんか？

2003年所得税（PAYE）規則第36条に基づき、P45は雇用終了日に完了させるか、それが不可能な場合は不当な遅延なく発行しなければなりません。実際には、HMRCはP45を従業員の最終給与と同時、または同じ給与計算サイクル内に発行することを期待しています。Sage、BrightPay、Xero Payroll、Iris、Moorepayなどのほとんどの給与計算ソフトは、従業員を退職者としてマークし、最終給与計算が処理されると自動的にP45を生成します。パート1は、従業員の最終給与日の当日またはそれ以前に、Full Payment Submission（FPS）を通じてHMRCに提出されます。

異なる給与計算ソフトのP45を一括処理できますか？

はい、テンプレートベースのOCRではなく、セマンティックAI抽出を使用すれば可能です。テンプレートベースのツールでは、Sage、BrightPay、Xero、Iris、Moorepay、FreeAgentなど、給与計算ソフトごとに異なるP45レイアウトに対応するために、個別の解析ルールが必要です。セマンティック抽出は、各P45を読み取る際に、フィールドラベル（「退職時の税コード」や「これまでの総支給額」など）の位置ではなく、その意味を理解します。つまり、複数の給与計算プロバイダーのP45が混在したバッチをアップロードし、単一の列定義セットに対してすべてを抽出できます。出力は、P45ごとに1行のデータが含まれる1つのスプレッドシートです。

P45のどの情報を新しい雇用主の給与計算システムに入力する必要がありますか？

P45のパート2と3からの5つの主要な項目：前職の退職日、現在の課税年度（4月6日から4月5日まで）のこれまでの総支給額と総税額、退職時の税コード（週1/月1ベースの指標を含む）、国民保険番号、および学生ローンの控除状況です。これらのいずれかが誤って入力された場合、新しい従業員は緊急税コードに設定され、最初の給与明細が間違ったものになります。課税年度の数値は累積的であり、新しい雇用主が従業員の税務状況をリセットせずに継続するために必要な累計額です。

P45とP60の違いは何ですか？

どちらも従業員の課税年度における収入と納税額を示しますが、発行されるタイミングが異なります。P45は従業員が退職した際に発行され、課税年度の開始日（4月6日）から退職日までの期間をカバーします。P60は毎課税年度末に、その時点で雇用主のもとで働き続けている従業員に発行され、4月5日までの満12ヶ月間をカバーします。雇用主は毎年5月31日までに、すべての現職従業員にP60を提供する義務があります。P60処理の詳細については、給与照合用に英国P60データをExcelに抽出するガイドをご参照ください。

P45の税コードを誤って入力するとどうなりますか？

税コードが間違っていると、従業員の非課税枠の計算が即座に変わります。例えば、1257Lとすべきところを1275Lと入力すると、非課税枠が£12,570ではなく£12,750となり、従業員は年間で£180の過少納税となります。HMRCは通常、RTIデータ照合を通じて不一致を検出し、修正された税コードを発行します。過少納税額は将来の税コード調整によって回収され、その後の月の従業員の手取り額が減少します。従業員は給与が変わった理由を尋ねて給与部門に連絡することが多く、給与部門は元のP45入力を遡って修正内容を説明する必要があります。このエラーが発見されないまま放置されると、課税年度をまたいで持続し、より大きな過少納税に拡大し、HMRCが直接追及することになります。

紙のP45フォームも同じ抽出ツールで処理できますか？

はい。紙のP45のスキャン画像や写真は、PDFと同様に機能します。AIは埋め込まれたテキストレイヤーではなく、文書を視覚的に読み取ります。これは、中小企業で依然として流通している紙のP45や、直接解析できない形式（スキャンPDF、JPEG写真、給与ポータルのスクリーンショットなど）で添付ファイルとして届くP45に特に有用です。抽出ツールは、PDF、JPG、PNG、WebP、AVIF形式の入力をサポートしています。

バッチP45抽出は、複数のクライアント企業を管理する給与計算代行会社でも機能しますか？

はい — 代行会社は最大のレイアウト多様性に直面するため、最も強力なユースケースです。5つの異なる給与計算ソフトウェアパッケージを使用する30の中小企業の給与を管理する代行会社は、毎月数十種類の異なる形式のP45に遭遇します。セマンティック抽出により、代行会社は1セットの列名を定義し、どのソフトウェアで作成されたかに関係なく、バッチ内のすべてのP45にそれを適用します。出力は、クライアントごとまたは処理実行ごとに1つの統合スプレッドシートになります。バッチP45処理ガイドでは、マルチクライアントの代行会社ワークフローについて詳しく説明しています。