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

80件の個別P11Dが「生成」ではなく「集計」の問題である理由

給与ソフトウェアはP11Dの生成を解決しています——ただし、一度に1名の従業員分のみです。Sage、BrightPay、Xero、IRIS、Moorepayはいずれも、税年度を通じて従業員の福利厚生記録を管理し、HMRCの定める評価ルールに基づいて現金同等額を計算し、提出可能なP11Dフォームを作成します。時間がかかるのは生成の段階ではありません。

時間がかかるのは、すべてのP11D(b)が要求する集計の段階です。P11D(b)は、全従業員に提供されたすべての福利厚生に対して支払うべきClass 1A National Insuranceの総額を申告する雇用主向けの書類です。HMRCのCWG5ガイダンスは明確です：Class 1Aの対象となるすべての福利厚生の現金同等額を——全従業員分——合算し、その合計にClass 1A税率の2025/26年度は15%を乗じます。この計算に必要なのは1つの数字、すなわちすべてのP11Dの全セクションにおける1Aフラグ付き現金同等額の合計です。その数字を得るには、80枚の個別フォームから値を取り出す必要があります。

単一の給与プロバイダーを利用している企業の場合、そのソフトウェア内のP11D生成ツールで80枚すべてのフォームを一括印刷できるかもしれません。しかし、従業員ごとに1行を割り当て、セクション別に現金同等額を分解した構造化スプレッドシートは生成されません。そのスプレッドシート——P11D(b)に反映する作業ファイル——は手作業で作成する必要があります。従業員1人あたり約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つの問題が生じますが、これらは給与ソフトウェアだけでは—バッチ印刷機能があっても—解決できません。

延滞ペナルティ制度により、転記エラーのコストは具体的になります：1枚のP11Dが遅延または不正確な場合、月ごとに£300の罰金が発生し、遅延が続く場合はHMRCがさらに1日あたり£60の罰金を適用する可能性があります。これらの罰金は裁量的ではありません — 7月6日の期限の翌日から適用されます。提出後に発見されたエラーは修正申告を引き起こし、HMRCは独自のタイムラインで処理します。

1つの列定義で、あらゆる給与システムのP11D出力に対応

手作業による転記を置き換える抽出アプローチがカスタム列抽出です。スプレッドシートのヘッダーとして必要なフィールド名（「Car Cash Equivalent」「Medical Insurance Cash Equivalent」「Loan Cash Equivalent」「Amount Made Good」など）を入力すると、AIが各P11Dドラフトを読み取り、どの給与システムが作成したかにかかわらず、正しいセクション値を該当する列にマッピングします。これは、フォーム上の各フィールドラベルの意味を理解することで機能し、ピクセル座標の一致に依存しません。車の福利厚生セクションを「Cars and car fuel」と表示するSage P11Dも、「Car benefit」と表示するBrightPay P11Dも、AIが両方をHMRC定義のセクションFの同じ概念として認識するため、「Car Cash Equivalent」列にマッピングされます。

これこそが、バッチP11D処理をフォームごとの再スキャンから単一パス操作へと変える転換点です。列スキーマを一度定義し、すべてのP11Dドラフトを1つのバッチとしてアップロードするだけで（PDF、スキャン、印刷フォームのスマホ写真など）、80行すべてが1つの結合スプレッドシートに入力されます。コレクションリンク（アカウント不要で、他の人がファイルを直接処理キューにアップロードできる共有リンク）は、ドラフトがチームメンバーや外部の給与事務局に分散している場合に役立ちます。

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

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

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

抽出されたスプレッドシートが完成すると（従業員ごとに1行、本人確認欄が埋められ、給付欄は該当する場合のみ記入され、該当しない場合は空白）、P11D(b)は電卓作業ではなく、数式になります。HMRCのCWG5計算例は計算方法を明確に示しています。Class 1Aの課税対象となるすべての給付の現金同等額を合計し、15%を掛けます。データが列に構造化されていれば、1A課税対象の給付列に対する1つのSUMIFと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種類すべてのフォームを処理する場合は、フォームごとに個別の列定義を保存して再利用してください。一括ワークフローは同じで、列名のみがフォーム固有です。

よくある質問