経費申請をアプリにする｜差し戻しと二重申請の確認項目

経費申請をシステム化するときは、事前申請と精算を関連付け、差し戻し後に直せる項目と、二重申請候補を確認する手順を決めます。領収書を添付できても、修正前の申請との関係が追えなければ、再申請してよい支出かを判断できません。

では、同じ領収書が再び添付されたら、すべて二重申請として止めればよいのでしょうか。差戻しや取消しを受けた申請なら、正当な再申請かもしれません。自動で結論を出す前に、元申請との関係を確認できる設計が必要です。

引用する楽楽精算とマネーフォワード クラウド経費の仕様は、2026年10月4日に確認しました。各社製品の機能例であり、Cotomuの標準提供機能ではありません。

経費申請のシステム化は、事前申請と精算を分けて考える

事前申請にあるのは「使う予定」で、精算明細にあるのは「実際に使った結果」です。両者を一つのレコードへ上書きすると、予定額と実績額のどちらが承認されたのかを区別しにくくなります。別の記録として持ち、対応関係を残すほうが判断しやすくなります。

次の表は、事前申請を原則としながら、申請前の立替も例外として確認できるようにする架空の設計例です。導入実績を示すものではありません。

事前申請なしの立替を認めない運用なら、対応がない精算は確認対象ではなく申請不可に変わります。例外を認めるなら、例外理由と承認者を記録する必要があります。

判断の手掛かりになるのが、楽楽精算の申請ルールチェック機能です。事前申請額より精算額が大きい場合に申請不可とする利用例が示されています。

自社では、差額があれば一律に止めるか、理由を入力して承認へ回すかを選びます。製品の利用例と同じルールを採用する必要はありません。

差し戻し後の編集範囲は項目ごとに決める

差戻し後の申請を丸ごと編集可にすると、指摘された金額だけでなく、明細や承認経路まで変えられます。反対に何も直せなければ、再申請になりません。編集権限は一括で切り替えず、変更対象ごとに分けます。

次の表は、差戻し中は明細の修正を許可し、承認後は申請者に直接上書きさせないと仮定した架空の設計例です。

この設計例では、再申請のたびに変更前後を保存し、同じ申請IDでも版を分けます。別のIDで出し直す場合も元申請IDを残し、明細の追加・除外と金額変更を承認者が比較できるようにします。再申請時は合計額と承認経路を判定し直し、変更後の申請全体を承認し直す運用にします。

マネーフォワード クラウド経費の再申請の案内では、差戻しまたは取消しとなった申請について、申請内チャットのコメントを確認し、内容を編集して再申請する手順が示されています。同ページ（2026年2月4日更新）によると、既存明細の編集、新しい明細の追加、申請からの明細除外ができます。承認者の変更・追加の可否は事業者側の設定によって分かれます。

承認済みなら扱いは変わります。同社の明細や申請の削除・取消し手順は、申請者が承認後の明細を削除できず、管理者による取消しが必要だとしています。同ページ（2026年1月28日更新）によると、最終承認後の取消しは申請フォームの編集権限設定に従います。集計に含まれた申請は、先に集計から除外する必要があります。

自社の設計でも、承認後の訂正は元の承認を上書きせず、権限者による取消しと再申請で扱います。まず経理担当が集計・会計連携・支払準備の進み具合を確認し、対象の処理を止めるか、対象から除外できたことを確かめてから取消しへ進めます。支払済み、または処理結果が分からない場合は、取消し・再申請を保留し、経理担当が訂正方法を決めます。アプリ内で取消しにしただけで、連携先の処理や支払も取り消されたとは扱いません。

同じ証憑は、二重申請候補として保留する

同じ領収書らしい申請を見つけても、それだけで重複とは断定できません。楽楽精算は、申請時と承認時に二重申請の可能性がある領収書または請求書を検知できると案内しています。一方、同ページの該当箇所には照合項目、判定しきい値、自動却下の条件までは示されていません。

検知は結論ではなく、確認を始める合図と捉えるのが安全です。次の表も架空の設計例であり、自動判定の精度や効果を示すものではありません。

この例では、経理担当を保留の確認者に定めます。保留画面には元申請と対象明細、承認・支払の状態、再申請理由を並べます。同じ証憑に結び付く他の明細IDや申請IDも照合し、元申請以外に処理中・支払済みの記録がないかを確認します。

確認が終わるまで、候補の申請は承認・支払へ進めません。経理担当が再申請してよいと判断した場合だけ、確認結果と解除理由を残して承認へ回します。重複と確認できた場合は申請者へ戻し、同じ支出が複数の支払対象に残らないようにします。

楽楽精算の申請ルールチェック機能には、設定した社内ルールに反する申請へ警告を表示するか、申請をブロックし、表示メッセージも設定できる仕様があります。これも同製品の機能例です。自社アプリでは、何を警告にとどめ、何を申請不可にするかを業務ルールとして定義します。

入力項目は判断に必要な記録から逆算する

画面に項目を増やすだけでは、差戻しや二重申請の判断は揃いません。少なくとも、次の関係を追えるようにします。

• 事前申請IDと精算申請IDを分けて持ち、対応付ける
• 予定額と実績額を別々に保持する
• 精算明細にもIDを付け、証憑と対応付ける
• 申請、差戻し、取消し、承認の状態を区別する
• 差戻し理由と再申請理由、元申請ID、変更前後の版と明細を残す
• 二重申請候補の元申請、承認・支払状態、確認結果、確認者を残す
• 承認後の取消しを行う権限者と、後続処理から外す条件を決める

この項目があれば、差額、再申請、証憑の再利用を同じ「不備」として処理せず、それぞれの理由に沿って判断できます。既存の表計算から移す場合は、項目をそのまま写す前にExcelから業務システムへ移行するときの考え方を確認すると、履歴や権限まで含めて移行範囲を整理しやすくなります。実装方法を選ぶ段階では、SaaS・kintone・独自開発の比較も選択肢の切り分けに使えます。

支払へ渡す際も、経理担当が承認済みの申請ID・版・明細IDを照合し、保留・取消しの明細や、すでに支払った支出が含まれていないことを確認します。承認済みという状態だけで、支払対象へ渡さないようにします。

試作では、同じ証憑を使う申請を二つ用意し、元申請が差戻しの場合と承認済みの場合を試します。どちらも即時に却下せず、元申請の状態と再申請理由を確認し、経理担当が判断するまで承認・支払を保留できるか。再申請では変更前後を比較でき、明細を追加した後の合計額と承認経路が見直されるかを確かめます。

承認後の変更では、申請者の直接上書きを防ぐだけでなく、後続処理から外れたと確認できるまで取消しを保留できるかを試します。支払済みや処理結果不明の申請を単純な再申請へ進めないことも、合格条件に含めます。

自社の申請ルールに合わせて、入力項目、権限、取消し、再申請の流れを整理したい場合は、業務アプリの相談をご利用ください。初期開発と運用保守は個別見積もりです。連携・移行・権限・データ出力を含む提供範囲は、契約前に確認します。