出張旅費の日当と宿泊料、単価を決める4つの方法と選び方

こんにちは。シンプルなのに多機能で圧倒的に使いやすい、クラウドワークフロー「kickflow」のメディア運営チームです。

「出張旅費の日当と宿泊料を、申請画面で役職から自動で出せないか」
紙の旅費精算書をワークフローに移す総務の担当者から、こうした相談を受けることがあります。単価表の役職と地域区分を、申請画面でそろえる方法が一通りではないためです。

マスタと計算の欄を持つ製品なら、単価表をマスタに登録し、選んだ行の単価を計算の欄に引く設定は組めます。一方で、どの値を申請者に選ばせ、どの値をシステムに任せるかを決めないと、選び間違いがどこで止まるかが定まりません。そこで今回は、単価を決める4つの方法と、申請者が選ぶ欄の置き方を解説します。

この記事の要点

• 日当と宿泊料の単価を決める要素は、システムが持っている値、持っているが計算に使えるとは限らない値、申請のたびに変わる値の3つです。
• 単価の決め方は、手入力、マスタから引く、役職をユーザーの追加情報から引く、経理が承認時に入れる、の4つです。1回の申請に並ぶ行の数、役職の情報を誰が更新するか、経理の入力の負担で選びます。
• 申請者が選ぶ欄は、初期値を置かずに回答必須にするか、低い単価か高い単価を初期値に置くかの3通りです。毎回選ぶ手間と、選び忘れたときの誤りの出方を引き換えます。
• 期間でまとめて出す申請では、日付ごとに1行の明細にします。

日当と宿泊料の単価を決める3つの要素

日当と宿泊料の単価は、申請画面から見ると出どころの違う3つの値の組み合わせで決まります。自動で出せるかどうかは、3つのうちどれが申請画面の上にそろっているかで決まります。

日当とは、出張の日数に応じて、旅費規程で定めた定額を支給するものです。旅費の費目は、金額の決まり方で単価表に載るかどうかが分かれます。

このあとの単価表に並ぶのは、定額で決まる日当と宿泊料です。例えば、ある会社の旅費規程に、次のような単価表があるとします（金額は説明のための例です）。

この会社の営業課長が、1か月分の旅費をまとめて申請します。その月の出張は、地域区分Bの営業所への2泊3日と、地域区分Aの取引先への日帰りの2回です。正しい金額は、日当が11,500円（3,000円×3日と2,500円×1日）です。宿泊料は18,000円（9,000円×2泊）で、合わせて29,500円になります。

扱いが分かれるのは、2つ目の役職です。計算式から役職を読めない場合、役職も申請者が選ぶ値になり、選び間違いの入り口が1つ増えます。

出張旅費の単価を決める4つの方法

単価の決め方は、手入力、マスタから引く、役職をユーザーの追加情報から引く、経理が承認時に入れる、の4つです。方法3だけは組める製品が限られ、残る3つの違いは申請者の手間と誤りの入り口の数です。表は上から順に、申請者の手から外れる値が増える並びです。

方法2は、単価表を選択肢のマスタとして登録し、選んだ行の単価を計算の欄に引く形です。計算の欄に引いた単価が申請した時点で固まる製品なら、規程の改定でマスタを書き換えても、出し終えた申請の金額は変わりません。マスタから値を引く欄の置き方は、申請フォームの項目が52個。どこまで画面に載せるかで扱っています。

方法3は、役職をユーザーの追加情報として持たせ、計算式から読める製品なら組めます。申請者は役職を選ばずに済みますが、組織図の役職とは別に、同じ情報をもう1か所で更新し続ける必要があります。人事の発令日とユーザーの追加情報の更新日がずれると、そのあいだの申請には前の役職の単価が出ます。

方法4は、経理が承認のステップで区分と単価を決めて入れる形です。申請者は規程を見なくて済みますが、経理の入力が申請の件数分増え、申請者は承認が進むまで金額が分かりません。承認者の入力を必須にできない製品では、経理が入れないまま承認が進むことがあります。

選ぶ基準は、1回の申請に並ぶ行の数、役職の情報を誰が更新するか、経理が件数分の入力を受け持てるかの3つです。行が多く、行ごとに区分を選ぶ手間が重いなら、区分も経理が決める方法4に寄ります。方法3で減るのは役職の選択だけです。人事の発令がユーザーの追加情報にすぐ反映されない会社では、方法2にすると、役職の誤りが申請画面の選択として見えます。

申請者が選ぶ欄の3つの置き方

申請者が選ぶ欄は、初期値を置かずに回答必須にするか、低い単価か高い単価を初期値に置くかの3通りです。毎回選ぶ手間と、選び忘れたときの誤りの出方を引き換えます。

ここでの選び忘れは、初期値のまま選び直さずに出すことです。違う値を選んでしまう選び間違いは、どの置き方でも残ります。初期値の設定が必須の欄では1つ目の置き方はとれないため、初期値を置かずに回答必須にできる欄の型を選びます。

例の単価表で、役職の欄の置き方を比べます。

営業課長が、一般社員の初期値のまま出したとします。日当は9,200円（2,400円×3日と2,000円×1日）、宿泊料は16,000円（8,000円×2泊）で、合わせて25,200円です。正しい29,500円より4,300円少なく出ます。課長の初期値のまま一般社員が出せば、本来の25,200円に対して29,500円が出て、4,300円多く払う誤りになります。

入力中に計算結果が出る製品では、最初に気づける機会は申請者が出す前にあります。入力画面で気づかなかった誤りが承認の時点で止まるかどうかは、承認者や経理が単価の内訳まで見るか、合計だけを見るかで決まります。

支給後に見つかった場合、少なく払った誤りは差額の追加支給で済みますが、多く払った誤りは本人に返金を頼む手続きが要ります。多く払う向きの初期値を置くなら、承認の時点で止める見方と組み合わせます。誤りの向きで重さが違うという同じ考え方は、承認者の挟み漏れについて申請者が承認者を毎回選ぶ運用を、いつまで続けられるかで扱っています。

申請者の多くが一般社員なら、一般社員を初期値にしても選び直す人は少数で済みます。申請者の多くが課長以上で、承認者が単価の内訳まで見る運用なら、課長を初期値にする置き方も選べます。役職の割合に偏りがなく、承認者が内訳まで見ない会社では、初期値を置かずに回答必須にするほうが、選び忘れそのものをなくせます。

期間でまとめる申請と日付ごとの明細

1か月分の出張をまとめて出す申請では、日付ごとに1行の明細にします。1件の申請に区分の違う出張が混ざり、領収書の日付と行を突き合わせられるためです。

相談の場で、明細の表にするより、日数と単価の掛け算で足りないかと私が尋ねたことがあります。返ってきたのは、1か月や1か月半の期間でまとめて申請している、という答えでした。何日に泊まったかを出したい、日付がばらばらだと領収書と確認が取れない、とも言われました。私は、出張1回ごとに申請するなら掛け算で足りると考えて尋ねていました。

例の営業課長の申請なら、明細は4行です。

行ごとに区分を選べば、同じ申請の中で区分Aと区分Bが混ざっても、その行の単価が引けます。計算の欄から別の行の値を参照できない製品では、区分は行ごとに選ぶ形になり、行の数だけ選ぶ手間が増えます。区分の欄に初期値を置けば、初期値と同じ区分の行は選び直さずに済みます。

まとめ

最初に決めるのは、役職と区分を誰が入れるか（申請者、ユーザーの追加情報、経理）です。次に、申請者が選ぶ欄ごとに、初期値を置くかどうかと、置くならどちらの単価にするかを決めます。申請者が選ぶ欄の置き方は承認者と経理が内訳まで見るかで変わるため、旅費規程を所管する部門と経理で先にすり合わせておきます。

この整理が、旅費精算書の画面を設計するときのたたき台になれば幸いです。

よくある質問

旅費規程の単価が改定されたら、申請画面はどう直しますか？

単価表をマスタで持つ製品なら、新しい単価を別の行として足し、古い単価に終了日を設ける方法があります。終了日を過ぎた単価が選択肢から外れる製品では、選べるかどうかは選んだ日で決まり、出張した日では決まりません。改定日をまたぐ出張の扱いは、規程の経過措置で決めておきます。

単価を自動で出したあと、承認者は何を見ればよいですか？

計算で出るのは、選んだ役職と区分に対するマスタどおりの単価までです。選んだ役職と区分が合っているか、その日に出張して泊まったかの確認は、承認者か経理に残ります。出張の事前申請を別に回している会社では、精算の申請に事前申請の番号を書く欄を置くと、承認者が2つの申請を見比べられます。精算の承認で誰が何を見るかの分け方は、ワークフローのAI承認、任せられるステップはどこかでも扱っています。

代理申請の機能で事務担当が出す場合、役職の単価はどうなりますか？

代理申請では、事務担当が本人に代わって申請画面を操作します。方法2では、事務担当が本人の役職を選ぶことを、欄の説明に書いておきます。方法3では、計算式が読むのが操作した人の情報か、代理を依頼した本人の情報かを確かめます。操作した人の情報を読む製品では、依頼した本人の情報を指す値を計算式に使えるかで、方法3を選べるかが決まります。