80件のP11D、1つのP11D(b)：
従業員福利厚生データの一括処理

なぜ80枚の個別P11Dが「生成問題」ではなく「集計問題」なのか

給与計算ソフトは、P11Dの生成を解決しています——ただし、一度に一人の従業員分だけです。Sage、BrightPay、Xero、IRIS、Moorepayはそれぞれ、税年度を通じて従業員の福利厚生記録を管理し、HMRC所定の評価ルールに従って現金相当額を計算し、提出可能なP11Dフォームを作成します。時間がかかるのは、この生成ステップではありません。

時間がかかるのは、すべてのP11D(b)に必要な集計ステップです。P11D(b)は、全従業員に提供されたすべての福利厚生に対して支払うべきClass 1A国民保険の総額を申告する雇用者用の書類です。HMRCのCWG5ガイダンスは明確です。Class 1Aの対象となるすべての福利厚生の現金相当額を——全従業員分——合計し、その合計に2025/26年度は15%のClass 1A税率を掛けます。その計算に必要なのはたった一つの数字、すなわちすべてのP11Dの全セクションから1Aフラグが付いた現金相当額の合計です。その数字を得るには、80枚の個別フォームから値を拾い出す必要があります。

単一の給与計算プロバイダーを利用している企業の場合、そのソフトウェア内のP11D生成ツールで80枚すべてのフォームを一括印刷できるかもしれません。しかし、従業員ごとに1行で、セクション別に現金相当額が区分された構造化スプレッドシートは生成されません。そのスプレッドシート——P11D(b)の元となる作業ファイル——は手作業で作成する必要があります。従業員一人あたり約2分かけてPDFを開き、該当するセクションの値を見つけて行に転記し、フォームの14セクションにわたって読み間違いがないか確認する作業を、80人の従業員の福利厚生ポートフォリオで行うと、期限前の最終2週間で2時間半以上の純粋なデータ入力作業が発生します。しかも、これはすべてのドラフトが同じソフトウェアから出力され、すべてのフォームの視覚的レイアウトが同一であることを前提としています。

すべてのP11D(b)計算を支える1枚のスプレッドシート

一括抽出を開始する前に、出力用スプレッドシートにはカラムスキーマが必要です。一般的なものではなく、P11D(b)が求める項目に直接対応する専用のスキーマです。英国給与専門家協会（CIPP）は、毎年の給与年度末資料でP11Dの記入に関する詳細なガイダンスを公開しており、毎年の内容に一貫したメッセージがあります。P11D(b)が従業員ごとに重視するのは、1A課税対象の給付の現金同等額の合計のみです。個々のフォームセクションに遡れる監査証跡を構築することで、給与責任者はHMRCから問い合わせがあった場合にその合計額を防御できます。

実用的なP11D(b)作成用スプレッドシートは、従業員1行につき、本人確認と給付集計の2つの目的を果たすカラムで構成されます。本人確認カラム（従業員名、NINO（英字2文字＋数字6桁＋サフィックス英字1文字、例：QQ 12 34 56 C）、雇用主PAYE参照番号）により、各行が正しいHMRC記録に遡れるようにします。給付カラムは、P11Dのセクション文字を、P11D(b)合計が参照できるスプレッドシートカラムにマッピングします。

このスプレッドシートのほとんどの行は、入力される給付カラムが2～3個のみです。これは、ほとんどの従業員が会社が提供する給付の一部のみを受け取るためです。役員と3人の上級管理職は社用車を持っています。従業員の半数は民間医療保険に加入しています。1人の従業員が年度途中で転居しました。200人規模の会社の給付ポートフォリオでは、報告対象の給付が1つ以上ある従業員が80人いる可能性があり、スプレッドシートは、空のセクションと0円と評価された給付を混同することなく、データの疎らさを処理する必要があります。

複数従業員規模で初めて顕在化する3つの構造的問題

P11Dを1件処理することと80件処理することは、まったく別の作業です。規模の拡大に伴い、給与計算ソフト（バッチ印刷機能付きでも）では対応できない3つの問題が生じます。

延滞ペナルティ制度により、転記ミスのコストは具体的になります。P11Dが1枚遅れたり誤っていたりするだけで、月額300ポンドが1枚ごとに課され、さらに遅延が続けばHMRCが1日あたり60ポンドの追加ペナルティを科す可能性があります。これらのペナルティは裁量によるものではなく、7月6日の期限の翌日から適用されます。提出後に誤りが発覚した場合は修正申告が必要となり、HMRCの処理スケジュールに従って処理されます。

1つの列定義で、すべての給与システムのP11D出力に対応

手動転記に代わる抽出方法はカスタム列抽出です。スプレッドシートのヘッダーとして必要なフィールド名（「車の現金同等額」「医療保険の現金同等額」「ローンの現金同等額」「補填額」など）を入力すると、AIが各P11Dドラフトを読み取り、どの給与システムで作成されたドラフトであっても、正しいセクションの値を指定した列にマッピングします。これは、フォーム上の各フィールドラベルの意味を理解することで機能し、ピクセル座標を照合するわけではありません。車の福利厚生セクションを「Cars and car fuel」と表示するSageのP11Dも、「Car benefit」と表示するBrightPayのP11Dも、AIが両方を同じHMRC定義のセクションFの概念として認識するため、「車の現金同等額」の列にマッピングされます。

これにより、バッチP11D処理がフォームごとの再スキャンから1回の処理へと変わります。列スキーマを一度定義し、すべてのP11Dドラフト（PDF、スキャン、印刷されたフォームのスマホ写真）を1つのバッチとしてアップロードすれば、80行すべてが1つの結合されたスプレッドシートに取り込まれます。コレクションリンク（アカウント不要で他の人がファイルを直接アップロードできる共有リンク）を使用すれば、ドラフトがチームメンバーや外部の給与計算代行業者に分散している場合にも対応できます。

抽出の仕組みを1枚のP11Dドラフトで今すぐテストできます。サンプル（任意の給与システムからエクスポートしたPDF、または印刷されたフォームの写真）をアップロードし、いくつかの列名を指定して、セクションの値がどのようにマッピングされるかを確認してください。

同じ列セットは、税年度や給与プロバイダーを超えて保存・再利用でき、複数の会社のP11D申告を処理する場合にも使用できます。HMRC報告用に英国P11D福利厚生データをExcelに抽出するための包括的なガイドでは、フォームごとの抽出ワークフローを詳しく説明しています。バッチ規模で重要なのは、フォルダ内のすべてのドラフトに対して、どのソフトウェアで生成されたものであっても、同じ列名が機能するという点です。

スプレッドシート80行からP11D(b)の1つの数値へ

抽出したスプレッドシートにデータが入力されると（従業員ごとに1行、識別列が埋められ、該当する給付項目は入力され、該当しないものは空白）、P11D(b)は計算機を使う作業ではなく、数式で完結します。HMRCのCWG5の計算例が示すように、Class 1Aの対象となるすべての給付の現金同等額を合計し、15%を乗じます。データが列に整理されていれば、1A対象の給付列に対してSUMIFを1回、乗算を1回行うだけです。

しかし、このツールはさらに一歩進められます。計算列を使えば、抽出後にではなく、抽出中にAIが合計を実行できます。Total 1A-Liable (sum of Car, Medical, Loan, Van, Accommodation cash equivalents minus Amount Made Good)という列を作成すれば、各下書きを読み取る際に、従業員ごとの1A対象純額が自動的に入力されます。P11D(b)のために80行すべてを合計する列は、すでに従業員負担分を差し引いた値を合計することになり、手動集計で最もよくあるミスの1つを排除します。

バッチ抽出でできないこと — 人の確認が必要な項目

誠実なバッチワークフローには検証工程が含まれます。抽出はドラフトに記載された内容を読み取るだけです。給与システムが福利厚生の値を誤って計算した場合、その誤りはそのままスプレッドシートに反映されます。抽出では、リスト価格とCO2バンドから車の福利厚生を再計算したり、有利な貸付が年間の£10,000の合計しきい値を超えたかどうかを確認したり、福利厚生が1A課税対象として正しく分類されているかを確認したりしません。これらの判断には、HMRC評価ルールに関する給与専門家の知識が必要です。

抽出後に実行する価値のある検証チェックは、データが列で構造化されているため迅速に行えます。

抽出された各行にはソースファイルの参照が含まれているため、フラグが立った行は元のP11Dドラフトにワンクリックでアクセスできます。このトレーサビリティにより、80人の従業員でも列レベルの検証が現実的になります。手動転記のワークフローでは体系的なチェックを維持することは不可能でした。転記の工程だけで利用可能な時間を消費していたからです。

P11D、P60、P45の一括処理：同じワークフロー、異なる列セット

英国の給与チームは3種類の法定従業員フォームを扱いますが、HMRCに報告するデータは異なっても、一括処理の問題は3つすべてで構造的に同じです。個別のPDF生成は解決済みですが、それを集約したスプレッドシートへのまとめは未対応です。列名は変わりますが、一括ワークフロー（スキーマを一度定義し、すべてのドラフトを一括アップロードし、マージしたスプレッドシートをエクスポートする）は同じです。

違いはフィールドセットです。P60の一括処理（給与監査のためのP60一括処理ガイド参照）では、年度末証明書から給与、税、国民保険料の数値を抽出します。P45の一括処理（退職者フォームP45の一括処理ガイド参照）では、退職日と退職時点の給与を抽出します。SA100の一括処理（SA100確定申告の一括処理ガイド参照）では、自己申告の数値を抽出します。チームで4種類すべてのフォームを処理する場合は、フォームごとに個別の列定義を保存して再利用してください。一括ワークフローは同じで、列名のみがフォーム固有です。

よくある質問