経費精算の月8時間を月1時間に。Slackで終わる仕組みの作り方

中小企業の経理担当が月末に直面する作業のうち、地味に時間を奪うのが経費精算です。社員から提出されたExcel申請書とレシート画像を1件ずつ突き合わせ、上長へ承認依頼を出し、差戻しを追跡し、最後に会計ソフトへ転記する。社員30名規模で月60〜80件、これだけで毎月8時間以上が単純作業に消えていきます。間違いも許されないし、〆切も動かせない。誰のためにもならないこの作業に、経営者や管理職の時間まで吸い込まれていく感覚があります。Googleフォームと社内のSlack、それに少しの仕組みづくりを組み合わせれば、月8時間を月1時間以下に置き換える運用に切り替えられます。本記事では、経費精算をSlackで完結させる具体的な手順を、現場でつまずきやすいポイントを含めて解説します。

経費精算には、効率化を阻む固有の手間がいくつもあります。まずは何が時間を奪っているのかを言語化しておくと、機械に任せられる部分とそうでない部分の切り分けがしやすくなります。

手作業の経費精算が月末に8時間消える理由

まず数字で現状を直視するところから始めます。私自身が経費精算を手作業で運用していた頃、社員30名規模・月60〜80件の精算業務にかかっていた時間は、経理担当と承認者を合わせて月8時間以上にのぼっていました。内訳を分解すると、どこに時間が吸われているかがはっきり見えてきます。

手作業の経費精算、5つの工程と時間内訳

• 申請内容の確認（2〜3時間）：Excelで提出された申請書を1件ずつ開き、勘定科目・税区分・領収書添付の有無を目視で確認
• 承認依頼と差戻し（1〜2時間）：上長への承認依頼メール、差戻し時の連絡、再申請の追跡を手動で運用
• 領収書の照合（1〜2時間）：申請内容とレシート画像の金額・日付を突き合わせ、不一致があれば申請者へ問い合わせ
• 会計ソフトへの転記（2〜3時間）：承認済みデータを目視でfreeeやマネーフォワードに転記
• 振込データ作成（1時間）：銀行用の振込FBデータを手動で組み立て、二重チェック

8時間というのは「単純作業に8時間使っている」という意味です。本来であれば月次決算の前倒し、資金繰りの精緻化、社員1on1の準備に充てるべき時間が、毎月この作業に吸い取られていました。

電子帳簿保存法とインボイス制度で、手作業のリスクはむしろ増えている

2024年1月の電子帳簿保存法改正で、電子取引データの電子保存が義務化されました。インボイス制度開始後は、適格請求書発行事業者の登録番号確認や税区分の判定も求められます。手作業のままでは「仕訳ミス」「証憑保存漏れ」「税区分の取り違え」が起きやすく、税務調査時のリスクは年々大きくなっています。

仕組みで判定し、仕組みで保存し、仕組みで通知する。経費精算こそ、人の判断を最小化したい業務です。

GoogleフォームとSlackで完結する経費精算の全体像

私が実装した仕組みの全体像は、3つの層に分かれています。新しい専用ツールを買い足すのではなく、Googleフォーム・スプレッドシート・Slackという既に社内にあるサービスをつないで、月8時間を月1時間以下に置き換えました。

3層構成の役割分担

1. 申請UI層（Googleフォーム＋スプレッドシート）：社員はGoogleフォームから申請するだけ。回答は精算台帳シートへ自動で集約されます
2. ロジック層（Google Apps Script）：申請データの整形、勘定科目の自動判定、上長への承認ルーティング、差戻し処理、会計ソフトへの連携を、GASで動かします
3. 通知層（Slack Incoming Webhook）：申請発生時に上長チャンネルへ通知、承認・差戻し時に申請者へDM、月次サマリーを経理チャンネルへ自動投稿します

なぜこの3層構成が中小企業に向いているのか

理由は3つあります。第1に、社員の学習コストがゼロに近いこと。Googleフォームは普段使いのツールなので、別アプリのインストールも研修も不要です。第2に、月額コストがかからないこと。Slack Webhookは無料、GASはGoogle Workspaceの範囲で動き、スプレッドシートも既存契約の中で完結します。第3に、自社の運用ルールが変わっても、GAS側を少し書き換えるだけで追随できる柔軟性があることです。

私が実際にBoostXのクライアント企業で構築した発注業務の自動化では、発注ミスをゼロにすることに成功しました。経費精算も同じ思想で「人が判定する箇所を最小化する」ことが、ミス削減と時間削減を同時に実現する鍵です。

【手順1】申請フォームと精算台帳をスプレッドシートで作る

最初に手を動かすのは、申請フォームと精算台帳の設計です。ここで列定義を雑にすると、後段のGASロジックが破綻するため、最初に時間をかけて整えます。

Googleフォームに入れる7項目

1. 申請日（自動入力）
2. 申請者氏名（メールアドレスから自動補完）
3. 利用日
4. 金額（数値・税込）
5. 勘定科目候補（プルダウン：旅費交通費／会議費／消耗品費／通信費／その他）
6. 用途・取引先（自由記述）
7. 領収書画像（Googleドライブへアップロード）

プルダウンの選択肢は、自社の勘定科目マスタとそろえます。後段で会計ソフトに連携する際、ここの文字列が会計データの正確性を決めます。

精算台帳シートに加える4つの管理列

フォーム回答シートに、GASが自動更新する4つの列を追加します。これが「ステータスを単純フラグで管理する」運用を支える背骨です。

• 承認ステータス：申請中／承認済／差戻し／支払済の4値
• 承認者：上長アカウントを自動判定して書き込む
• 承認日時：Slackの承認ボタン押下タイミングを記録
• 会計ソフト連携ステータス：未連携／連携済／連携失敗の3値

【手順2】GASで承認の流れを動かす

GASで実装するロジックは、フォーム送信トリガーで起動する関数1本と、Slackの承認ボタン押下を受けるWebhook受信関数1本、合計2本です。コードは150行程度に収まります。

フォーム送信時に動かす5つの処理

1. 勘定科目の自動判定（用途・取引先キーワードから推論）
2. 承認者の自動決定（申請者の所属組織マスタを参照）
3. 申請IDの採番（YYYYMMDD-連番形式で重複防止）
4. 領収書画像のリネームとフォルダ自動仕分け（電子帳簿保存法対応）
5. 承認者へのSlack通知送信（次節で詳述）

勘定科目の自動判定は、用途欄の文言に対するキーワードマッチで十分機能します。「タクシー」「JR」「新幹線」→旅費交通費、「ランチ」「会食」「カフェ」→会議費、というシンプルなif分岐から始め、3カ月運用しながら誤判定を学習リストに足していくのが実用的です。

承認後にGASがやってくれること

承認ボタンが押されたら、GASは台帳のステータス列を「承認済」に更新し、freee APIで仕訳データを作成します。BoostXの社内では、freee連携で月次の請求書発行を仕組み化しており、社長としては「毎月、人が触らずに請求書が全件送られる状態を作りたい」という方針を掲げています。経費精算側も同じ思想で、承認済みデータは人手介在ゼロで会計ソフトに流し込む設計が望ましい形です。

差戻し時はステータスを「差戻し」に変更し、申請者へSlackで通知します。差戻し理由を承認者がSlackモーダルで入力できるようにすると、申請者の再申請までの時間が大幅に短縮されます。

【手順3】Slackで申請・承認・差戻しを完結させる

Slack連携は3種類の通知で構成します。Slack Incoming Webhookは無料で発行でき、GASからは数行のコードで投稿できます。

運用する3つのSlack通知

• 申請通知（承認者向けDM）：申請内容のサマリーと承認・差戻しボタンをBlock Kitで送信。承認者はSlack上のクリックだけで処理を完結できます
• 承認結果通知（申請者向けDM）：承認・差戻しの結果と、差戻し時は理由テキストを送信。次のアクションが明確になります
• 月次サマリー（経理チャンネル）：毎月1日朝に前月の申請件数・承認率・会計連携の成功率を自動投稿。月次決算の前倒しに直結します

承認ボタンを動かす受け口

Slackの承認ボタン押下を受けるGAS Webアプリのエンドポイントを1つ用意します。Slackから飛んでくるpayloadを解釈し、申請IDを台帳から検索して、ステータスを更新するだけのシンプルな受け口です。Slack側ではAppを作成し、Interactivity & ShortcutsのRequest URLにGASのデプロイURLを登録します。

承認ボタンが動き出すと、承認者は「メールを開く→添付を確認する→Excelを開く→印鑑をもらう」という4ステップを「Slackで承認を押す」の1ステップに圧縮できます。これだけで承認者側の月間2時間が消えます。

導入時にハマる3つの落とし穴と対処法

私自身が初期実装でハマった失敗実例として、データ形式バラバラで動作不能・GAS6分制限・エラー通知未設定の3つがあります。すべて事前に対処すれば回避できます。

落とし穴1：申請データの形式バラバラで突合できない

フリーテキスト入力を多用すると、後段のロジックが破綻します。「カフェ代」「coffee代」「珈琲代」が別データとして扱われると、勘定科目の判定も会計連携もうまく動きません。対策は、可能な限りプルダウン化することと、自由記述欄には「取引先名のみ」「目的のみ」と記入ルールを明記することです。

落とし穴2：GASの実行時間6分制限に引っかかる

GASは1回の実行が6分を超えるとタイムアウトします。月初に前月分100件を一括処理する設計だと、freee API連携でこの制限に引っかかります。対策は2つあります。1つは時間トリガーを5分間隔で起動し、1回あたり10〜20件ずつ処理するキュー方式。もう1つは申請の都度freee連携を走らせる即時方式。BoostXのGAS実装では、即時方式とキュー方式を組み合わせて運用しています。

落とし穴3：エラー通知が設定されておらず、止まっていることに気づかない

GASは通知を仕込まないと、エラーが起きても誰も気づきません。3日後に経理から「Slackに通知が来ていません」と相談されて初めて気づく事態は、避けたい失敗です。対策は、try-catchで囲んで失敗時は経理チャンネルへSlack通知を飛ばすこと、加えて週次で「正常稼働しています」のヘルスチェック通知を入れることです。

よくある質問