情報申告の送信後処理まで解説
米国の情報申告をFIREへ送信してきた企業や税務事業者は、単に接続先をIRISへ変えれば済むわけではありません。送信ファイルの形式、認証、エラー処理、訂正申告の運用まで見直さなければ、期限直前に処理が止まるおそれがあります。
FIREは長年使われてきた一方、IRISはWeb画面から入力する小規模利用者と、システム間連携で大量送信する事業者の双方を想定しています。今回の移行は、古い伝送経路の置き換えというより、IRSが情報申告を受け取る方法そのものを組み直す動きとして捉えるべきです。
FIRE廃止で変わる範囲
FIREは「Filing Information Returns Electronically」の略称で、Form 1099シリーズなどの情報申告書を電子送信するために使われてきました。ここで扱われるのは主に支払先や支払額をIRSへ報告する情報申告であり、法人税や個人所得税の申告書を提出する一般的な電子申告システムとは役割が異なります。FIREの終了は、米国の電子税務申告がすべてIRISへ統合されるという意味ではありません。
後継となるIRISは「Information Returns Intake System」と呼ばれ、対象となる情報申告書を受け付けます。IRSは段階的に対象様式や機能を追加しているため、FIREの最終利用可能時期とIRISへの移行期限は、申告書の種類や課税年度によって異なる可能性があります。最新の日程と対象様式は、IRSのFIREに関する案内とIRISの案内で申告前に確認してください[要確認]。
たとえば、ある企業がForm 1099-NECをIRISへ移せても、別部門が提出する様式まで同じ時期に移行できるとは限りません。移行計画を会社単位で一括管理すると、対象外の様式を見落としやすくなります。実務では「どの法人が、どの様式を、何件提出しているか」を先に一覧化し、様式ごとに移行可否を判定する必要があります。
IRISには二つの提出方法がある
IRISには、ブラウザ上で申告情報を入力またはアップロードするTaxpayer Portalと、業務システムからデータを送るApplication to Applicationの仕組みがあります[要確認]。前者は件数が少なく、専用システムを開発するほどではない企業に向いています。後者は給与計算会社や決済事業者のように、多数の受取人について反復して申告する組織で検討しやすい方式です。
たとえば年間30件のForm 1099を提出する会社なら、担当者がポータルを使うほうが開発費を抑えられます。一方、数十万件を処理する事業者が同じ運用を採れば、ファイル生成、受付結果の取得、再送を人手で回せません。提出件数だけでなく、訂正の頻度と処理を完了させるまでの作業量で方式を選ぶべきです。
A2Aでは、FIRE用ファイルをそのまま送信できるとは考えないほうが安全です。IRISが指定するXMLスキーマ、送信単位、認証手続き、受付結果の形式に合わせて実装し直す必要があり、利用開始前には申請や試験が求められる場合もあります[要確認]。FIRE向けの固定長ファイルを給与システムから直接生成していた企業なら、データ抽出部分は残しつつ、IRIS用データへ変換する層を分離すると改修範囲を抑えられます。
移行で難しいのは送信後の処理
IRIS対応では、申告データを送れた時点を完了としない設計が必要です。システムが送信を受け付けたことと、各申告レコードが正常に処理されたことは同じではなく、受付結果を取得してエラーの有無を確認しなければなりません。通信が切れた際に同じデータを再送すると、重複申告を発生させる可能性もあります。
たとえば1万件をまとめて処理した際、一部の受取人識別番号や住所に問題があれば、そのレコードだけが拒否される場面を想定できます。担当者には「送信成功」と表示されているのに、実際には複数件が未提出のまま残る設計では、申告期限後まで不備に気づけません。受付番号、レコードごとの状態、エラー内容、再送履歴を保存し、元の会計データまで追跡できるようにします。
移行後の処理は、次のように送信と確認を分けて管理します。図の後半にある訂正申告は通常の再送とは異なるため、元の申告を特定できる情報を保持しておかなければなりません。
flowchart TD
A["会計・給与データを確定する"] --> B["IRIS形式へ変換する"]
B --> C["事前検証を行う"]
C --> D["IRISへ送信する"]
D --> E["受付結果を取得する"]
E --> F{"エラーがあるか確認する"}
F -->|ある| G["原因を修正して対象レコードを再処理する"]
F -->|ない| H["受付情報と申告データを保管する"]
H --> I{"後日訂正が必要か確認する"}
I -->|必要| J["元申告に対応する訂正申告を作成する"]
特に注意したいのが、氏名や納税者番号を直す訂正と、金額を直す訂正の扱いです。申告書の種類や訂正内容によって必要なデータが変わるため、単純に最新データで上書きする実装では履歴を説明できません。IRSから照会を受けたときに備え、送信時点の内容と訂正後の内容を別々に保存しておくほうが安全です。
並行稼働を期限直前まで延ばさない
移行は、FIREの停止日から逆算するのではなく、最初の本番提出日から逆算します。IRISの利用申請、権限設定、証明書などの準備、試験送信、社内承認にはそれぞれ時間がかかる可能性があります[要確認]。外部ベンダーへ開発を委託していても、提出者として登録する法人情報や担当者権限まで任せきりにはできません。
たとえば1月末に大量の情報申告を行う会社が、同じ月に初めてA2Aの接続試験を始めると、エラーがIRIS側の仕様によるものか、自社データによるものかを切り分ける時間が足りなくなります。前年中に少量のテストデータを通し、受付結果を社内システムへ戻すところまで確認しておくと、本番時の調査範囲を狭められます。FIREとIRISの並行利用が認められる期間であっても、同一申告を両方へ送らない統制が必要です。
また、IRISへの移行を機に提出元データの品質も確認したいところです。受取人名、納税者番号、住所、支払区分が複数のシステムに分散していると、送信形式だけを変更してもエラーは減りません。IRIS対応を接続改修ではなく、元データから受付確認までを一本につなぐ業務変更として進めることで、FIRE終了後も期限内申告を安定して続けられます。