英国P11D給与非課税特典データをExcelに抽出
HMRC年次報告対応ガイド（2026年版）

P11Dに記載されるもの — スプレッドシートに反映される項目

P11Dは、課税対象となる現物給付（BIK）— 会社用車、民間医療保険、低利融資などの非現金特典 — を報告する書類で、雇用主が課税年度（4月6日から翌年4月5日）に従業員または取締役1名に提供したものを対象とします。1枚の用紙で1人分をカバーします。HMRCはこの書式をAからNまでの14のアルファベットセクションに分類し、各セクションは独自の評価ルールを持つ給付カテゴリをカバーしており、そのセクションの値が列に必要なものです。

抽出においてセクション文字が重要なのは、同じ給付がどの給与システムで印刷されたかに関わらず常に同じセクションに配置されるからです。以下は、HMRCが公式「P11DおよびP11D(b)の記入方法」ガイダンスで定義しているセクションです：

各セクション内では、2つの数値が重要です。現金等価額は給付の課税価値です。会社用車の場合、P11D価値（定価＋アクセサリー）に、CO2排出量と燃料タイプに基づく適切なパーセンテージを乗じたものです。従業員負担額は、従業員が給付に対して支払った拠出金で、課税価値を減らします。実際にHMRCに報告される金額は、現金等価額から従業員負担額を差し引いたものです。1A表示が付された給付は、雇用主がクラス1A国民保険料を支払う義務があるもので、後でP11D(b)の合計を計算する際に重要になります。

したがって、実用的なP11D抽出スプレッドシートは、従業員1人につき1行で、識別フィールドとセクションごとの給付値を組み合わせた列セットになります：

P11Dの給与明細より抽出が難しい理由

給与明細には、総支給額、税金、国民保険、手取り額といった安定した繰り返し項目があり、人によって大きく変わることはありません。しかしP11Dはそうではなく、これが手作業による転記が非効率になる第一の理由です。従業員ごとに記入される項目が異なります。ある役員はセクションF、H、Iに値が入り、現場技術者はセクションGのみ、事務長はセクションIだけという具合です。毎回同じ20の項目を読むのではなく、14あるセクションのうち値が入っている2～3つを探し出し、空欄をゼロと誤認せずにスキップする必要があります。

第二の理由は、記入された各セクションの評価ルールが異なるため、給与明細のように数値同士で整合性を確認できないことです。社用車の現金同等額は定価とCO2排出区分に依存し、有利な融資は平均残高とHMRCの公定利率に基づき、医療保険は単に保険料です。セクション間で「これで正しそう」という一律の判断基準がないため、数字を再入力する作業者には自然なエラーチェックが働かず、セクションFで誤った数字を入力しても、正しい数字と同じくらいもっともらしく見えてしまいます。

第三の理由はレイアウトです。HMRCはP11Dのデータ内容を義務付けていますが、視覚的な形式は指定していないため、異なる給与計算ソフトが出力する代替P11Dでは、同じセクションの値が異なる位置に配置されます。Sageはセクション記号を左側に並べた積み上げ表で給与非課税支給額を表示するかもしれませんが、BrightPayは異なるグループ分けをする可能性があり、事務所の独自テンプレートからPDFにエクスポートしたドラフトではすべての順序が変わることがあります。あるプロバイダーのレイアウトで学習したテンプレートベースのOCRツールは、次のプロバイダーでは機能しません。座標ではなく意味に基づいて読み取るという、複数の給与計算プロバイダーにわたってP60年末証明書を抽出するのと同じ原理こそが、1つの列定義ですべてのソースをカバーできるようにするものです。

P11D抽出ワークフローの設定

手動によるP11D転記を置き換えるワークフローは3つのステップで構成され、最初のステップである列の定義は、一度設定すれば、すべての従業員、すべての給与計算プロバイダー、そしてP11Dが存続する将来のすべての税年度で再利用できます。

ここで1つのP11Dを使って抽出ステップをお試しいただけます — ドラフト（または写真）をアップロードし、いくつか列名を指定してセクション値のマッピングを確認してみてください：

抽出データからP11D(b)合計を算出

構造化されたスプレッドシートは作業の終わりではなく、P11D(b)を電卓作業から計算式に変えるものです。P11D(b)は、全従業員に報告されたすべての福利厚生に係る雇用主のClass 1A国民保険総額の申告書です。HMRCのCWG5ガイダンスでは、Class 1Aの課税対象となるすべての福利厚生の現金相当額を合計し、その合計にClass 1A税率（2025/26年度は15%、2025年4月5日までは13.8%）を乗じると定められています。

抽出データが列に整理されていれば、1A課税対象の福利厚生列に対してSUMIFを1回実行し、乗算を1回行うだけです。しかし、このツールはさらに一歩進んで、計算列を使用することで、抽出後にではなく抽出中にAIが値を計算できます。課税対象福利厚生合計（現金相当額から従業員負担額を差し引いた額）という列を作成すれば、下書きを読み取る際に従業員ごとの純額が自動入力されるため、P11D(b)で合計する数値はすでに従業員負担額が差し引かれた状態となり、手動集計でよくあるミスを防げます。

抽出したP11DデータをP11D(b)に反映する前の検証

各セクションは独自のルールで評価されるため、ここでの検証は計算チェックよりも、形式と完全性に重点を置いています。以下のチェックはExcelで列ごとに実行され、ソース原稿と照らし合わせて確認すべき数行を抽出します。すべての行のすべてのフィールドをチェックするわけではありません。

抽出された各行にはソースファイルの参照情報が含まれているため、フラグが立った行は元の原稿からワンクリックで確認できます。このトレーサビリティにより、150人の従業員規模でも列レベルのチェックが現実的になります。手動での転記ではこのようなチェックを維持することは不可能であり、まさにそれが手動でのP11D作成が検証を省略しがちな理由です。

P11DとP60とP45：3つの書式、3つの抽出作業

英国の給与チームは3つの法定従業員書式を扱いますが、これらは混同されやすく、それぞれ異なる列定義が必要です。P60は4月5日時点で給与計算対象の全従業員に発行される、年間の給与および源泉徴収税額の証明書です。P45は退職時に発行され、退職日までの給与と税額をまとめたものです。P11Dは課税対象の現物給付を報告するもので、3つのうち給与ではなく福利厚生を扱う唯一の書式です。

実務上の要点：P11Dの列セットはセクションごとの現金等価額とClass 1A納税義務に関するもので、本人確認フィールド以外は給与・税額の書式と重複しません。3つすべてを処理するチームは、それぞれに専用の列定義を保存して使い回してください。バッチ処理のワークフローは同一ですが、フィールド名は書式ごとに異なります。同じツールキットの給与・税額面については、P45退職者データのExcel抽出ガイド、P45抽出ワークフロー完全版、給与監査のためのP60一括処理をご参照ください。

よくある質問