PAYGサマリー手動入力が、
ほとんどの給与計算チームの想定以上にコストを生む理由
オーストラリア税務署（ATO）のデータマッチングシステムは、毎年約1400万件の個人所得税申告を処理し、納税者が申告する給与・賃金の金額と、雇用主が報告するPAYG源泉徴収データを照合します。両者が一致しない場合（ATOの税務監察官総局のレビューによると、フラグが立った不一致の85～89％が調整に至るとされています）、従業員のmyGov受信箱に届く通知は連鎖反応を引き起こします。従業員が給与計算部門に電話をかけ、給与担当者が元の支払サマリーを開き、そして誰か（通常は4ヶ月前に調整スプレッドシートにTFNを入力した人物）が、たった1桁の入力ミスを3つのシステムと2つの課税年度にわたって追跡するのに2時間を費やすことになります。
重要ポイント
- 7月のPAYG繁忙期は、カレンダー上は1つの日付に3つの期限が重なっています：STP最終化、非STPサマリーの配布、そして4週間前に入力したデータを4回の四半期BAS申告と照合する8月の年次報告書です。
- ATOのデータマッチングフラグの85～89％が実際の調整に至ります。そして、解決された各照会は、中断によってエラー率が倍増する7月の圧縮された期間中に入力された、たった1桁の数字の誤りに遡ることができます。
- STPにより、100人の従業員のうち88人分のサマリーは不要になりましたが、残りの12人分が調整時間の80％を消費しています。この12の例外ケースを自動化すれば、7月のボトルネック全体が解消されます。
7月の繁忙期は、3つの締切が1つに重なったもの
PAYGサマリー手続きの説明では、多くの場合、7月14日という単一の日付に焦点が当てられます。これは、従業員への支払サマリー発行とSTPファイナライゼーションの期限です。しかし、実際に作業を行う給与チームにとって、7月は3つの締切が重なり、それぞれに異なる調整要件とデータソースが存在します。手作業の負荷は、これら3つすべての合計であり、単に1つのサマリーを入力する時間ではありません。
最初の締切は、7月14日までのSTPファイナライゼーションです。給与担当者は、ファイナライゼーション宣言を提出する前に、給与システム内の全従業員の年度累計額が正しいことを確認する必要があります。つまり、システムの合計をサマリー出力と照合する必要があります。単一の給与プラットフォームでデータがクリーンな企業にとっては、これは確認ステップです。しかし、年度途中で給与プロバイダーを変更した企業、異なるABNを持つ複数の事業体に従業員がいる企業、または9月30日までファイナライゼーションが延長された特定の支払先がある企業の場合、この確認は複数ソース間の調整作業となり、電子的に照会できないソースはすべて手動で入力する必要があります。
2番目の締切は、同じく7月14日までの、STPで報告されていない従業員へのPAYG支払サマリー発行です。これにより、書類の山が発生します。STPが免除されている雇用主、中間サマリーを受け取る特定の支払先、およびSTP導入前の期間について従来の証明書が必要な従業員は、すべて物理的またはPDFのサマリーを作成し、給与チームは配布前に検証する必要があります。各サマリーはフォルダに保管され、各フォルダのデータは調整スプレッドシートに反映させる必要があります。
3番目の締切は、8月14日までに提出が必要なPAYG支払サマリー年次報告書（NAT 3447）です。これは、発行されたすべてのサマリーの集計値を、4つの四半期BAS源泉徴収額（ラベルW1およびW2）と照合する必要があります。1つのサマリーで1桁の数字を誤ると、年次報告書に10ドルの差異が生じます。そして、10ドルの差異は、1万ドルの差異と同じATOの照会状を引き起こします。
多くの給与チームが見落としていること： 作業負荷は、サマリーの数に1件あたりの入力時間を掛けたものではありません。それは、サマリーの数に、入力時間、各サマリーを異なるソースシステムと照合する時間、そして照合で見つかった差異を調査する時間を加えたものです。手作業による入力は目に見えるコストであり、調整の手戻りはそれを倍増させる目に見えないコストです。
3つのデータソース、3つの形式、1つの照合スプレッドシート
7月の照合スプレッドシートは3つの異なるデータソースから作成され、それぞれに手動入力の負荷が伴います。
ソース1：STP給与システムデータ。 大半の従業員について、給与システムには正しい年度累計額（総支給額、源泉徴収税、年金拠出金）が記録されています。しかし、これらの数値は給与ソフトウェア内に存在し、照合スプレッドシートで直接利用できる形式ではありません。給与台帳レポートをCSVにエクスポートするのが第一歩です。そのCSVの各行を、従業員名またはTFNで対応するPAYGサマリーに一致させるのが第二歩です。すべてのサマリーが同じ行・列形式で抽出されていない限り、第二歩は手作業です。データは存在しますが、給与CSVの行とサマリーPDFの間の関連付けはなく、その関連付けを作る作業がタイピングです。
ソース2：STP移行前の支払サマリー。 会社がSTPに移行する前に年度の一部を勤務した従業員、または雇用主が年度途中で給与プロバイダーを変更し移行前の期間がSTP報告対象外となった従業員は、STP移行前の月数分の従来型PAYG支払サマリーを持っています。これらのサマリーは、以前の給与ソフトウェアで生成されたPDF、または印刷された証明書のスキャンコピーとしてのみ存在します。現在のSTPデータに対応する行がないため、照合スプレッドシートには独立したエントリとして含める必要があります。電子的な抽出データがないため、各サマリーのすべてのフィールド（ABN、TFN、総支給額、源泉徴収税、RFBA、RESC、一時金の金額）を再入力する必要があります。
ソース3：サードパーティプロバイダーの支払サマリー。 任意源泉徴収契約に基づいて支払われる請負業者、給与管理を共有するが別のABNで運営される関連会社の従業員、および独自のPAYGサマリーを発行する人材派遣会社から支払いを受けた労働者 — これらの証明書は、給与受信箱にPDF添付ファイルまたは物理的な郵便物として届きます。それぞれが1つの文書で、15～20のフィールドがあり、照合スプレッドシートに抽出して追加する必要があります。給与システムデータとは異なり、CSVエクスポートもSTP記録も電子的な対応物もありません。PDFからスプレッドシートへの唯一の経路はキーボードです。これは、英国の給与チームがP60手動データ入力やP45紙処理を行う際に直面するシナリオでもあります。文書の種類や地域は変わりますが、紙やPDFの証明書から照合スプレッドシートにデータを抽出するという根本的な問題は同じです。
誰も数えないコスト：ATO照会、監査の摩擦、従業員からの問い合わせ殺到
手作業による入力の直接コスト（入力に費やす時間）は、全体の負担の中で最も小さい部分です。それよりも大きく、定量化が難しく、給与計算の計画で予算化されることがほとんどない3つのダウンストリームコストがあります。
ATOデータ照合クエリの解決
ATOのデータ照合システムは、全従業員の確定申告と雇用主が報告したPAYGデータを比較します。税務監察総局の調査によると、フラグが立ったケースの85～89%が調整対象となり、不一致の大半は誤検知ではなく実際のエラーであることが判明しています。TFNの数字1桁の入力ミス（従業員123 456 789を123 456 798と入力）は、3つのシステムで不一致を引き起こします。従業員のmyGovプリフィルに誤った雇用主が表示され、従業員が異議を申し立て、ATOが雇用主に問い合わせ、給与担当者は原本のTFN申告書を探して正しい番号を証明しなければなりません。クエリ1件あたりの解決時間は30分～2時間。手入力された100件のサマリーのバッチで、給与担当者のエラー率が控えめに見積もって1%の場合、少なくとも年に1件のクエリが発生します。8時間のデータ入力作業では疲労が蓄積するため、実際はさらに多くなります。
外部監査の摩擦
外部監査人が給与費用の実証テストのために20名の従業員を選んだ場合、各従業員のPAYGサマリー数値を給与システム、支払いを示す銀行取引明細書、四半期BASまで遡って追跡する必要があります。サマリーが抽出されていないPDFとしてのみ存在し、調整スプレッドシートが手入力で作成されている場合、監査人は自らサンプルを再入力しなければ抽出精度を独立して検証できません。これにより監査期間が延び、請求時間が増加します。データが間違っているからではなく、手作業を繰り返さなければ正しいことを証明できないからです。対照的に、自動抽出で生成された単一のスプレッドシートは、監査人に追跡可能なソースを提供し、再入力なしで元のPDFと照合してサンプリングできます。
確定申告シーズンに殺到する従業員からの問い合わせ
オーストラリアでは7月1日から確定申告が可能になります。従業員がmyGovにログインして収入明細を確認した瞬間、ATOに事前入力されたデータと、最終給与明細や自身の給与の認識、前年度のサマリーに基づいて期待していた金額との間に差異があると、給与計算部門に電話やメールが殺到します。7月1日から14日までの2週間で、120人の従業員を担当する給与計算担当者は、通常15～25件のサマリー数値に関する問い合わせに対応します。各問い合わせでは、元のサマリー、給与台帳、従業員の最終給与明細を確認し、差異を説明する必要があります。しかし、その差異は多くの場合、実際の差異ではなく、タイミングの違い（6月のボーナスが7月に支払われた、従業員が忘れていた給与牺牲制度、従業員が報告対象と認識していなかった報告対象 fringe benefit）に過ぎません。調整スプレッドシートが手動で作成されていた場合、給与計算担当者は自身のデータ入力を確認して質問に答えることになりますが、元のPDFを再確認しない限り、従業員が確認している数値が正しいのか、転記ミスなのかを確認する方法はありません。
STP移行で解決されるはずだったこと、そして残された課題
シングルタッチペイロール（STP）は、PAYG支払概要書を廃止する目的で導入されました。ほとんどの標準的な従業員と雇用主にとって、これは成功しました。雇用主が7月14日までにSTPデータを確定すれば、従業員はmyGovを通じて収入明細にアクセスでき、紙やPDFの概要書は不要になります。ATOは各給与支払い時に直接データを受信し、年度末の確定申告で確認されます。
しかし、STPの約束は3つの特定のシナリオで破綻し、毎年7月に数千のオーストラリアの給与計算チームに影響を与えています。
第一に、STP移行前の期間です。会計年度の途中でSTPに移行した雇用主、または給与計算ソフトを変更し、移行前の期間を新しいシステムのSTPチャネルで報告できない雇用主は、STP移行前の期間について従来のPAYG支払概要書を発行する義務が依然としてあります。これらの概要書は旧ソフトウェアで生成されたPDFとして存在し、ATOは雇用主に5年間の保管を義務付けています。2026年7月に新しい給与計算担当者が2023-24年度の調整を行う必要がある場合（元従業員が2024年の税務評価について問い合わせをしたため）、それらのSTP移行前の概要書はアーカイブフォルダ内のPDFであり、STPデータの行ではありません。
第二に、密接関係者（クローリー・ヘルド・ペイイー）です。取締役、家族経営の家族メンバー、および密接関係者に分類される特定の信託受益者には、標準的な従業員の期限より2.5ヶ月遅い9月30日という別のSTP確定期限があります。多くの雇用主は、STPデータがまだ確定されていない間の暫定書類として、これらの支払対象者に従来のPAYG支払概要書を発行することを選択します。密接関係者の概要書はそれぞれ7月にPDFで届き、9月まで確定されないSTPデータとは別に抽出して調整する必要があります。
第三に、第三者証明書です。人材派遣会社、包括会社、および異なるABNで運営される関連事業体は、別の雇用契約で主要雇用主の給与計算にも記載されている可能性のある労働者に対して、独自のPAYG概要書を発行します。これらの証明書は組織の給与計算システム外から届きます。雇用主自身の報告にはSTP対応物がありません。そして、ABN、TFN、総支給額、源泉徴収額など、すべてのフィールドを手動で調整スプレッドシートに入力する必要があります。なぜなら、第三者のPDFと雇用主の調整プロセスを結ぶ自動化されたパイプラインは存在しないからです。
「PAYG概要書は時代遅れ」というSTPの説明は、大多数の単純な従業員シナリオでは正しいです。しかし、手動データ入力の負荷が集中するまさにその境界線では誤りです。100人の従業員をSTPで処理し、12人の従業員を従来の概要書で処理する給与計算チームは、調整時間の12%を従来の概要書に費やすわけではありません。80%を費やします。なぜなら、STPデータは既に電子化されている一方、従来の概要書は入力が必要だからです。
同じパターンは、雇用主の税務報告を近代化したすべての管轄区域で見られます。オーストラリアのPAYG概要書抽出は、英国のP60抽出と同様に、どちらも最新のデジタル報告と、消えることを拒むレガシーな紙の証明書を調整しています。
よくある質問
なぜ給与ソフトのCSVエクスポートだけでは調整が不十分なのですか？
給与ソフトのCSVエクスポートは、システムに記録されたデータを示します。一方、PAYG支払報告書は従業員とATOに報告されたデータを示します。この2つは異なる可能性があり、その差異こそが調整で発見すべきものです。給与計算システムで最終給与計算後に直接入力された手動調整、6月に支払われたが7月の給与サイクルで処理された賞与（翌年度に属する）、または標準的なSGではなくRESCとして誤ってコード化された給与牺牲制度など、これらすべてがCSVと報告書の間に不一致を生み出します。CSVは給与システムが支払ったと認識している金額を示し、報告書は従業員とATOに支払われたと通知された金額を示します。調整には両方の情報源が必要であり、その差を埋めるのが手動入力です。比較を行うために、報告書データをCSVと同じ形式に手作業で入力する必要があるからです。
STPの確定により、手動調整のステップを完全に省略できますか？
いいえ。STPの確定は、年間を通じて報告したデータが正しいことを確認するものですが、発行する支払報告書、総勘定元帳、四半期BASとデータが一致することを独立して検証するものではありません。ATOは、従業員の税務申告とSTPデータを照合します。従業員の税務申告でSTP報告と異なる収入が申告された場合、ATOのシステムが不一致をフラグし、調査は給与記録に遡ります。STPは報告パイプラインを自動化しますが、パイプラインが正しい数値を伝達したことを確認する検証ステップを代替するものではありません。
100件の報告書の場合、手動入力と自動抽出の実際の時間差はどのくらいですか？
1件のPAYG支払報告書の手動入力（ABN、TFN、総支給額、源泉徴収税額、RFBA、RESC、手当、一時金などを15～20項目入力し、給与台帳と照合）には、慎重に行った場合、1件あたり約2～3分かかります。100件の場合：入力だけで3.5～5時間、さらに入力中に発見した不一致への対応時間は含みません。自動抽出の場合、100件の報告書を一括アップロードし、1つの統合スプレッドシートを受け取るまでに数分の処理時間と、その後15～30分の検証フラグ確認時間がかかります。差は100件あたり約3～4.5時間です。この時間は、給与チームが最も時間に余裕のない7月の時期に節約されます。
数年前のSTP以前の給与明細サマリーは、現在の調整にどのような影響を与えますか？
ATOの監査や過去の税年度の審査（ATOは、ほとんどの納税者に対しては評価後最大4年、詐欺や脱税の場合は無期限に開始可能）において、雇用主は審査対象年度の原本の給与明細サマリーを提出する必要があります。それらのサマリーが現在のシステムでは動作しない給与計算ソフト（例えば2020年にサポート終了したMYOBデスクトップ版）で生成された場合、アクセス可能な記録はスキャンされたPDFまたは印刷コピーのみです。監査人がその年度に発行された全サマリーのスプレッドシートを求めた場合、給与計算チームは、スキャンされた各サマリーのすべてのフィールドを再入力するか、スキャンからスプレッドシートに抽出するかの選択を迫られます。税年度が古くなるほど、元の給与データにアクセスできない可能性が高くなり、紙のファイルキャビネットから監査人が確認できるスプレッドシートへの唯一の道として、自動抽出の価値が高まります。
任意源泉徴収契約に基づいて支払われる請負業者にもPAYGサマリーは必要ですか？
はい。請負業者と任意PAYG源泉徴収契約を結んでいる場合、7月14日までにその請負業者にPAYG支払サマリー（事業および個人サービス所得用、NAT 72545）を発行する必要があります。これは個人非事業用のフォームとは別のサマリー種別で、フィールドラベルは異なりますが、総支払額と源泉徴収税額という同じコアデータを含みます。これらのサマリーは通常のSTPチャネルを通じて送信されません。これらは個別のPDF（通常は請負業者ごとに1つ）として存在し、それぞれを抽出して年次報告書の提出に含める必要があります。任意源泉徴収契約を結んでいる15人の下請け業者がいる建設会社の場合、7月に処理すべきサマリーがさらに15件追加され、それぞれに個別の抽出要件が生じます。