PAYG支払明細書の手動入力にかかるコストは
ほとんどの給与チームが気づいていないほど大きい
オーストラリア税務当局(ATO)のデータ照合システムは、毎年約1,400万件の個人所得税申告を処理し、納税者が申告した給与・賃金の金額と、雇用主が報告したPAYG源泉徴収データを照合しています。両者の金額が一致しない場合 — ATO自身の税務監察総監のレビューによると、フラグが付いた不一致の85〜89%が修正につながるとされています — 従業員のmyGov受信箱に届く通知は連鎖反応を引き起こします。従業員は給与部門に電話します。給与担当者は元の支払明細書を開きます。そして誰か — 通常は4か月前に照合スプレッドシートにTFNを入力した担当者 — が、3つのシステムと2つの課税年度にまたがる1桁の数字の入れ違いを追跡するのに2時間を費やします。
重要なポイント
- 7月のPAYG繁忙期は、カレンダー上では1つの日付に3つの締め切りが重なっています:STPの最終化、非STP支払明細書の配布、そして4週間前に入力したデータを4回の四半期BAS申告と照合する8月の年次報告書です。
- ATOのデータ照合フラグの85〜89%が実際の修正につながります — そして、解決された各照会は、中断によってエラー率が2倍になる7月の短い期間に入力した1桁の数字の入れ違いに遡ります。
- STPにより、100人中88人の従業員の支払明細書が不要になり、残りの12人が照合時間の80%を占めるようになりました — その12の例外ケースを自動化すれば、7月のボトルネック全体が解消されます。
7月の繁忙期は、3つの締め切りが1つに重なったもの
PAYGサマリーのプロセスに関する説明のほとんどは、単一の日付に焦点を当てています。7月14日、従業員への支払明細書の発行とSTPのファイナライズの締め切りです。しかし、実際に作業を行う給与チームにとって、7月は3つの重なる締め切りがあり、それぞれに独自の照合要件があり、それぞれ異なるデータソースからデータを取得します。手入力の作業量は、これら3つの合計であり、1つのサマリーを入力するのにかかる時間ではありません。
最初の締め切り — 7月14日までのSTPファイナライズ — では、給与担当者がファイナライズ宣言を提出する前に、給与システム内の全従業員の年度累計額が正しいことを確認する必要があります。つまり、システムの合計をサマリー出力と照合することです。単一の給与プラットフォームでクリーンなデータを持つ企業にとっては、これはレビューのステップです。年度途中で給与プロバイダーを変更した企業、異なるABNを持つ複数の事業体に従業員がいる企業、または30日9月のファイナライズ延長がある関連する受取人がいる企業にとっては、レビューは複数ソースの照合となり、電子的に照会できないソースはすべて手動で入力する必要があります。
2番目の締め切り — STPを通じて報告されていない従業員へのPAYG支払明細書の発行（これも7月14日まで）— は、書類の山を生み出します。STP免除の雇用主、中間サマリーを受け取る関連する受取人、STP導入前の期間に従来の証明書が必要な従業員は、すべて物理的またはPDFのサマリーを生成し、配布前に給与チームが検証する必要があります。各サマリーはフォルダーに置かれ、各フォルダーには照合スプレッドシートに反映する必要があるデータが含まれています。
3番目の締め切り — PAYG支払明細書年次報告書（NAT 3447）（8月14日締め切り）— は、発行されたすべてのサマリーの合計を、4つの四半期BAS源泉徴収合計（ラベルW1およびW2）と照合することを要求します。1つのサマリーで1桁の数字が入れ違うと、年次報告書に10ドルの差異が生じます。そして10ドルの差異は、10,000ドルの差異と同じATOの照会レターを引き起こします。
ほとんどの給与チームが見落としている点：作業量は、サマリーの数×1つのサマリーを入力する時間ではありません。それは、サマリーの数×入力時間に加えて、各サマリーを異なるソースシステムと照合する時間、そして照合で見つかった差異を調査する時間です。手入力は目に見えるコストであり、照合の手戻りはそれを2倍にする目に見えないコストです。
3つのデータソース、3つの形式、1つの照合スプレッドシート
7月の照合スプレッドシートは3つの異なるデータソースからデータを取得しており、それぞれに手動入力の手間が伴います。
ソース1: STP給与システムのデータ。 ほとんどの従業員について、給与システムには正しい年度累計値（総支払額、源泉徴収税額、退職年金拠出額）が保持されていますが、これらの数値は給与ソフトウェア内に存在し、照合スプレッドシートが直接利用できる形式ではありません。給与台帳レポートをCSVにエクスポートすることが第一歩です。そのCSVの各行を、従業員名またはTFNで対応するPAYGサマリーに照合することが第二歩です。すべてのサマリーがすでに一致する行・列形式に抽出されていない限り、第二歩は手動です。データは存在しますが、給与CSVの行とサマリーPDFの間の関連付けは存在せず、その関連付けを作る作業が入力作業です。
ソース2: STP導入前の支払明細書。 会社がSTPに移行する前に会計年度の一部を勤務した従業員、または雇用主が年度途中で給与プロバイダーを変更し、移行前の期間がSTP報告の対象外となった従業員には、STP導入前の月分の従来型PAYG支払明細書があります。これらの明細書は、以前の給与ソフトウェアで生成されたPDF、または印刷された証明書のスキャンコピーとしてのみ存在します。現在のSTPデータに対応する行がないため、照合スプレッドシートには独立したエントリとして含める必要があります。STP導入前の各明細書のすべてのフィールド（ABN、TFN、総支払額、源泉徴収税額、RFBA、RESC、一括支払額）は、電子的な抽出データが存在しないため、すべて再入力する必要があります。
ソース3: 第三者プロバイダーの支払明細書。 任意源泉徴収契約に基づいて支払われる契約社員、給与管理を共有しながらも別のABNで運営されている関連会社の従業員、および独自のPAYGサマリーを発行した労働者派遣会社から支払いを受けた労働者 — これらの証明書は、給与受信箱にPDF添付ファイルまたは物理的な郵便物として届きます。それぞれが15〜20のフィールドを持つ単一の文書であり、照合スプレッドシートに抽出して追加する必要があります。給与システムのデータとは異なり、CSVエクスポートもSTPレコードも電子的な対応物もありません。そのPDFからスプレッドシートへの唯一の経路はキーボード入力です。これは、P60の手動データ入力およびP45の紙文書処理を扱う英国の給与チームが直面するシナリオでもあります — 文書の種類は変わり、地域も変わりますが、紙またはPDFの証明書から照合スプレッドシートへデータを抽出するという中核的な問題は同じです。
誰も集計しないコスト：ATOの照会、監査の摩擦、従業員からの問い合わせの殺到
手入力の直接コスト（タイピングに費やす時間）は、全体の負担の中で最も小さな部分です。それよりも大きな3つの下流コストがあり、定量化が難しく、給与計画で予算化されることはほとんどありません。
ATOデータ照合クエリの解決
ATOのデータ照合システムは、各従業員の納税申告書を雇用主が報告したPAYGデータと照合します。税務監察総監は、フラグが立てられた案件の85〜89%で調整が必要になるとの調査結果を発表しており、不一致の大半が誤検知ではなく実際のエラーであることを示しています。TFNの数字の入力ミス（従業員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日から7月14日までの2週間で、120名の従業員を担当する給与担当者は通常、明細書の数字について15〜25件の問い合わせを受けます。各問い合わせには、元の明細書、給与台帳、従業員の最終給与明細書を確認して相違を説明する必要があります。多くの場合、それは実際の相違ではなく、タイミングの違いです（7月に支払われた6月分のボーナス、従業員が忘れていた給与天引き制度、報告が必要だと気づかなかった報告可能なフリンジベネフィットなど）。照合スプレッドシートが手動で作成されている場合、給与担当者は自分のデータ入力を確認して質問に答えることになり、従業員が見ている数字が正しいのか、元のPDFを再確認せずに入力ミスなのかを確認する方法がありません。
STP移行で解決されるはずだった問題と、残された課題
Single Touch Payrollは、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を雇用主の照合プロセスに接続する自動化パイプラインが存在しないためです。
STPの説明—「PAYG支払明細書は廃止された」—は、ほとんどの標準的な従業員シナリオでは正しいです。しかし、手動データ入力の負荷が集中するまさにその境界では不正確です。100人の従業員をSTPで処理し、12人を従来の明細書で処理する給与チームは、照合時間の12%を従来の明細書に費やすわけではありません。80%を費やします。STPデータはすでに電子的であり、従来の明細書は入力が必要なものだからです。
同じパターンは、雇用主の税務報告を近代化したすべての管轄区域で見られます。オーストラリアのPAYG明細書抽出は、英国のP60抽出と同様です。どちらも、消えることを拒む従来の紙の証明書と、現代のデジタル報告を照合します。
よくある質問
照合に給与ソフトのCSVエクスポートを使うだけではダメなのはなぜですか？
給与CSVエクスポートは、給与システムに記録されたデータを提供します。PAYG支払明細書は、従業員とATOに報告されたデータを提供します。この2つは異なる場合があり、その差異こそが照合で検出する対象です。最終給与計算後に給与システムへ直接入力された手動調整、6月に支払われたが7月の給与サイクルで処理されたボーナス（翌会計年度に属する）、または標準の法定退職年金ではなくRESCとして誤ってコード化された給与天引き制度など、これらすべてがCSVと明細書の間に不一致を生み出します。CSVは給与システムが支払ったと認識している金額を示し、明細書は従業員とATOに支払われたと通知された金額を示します。照合には両方のソースが必要であり、その間のギャップが手動入力を必要とする理由です。比較を実行するには、明細書データをCSVと同じ形式で誰かが入力する必要があるからです。
STPの確定処理を行えば、手動での照合手順を完全に省略できますか？
いいえ。STPの確定処理は、年間を通じて報告したデータが正しいことを確認するものですが、発行した支払明細書、総勘定元帳、四半期ごとのBASとデータが一致することを独立して検証するものではありません。ATOは、従業員の税務申告とSTPデータを照合します。従業員の税務申告でSTPを通じて報告された金額と異なる収入が申告された場合、ATOのシステムは不一致をフラグし、調査は給与記録に遡ります。STPは報告パイプラインを自動化しますが、パイプラインが正しい数値を運んだことを確認する検証手順を置き換えるものではありません。
100件の明細書で、手動入力と自動抽出の実際の時間差はどのくらいですか？
PAYG支払明細書1件の手動入力は、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件あり、それぞれに独自の抽出要件があります。