スプレッドシートは、チームが慣れ親しんだ方法で記録を追跡し、進捗を監視できるため、税務・規制報告の整理によく利用されています。しかし、組織がプロセス全体の管理状況を把握するためにスプレッドシートに依存すると、その限界が明らかになります。
TIN検証や年末の税務報告などの業務では、完了した記録に最終ステータス以上の情報を示す必要がある場合があります。組織は、検証結果、修正、例外、必要なレビューに関する情報も保持しなければならないことがあります。報告量が増えるにつれ、こうした詳細をスプレッドシートで管理することは次第に難しくなります。
スプレッドシートがコンプライアンスプロセスの一部になるとき
スプレッドシートは、未処理の作業を管理する単純なトラッカーとして始まり、徐々により大きな役割を担うようになることがあります。新たなニーズが生じるたびに、従業員が検証結果、例外、承認、担当者、その他の情報を記録する列を追加することもあります。やがてスプレッドシートは、必要な作業が完了したかどうかを判断するために従業員が使う主要なツールの一つになり得ます。
TIN検証を考えてみましょう。従業員が検証を実施した後、記録が合格したことを示すためにスプレッドシートを更新することがあります。このステータスがあれば、次の担当者は報告プロセスを続行できますが、すでに実施された業務を記録するための別の手順が必要になります。例外が発生した場合、別の担当者がその記録を先に進めてよいか判断できるよう、従業員は問題を説明する追加情報を提供しなければならないことがあります。
プロセスが複雑になるにつれ、この方法ではスプレッドシートにかかる責任が増します。従業員は単に記録を整理するためだけにスプレッドシートを使うのではなく、スプレッドシート外で実施した業務を表すために手入力された情報にも依存することになります。そのため、更新の欠落や不備があれば、他の従業員に見える情報に影響を及ぼす可能性があります。
コンプライアンス業務の完全な記録を維持する
スプレッドシートベースの監督における大きな限界の一つは、記録が変更される過程の履歴を維持することです。スプレッドシートは情報を最新の状態に保つよう設計されているため、過去に何が起きたかを保存する必要性と相反することがあります。
たとえば、支払先の氏名とTINの組み合わせが一致しないため、最初はTIN検証に不合格となることがあります。修正された情報を受け取ると、従業員は元の情報を置き換えてステータスを更新できます。これでスプレッドシートには報告に必要な情報が含まれますが、以前の不一致や、その後の修正が分からなくなる可能性があります。
次のような場合、完全な記録を維持することはさらに難しくなります。
- 以前の情報が置き換えられる場合。修正された情報で記録を更新すると、元のステータスや、その過程で行われた変更の詳細が失われることがあります。
- 担当者が変更される場合。担当者欄には現在その記録を担当している人物を表示できますが、以前のレビューや承認を誰が完了したかまでは保存できません。
- 関連書類が別の場所に保存されている場合。例外の解決に使った情報が別のシステムや共有フォルダーに保管され、スプレッドシートと突き合わせなければならないことがあります。
バージョン履歴や別途保存したコピーによって、こうした情報の一部を残せる場合はあります。しかし、記録の履歴を明らかにするには、複数の情報源を比較しなければならないことがあります。現在のスプレッドシートの外部で管理される情報が増えるほど、スプレッドシートだけでコンプライアンス業務の完全な記録を提供することは難しくなります。
報告量が増えた場合の手作業による監督
組織が大量の記録を処理すると、スプレッドシートベースの監督に伴う手作業の量は大幅に増える可能性があります。記録が増えれば検証業務も増え、その中にある例外については、報告可能な状態にする前に追加の文書化が必要になることがあります。
たとえば、数千人の受取人を処理する組織では、追加対応なしでTIN検証に合格する受取人が多数いる一方、修正情報や追加レビューが必要な受取人もいます。従業員が検証を完了するたびに各結果をスプレッドシートに記録する責任を負う場合、業務そのものと、その業務の組織上の記録との間に、記録ごとに別の手作業による更新が発生します。
この規模になると、従業員による業務の記録方法の違いも目立つようになります。ある人は例外が発生した理由を詳しく記載する一方、別の人は解決後にステータスだけを変更するかもしれません。最終的には両方の記録が同じ結果を示していても、それを裏付けるために利用できる情報量は異なる可能性があります。
組織は、必須項目やより詳細な指示、追加のレビューステップをスプレッドシートのプロセスに加えることで対応することがあります。こうした対策によって文書化の一貫性は高まりますが、コンプライアンス業務に伴う作業量も増えます。従業員は基礎となる業務を完了させたうえで、スプレッドシートに正確に反映されていることも確認しなければなりません。
組織が追加要件に対応しようとするにつれ、スプレッドシート自体も複雑になる可能性があります。単純なトラッカーとして始まったものが、やがて従業員が理解し、正しく維持しなければならない多数の項目、タブ、メモ、参照情報を含むようになることがあります。その結果、処理量が増えるほど、プロセスは社内手順や従業員の知識に依存するようになります。
明確な監査証跡を作成する
スプレッドシートベースの監督の限界は、スプレッドシート全体ではなく、個々の記録を見ると把握しやすくなります。追加対応が必要だった完了済みの項目を一つ選び、それを担当した従業員に尋ねずに何が起きたのかをたどってみてください。
たとえば、支払先が最初にTIN検証で不合格となった場合、その記録が不合格になった理由と、最終的にどのように解決されたかを確認できるはずです。プロセスによっては、その情報に、以前のスプレッドシートへの入力、関連書類、または検証結果を示す別の記録が含まれることがあります。
履歴を明らかにする前に、それらの情報を探し出して組み合わせなければならないのであれば、組織は必要な情報を保持していても、連続した監査証跡として維持できていない可能性があります。この方法で一つの例外をレビューすることは管理可能でも、同じレベルのレビューを多数の記録にわたって行う必要がある場合、プロセスはより困難になります。
基礎となる業務のために設計されたテクノロジーを利用すれば、こうした分断を減らせます。たとえばSovos TINCheckを使えば、リアルタイムまたは一括の検証によって、IRS、SSA、政府の監視リストのデータと納税者識別情報を照合できます。大量の受取人を処理する組織にとって、これは一つのプロセスで検証を完了し、従業員が別のスプレッドシートに業務記録を維持する方法に代わる選択肢となります。
スプレッドシートによる監督の限界に達する地点
スプレッドシートが機能しなくなる記録件数や報告量のしきい値が、必ずしも一つに定まっているわけではありません。むしろ、監督を維持するためにどれだけの追加作業が必要かに注目できます。従業員が同じ情報を複数の場所で更新したり、スプレッドシート上のステータスを裏付ける別の文書を管理したりする必要があるなら、そのプロセスはすでに単純な追跡の範囲を超えている可能性があります。
もう一つの考慮点は、プロセスが管理者にどれほど依存しているかです。経験豊富な従業員が関連記録の保管場所や、特定のステータスの意味を説明できれば、日常業務では問題なく機能するかもしれません。しかし、別の従業員がその説明を受けなくても、利用可能な情報だけで同じ記録をレビューできるべきです。
規制対象業務の量が多い場合、スプレッドシートを拡張し続けるよりも、基礎となる業務を管理するために設計されたテクノロジーへ移行する方が、最終的には現実的になることがあります。これは、TIN検証のような反復可能な業務に特に当てはまります。検証をスプレッドシート外で処理すれば、後から手作業で記録する必要がなくなるためです。
スプレッドシートベースの監督から移行する
スプレッドシートは業務を追跡する有効な方法になり得ます。しかし、組織がスプレッドシートに、別の場所で実施された管理を記録し、後からその業務を裏付けるために必要な履歴を保存する役割まで持たせると、限界が大きくなります。報告量が増えるにつれ、TIN検証などの業務をそのために設計されたシステムへ移行すれば、並行して手作業で追跡する必要性を減らしながら、コンプライアンス監督により一貫したアプローチを提供できます。