スプレッドシートの経費精算管理が破綻する理由

経費精算をGoogleスプレッドシートで管理している組織は珍しくありません。初期費用がかからず、誰でも編集でき、集計も自由自在です。問題は、この方法が何人・何件までなら成立し、どこから成立しなくなるのかが、破綻するまで見えないことです。この記事では、詰まるポイントを4つに分けて整理し、移行を検討すべきタイミングの見極め方を示します。

この記事の要点

• スプレッドシート運用は、同時編集による行ずれ、承認済みデータの改ざん、証憑の紐付け、法令対応の4点で詰まる。
• 4つのうち最初の1つは運用の工夫で消えるが、残り3つは道具の性質に由来するため工夫では消えない。
• 人数より、月あたりの申請件数と承認者の数が効いてくる。
• 立替そのものを減らせば、精算管理の問題は規模を小さくできる。

詰まる4つの論点

先に全体像を示しておくと、詰まる箇所は4つあり、そのうち工夫で解決できるのは1つだけです。残り3つは、スプレッドシートという道具が「誰でも編集できること」を前提に設計されていることに由来するため、運用ルールでは消えません。

論点1：同時編集と行ずれ

月末に集中する編集

経費精算の申請は月末に集中します。同じシートを複数人が同時に開き、自分の行を追加・編集する状況が生まれます。Googleスプレッドシートは同時編集に強いとはいえ、行の挿入・削除が重なると、他の人が入力中のセルの位置がずれます。

実害として多いのが、別の人の行に金額を上書きしてしまう、フィルタをかけた状態で行を削除して意図しない行が消える、といった事故です。編集履歴から復元はできますが、誰の金額が正しいのかを確認する作業が発生します。

入力規則では防ぎきれない

データの入力規則や条件付き書式で、ある程度の入力ミスは防げます。しかし「誤った行を編集してしまう」という種類のミスは、入力規則では防げません。行の所有者という概念がシートにはないためです。

これは工夫で消える

4つの論点のうち、これだけは構成を変えれば解消します。Googleフォームを入口にして、回答が自動で追記される構成にすれば、申請者が台帳を直接触る必要がなくなります。台帳の編集権限を承認者と経理だけに絞れば、行ずれの事故はほぼ起きなくなります。

フォームから台帳への流れを作る方法はGoogleフォームで承認ワークフローは作れる？限界と対策で扱っています。

論点2：承認済みデータを後から書き換えられる

構造的な弱点

スプレッドシートを台帳にしている限り、承認済みの行を後から編集できるという問題は残ります。保護範囲を設定すれば一般ユーザーの編集は制限できますが、編集権限を持つ管理者やシートのオーナーには開いたままです。

日常の運用では誰も書き換えないので、問題として認識されません。表面化するのは、監査法人や親会社から証跡の提出を求められたときです。「このデータが承認当時から変わっていないことをどう示すか」に答えられないと、証跡としての価値が下がります。

緩和策と、その限界

現実的な緩和策は3つあります。ひとつは承認イベントを別の追記専用シートにログとして書き出し、台帳と突き合わせられるようにすること。ふたつめは承認時点のスナップショットをPDF等で保存すること。みっつめは、承認済みの行に対してハッシュ値のような検証用の値を持たせ、後から整合性を確認できるようにすることです。

いずれも「書き換えられない」状態を作るわけではなく、書き換えがあれば検知できる可能性を上げるものです。上場準備やIPOを視野に入れている場合、この差は小さくありません。統制の考え方はGoogle Workspaceで稟議・ワークフローを電子化する方法でも扱っています。

承認者の本人確認も同じ根を持つ

もうひとつ見落とされやすいのが、承認したのが本当に承認者本人かという点です。メールのリンクをクリックするとステータスが変わる実装だと、URLを知っていれば誰でも承認できます。この問題を構造的に解く方法はGoogle Chatで承認フローを回す方法と実装の勘所で扱っています。

論点3：証憑と申請の紐付け

領収書はどこに置くか

経費精算には領収書が伴います。スプレッドシート運用では、Googleドライブのフォルダに画像をアップロードし、そのリンクを行に貼る、という方法が一般的です。

ここで起きるのが、リンク切れとファイルの散逸です。アップロードした人がファイルを移動する、共有設定が個人のままで承認者が開けない、フォルダの命名規則が人によって違う——いずれも月に数件なら対処できますが、年間数千件になると紐付けの維持自体が作業になります。

件数に比例して重くなる

この論点の厄介なところは、件数に対して負荷が線形に増えることです。月30件なら月に1〜2件のリンク不備を直せば済みますが、月500件になると常時誰かが対応し続けることになります。しかも不備が見つかるのは承認や監査の段階なので、発見が遅れるほど確認のコストが上がります。

対策としては、フォームのファイルアップロード機能を使い、保存先フォルダと共有設定を固定してしまうのが有効です。申請者が自分でドライブに置く運用をやめるだけで、不備の大半は減ります。

金額の転記ミス

領収書の画像を見ながら、申請者がシートに金額を手入力します。この転記が二重チェックの対象になり、経理の確認工数が発生します。OCRで読み取る構成も組めますが、読み取り結果の検証が別途必要になるため、件数が少ないうちは手入力のほうが速いという逆転も起きます。

同じ課題をkintone側で扱った整理がkintoneで経費申請を自動化する方法｜標準機能の限界とはにあります。

論点4：電子帳簿保存法への対応

何が求められるか

電子取引で受け取った領収書・請求書は、電子データのまま保存することが求められます。保存にあたっては、日付・金額・取引先で検索できること、そして保存後の改ざんを防止する措置が必要とされています。

スプレッドシートとドライブの組み合わせでも、検索要件は運用で満たせます。難しいのは改ざん防止のほうで、前述のとおりスプレッドシートは編集できる前提の道具です。事務処理規程を定めて運用で担保する方法もありますが、規程を定めれば足りるのか、システムで担保すべきかは、組織の規模と統制要件によって判断が分かれます。

なお、具体的な要件の解釈と自社への適用については、顧問税理士や所轄の税務署に確認してください。この記事は一般的な論点の整理にとどまります。

いつ移行を検討すべきか

件数より「承認者の数」で見る

移行のタイミングを判断する指標として、社員数よりも「月あたりの申請件数」と「承認者の数」が実態に近い指標になります。承認者が1人か2人で、全員が同じシートを見る運用なら、件数が増えてもなんとか回ります。承認者が部門ごとに分かれ、自分の担当分だけを見たいという要求が出てきた時点で、シート運用は急に苦しくなります。

理由は単純で、スプレッドシートには「自分に関係する行だけを見せる」という概念がないからです。フィルタビューで擬似的には実現できますが、承認者ごとに設定を作ることになり、その保守が新たな作業になります。

検討に値する3つのサイン

次のいずれかが起きたら、移行を検討する段階です。

1. 月末の締め作業で、集計より「誰の行が正しいか」の確認に時間を使っている
2. 承認者から「自分の担当分だけ見たい」「承認したかどうかを後から確認したい」という要望が出ている
3. 監査や親会社から、過去分の証跡提出を求められる可能性が出てきた

3つめが出たら、運用の工夫では解決しません。

移行前にやっておくこと

移行を決めたら、その前に申請項目と承認ルートの棚卸しをしてください。既存のシートには、途中で追加されたまま誰も使っていない列が残っていることが多く、それをそのまま新しい仕組みに持ち込むと初期設定が無駄に複雑になります。

直近3か月の申請を見て、実際に値が入っている列と、承認の判断に使われている列だけを残す。この作業をしておくと、どの仕組みに移っても立ち上げが速くなります。

「精算をなくす」という方向

ここまでは、精算業務をどう管理するかの話です。もう一段引いて見ると、そもそも立替が発生しなければ精算は要りません。

社員が自分のカードで立て替えるのは、会社の支払手段がその場で使えないからです。購買や出張の手配を法人決済に寄せられれば、立替そのものが発生せず、申請・承認・精算・振込という一連の工程がまとめて消えます。残る精算対象は、日当や少額の現地払いだけになります。

この方向を取ると、前述の4つの論点のうち3つ（改ざん、証憑の紐付け、法令対応）が、そもそも対象件数として小さくなります。管理の仕組みを強化するのではなく、管理すべき対象を減らすアプローチです。

1Approval for Google Workspaceは、Google Workspaceの日常の画面を申請承認の入口としながら、承認と同時に発注・決済を確定させます。立替が発生しないため、精算管理の仕組みをどう作るかという問題自体の規模が小さくなります。

出張領域での同じ考え方はSAP Concurとは？3製品の機能・料金・注意点の後半でも扱っています。

よくある質問（FAQ）

スプレッドシートでの経費精算管理は何人までなら大丈夫ですか？

人数よりも、月あたりの申請件数と承認者の数で決まります。承認者が1〜2人で全員が同じシートを見る運用なら、件数が増えてもある程度は回ります。承認者が部門別に分かれた時点で運用が苦しくなります。

承認済みデータの改ざんを完全に防ぐことはできますか？

スプレッドシートを台帳にしている限り、編集権限を持つユーザーには開いたままです。承認ログを別シートに追記する、承認時点のスナップショットを保存するといった緩和策はありますが、完全な防止にはなりません。

GASで経費精算の承認フローを作れば解決しますか？

申請と承認の流れは改善します。ただし台帳がスプレッドシートである限り、改ざん防止の問題は残ります。また、承認後の振込や会計連携は別途作り込みが必要です。

電子帳簿保存法にスプレッドシート運用で対応できますか？

検索要件は運用で満たせますが、改ざん防止措置の扱いが論点になります。規程の整備で対応するか、システムで担保するかは組織の規模と統制要件によります。具体的な適用は顧問税理士や所轄の税務署にご確認ください。

領収書の保存先はドライブで問題ありませんか？

保存先としては機能しますが、申請者が個別にアップロードする運用だと共有設定の不備とリンク切れが避けられません。フォームのファイルアップロードを使い、保存先フォルダと共有設定を固定する構成にしてください。

まとめ

スプレッドシートでの経費精算管理は、初期コストがかからず柔軟である一方、同時編集の事故、承認済みデータの改ざん、証憑の紐付け、法令対応という4つの論点を抱えます。このうち最初の1つはフォームを入口にすることで解決でき、残り3つは道具の性質に由来するため、工夫では消えません。

移行を判断するサインは、月末の確認作業の内容、承認者からの要望、そして証跡提出の可能性です。あわせて、精算業務そのものを減らす方向——立替を発生させない仕組みに寄せる——も同時に検討すると、解くべき問題の大きさが変わります。