本文へ移動
サンプル記事 / 02
SAMPLE ARTICLE

AIおまかせ編集部の制作サンプルです。掲載画像はイメージです。

経費精算システムを入れたのに月末が楽にならないときの運用改善

経費精算システムを入れたのに月末が楽にならないときの運用改善

この記事の目次全9章

経費精算システムを導入しても、差戻しや承認待ち、仕訳連携後の修正が残り、月次締めが楽にならないことがあります。このとき、申請者の入力ミスやシステムの使いにくさだけを原因にすると、本当に滞っている工程を見落としかねません。

本記事は、数十人規模の会社で経理を1〜2人で回している担当者を想定しています。まず直近の締めを工程別に調べ、担当者と期限を明らかにします。そのうえで、次回の締めで試す変更を1つだけ選びます。買い替えを検討する前に、止まった工程と次に動く担当を特定することが第一歩です。

システムを変えるかどうかではなく、「どの申請が、どこで止まり、誰の行動を待っていたか」から見ていきます。

経費精算の費用発生から支払までの工程と、申請者・承認者・経理の担当、停滞しやすい確認箇所を示す図。

月末の負荷は、申請・承認・経理確認・連携など、止まっている工程ごとに分けて見ます。

システムを入れても月末が忙しい。原因はどう見つける?

「月末が忙しい」という感覚ではなく、直近で完了した1回の締めを申請単位で追います。費用発生、申請、承認、差戻し、経理確認、連携、仕訳計上、支払、締め後修正は別の工程で、止まる場所も担当も異なります。なお、本記事で「マスターデータ」と書く場合は、経費科目、勘定科目、部門、税区分など繰り返し使う設定を指します。

利用中のシステムから取得できる情報を使い、足りない項目だけ次の管理表(表1)で補います。ステータス名や時刻、識別番号はシステムによって異なるため、実際に取得できる項目へ置き換えてください。

項目記入する内容
対象締め・基準時点対象月と表を固定した日時
申請の識別情報申請ID。なければ重複しない管理番号
費用発生日・初回申請時刻支出日と最初の申請日時
現在・最終状態システムに表示される正式なステータス
停滞工程申請、承認、差戻し後、経理確認、連携、計上、締め後修正
担当・工程期限次に行動する役割と期限
差戻し理由証憑、用途、金額・日付、科目・部門、例外など
経理・連携状態確認済み、保留、連携対象、連携結果、仕訳計上など
次の行動行動を1つに絞り、担当と完了期限を記入
原因の仮説ルール、役割・権限、マスター・設定、連携・データ、必要機能

「経理確認締め直後」など基準時点を固定し、更新前の表も保存します。件数に加え、停滞日数、反復する差戻し理由、経理修正、締めや支払への影響を見れば、優先する工程と責任者を決められます。例えば差戻し30件のうち20件が「用途欄が空欄」なら、直すべきは承認者でもシステムでもなく、申請フォームの入力案内です。承認待ちの大半が特定の1人に集中しているなら、承認体制の問題です。

本記事では、公式サポート資料が公開されているマネーフォワード クラウド経費を例に参照先を示します。他のシステムでも工程と役割の考え方は同じなので、参照先を各社の公式資料に置き換えてください。申請から精算・仕訳までの流れは公式ガイドにまとまっています。

申請と承認の締め切りは、いつにすればよい?

費用発生から申請締め、承認締め、経理確認、連携、支払日までを逆算して並べた月次締めのタイムライン。

支払日など動かしにくい基準日から逆算し、承認・修正・連携照合の時間を分けて確保します。

申請締め、承認締め、経理確認締めを同日にすると、差戻しや不在の影響が後工程へ集中します。支払実行日、銀行への振込データ提出日、会計締め日、経営報告日など、自社で動かしにくい基準日を決め、そこから逆算します(表2)。

例えば支払日が翌月25日なら、連携実行を20日、経理確認締めを17日、承認締めを12日、申請締めを10日のように置き、承認と差戻し後の修正に各2〜3営業日、経理確認に3営業日程度を確保する考え方です。日数は自社の件数と担当人数で調整してください。

日程・時点自社日付決め方と担当遅延・不在・差戻し時の行動
対象期間[ 月 日〜 月 日]当月扱いとする費用発生日の範囲を決める範囲外(前月以前)の申請は例外審査へ回す
申請締め[ ]承認・修正期間から逆算遅延申請として識別し、社内方針に沿って処理
承認締め[ ]経理確認締めより前に設定正式な代理承認者、または督促担当へ連絡
経理確認締め[ ]連携前の照合・修正時間を確保保留、例外、次回処理などへ分類
連携実行[ ]会計連携・支払処理の要件から設定予備担当が結果を見届け、安易に再実行しない
支払日[ ]社内規程や支払方針に従う締切超過時の扱いを方針に沿って連絡

日程確定前に、土日祝日、担当者の不在、システム保守、差戻し後の修正期間、主担当と予備担当を洗い出します。承認締めと経理確認締めの間に連休が入る月は、その分だけ前倒しが必要です。

差戻しや締め切り後の申請は、どう扱えばよい?

経費申請を通常申請、差戻し後の修正、例外審査、締め後修正に分けた判断フロー。

通常の不備対応と例外判断、締め後の訂正を分けると、重複申請や判断待ちを抑えやすくなります。

不備と特殊事情を一律に扱うと、差戻しや個別判断が増えます。例えば、領収書の宛名が個人名になっていた申請と、領収書そのものを紛失した申請を同じ「差戻し」で返すと、前者は再提出で済むのに、後者は申請者と承認者が判断を抱えたまま止まります。申請を次の4つに区分し、行動と判断者を明確にします。

  1. 通常申請

    費用発生日、支払先、金額、用途、必要な科目・部門、証憑をそろえて承認へ進めます。

  2. 差戻し後の修正

    通常ルール内で補える不備は、修正内容、担当、期限を示し、元の申請を修正します。差戻し理由と再申請日時も残します。

  3. 例外審査

    領収書紛失や期限後申請などは、理由、代替情報、金額、日付、業務上の必要性を添えて、指定の権限者が判断します。例外申請は審査依頼であり、受け付けただけでは承認、精算、当月支払は決まりません。

  4. 締め後修正

    元の申請ID、対象期間、誤りの理由、権限者、訂正記録を残し、社内で定めた手順に従います。

差戻し後に別の申請を作る前に、元申請の状態を調べる

差戻し後の編集、再申請、取消、新規作成は、元申請の状態と利用中のシステムの手順を調べてから行います。調べる前に別申請を作ると、重複や履歴の分断につながります。

例に挙げたマネーフォワード クラウド経費では、再申請に関する公式FAQと承認後の修正に関する公式FAQで手順を調べられます。領収書を紛失した経費の扱いや締め後の訂正は、消費税の仕入税額控除に必要なインボイスの保存や、電子帳簿保存法の保存要件に関わるため、社内規程で決めきれない場合は税理士に相談してください。

承認者が休みのとき、誰が対応すればよい?

承認者が出張中の3日間で承認待ちが積み上がり、戻った日に一括承認した申請が経理確認に殺到する、という流れは珍しくありません。承認、経理確認、督促、設定変更は別の役割です。承認者が不在でも、督促担当に承認権限が移るわけではありません。

締め運用で明確にしたい5つの役割

申請者

必要情報をそろえ、差戻し箇所を修正します。

業務承認者・正式な代理承認者

業務承認者は割り当て範囲で支出の必要性を判断し、代理承認者は記録された範囲と期間に限って代理承認します。

督促・エスカレーション担当

期限超過や不在を連絡しますが、承認はしません。

経理確認者・経理責任者

経理確認者は処理に必要な情報がそろっているか見て、経理責任者は例外、締め後修正、再連携の権限を管理します。

システム管理者

承認された設定変更を実施します。

代理承認には対象範囲、有効期間、記録方法を定め、権限が有効か確かめます。例えば「部長の不在中は課長が自部門の申請に限って代理承認し、期間と件数を督促担当が記録する」のように決めておくと、戻った承認者も内容を追いやすくなります。

例に挙げた製品では、従業員ごとの権限とワークフロー割当を公式ガイド(STEP5 従業員)で調べられます。代理承認を誰にどう設定できるかはシステムや契約プランで異なるため、現行設定と公式サポートで確かめてください。

会計ソフトに連携したら、経理の確認は終わり?

承認済みの申請を連携対象、保留などに分け、連携成功から仕訳計上までを照合する関係図。

承認済み、連携成功、仕訳計上を別の状態として照合し、結果不明のまま再連携しないようにします。

承認済み、連携対象、連携成功、仕訳計上、支払完了は別の状態です。連携が成功しても、会計側で仕訳が計上されたとは限りません。連携直前に対象を固定し、件数と金額の両方で次の関係を照合します。

基準時点の承認済み=連携対象+保留+除外+手動処理+修正・繰越

保留は判断待ちで当月は連携しないもの、除外は経費として計上しないもの、手動処理は会計側で直接起票するもの、修正・繰越は差戻しや翌月送りにしたものを指します。承認締め後に行った承認や取消は基準時点の件数に含めず、申請ID、金額、理由、日時を別に記録します。

続いて、連携対象=連携成功+失敗・結果不明、連携成功=仕訳計上+正常な時間差+連携後の取消・修正を突き合わせます。正常な時間差は、連携済みで会計側への反映を待っているものです。差異があれば申請単位で追います。よくあるのは、連携後に部門や科目を会計側で直したため、経費側の記録と合わなくなるケースです。この状態で再連携すると、二重計上につながります。

連携と修正で残す最低限の記録

連携実行記録

実行日時、担当、対象と結果の件数・金額を残します。

再連携前の照合

元申請、前回結果、会計側の検索結果、再実行理由を記録します。

申請と仕訳の照合

利用できる申請ID、連携情報、仕訳番号、金額を対応させます。

マッピング変更記録

勘定科目、部門、税区分などの変更理由、承認者、適用日を残します。

締め後修正記録

元記録、対象期間、理由、権限者、訂正の参照情報を残します。

結果不明のまま再連携しない

再連携前に、元申請と会計側の計上状況を照合します。利用できる識別情報や連携時点は、システムと連携先によって異なります。

例に挙げた製品では、経費機能設定の公式ガイドと、クラウド会計・確定申告との未連携に関する公式FAQが参照先です。

次の月末を楽にするには、何から変えればよい?

複数のルールや設定を同時に変えると、何が結果へ影響したか判断しにくくなります。直近締めで見つかった問題から、件数を数えられる対象を1つ選びます。次回の締めでは、変更も評価対象も1つに絞ることが重要です。

評価表には、次の4ステップで決めた内容をそのまま記録します。

  1. 対象を決める

    「申請品質」ではなく「用途不明による差戻し」のように数えられる問題を選びます。影響件数、締めへの影響、統制リスク、次回締めまでに安全に実施できるかを同じ基準で比べ、優先度として記録します。

  2. 比較条件を固定する

    前回と次回で同じ母集団、基準時点、算定方法を使い、基準値として記録します。承認待ち日数なら「初回申請から最終業務承認まで」と定義し、差戻し中の時間は分けて集計します。

  3. 変更を1つ実施する

    入力案内、承認体制、差戻し文面、連携記録などから1つ選び、責任者、適用期間、次回締め後の評価日を決めます。

  4. 評価日に判断する

    指標と副作用(経理作業、例外件数、遅延申請の増減)を見て、継続、調整、追加調査、要件見直しを決めます。重複支払・重複計上、記録欠落、無権限承認は、件数が少なくても優先します。

変更を周知するときは、締め日・必要項目・例外の扱い・連絡先を1通にまとめます。次の文面を社内向けに書き換えて使ってください。

次回の申請締めは[日時]、承認締めは[日時]です。申請時は[必要な用途・証憑・部門等]を入力してください。不足がある場合は、理由と裏付けとなる情報を添えて例外申請を行います。例外申請は別途審査され、当月支払を保証しません。不在や期限の連絡先は[督促・エスカレーション担当]です。

運用を変えても改善しないとき、システムを買い替えるべき?

未解決の問題を、表1の「原因の仮説」と同じ区分で「ルールの不備」「役割・権限の設定不備」「マスター・設定の不備」「連携・データ形式の不一致」「必要機能の不足」に分けます。月末の忙しさだけでは、システムが原因とは判断できません。例えば「承認者が毎月遅い」は役割・権限の問題で、「異動した社員の申請が旧部門で計上される」はマスター更新の問題です。どちらも買い替えでは解決しません。

システム・連携の見直しを始める前に押さえること

  • 必要なフローや統制、担当、期限、例外時の判断者を業務要件として記述した
  • マスター、権限、承認経路、連携設定を見直した
  • 公式資料またはベンダーサポートで仕様を調べ、可能な運用変更または設定変更を試した
  • 問題の再現条件、影響する申請件数・利用者・締め日程、回避策とその負担・リスクを記録した
  • 業務、支払、記録、権限、統制への影響を把握した

記録を基に、運用継続、設定・連携調査、要件見直しのどこへ進むかを判断します。

要件見直しへ進む場合に限り、移行、設定、連携、教育、社内工数、データ保持、並行稼働の範囲を調べます。例に挙げた製品の現行仕様は公式サポートサイトで調べられます。

経費精算の締め運用でよくある質問

Q. 期限後や例外の申請は当月支払の対象になりますか?

受け付けただけでは決まりません。指定の権限者による審査結果と社内方針に従います。

Q. 承認者が不在なら督促担当が承認できますか?

督促担当というだけでは承認できません。あらかじめ範囲と期間を定めた正式な代理承認者が対応します。

Q. 差戻された申請は新しく作り直しますか?

原則は元申請を修正します。元申請の状態とシステムの手順を調べずに新規作成すると、重複申請や履歴の分断につながります。

Q. 必要な承認経路や連携統制を実現できるか、どう確かめますか?

業務要件と現行設定を書き出してから、公式資料で調べるかベンダーサポートに問い合わせます。

まとめ:次の月末までに変えるのは1つだけ

直近締めの停滞工程と責任者を特定したら、次回は改善を1つだけ試します。同じ母集団と基準時点で結果を比べ、運用、設定・連携、必要機能のどこを見直すか決めてください。システムの買い替えは、その記録がそろってから検討しても遅くありません。