LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）として業務システムの開発・保守を受託

経費精算システムとは——申請から仕訳・電帳法対応までを担う基盤

経費精算システムとは、従業員が立て替えた交通費・出張費・接待費などの申請から、上長による承認、経理部門でのチェック、会計システムへの仕訳連携、そして帳簿・書類の保存までを一気通貫で扱う業務基盤です。単なる申請フォームではありません。領収書のスキャンやOCR（Optical Character Recognition。画像から文字情報を読み取る技術）による自動入力、交通系ICカードや法人カードとの連携、社内規程に沿った金額・費目のチェックまでを含む点に特徴があります。

従業員から見た価値は、入力負荷の軽減にあります。撮影した領収書からOCRで日付・金額を読み取り、交通費はIC連携で経路と運賃を自動取得できれば、手入力の手間は大きく減るでしょう。一方、経理部門から見た価値は確認負荷の軽減です。規程に反する申請や証憑の不備をシステムが一次チェックし、承認済みデータをそのまま会計仕訳へ流せれば、月次の締め作業は速くなります。

つまり経費精算システムは、従業員の入力負荷と経理の確認負荷という二つの負担を、同時に下げることを狙う仕組みです。開発や刷新を検討する際は、どちらの負担を優先的に解消したいのかを最初に定めることが出発点になります。

なぜ今、経費精算システムの開発・刷新が検討されるのか

刷新ニーズの背景には、法対応と業務負荷の二つがあります。まず法対応の面です。電子帳簿保存法では、帳簿・書類の電子的な保存を「電子帳簿等保存」「スキャナ保存」「電子取引データ保存」の3つの区分に分けて定めています^*1。このうち電子取引データ保存については、令和6年（2024年）1月1日以後に行う電子取引の取引情報は、原則としてデータのまま保存することが求められます^*1。メールやWeb上で受け取った請求書・領収書を紙に印刷して保管するだけでは、要件を満たさない場合があるということです。

経費精算の現場では、電子で受領した証憑と、紙で受け取ってスキャナ保存する証憑が混在します。スキャナ保存については、令和5年度の税制改正で解像度・階調・大きさに関する情報の保存が不要になるなど、要件の一部が緩和されました^*2。とはいえ、どの証憑をどの区分で保存するかを正しく仕分ける運用は、依然として設計上の要点です。法令の求める保存方式に合わせて、システム側の証憑管理やタイムスタンプの扱いを整える必要があります。

次に業務負荷の面を見てみましょう。Sansanが2024年4月に経費精算へ携わるビジネスパーソン1,044名を対象に実施した調査では、立替精算は一社あたり月平均1,518件にのぼり、経理担当者は立替精算に毎月平均104時間を費やしていました^*3。同調査では、約34.8%が経費の不正利用を見聞きした経験があると回答しています^*3。インボイス制度への対応でも、経理担当者の35.0%が「求められる要件確認に手間がかかる」と答えました^*3。

従業員側の負担も小さくありません。Sansanが2024年7月に20〜50代の会社員1,000名へ実施した別の調査では、72.8%が立替経費に課題を感じており、精算処理が面倒だと答えた人の46.6%が「システム上で手入力する」ことを煩わしいと挙げていました^*4。手入力の削減とOCRの精度は、従業員の入力負荷を左右する現実的なテーマといえます。法対応の確実性と、こうした二重の業務負荷の解消。この両立が、開発・刷新を後押しする動機になっています。

会計・請求書・ワークフロー・購買調達システムとの違いと連携

経費精算システムを検討するとき、隣接するシステムとの守備範囲の切り分けがあいまいだと、要件が膨らみがちです。まず整理しておきましょう。

会計システムは、仕訳を起点に総勘定元帳や試算表、決算書を作る基幹です。経費精算システムは、その手前で従業員の立替経費を集約し、承認を経て仕訳データを会計側へ引き渡す役割を担います。両者は仕訳連携でつながりますが、担う工程は別物です。請求書システム（取引先からの請求や自社の発行請求を扱う仕組み）は、支払・売上の管理が中心で、社内の立替経費とは対象データが異なります。

ワークフローシステムは、稟議や各種申請の回付を汎用的に扱う基盤です。経費精算にも承認フローは含まれますが、経費に特化したシステムは費目判定・規程チェック・証憑管理まで踏み込む点で守備範囲が広くなります。購買調達システム（発注から検収・支払までを管理する仕組み）は、事前の発注プロセスを扱うため、事後の立替精算とは扱うタイミングが異なる点に注意が必要です。両者の違いと連携は、購買調達を扱った別稿でも整理しています。

これらの違いを一覧にすると、次のようになります。

要件を固める段階では、この切り分けをもとに「経費精算システムで担う範囲」と「連携で済ませる範囲」を明確に線引きしておくことが後工程を軽くします。とりわけ会計システムとの仕訳連携は、費目マスタや部門コードの整合が崩れると手戻りが発生しやすい箇所です。外注先との要件定義でも、連携仕様を早期に固めることが望まれます。

パッケージ（経費精算SaaS）とスクラッチの判断軸

開発方式の選択は、大きくパッケージ（経費精算SaaS）の活用とスクラッチ開発に分かれます。経費精算は業種を問わず共通性が高い業務のため、標準的な承認フローと会計連携で足りるなら、SaaSの導入・設定で対応できるケースが多いでしょう。法改正への追随をベンダー側が担ってくれる点も、SaaSを選ぶ理由になります。

パッケージ（SaaS）が向くケース

承認ルートが比較的シンプルで、社内規程が一般的な範囲に収まる場合は、SaaSの標準機能でカバーしやすくなります。電子帳簿保存法やインボイス制度への対応が製品側で継続的に更新される点も見逃せません。導入スピードを優先し、初期費用を抑えたい企業にも向いた選択肢です。ただし、承認フローの細部や特殊な費目判定、既存基幹との深い連携には限界が出ることがあります。

スクラッチ開発が向くケース

一方、多段階で分岐する承認規程、グループ会社ごとに異なる費目体系、自社で作り込んだ会計・人事システムとの密な連携が必要なら、スクラッチ開発や大幅なカスタマイズが選択肢になります。SaaSの制約に業務を合わせるより、業務に合わせてシステムを作る判断です。もっとも、法改正への追随を自社側で担い続ける負担が生じる点は見落とせません。作って終わりではなく、電子帳簿保存法やインボイス制度の改正のたびに改修が要ります。

判断の軸は、初期費用の高低だけではありません。承認規程の複雑さ、既存システムとの連携要件、そして法令追随を誰が担うかという運用面を含め、数年単位の総保有コストで見比べることが実務的です。SaaSを土台にしつつ、連携部分だけをスクラッチで開発するハイブリッドな構成も現実的な選択肢になります。

外注時に確認すべきポイント——法対応の追随・既存連携・OCRの使い勝手

外注を前提に進める場合、確認すべき点は主に3つに整理できます。いずれも、稼働後のトラブルや追加費用を左右する箇所です。

1. 法改正への追随体制

電子帳簿保存法もインボイス制度も、要件が段階的に見直されてきた経緯があります^*2。スクラッチ開発の場合、改正が入るたびに保存要件や証憑の扱いの改修が必要です。外注先には、改正時の改修をどの契約範囲で担うのか、保守契約に法対応の追随が含まれるのかを事前に確認しておきましょう。SaaSを組み合わせる場合でも、連携部分が改正の影響を受ける可能性は残ります。

2. 既存の会計・人事システムとの連携

経費精算は単体では完結しません。会計システムへの仕訳連携、人事システムからの組織・従業員マスタの取り込み、法人カード明細の連携など、周辺システムとのつなぎ込みが要です。既存システムのAPI（Application Programming Interface。システム間でデータをやり取りするための接続仕様）の有無や、連携方式（リアルタイム連携かファイル連携か）によって、開発工数は大きく変わります。外注先が既存環境を調査したうえで連携仕様を提示できるかどうかは、見積もりの精度に直結する要素です。

3. モバイル・OCRの使い勝手

入力負荷の削減が目的の一つである以上、スマートフォンでの申請やOCRの読み取り精度は、現場の定着を左右します^*4。デモや検証環境で、実際の領収書を読み取らせて精度を確かめることが望まれます。読み取り誤りの補正がどれだけ手間なく行えるか、交通系ICや法人カードの連携がどこまで自動化されるかも、あわせて確認しておくとよいでしょう。使い勝手が悪いと、せっかく開発しても従業員が使わず、手入力に逆戻りしかねません。

この3点に加え、不正・規程チェックの柔軟さも見ておきたい観点です。金額上限や費目ごとのルールをシステム側でどこまで表現できるか、規程改定のたびに設定変更で対応できるかを、要件定義の段階で外注先とすり合わせておくと、運用が安定します。

内製と外注の分かれ目——工数と法令追随の体制で判断する

経費精算システムを内製で担うか外注するかは、自社の開発体制と、法令追随を続けられる余力で決まります。標準的な業務に近く、SaaSの設定中心で済むなら、情報システム部門が主導して内製的に立ち上げられる場合もあるでしょう。一方、自社で作り込んだ会計・人事システムとの密な連携や、複雑な承認規程をスクラッチで作り込む場合は、要件定義から連携開発、テストまでの工数が一気に膨らみます。

専門の開発パートナーに委託する利点は、要件定義から法対応、既存システムとの連携、稼働後の保守までを一貫して任せられる点にあります。元請（プライムベンダー）として全体を統括できる相手であれば、会計・人事・カード会社など複数の関係先との調整も含めて引き受けてもらえます。委託範囲を決める際は、開発だけでなく、電子帳簿保存法やインボイス制度の改正に追随する保守までを見据えて契約範囲を定めることが肝心です。

内製では、既存の担当者が通常業務と並行して対応することになり、法改正のたびの改修対応まで手が回らない懸念が残ります。現状の業務量やシステム構成を踏まえ、どこまでを自社で担い、どこからを外注するかを切り分けることが、現実的な進め方です。

まとめ：経費精算システムの開発を外注する3つの判断軸

本稿では、経費精算システムの開発・刷新を外注する際の進め方を整理してきました。要点は次の3つです。第一に、経費精算システムは申請・承認・OCR・会計仕訳連携・法令対応の保存までを担う基盤であり、会計・請求書・ワークフロー・購買調達の各システムとは守備範囲が異なります。連携で済ませる範囲を早期に線引きすることが、要件の膨張を防ぎます。第二に、電子帳簿保存法の電子取引データ保存は令和6年（2024年）1月1日以後の取引で原則義務化されており^*1、外注時は法改正への追随を誰がどの契約範囲で担うのかが要点です。第三に、パッケージ（SaaS）で足りるかスクラッチが要るかは、承認規程の複雑さと既存システムとの連携要件を、数年単位の総保有コストで見比べて判断するのが実務的といえるでしょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：国税庁「電子帳簿等保存制度特設サイト」（https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/tokusetsu/index.htm）
2. *2　出典：国税庁「スキャナ保存に関する情報」（電子帳簿等保存制度特設サイト）（https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/tokusetsu/03.htm）
3. *3　出典：Sansan株式会社「経費精算に関する実態調査」（2024年5月27日公表、2024年4月16〜19日実施、経費精算に携わるビジネスパーソン1,044名）（https://jp.corp-sansan.com/news/2024/0527.html）
4. *4　出典：Sansan株式会社「経費精算業務に関する実態調査」（2024年8月15日公表、2024年7月12〜17日実施、20〜50代の会社員1,000名）（https://jp.corp-sansan.com/news/2024/0815.html）

Tweet