300枚のT4を一括処理し、CRA対応の
給与レポートに — 手入力不要

300枚のT4が3枚とは根本的に異なる問題である理由

1枚のT4スリップからのデータ抽出は解決済みの問題です。T4抽出ガイドでは、欄の構造とワークフローについて説明しています。しかし、300人の従業員、同じCRA必須データを異なる視覚的レイアウトで表示する2～3の給与プロバイダー、総勘定元帳の調整を求めるCFO、層別サンプリングを要求する外部監査人、そして数週間後に迫ったT4サマリーの提出期限——これらが加わると、問題は抽出ではなく構造へと変わります。300枚規模では、1枚規模では存在しない3つの構造的問題が発生し、どれも単なる入力を速めるだけでは解決できません。

カナダ給与のマルチプラットフォーム現実：CeridianとADPとQuickBooksは別物

多くのカナダ企業は、意図してではなく買収によって複数の給与プラットフォームを運用しています。2023年に地域競合他社を買収した企業は、そのADP給与データを引き継ぎました。別個の労働協約で運営される部門はCeridian Powerpayを使用し、本社はQuickBooks Canada Payrollを運用しています。準州でプロジェクトベースの業務を行う子会社はWagepointを使用しています。CRAはレイアウトの異なる代替T4様式を認めており、主要な給与ソフトウェアプロバイダーはすべてその許可を行使しています。その結果、同じCRA必須欄データ（14、16、16A、18、20、22、24、26、40、44、46、52）が、どのソフトウェアで作成されたかによって異なる視覚的配置で表示されます。

これはCRAのシステムのバグではありません。RC4120雇用主ガイドはデータ内容を義務付けています（すべての欄が明確に番号付きで表示されなければならない）が、視覚的なレイアウトはソフトウェアプロバイダーに委ねています。給与プラットフォームが1つだけの雇用主にとっては問題ありません。すべてのT4が同じに見えるからです。しかし、2つまたは3つのプラットフォームを持つ雇用主にとっては、印刷のたびに視覚的に異なるT4が生成され、それらは同一の基礎データスキーマを含んでいるため、給与担当者が翻訳層となります。

テンプレートベースの抽出ツール — サンプルT4の各欄の周りに矩形を描画する方式 — は、Ceridianのレイアウトに調整されたテンプレートがADPのレイアウトを完全に誤読するため、この時点で機能しません。給与担当者は、各プロバイダーのT4をそれぞれ別のテンプレートで個別に処理するか（これにより3つの別々のスプレッドシート間での手動統合ステップが再導入されます）、または非標準フォーマットについては手動入力を余儀なくされます。セマンティック抽出は、各欄がどこにあるかではなく、何を意味するかを読み取ることでこれを排除します。「第16欄 CPP」をCeridianのT4で見つけるのと同じ列スキーマが、ADPのT4、QuickBooksのT4、スキャンされた紙のT4でもそれを見つけます。なぜならAIは、「第16欄」と「従業員のCPP拠出額」が、ピクセル座標に関係なく同じデータポイントを指すことを理解しているからです。

1つのバッチ、3つの異なる関係者：CFO、監査人、そしてT4サマリー

300枚のT4一括抽出の出力を必要とする人々は、同じデータから異なるものを求めています。しかし、全員が1つの信頼できる情報源からそれを得る必要があり、同じ給与担当者が3つの異なる期限に追われて作成した3つの別々のスプレッドシートから得るべきではありません。

300行のCRA照合に耐えるバッチカラムスキーマの構築

バッチをアップロードする前に定義するカラム名は、ワークフロー全体で最も重要な判断です。5人の従業員のテストバッチ用に設計されたカラムスキーマは、300行になるとしばしば機能しません。それは、照合のエッジケース（別途カラムが必要なCPP2拠出金、目に見えないカテゴリを集計する第40欄の課税対象手当、同一課税年度に複数の州からのT4を持つ従業員など）を考慮していないからです。

300行のCRA照合に耐えるカラムスキーマは、出力スプレッドシートでそれぞれ異なる機能を果たす3種類のカラムを中心に構築されます。

複数の事業者番号（それぞれに独自の給与口座を持つ3つの子会社を持つ親会社など）にわたってT4を管理するチームにとって、BNカラムはバッチグループ化キーと照合ピボットの両方の役割を果たします。BNでフィルタリングし、第14欄と第22欄を合計し、各子会社の合計を独自のT4サマリーと比較します。1回の抽出パス、1つのカラムスキーマ、単一のカラムでフィルタリングすることにより同じスプレッドシートから生成される3つの個別のT4サマリー申告。

計算列：CRAより先にCPP・EIの不一致を検出する

300枚のT4を一括抽出する際の最大の価値は、抽出速度ではなく、CRAの調整ロジックを抽出処理そのものに組み込める点にあります。計算列は、各T4の読み取り中に計算を実行し、出力スプレッドシートが開く前に、不一致が発生している少数の明細にフラグを立てます。給与担当者の役割は、データ入力から例外管理へと移行します。つまり、300行すべてを再入力するのではなく、フラグが立った12行を確認するだけで済むのです。

T4一括抽出を申告前監査に変える4つの計算列：

単一T4抽出ワークフローでは、従業員ごとに1行が生成されます。300枚のスリップ規模でのバッチ抽出では300行が生成され、計算列により12行にフラグが立てられます。これらは、CPP拠出、EI保険料、または実効税率が期待範囲外となった12行です。給与担当者は、300行すべてではなく、この12行をレビューします。これが、2月をデータ入力に費やすか、コンプライアンス検証に費やすかの違いです。

バッチ出力とT4サマリー（T4SUM）の照合

T4サマリーは、300枚の個別T4明細書を1つの雇用主レベルの集計に変換します。その中核メカニズムは単一の算術チェックです。80行目（全明細書で報告された控除総額）から82行目（暦年中にCRAに納付された総額）を差し引きます。差額がある場合、それは過払い金（84行目）または未払い金（86行目）のいずれかです。CRAは2ドル以下の差額については請求も還付も行いません。これは四捨五入以外の誤差をカバーする許容範囲です。

300名の従業員のバッチ抽出における照合ワークフローは次のとおりです。

バッチのエッジケース：5枚から300枚のT4にスケールする際に変わること

CPP2 第16A欄 — 静かな照合破綻要因

CPP2は2024年度から導入され、第1天井（YMPE、2025年は68,500ドル）から第2天井（YAMPE、79,400ドル）までの収入に適用されます。給与ソフトウェアがCPP2に対応していない場合、または抽出列スキーマに独立した第16A欄が含まれていない場合、CPP2拠出金は第16欄にまとめられるか（従業員ごとのCPP拠出額がBox 26の5.95%より高く見える）、または完全に省略されます（T4SUMの16行目＋16A行目の合計が納付額に届かない）。300枚のT4のバッチでは、おそらく40名の従業員がYMPEを超え、その40名全員に独自の列に表示されるべきCPP2拠出金があります。第16欄の率を第26欄に対して検証する計算列が不一致を検出し、スキーマ内の独立した第16A欄がそれを修正します。

複数州での雇用 — 1人の従業員、2枚のT4、1つのSIN

暦年の前半をオンタリオ州、後半をアルバータ州で働いた従業員は、同じ雇用主から2枚のT4を受け取ります。各T4は、雇用収入、CPP、EIの州別配分を報告します。CRAは、雇用州ごとに個別のT4明細書を要求します。手動ワークフローでは、給与担当者は同じ従業員が2回出現することを認識し、給与台帳と照合する際に総報酬を二重計上しないようにする必要があります。バッチ抽出では、「雇用州」を列として含め、SINでグループ化して、複数の州を持つ従業員の総雇用収入が年俸と等しく、その2倍にならないことを検証します。

修正・訂正済みT4 — CRAに提出するのはどちらのバージョン？

CRAが提出されたT4を却下した場合（通常、SINが登録名と一致しない場合）、雇用主は修正版T4を発行して再提出します。修正版が原本と同じバッチに含まれると、スプレッドシートには同じ従業員の異なる欄の値を持つ重複行が発生します。計算列「修正フラグ」は、AIがスリップ上の「修正済み」表示を検出し、原本と修正版を区別します。給与担当者はこの列で並べ替え、T4サマリー（T4SUM）集計から原本行を除外し、修正後の数値を提出します。この列がないと、給与担当者はスプレッドシートの合計が一致しない時点で初めて不一致に気づきますが、それは後になってからです。300行の中から1つの重複を見つけ出すのは、バッチ抽出が本来排除すべき手作業の問題です。

ケベック州の従業員 — T4とRL-1の共存

ケベック州の従業員は、連邦T4とRevenu Québec発行のRelevé 1（RL-1）の両方を受け取ります。この2つのフォームは重複しますが、拠出率が異なります。2025年のQPPは6.40%、CPPは5.95%、ケベック州のEI（QPIP）は連邦EIとは異なる率です。バッチ抽出では、T4とRL-1をリンクされた別個の文書として処理する必要があります。T4の第14欄からRL-1の雇用所得を差し引いた額が、ケベック州外で得た所得です。「州」列を含め、ケベック州の従業員をフィルタリングして、T4とRL-1の雇用所得合計が一致することを確認します。RL-1はCRAではなくRevenu Québecに提出され、期限は2月28日と独自です。二重文書の調整の詳細については、T4抽出ガイドでT4/RL-1の分割を詳しく説明しています。

バッチスキーマの税年度間および国境を越えた再利用

2025税年度のT4バッチ用に定義された列スキーマは、2026年、2027年、およびそれ以降のすべての年度で機能します。なぜなら、CRAの欄構造は法改正があった場合にのみ変更され、変更があった場合（2024年のCPP2のように）、スキーマに1列追加するだけで、残りを再構築する必要がないからです。従業員は変わり、数値は変わり、給与プラットフォームは年度途中で変わるかもしれません（ADPからCeridianに移行する企業でも、両方のプロバイダーのT4で同じスキーマを使用します）が、列定義は一定のままです。

同じバッチ処理ロジック（1つの列スキーマ、1回のアップロード、1つの統合スプレッドシート）は、他の年末給与調整ワークフローにも直接転用できます。オーストラリアの給与チームにとっては、同等のアプローチが、ATO年次報告書提出を伴うバッチPAYG支払概要処理に適用されます。英国の雇用主にとっては、同じ方法論で、5月31日のHMRC期限前に給与監査スプレッドシート用のバッチP60処理を処理します。文書の種類は変わり、税務管轄区域は変わり、法定フィールドは変わります。しかし、列を一度定義してすべてを1回のパスで処理するというバッチの原則は直接転用できます。なぜなら、ボトルネックは決して抽出速度ではないからです。それは、給与ソフトウェアが生成するものと、調整に必要なものとの間の構造的なギャップなのです。

FAQ：カナダT4スリップのバッチ処理