英国P11D給与非課税データをExcelへ抽出する方法
HMRC年次報告用（2026年版ガイド）

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

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

セクションのアルファベットを知ることは抽出において重要です。なぜなら、同じ特典は、どの給与システムがドラフトを印刷したかに関係なく、常に同じセクションに存在するからです。以下は、HMRCが公式の「P11DおよびP11D(b)の記入方法」ガイダンスで定義しているセクションです：

各セクション内では、2つの数値が重要な役割を果たします。キャッシュ・イクイバレントは特典の課税価値であり、会社車の場合、P11D価値（定価プラス付属品）に車のCO2排出量と燃料タイプに基づいて設定された該当パーセンテージを乗じたものです。精算済み額は、従業員が特典に対して支払った貢献分であり、課税価値を減らします。実際にHMRCに流れる数値は、キャッシュ・イクイバレントから精算済み額を差し引いたものです。1A指標が付けられた特典は、雇用主がClass 1A国民保険を支払う義務があるものです。これは後でP11D(b)合計を作成する際に重要になります。

したがって、実用的なP11D抽出スプレッドシートは、従業員ごとに1行、身元情報フィールドとセクション別の特典値を組み合わせた列セットで構成されます：

P11Dの現物給与データが給与明細より抽出しにくい理由

給与明細には、総額・税・NI・手取りといった安定した繰り返しのフィールドセットがあり、人によって大きく変わることはありません。一方、P11Dはそうではなく、これが手作業での転記が滞る第一の理由です。従業員ごとにフォームの記入箇所は異なります。ある役員はセクションF・H・Iに記入があり、フィールドエンジニアはセクションGのみ、オフィスマネージャーはセクションIのみという具合です。毎回同じ20の欄を読むのではなく、14のセクションのうち値が入っている2〜3箇所を探し出し、空欄をゼロと誤認せずにスキップする必要があります。

第二の理由は、記入された各セクションが異なるルールで評価されるため、給与明細の数値のように相互に整合性を確認できないことです。会社車のキャッシュ・イクイバレントは定価とCO2バンドに依存し、有利融資は平均残高とHMRCの公定利率に依存し、医療保険は単に保険料です。セクションをまたいだ「これで正しそうか」という単一のヒューリスティックは存在せず、そのため転記するオペレーターには自然なエラー検出の仕組みがありません。セクションFで数字を1桁誤入力しても、正しい数字と同じくらい妥当に見えてしまうのです。

第三の理由はレイアウトです。HMRCはP11Dのデータ内容を義務付けていますが、視覚的な形式は指定していません。そのため、異なる給与ソフトウェアが出力する代替P11Dでは、同じセクションの値が異なる位置に配置されます。Sageは左側にセクション文字を並べた積み上げテーブルで給与特典を印刷するかもしれません。BrightPayは異なるグループ分けをするかもしれません。ビューローの独自テンプレートからPDFにエクスポートしたドラフトでは、すべての順序が変わるかもしれません。特定のプロバイダーのレイアウトで学習したテンプレートベースのOCRツールは、次のプロバイダーでは機能しません。座標ではなく意味で読むこと—複数の給与プロバイダーにわたるP60年末証明書の抽出の背後にある同じ原則—こそが、1つの列定義で全てのソースをカバーできるようにするのです。

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

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

これら3つのステップがP11DからExcelへの変換の全体です — ステップ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が値を計算できます。Total Taxable Benefit (sum of cash equivalents minus amounts made good)という列を指定すると、ドラフトが読み取られる際に従業員ごとの純額が自動入力されます。つまり、P11D(b)用に合計する数値は、すでに従業員負担分が差し引かれた純額になっているため、手動集計でよくあるミスを防げます。

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

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

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

P11D vs P60 vs P45：3つのフォーム、3つの抽出作業

英国の給与チームは3種類の法定従業員フォームを扱いますが、これらは混同されがちでありながら、それぞれ異なる列定義が必要です。P60は4月5日時点で給与計算対象の全従業員に発行される、給与と控除済み税額の年度末証明書です。P45は従業員が退職する際に発行され、退職日までの給与と税額をまとめたものです。P11Dは課税対象となる現物給与を報告するもので、3つのうち唯一、給与ではなく福利厚生に関わるものです。

実務上の要点：P11Dの列セットはセクションごとのキャッシュ・イクイバレントとClass 1A負債に関するもので、本人確認フィールド以外では給与・税額フォームと重複しません。チームで3つすべてを処理する場合は、それぞれに独立した保存済み列定義を用意して再利用してください。バッチ処理のワークフローは同一ですが、フィールド名はフォームごとに異なります。同じツールキットの給与・税額側については、P45退職者データをExcelに抽出するガイド、P45抽出の完全ワークフロー、給与監査用のP60バッチ処理をご覧ください。

FAQ