P11D書類業務の負担
なぜ従業員特典報告がHR部門の7月で最も嫌われる業務なのか
7月はすでに給与部門にとって最も厳しい月です。月末の給与計算は夏でも止まりません。チームの半数は年次休暇中です。Q3の予算編成が本格的に始まります。そしてそのすべてに加えて、7月6日のP11D申告期限がやってきます。前課税年度に会社が提供したすべての社用車、すべての民間医療保険契約、すべての低金利ローン、すべてのジム会員権について、HMRCの正確な評価規則に従って計算し、従業員ごとの申告書にまとめ、単一のClass 1A National Insurance請求書に集計しなければならない瞬間です。5月のP60をこれほどきれいに処理した給与ソフトウェアは、ここでは役に立ちません。P11Dに必要なデータは、そもそも給与システムには存在しなかったからです。 P60シーズンは同じ構造的なギャップを露呈します。給与ソフトウェアが生成するものと、下流の報告業務が実際に必要とするものとの間のギャップです。ただしP11Dのギャップはさらに広い。なぜなら、ソースデータが給与システムにまったく存在しないからです。

重要ポイント
- CIPPが給与担当者に任意の給与課税処理を選んだ理由を尋ねたところ、最も多かった回答は「P11Dを速くするため」ではなく「P11Dの負担を完全に取り除くため」でした。
- P11Dに必要なデータは、そもそも給与ソフトウェアの中にはありません。HR記録、リース契約、保険会社の請求書に存在しており、業界は20年かけて申告ボタンの自動化に注力してきましたが、データ抽出のステップにはいまだにツールがありません。
- 特典価値を給与モジュールに入力する前にスプレッドシートに抽出することで、現在存在しない監査可能な中間レイヤーが生まれ、6月の業務が「互換性のない3つのシステムの突き合わせ」から「1つの構造化テーブルの検証」に変わります。
7月はP11Dが加わる前からすでに埋まっていた

まず、この摩擦の根本にある暦上の現実から始めましょう。6月中旬までに、英国の給与部門はP60の発行を終えたばかりです — 3,020万人のPAYE従業員に対する年末証明書の法定期限である5月31日です。年度末の調整処理(最終Full Payment Submission、最終Employer Payment Summary、P32のバランス調整)はまだ冷めやらぬ状態です。6月には現行税年度の月末給与計算が控えています。7月にも再びそれが控えているうえ、夏季休暇のカバー対応もあります — 給与担当者の少なくとも1人が休暇中で、そのデスクを引き継いだ担当者は控除モジュールを単独で実行した経験がないという状況です。
そしてそこにP11Dがあります。
7月6日の期限は孤立したイベントではありません。これは年末申告の第二の波であり、最初の波を終えたばかりの同じチームに、同じ圧縮された期間内で、根本的に異なるデータ問題とともに襲いかかります。P60は給与データから供給されます — システムにはすでに数値があります。P11Dは福利厚生データから供給されます — システムには数値がありません。少なくともHMRCが要求する形式では存在しません。この違いにより、7月は提出作業から組み立て作業へと変わり、その組み立てはすでに過密な月の合間に行わなければなりません。
英国の給与専門家のための公的機関であるChartered Institute of Payroll Professionals(CIPP)が2019年に実施した調査では、雇用主に福利厚生の給与課税(payrolling benefits)を自主的に選択した理由を尋ねました。最も多かった回答は「P11Dの作成の必要性と負担を取り除くこと」でした。軽減するのではなく、取り除くことです。この言葉遣いは示唆に富んでいます。複数のP11Dシーズンを経験してきた給与実務者の間では、このフォームはコンプライアンス業務としてではなく、負担として表現されていました。
構造的な問題:P60シーズンは、給与システムがすでに保持している給与データで動きます。P11Dシーズンは、他の場所で発生した福利厚生データ — HRシステム、リース契約、保険会社の請求書、メールでの承認 — に依存し、HMRCに属するルールによって課税価額に変換されなければなりません。データが存在する場所とフォームが要求する内容との間のギャップこそが、毎年7月を消費する場所なのです。
14のセクション、14種類の計算方法

P11Dが1つのフォームに1つの計算ルールしかないのであれば、特筆すべきことはないでしょう。しかし実際はそうではありません。現在のP11Dは、HMRCのPAYE Onlineサービスまたは市販の給与計算ソフトウェアを通じてオンラインで提出されますが、AからNまでの14のアルファベットセクションで構成され、各セクションに独自の評価方法があります。福利厚生の評価に関する公式リファレンスであるHMRC 480税務ガイドは、複数の章にわたって数百ページに及び、何を計上するかだけでなくどのように計上するかという点でも異なる評価ルールを網羅しています。
最も一般的な福利厚生カテゴリのうち3つについて、給与計算担当者が実際に何をしなければならないかを考えてみましょう。それぞれに異なる考え方が必要となる理由も併せてご覧ください。
セクションF — 会社用車。課税対象となる福利厚生は、会社が支払うリース費用ではありません。それは、車両のP11D価格(VAT、納車費用、全オプション装備を含む定価から、従業員の資本拠出額を最大£5,000まで差し引いた額)に該当するパーセンテージを乗じたものです。そのパーセンテージは、WLTPに基づいて測定された車両のCO₂排出量によって決定され、HMRCの年間BIK税率表と照合されます。2025/26年度では、CO₂排出量が121 g/kmのガソリン車には30%のBIK税率が適用されます。排出量ゼロの電気自動車には3%が適用されます。どちらも同じセクションFに記載されます。燃料タイプのキーレター — Euro 6d基準を満たすディーゼルはF、ディーゼルはD、その他はA — を正しく入力する必要があります。プラグインハイブリッドの場合、ゼロエミッション電気走行距離によって別の税率帯が決定されます。また、車両が例えば10月からしか利用可能でなかった場合(課税年度全体ではない場合)、福利厚生は期間按分する必要があります。CO₂のパーセンテージを1つの帯域間違えると、従業員の現金相当額が変わり、従業員の税コードが変わり、雇用主のClass 1A NIC負債も変わります。
セクションI — 民間医療保険。ここでの評価ルールはまったく異なります。課税対象となる福利厚生は、保険を提供するための雇用主の費用、つまり保険会社への保険料です。保険が従業員の配偶者や扶養家族をカバーする場合、その分も含まれます。従業員が給与天引きで保険料の一部を支払う場合、その「補填額」は差し引かれます。ロジックは単純です。課題は、保険料の数字が給与計算ソフトウェアではなく、保険会社またはブローカーからのスプレッドシートにあり、保険会社の請求書に総人数のみが記載されているグループ保険契約において、従業員ごとに正しく割り当てなければならないことです。
セクションH — 有利な融資。これもまた異なります。雇用主が課税年度中のいずれかの時点で£10,000を超える無利子または低金利の融資を提供した場合、福利厚生は、従業員が実際に支払った利息と、HMRCの公定利率で支払うべきだった利息との差額です。2025/26年度の公定利率は3.75%ですが、2025年4月以降、HMRCは利率を年次ではなく四半期ごとに見直すため、同じ課税年度内に複数の異なる利率が計算に関わる可能性があります。融資残高、貸付日と返済日、実際に支払われた利息 — これらはすべて給与計算システムではなく、財務システムにあります。
14セクションのうち、この3つはそれぞれ異なるソースシステムから給与担当者のデスクに届き、それぞれ異なる評価ロジックを持ち、いずれも従業員の給与明細を見ただけでは計算できません。セクションK(提供サービス)やセクションM(専門団体会費)のような比較的単純なセクションでも、そもそもその給付が存在したことを誰かが把握している必要があります。その知識は、給与システムが記録する「支払った金額」ではなく、HR部門が記録する「承認された内容」の中にあります。
調整における三者間の問題

P11Dの構造的な根本問題は、フォーム自体ではありません。異なるロジックで動作する3つの情報システムが、7月の第1週までに単一の数字セットについて合意しなければならないのに、いずれも相互に連携するようには作られていない、という点にあります。
1つ目のシステムはHR記録です。ここで給付が発生します。入社時のカーリース契約書、民間医療保険の加入申込書、ライン管理者からのジム会員資格承認メールなどです。HRシステム(PeopleHRのような専用HRIS、スプレッドシート、あるいはパートタイムのオフィスマネージャーの頭の中にあるモデルまで)は、給付が提供されたことを記録します。しかし、例外的な場合を除き、その課税価値を計算することはありません。それらのフォームから選択内容を取り出すこと自体が1つのステップであり、給付登録をExcelに変換することで、チェックボックスの選択、補償レベル、扶養家族の名前が、給与チームが照合できる列になります。セルフサービスポータルでの取得記録が署名済みフォームではなくなっている場合(ADP、Gusto、BambooHRを導入している雇用主では標準的)、給付登録スクリーンショットの抽出によって、同じプラン名、補償レベル、給与天引きごとの保険料を復元できます。
2つ目のシステムは給与ソフトウェアです。ここで最終的にP11Dが申告されます。Sage 50 Payroll、Xero Payroll、BrightPay、ADP — いずれもP11Dモジュールを備えています。しかし、これらのモジュールはデータ入力インターフェースにすぎず、生データ(車両の定価、CO₂排出量、保険料、ローン残高)が入力されれば現金同等額を計算しますが、その生データを自ら調達することはできません。給与システムは従業員に支払った金額を知っています。しかし、リース会社が事業者に請求した車両代金は知りません。その情報は外部から持ち込む必要があります。
3つ目のシステムはHMRCのルールブックです。Employment Income Manual、480税務ガイド、毎年のBIK税率表、四半期ごとの公定利率、給与の代わりに給付を選択した場合に適用されるOpRA(Optional Remuneration Arrangement)規則 — これらすべてが各給付カテゴリーの「現金同等額」を定義しており、その金額は会社が支払った額とも従業員が受け取った額とも一致しないことが頻繁にあります。カーリースが会社に月350ポンドかかる場合でも、P11Dの課税価値は定価とCO₂排出量に基づいて計算されるため、まったく異なる数字になります。従業員は民間医療保険を「無料」と認識するかもしれませんが、HMRCは保険料を課税所得とみなします。
6月から7月初旬の給与管理者の仕事は、これら3つのシステムの交差点に立ち、翻訳することです。人事ファイルを開いて車両の詳細を確認する。保険会社の請求書を開いて保険料を確認する。HMRCのBIK税率表を開いて該当するパーセンテージを確認する。その結果を給与ソフトウェアのP11Dモジュールに入力する。福利厚生を受ける従業員ごとに繰り返す。各従業員が保有する福利厚生カテゴリごとに繰り返す。このパターン — 断片的なソース文書からデータを照合して構造化された形式にまとめること — はP11Dに固有のものではなく、P45処理やP60の作成も同じ照合構造を共有していますが、P11DにはHMRC固有の評価ロジックの層が加わり、各フィールドが転記ではなく計算作業になります。
これはデータ入力ではありません。三角測量です。そして、このプロセスに対する公式の評価 — Office of Tax Simplificationの従業員福利厚生および経費に関する中間報告書 — は、P11Dプロセスを「雇用主とHMRCの両方にとってリソース集約的」であり、「雇用主の間で大きな懸念事項」と説明しています。財務大臣に提出されたこの報告書は、P11D管理を「さらなる作業の重要優先事項」として明示的に特定しました。
1つの誤ったCO₂パーセンテージ — そしてその後に起こること
P11DのエラーはP60のエラーとは異なります。P60の総支給額の入力ミスは従業員の税コードに反映され、発見されれば修正されます。P11Dの福利厚生の入力ミスは横方向に波及します — 従業員の税負担、雇用主のClass 1A NIC計算、P11D(b)の集計、そして会社がその課税年度に保有するすべてのコンプライアンス記録に影響を及ぼします。
最も一般的な高額エラーシナリオを取り上げます:会社用車両のCO₂パーセンテージが1バンドずれているケースです。2025/26年度のHMRCのBIK税率表は、2%(50g/km未満の超低排出車両)から37%(155g/km超の車両、または2000cc超の1998年以前の車両)までの範囲です。P11D価値が£40,000の車両で1バンドのずれ — 30%から31% — が生じると、年間現金同等額は£12,000から£12,400に変わります。その£400の差は以下に波及します:
- 従業員の所得税負担(20%または40%で、追加£80または£160の税金)
- 従業員の翌年度の税コード調整 — 修正されるまで誤ったままになります
- 雇用主のClass 1A NIC(15%で、追加£60)
- P11D(b)の集計合計 — これは全個人P11Dの合計と一致する必要があります
- 車両がディーゼルでRDE2基準を満たさない場合:追加の4%上乗せが適用され、エラーがさらに悪化します
ここで、その1台の車両を80台の社用車フリートに拡大してみます。複数の排出バンド、ガソリン、ディーゼル、プラグインハイブリッド、完全電気自動車の混合 — それぞれ異なるBIK率、それぞれ課税年度の一部のみ利用可能な場合、従業員の資本拠出によりP11D価値が減額されるもの、£28,200の乗数にCO₂パーセンテージを掛けた燃料福利厚生チャージが上乗せされるものもあります。単一フリートのP11Dパッケージはフォームではなく、相互依存する計算の80行のスプレッドシートであり、1つの不正確なCO₂数値がその行だけでなく、P11D(b)のClass 1A合計全体を変動させます。
不正確なP11Dに対するHMRCの罰則構造は多層的です:不正確な個人フォームごとに最大£3,000、さらにP11D(b)に対する不正確さ罰金は「失われた可能性のある収入」のパーセンテージとして計算されます — 過失エラーで0%から30%、意図的で最大70%、意図的かつ隠蔽で最大100%です。CIPPの2017/18年度のステップバイステップガイドは、不正確さ罰金による財務的エクスポージャーは「福利厚生自体のコストをはるかに超える可能性がある」と指摘しています。
しかし、ペナルティ通知に決して載らないコストは、修正に費やされる時間です。HMRCの修正プロセスでは、P11DとP11D(b)の両方を完全に再提出する必要があります。変更された数字だけでなく、初回に正しかった項目も含めてフォーム全体を再提出するのです。雇用主は、エラーの特定、再計算、再提出、影響を受ける従業員への修正明細書の発行を行い、従業員が誤ったP11Dに基づいてすでに確定申告を提出していた場合は、SA100の修正を調整する必要があります。これは、フリーランサーや小規模事業主にとって自己評価の紙の証跡が特に厄介となる、同じ種類のSA100書類のやり取りです。その修正作業のいずれも、誰かに請求できるものではありません。それは、すでにキャパシティを超えていた月である7月の給与部門に吸収されます。
実際の影響は理論上の話ではありません。r/UKPersonalFinanceでは、ある従業員が、雇用主の誤った報告に起因するP11D上の£4,200の差異を発見したと投稿しました。誤って分類された福利厚生により税金の未納が生じ、HMRCが雇用主ではなく従業員に対して追及するという内容でした。その投稿の不安はお金についてではなく、コンプライアンス書類の速度でやり取りする2つの組織間でエラーの修正に数週間を費やさなければならないことについてでした。
今年のP11Dの苦労を理解する価値がある理由となる2027年の圧迫
現物給付の必須ペイローリングは2027年4月から施行されます。当初発表された2026年4月の期限から12か月延期され、雇用主とソフトウェアプロバイダーにより多くの準備時間が与えられました。その日以降、ほとんどの福利厚生(社用車、医療保険、ジム会員権など)は、P11Dで毎年報告するのではなく、各給与期間ごとにリアルタイムで給与を通じて課税されなければなりません。数十年にわたって存在してきたP11Dフォームは、これらのカテゴリーでは廃止されます。
これがP11D問題の終わりのように聞こえるなら、それは違います。これは別の問題への移行であり、移行年自体が、まだほとんど雇用主がモデル化していない独自の財務的圧力ポイントを生み出します。
2027年7月に何が起こるかを説明します。2026/27課税年度(P11D報告の最終年度)について、雇用主は12か月分のClass 1A National Insuranceを支払う義務があり、2027年7月22日までに一括で支払う必要があります。同時に、2027年4月以降、同じ雇用主は新たにペイローリングされた福利厚生について、リアルタイムの給与提出を通じて毎月Class 1A National Insuranceを支払います。つまり、2027年7月は特に厳しい状況です。雇用主は2026/27年度分の12か月分のClass 1A一括支払いに加えて、2027年6月分のリアルタイムClass 1A月次支払いを行わなければなりません。実質的に、2027年7月は単一のキャッシュフロー月に13か月分のClass 1A National Insuranceを負担することになります。しかも、2024年秋予算以前に適用されていた13.8%から引き上げられた新しい15%の税率でです。
社用車 fleet、医療保険、その他いくつかの課税対象特典を備え、150人の福利厚生受給従業員を抱える雇用主にとって、Class 1A一括支払いだけで簡単に数万ポンドに達する可能性があります。その上に1か月分のリアルタイムNational Insuranceを積み重ねることは、簿記上の詳細ではありません。これは流動性イベントであり、給与・財務チームが給与計算実行中に発見するのではなく、今すぐ分離して確保しておく必要があります。
そして、給与課税(payrolling)方式でも、福利厚生データの品質問題は解消されません。現行制度では、福利厚生の評価額に誤りがあれば、P11Dの作成時に発見されます。年に一度のチェックであり、手間はかかるものの、雇用主にとって自然な見直しのタイミングとなります。一方、給与課税方式では、誤った評価額が入力された最初の月から、毎月の給与明細に直接反映されてしまいます。新規の社用車について4月にCO₂排出量の割合を誤って登録した場合、誰かが気づくまで従業員は毎月誤った税金を支払うことになります。気づくのは翌年4月に税コードの調整がおかしいと気づいたときかもしれませんし、HMRCのコンプライアンスチェックがあるまで気づかないかもしれません。年次のP11Dレビューは、欠点はあるものの、問題を断ち切る役割を果たしていました。給与課税方式はそれを取り除いてしまいます。入力するデータの正確性は初日から確保されなければならず、しかもそのデータは依然として、互いに連携していなかった同じ3つのシステムから取得する必要があるのです。
ツールが対応する範囲と、対応しない範囲
給与計算ソフトウェア業界は、福利厚生報告パイプラインの下流側、すなわち入力データが入った後の現金同等額の計算、HMRCへのオンライン提出、従業員用コピーの生成を自動化することに20年を費やしてきました。Sage、Xero、BrightPay、ADP、PayFit — いずれも申告書の提出には対応しています。しかし、データ抽出に対応しているものはありません。
この違いが重要なのは、時間を消費するのは抽出の部分だからです。給与計算担当者が6月にP11Dの準備に取りかかるとき、クリーンなデータフィードから始めるわけではありません。書類の集合体から始めるのです。リース会社の車両一覧表(車両ごとの定価とCO₂排出量を示すもの)、保険会社の従業員ごとの年間保険料明細、経理部門の有利な融資と返済の記録、人事部門の年間の新規採用・退職・福利厚生変更の記録。これらの書類はそれぞれ異なる形式で、異なるソースから、異なる目的のために構成されています。それらの書類から正しい数字をP11Dモジュールに入力する作業、すなわち抽出がボトルネックなのです。申告書の提出はボタンを押すだけです。この抽出を構造化し、給与計算ソフトウェアが読み込めるスプレッドシートにデータをエクスポートする方法の完全な手順については、P11D福利厚生データをExcelに抽出するステップバイステップガイドをご覧ください。
ここで、テンプレート不要のAI抽出が、より優れた給与計算モジュールでは実現できない方法でワークフローを変えるのです。車両一覧表のPDFを読み、各車両のP11D価額とCO₂排出量を手作業で給与計算システムに入力する代わりに、抽出ツールが文書を直接読み取り、車両の詳細を特定し、関連する数値を識別して、スプレッドシートの構造化された列として出力します。同じプロセスが、保険会社の保険料明細、ローン明細書、ジム会員プロバイダーの年間利用報告書にも適用できます。出力されるのは完成したP11Dではありません — それは引き続き給与計算ソフトウェアの役割です — しかし、一度検証すればアップロードできる構造化されたデータセットであり、税務申告用に設計されたわけではない元の文書からフィールドごとに手入力する必要はありません。
ファイルは安全に処理され、保存されません。
構造上の利点はスピードだけではありません。抽出によって、監査可能な中間ステップが生まれるのです。抽出された給与非課税額のスプレッドシートは、給与システムに入力される前にレビューし、承認することができます。エラーが見つかった場合は、再提出するP11Dではなく、スプレッドシート上で修正されます。HMRCから金額の算出方法を問われた場合も、元のドキュメントと抽出結果を並べて提示できます。この部分は、現在ツールがまったく存在しないワークフローの領域であり、税年度末から7月6日の期限までの時間の大半を占めている部分でもあります。
複数のクライアントのP11D申告を管理する給与計算事務所や会計事務所にとって、抽出ステップは件数が増えるほど負担が大きくなります。20社のSMEクライアントのP11Dを処理する事務所に、専任の給与非課税データ管理者がいるわけではありません。P11Dシーズンを担当する人物は、クライアントの給与照会への対応、不足情報の追跡、クライアントのオフィスマネージャーが保険会社の実際の請求書ではなく記憶で見積もった数字の修正も同時に行っています。各クライアントのソースドキュメントを、車両情報がPDF、スキャンしたリース契約書、フリート管理ポータルのスクリーンショットのいずれで届いたかにかかわらず、標準化されたデータテーブルに変換する抽出アプローチは、ワークフローで最も手作業が多い部分を削減することで、クライアントごとの処理時間を短縮します。
単一の雇用主でも、より小規模ながら同じ効果が得られます。年間のドラフトに対する1回のP11DからExcelへの変換で、事務所のクライアントリスト全体と同様に、手作業による照合作業を完全に不要にできます。
よくある質問
福利厚生を給与計算に含めている場合でも、P11Dフォームの提出は必要ですか?
給与計算に含めた福利厚生については個別のP11Dフォームが不要になる場合がありますが、7月6日までにP11D(b)を提出し、給与計算対象・非対象のすべての福利厚生の合計額に対するClass 1A National Insuranceを申告・納付する必要があります。任意の給与計算方式ではP11D(b)の義務はなくならず、2027年4月に義務化が始まった後も引き続き残ります。
7月6日のP11D提出期限に間に合わなかった場合はどうなりますか?
個別のP11Dが遅延した場合、フォーム1件につき最大£300の罰金に加え、提出までの1日ごとに£60が加算されます。ただし、これにはHMRCがFirst-tier Tax Tribunalの命令を求める必要があります。より直接的な財務リスクはP11D(b)にあります。申告が遅れた場合、従業員50人ごと(端数含む)に月£100の自動罰金が科されます。従業員105人の場合、月£300となり、罰金の計算は7月6日の期限日から始まります。別途、Class 1A NICの納付遅延には7月22日(小切手払いの場合は7月19日)から利息が発生し、さらに段階的な割合の罰金が加算されます:30日後に5%、6ヶ月後にさらに5%、12ヶ月後にさらに5%です。
提出後にP11Dを修正できますか?
できますが、修正プロセスは誤った項目を単純に訂正するものではありません。HMRCのオンライン修正フォームを通じて、完全なP11D(合計額が変わる場合はP11D(b)も)を再提出する必要があります。再提出では、前回版との差額ではなく、すべての福利厚生について修正後の完全な金額を示す必要があります。修正によって追加のClass 1A NICが発生する場合、利息および不正確申告による罰金は修正日ではなく元の期限日から適用されます。
2027年4月以降も給与計算に含められないものは何ですか?
2つのカテゴリーが義務的な給与計算の対象外のままです:雇用主が提供する居住用住居、および優遇(低金利または無利子)ローンです。これらは引き続きP11Dで報告するか、雇用主が課税年度開始前に登録すれば任意で給与計算に含めることができます。ローンについては、2025年4月に導入された公定利率の四半期見直しにより、さらに複雑な問題が加わります:課税対象となる福利厚生の計算には、単一の課税年度内に複数の異なる利率が関わる可能性があります。
OpRA(任意報酬制度)はP11Dの評価額にどのように影響しますか?
従業員が給与を手放す代わりに福利厚生を受け取る場合(例えば、給与犠牲型の社用車制度)、OpRAルールでは、課税価額は放棄した給与額と標準的な現物給付評価額のいずれか高い方とすることが求められます。従業員が標準的なBIK価値が£3,600の社用車のために£5,000の給与を犠牲にした場合、P11Dの金額は£5,000となります。低排出ガス車(CO₂排出量75g/km以下)はこのルールの対象外であり、標準的なBIK計算が適用されます。超低排出ガス車もOpRA比較の対象外となるため、電気自動車の給与犠牲型制度は、標準的な評価が今も適用される数少ない領域の一つとなっています。
P11Dの準備には実際にどのくらいの時間がかかりますか?
従業員一人当たりのP11D準備時間に関する公表されたベンチマークは存在せず、そのデータの欠如自体が状況の一端を物語っています。英国の給与部門のタイムシートにはP11Dの予算項目はありません。この作業は6月から7月初旬にかけて、月末給与計算、P60に関する問い合わせ、夏季休暇の対応と並行して行われます。CIPPが会員を調査し、「P11Dの負担を取り除くこと」が給与計算代行を採用する主な動機であることを発見したとき、それは給与専門家がすでに知っていたことを実証的に裏付けたものです。つまり、時間的コストは現実的で、繰り返し発生し、自主的なシステム移行を促すほど重大であるということです。100人規模の企業における実際の状況は、断片的な作業が1〜2週間続くというものです。フルタイムではありませんが、常に存在し、実際に期限が設定されているタスクの合間を埋めているのです。