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部構成の証明書を生成します。Part 1は最終のFull Payment SubmissionでRTIを通じてHMRCに送信され、Part 1A、2、3は従業員に渡されます。発行側はほぼ自動化されています。Sage Payroll、BrightPay、Xero Payroll、Iris、Moorepayはすべて標準機能としてP45生成を処理し、税年度開始日（4月6日）から退職日までの年度累計額を計算し、正しい税コード基準を適用して証明書を作成します。

受領側こそ、自動化が終わるところです。新しい入社者が前の雇用主からP45を持参した場合—または、まったく異なる給与計算ソフトウェアで生成されたPDFをメールで送ってきた場合—誰かがその書類を開き、5つの項目を特定して、新しい雇用主の給与計算システムに入力しなければなりません。その5つの項目とは、退職日、当該税年度の累計支給額と累計税額、退職時の税コード、National Insurance番号、学生ローンの控除状況です。いずれか1つでも誤って入力すると、新しい入社者の最初の給与明細が不正確になります。そして、その修正対応はソフトウェアベンダーではなく、給与計算チームに降りかかります。HMRCは給与計算記録を少なくとも3年間保管することを義務付けており、不十分な記録は推定税額の請求や最大£3,000の罰金につながる可能性があると警告しています。

1月には、この方程式の受領側が倍増します。通常は週に2〜3件の新規入社者P45を処理する給与計算担当者が、1月の第2週には15件に直面するかもしれません—12月の退職者が、今度は別の会社の1月の新規入社者になるのです。各P45の転記と確認には2〜3分かかります。英国の給与計算担当者の中央値である年間総額約£29,750—これは、£5,000のセカンダリ閾値を超える部分に対する15%の雇用主Class 1 National Insuranceと、自動加入の年金拠出を考慮すると、時間あたり約£21の雇用主負担コストに相当します—つまり、P45あたり約70ペンスの労働コストになります。そのコストは小さすぎて誰も予算化しないため、まさにそれがP45データ入力がほとんどの組織で適切にコスト計算されたことがない理由です。しかし、4〜5回の給与支払期間にわたる1月に週15件のP45を処理する場合、画面上のPDFとシステム内の給与計算記録の間に自動化レイヤーがないこの作業には、時間が刻々と迫っています。

P45が手作業のままである5つの項目

RTIは2013年にP45の雇用主からHMRCへの送信部分をデジタル化しました。現在、すべての給与計算ソフトウェアは、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つの項目（退職日、支給額累計、税額累計、税コード、NI番号）はすべての証明書に記載されていますが、その座標、フォントサイズ、ラベル表記、他のデータ項目との近接性は、ソフトウェアベンダーごと、バージョンアップデートごと、場合によっては雇用主が設定するテンプレート設定ごとに異なります。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の実際の動作方法に適合する最初の抽出方法です。つまり、同じデータ、異なるレイアウト、標準化なし、ということです。抽出したい列名（Leaving Date、Pay to Date、Tax Code、NI Number、Student Loan Statusなど）を入力すると、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%の範囲です。P45の5つのフィールドにわたって、フィールドあたり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つのブロックに再構成できます。

時間の計算は単純です。手入力でP45あたり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処理ガイドでは、マルチクライアントの代行会社ワークフローについて詳しく説明しています。