経理部門が明確に説明できる経費承認ルール

経理部門に明確な承認ルールが必要な理由

「すべての経費をマネージャーが承認する」という単純なルールは、支出が複数のチーム、予算、金額制限にまたがると機能しなくなります。営業マネージャーは、顧客との夕食会が必要な理由を理解できても、そのコストセンターに残りの予算があるか、経理部門が支出を確認すべきかまでは把握していないかもしれません。

明確な経費承認ルールがあれば、誰が何を判断するのかが決まります。申請者は事実を入力します。予算責任者は、その支出が自分のコストセンターに属することを確認します。経理部門は、ポリシー、税金、領収書、高額支出の限度額を確認します。申請は、曖昧な「確認してください」という依頼がメールのやり取りを行き来するのではなく、決められたルートを進みます。

支出限度額と予算の所有権は、別の問いに答えるものです。限度額は、別の承認レベルが必要になるタイミングを示します。予算の所有権は、その経費をどの予算が負担するかを示します。部門マネージャーが、その部門のすべての予算を自動的に管理するとは限りません。チームを率いる人と、購入費用を負担するプロジェクトやコストセンターの資金を管理する人が別の場合もあります。

たとえば、従業員が顧客プロジェクト用に180ドルのソフトウェア契約を申請したとします。マネージャーは業務上の必要性を承認し、プロジェクトの予算責任者はそのプロジェクトへの計上を承認できます。契約が通常のポリシーから外れている場合だけ、経理部門が確認することもできます。金額が3,500ドルなら、経理部門のディレクターや購買担当者の承認も必要になるかもしれません。

申請画面を作る前に、これらの判断を決めておきましょう。そうしないと、フォームにはマネージャー名を入力させているのに、実際のワークフローではコストセンターとプロジェクトコードが必要になることがあります。後から例外を追加すると、手戻りと混乱が生まれます。

ルールは平易な言葉で書きます。各ルールには、次の内容を含めてください。

• 金額、経費の種類、コストセンターなど、承認を開始する条件
• 誰が申請を承認し、何を確認するか
• 2人目の承認が必要になるタイミング
• 通常の承認者が不在の場合の対応
• 例外を承認できる人

経理部門、マネージャー、従業員が同じようにルールを解釈できなければなりません。ポリシーに合意したら、AppMasterのようなノーコードプラットフォームで、ルールの全体像をフォーム、承認プロセス、通知に変えられます。ポリシー上の判断を画面設計の中に隠す必要はありません。

まず各申請に必要な情報を決める

承認者は、コメントで追加情報を尋ねなくても判断できるだけの背景情報を必要とします。経費承認ワークフローを作ったりフォームを設定したりする前に、経理部門で必須情報を決めておきましょう。

多くの承認者が知りたいのは、従業員が何にいくら使うのか、なぜ業務上必要なのか、どの予算が負担するのか、ポリシーに沿っているかです。マネージャーは業務上の理由を重視します。コストセンターの責任者は予算を確認します。経理部門は、カテゴリーごとの限度額、税務上の証拠、添付書類を確認します。

各申請には、基本情報を一貫した形式で記録します。

• 税込みかどうかを含む合計金額と通貨
• 旅行、ソフトウェア、顧客との食事、オフィス備品などの経費カテゴリー
• コストセンター、必要に応じてプロジェクトコードまたは顧客コード
• 申請者、部門、判断が必要な日付
• 業務上の目的、仕入先、見積書や領収書などの書類

必須項目は、実際の判断と結び付けます。月額25ドルのソフトウェア契約なら、仕入先、金額、コストセンター、業務上の目的だけで足りるかもしれません。4,000ドルのノートパソコン購入では、利用者、交換理由、資産申請番号も必要になることがあります。すべての申請に長いフォームを使うと、データの質が下がり、従業員の負担も増えます。

カテゴリーや金額に応じて必要な項目だけを表示します。出張申請なら目的地と出張日程が必要になることがあります。顧客との接待なら参加者名が必要かもしれません。一定額を超える申請には、複数の見積もりや、仕入先を選んだ理由を求めることもあります。条件付きの質問にすると、なぜ追加情報を求められているのかがわかり、フォームに答えやすくなります。

情報を入力する人も決めておきます。申請者は、目的や仕入先など、自分が知っている事実を入力します。フォームは従業員プロフィールから部門とマネージャーを自動入力できます。経理部門は、申請後にポリシーへの適合状況や会計コードを追加できます。従業員が確認できない項目を推測して入力する必要がなくなります。

フォームを作る前に、最近の経費申請を3件使って項目をテストします。メールを開いたり追加の質問をしたりせずに承認者が判断できるなら、情報は十分です。足りなければ、プロセスが紙の上にあるうちに項目を追加するか、表現を明確にします。

承認限度額を混乱なく設定する

金額帯は、会社の実際の支出方法に合わせます。年間ソフトウェア契約を購入するチームと、主に走行距離、食事、少額の備品を精算する会社では、適した限度額が異なります。他社の限度額をそのまま使ってもうまくいかないことが多いでしょう。

覚えやすい少数の金額帯を使います。たとえば、部門マネージャーが500ドルまで承認し、経理マネージャーが501ドルから2,500ドルまで承認し、それを超える金額は部門長が承認する、といった設定です。金額帯が少ないほど、振り分けのミスも少なくなります。

各金額帯の横に計算方法を書きます。税抜金額を使う人と、最終請求額を使う人がいると、経理部門内で意見が分かれがちです。合計に消費税、チップ、為替手数料、継続課金を含めるかどうかを明記します。12か月契約の場合、最初の月額支払いで判断するのか、年間契約の総額で判断するのかも決めてください。

支出の種類も重要です。1,000ドルの顧客接待と1,000ドルのノートパソコンに、同じ確認が必要とは限りません。備品にはIT部門や購買部門の承認が必要かもしれませんが、通常の限度額内の出張なら、従業員のマネージャーだけで済むことがあります。

ポリシーを決めるときは、次のようなシンプルな表を使います。

2人の承認が必要な場合は、具体的に決めます。順番に承認するのか、同時に承認するのか、支払い前に両方の判断が必要なのかを定義してください。1,800ドルのソフトウェア申請なら、まずコストセンターのマネージャーに送り、その後で経理部門に送る方法があります。制限付きプロジェクト予算に3,000ドルを計上する申請なら、従業員のマネージャーがすでに承認していても、予算責任者と経理部門の承認が必要になるかもしれません。

限度額の変更は経理部門が管理します。フォーム内の限度額を誰でも編集できたり、口頭で例外を認めたりすると、ワークフローの説明と監査が難しくなります。現在の金額帯を1つのポリシー文書にまとめ、その内容に合わせてフォームを作ります。

コストセンターごとに責任者を決める

稼働中の各コストセンターには、名前が明確な予算責任者を1人置きます。その人がすべての購入を自分で承認する必要はありません。ただし、その予算への支出に誰が責任を持つのかを、従業員と経理部門が把握できなければなりません。「部門長に送る」というルールでは、1つの部門に複数のチームや予算がある場合に遅延が起きます。

申請のコストセンターを使って、最初の承認者を選びます。たとえば、営業コーディネーターが北米営業のコストセンターに450ドルのイベント費用を申請した場合、そのコストセンターの責任者に送り、その後で金額に応じたルールを適用します。コーディネーターが、どの営業責任者が予算を管理しているか推測する必要はありません。

所有権はシンプルに保ちます。

• 稼働中の各コストセンターに、主担当者を1人割り当てる。
• 複数の同等な責任者を登録するのではなく、バックアップ対応には代理ルールを使う。
• 共通費や全社費用には、別のルートを設定する。
• コードがない、または無効な申請は経理部門の確認に送る。

共通費には、明確なルートが必要です。複数の部門で使うソフトウェア、共用オフィス用品、社内イベントなどは、申請が特定の部門に自動で割り当てられると問題になります。経理部門が共通サービスの責任者に割り当てる、申請者に費用を分割させる、予算を選ぶ前に経理部門が確認する、といった方法があります。よくある共通支出の種類ごとに、1つの方法を選んでください。

フォームでは、存在しないコードを選べないようにします。従業員が閉鎖済みのプロジェクトや廃止されたチームコードを選んだ場合、申請を止め、現在のコストセンターを選ぶよう求めます。選択できない場合は、「コストセンターが未指定」といった理由を付けて経理部門に送ります。ポリシーで認められていれば、経理部門が修正のために差し戻すか、一時コードを割り当てます。

コストセンター名、コード、主担当者、ステータスを記載した短い責任者リストを管理します。予算の移管、組織変更、責任者の退職があったら更新します。AppMasterのアプリケーションでは、管理者がこのリストをデータテーブルで管理し、申請を自動的に振り分けられます。変更の管理は経理部門が行い、予算を管理していない人の受信箱に申請が滞留することもありません。

代理人と不在時のルールを決める

マネージャーが休暇中、出張中、または別の役割へ移っただけで承認が止まってはいけません。代理承認を使えば申請を進められます。ただし、誰がなぜ判断したのかを経理部門が確認できるよう、ルールに制限を設ける必要があります。

代理承認は、指名された承認者本人が設定するか、権限を持つ経理部門または人事部門の管理者だけが設定できるようにします。代理人の名前、開始日、終了日を記録します。期限のない代理設定は、古い権限が残る問題を引き起こします。

たとえば、計画的な休暇中、部門マネージャーが最長30日間、代理人を1人指定できるルールにします。不在がそれより長くなる場合は、経理部門が設定を確認して更新します。これにより、代理人が現在も適切な権限を持っているか確認するタイミングが明確になります。

承認履歴を明確に保つ

ワークフローには、元の承認者と代理で対応した人を並べて表示します。代理期間と承認時刻も記録します。後から経理部門や監査担当者が経費を確認するとき、マネージャー本人が承認したのではなく、代理人が許可を得て対応したことがわかります。

元の承認者名を代理人名に置き換えないでください。この近道を使うと、特に通常とは異なる支出で問題が起きたときに、争点を解決しにくくなります。

代理人自身のチームが提出した申請の扱いも明確にします。代理人がそのチームの通常の申請を承認できるようにする経理部門もありますが、代理人自身の経費は別のマネージャーが承認する必要があります。委任されたマネージャーの部下からの申請をすべて別ルートへ送る方法もあります。どちらを選ぶにせよ、ポリシーに明記してください。

代理承認のポリシーには、指定された期間中に指定された承認者の代わりとしてのみ行動すること、自分の経費を承認できないこと、通常の金額とコストセンターのルールに従うことを明記します。マネージャーが退職したり役割を変えたりした場合に備え、経理部門は代替承認者を設定します。

役割の変更には、短期的な不在とは別の対応が必要です。退職者の承認権限を速やかに取り消し、担当していたコストセンターを新しい責任者に割り当てます。恒久的な責任者がまだ決まっていない場合は、経理部門が終了日付きの一時的な代替担当者を指定できます。退職者の代理人に、申請をいつまでも送り続けてはいけません。

遅延を生む前に例外ルートを決める

どの経費承認ワークフローにも、通常のルールに当てはまらない申請のルートが必要です。画面を作る前に、該当するケースを定義します。そうしないと、従業員がメールを送り、マネージャーが非公式に判断し、なぜ申請が進んだのか誰も説明できなくなります。

よくある例外には、緊急出張、領収書不足、標準限度額を超える申請、誤ったコストセンターへの計上などがあります。曖昧な「特別ケース」ではなく、名前の付いた例外の種類として扱います。申請者は理由を選び、必要な詳細を添付します。

たとえば、会議日程が変わり、従業員が翌日の顧客訪問を予約する必要があるとします。申請には、旅程、緊急になった理由の簡単な説明、見込み総額を求めます。その後、通常の承認チェーンではなく、従業員のマネージャーと経理部門のレビュアーに送ります。

各例外に責任者を置く

例外ごとに、誰が承認でき、どの証拠が必要かを決めます。領収書がない場合は、署名済みの申告書とカード利用明細が必要になるかもしれません。緊急購入では、通常の購買ルートを使えなかった理由を説明するマネージャーのメモが必要になることがあります。

すべての例外承認について、最終判断、レビュアー名、日付、上書きの理由を記録します。経理部門が使える監査記録になり、繰り返し起きるポリシー上の問題も見つけやすくなります。

回答期限とエスカレーションを追加する

レビュアーが不在だったり通知を見落としたりすると、申請は滞留します。例外ごとに回答期限を設定します。期限を過ぎたら、ワークフローが代理人へ通知するか、指定されたバックアップレビュアーへエスカレーションします。

緊急出張なら、最初のレビュアーに1営業日の回答期限を設定できます。対応がなければ代理人へ送り、代理人も4営業時間以内に対応しなければ経理部門が判断します。最初のレビュアーを表示したままにして、遅延がどこで始まったのか確認できるようにします。

アプリケーションには、例外の種類、証拠、上書きの理由、エスカレーションのステータスを保存します。AppMasterなら、これらの項目をモデル化し、ビジュアルビジネスプロセスで申請を振り分けられます。従業員には正当な例外の明確な道筋を示し、経理部門には一貫した記録を残せます。

現実的な申請を一通り確認する

マーケティングコーディネーターが、年間1,200ドルのソフトウェア契約を申請するとします。フォームでは、仕入先、金額、業務上の目的、更新日、マーケティングのコストセンターを入力します。コーディネーターはベンダーの見積書を添付し、そのツールがキャンペーンのレポート作成に役立つと説明します。

ワークフローは通知を送る前に、金額とコストセンターを読み取ります。合意済みのルールでは、1,000ドルから2,500ドルの購入には、コストセンターの責任者と経理部門のレビュアーの承認が必要です。申請はまずマーケティング予算の責任者に送られます。

責任者には、申請内容、コストセンターの残り予算、購入理由が表示されます。承認、却下、質問を添えた差し戻しを選べます。承認すると、同じ記録が経理部門に送られます。経理部門は、契約がポリシーに合っているか、税務情報があるか、仕入先がすでに登録されているかを確認します。

両者が承認すると、システムは判断、承認者名、タイムスタンプを記録します。コーディネーターにはステータスが通知され、購入を進められます。経理部門が却下した場合、記録には「現在の契約が終了するまで、既存のレポートツールを使ってください」といった理由が残ります。

コストセンターの責任者が不在の場合

マーケティング責任者が休暇中なら、責任者が事前に代理設定を行い、その設定が休暇期間中有効な場合に限り、代理人が対応します。代理人には、マーケティング責任者の代わりに対応していることが通知されます。

代理人は同じ判断をできますが、記録には適用される権限の持ち主と、実際に対応した人の両方を表示します。代理人が承認した後も、経理部門は申請を確認します。代理人は自分の経費を承認したり、より高い承認限度額を回避したりできません。

申請に例外が必要な場合

仕入先が通常の確認完了前の支払いを求めている場合や、購入がポリシーの限度額を超える場合、コーディネーターは例外を申請できます。フォームには、短い例外説明と、仕入先の見積書に記載された締切日などの証拠を必須にします。

ワークフローはその後、例外を承認する権限を持つ人、通常は経理マネージャーに申請を送ります。その判断は通常の承認に取って代わるのではなく、通常の承認と並んで記録されます。たとえば、「例外を承認。イベント登録が金曜日に締め切られるため、通常の条件より前の支払いを許可」といった形です。

この例では、混乱が起きやすい金額限度額、責任者、不在時の一時的な対応、例外を確認できます。すべてのルートに責任者と記録された結果が決まってから、申請画面を作りましょう。

よくある承認ルールの間違いを避ける

多くの承認ワークフローは、予算の所有権ではなく組織図をそのまま使うために失敗します。役職名だけでは、状況を十分に示せません。1人のマネージャーが2つのコストセンターを管理していたり、一時的に予算を担当していたり、特定の支出カテゴリーだけを承認していたりすることがあります。「部門長」のような役職ではなく、人、コストセンター、カテゴリー、限度額に承認権限を結び付けます。

すべての申請を経理部門のディレクターに送るのも避けます。通常の購入まで滞留し、経理部門がボトルネックになります。経理部門はポリシーを設定し、通常とは異なるリスクを確認し、選ばれた例外を処理する役割を担います。コストセンターの責任者は合意された限度額内の通常支出を承認し、高額な支出や制限付きカテゴリーだけを次のレベルに送ります。

例外ルールをメールのやり取りに置かず、ワークフローに組み込みます。フライトのキャンセルで従業員が当日中にホテルを取る必要があるなら、理由を記録し、証拠を添付し、適切な承認者に送り、判断を記録するという明確なルートが必要です。

次の確認で、ほとんどの混乱を防げます。

• 役職だけでなく、予算上の責任に基づいて承認権限を割り当てる。
• 通常の申請には限度額を設定し、例外には別のルートを用意する。
• 不在時の対応と、各代理設定の期間を定義する。
• 経理部門のディレクターによる承認は、必要な金額、カテゴリー、例外に限定する。
• 申請者が最終承認者を自分で選べないようにする。

最後の点は、利益相反からプロセスを守ります。申請者は計上するコストセンターを選べても、承認者は承認済みのルールからワークフローが選ぶべきです。営業マネージャーが営業コストセンターに900ドルの顧客接待費を申請した場合、親しいマネージャーの一覧ではなく、その予算責任者に送られなければなりません。

ルールは、誰でも試して説明できる言葉で書きます。たとえば、「5,000ドルを超える申請には、コストセンターの責任者と経理部門の承認が必要。緊急時に予約した出張は事前承認を省略できるが、従業員は2営業日以内に領収書と書面の理由を提出する」といった書き方です。

フォームを作る前に簡単な確認を行う

不明確なルールをフォームで解決することはできません。提案する承認マップを短い文書にまとめ、経理部門、予算責任者、業務担当者が読みやすい形にします。

まず責任者から確認します。稼働中のすべてのコストセンターに、名前のある承認者と、不在時のバックアップルートが必要です。会社が役割の一覧を常に更新していないなら、「部門リーダー」のような表現は避けます。マーケティングのコストセンターに責任者がいない場合、申請を止めるのか、経理部門に送るのか、一時的な代理人に送るのかを決めます。

各限度額を最近の申請と照らし合わせます。先月または前四半期の申請を少数抽出し、金額、コストセンター、経費の種類ごとに確認します。もっともらしく見えるルールが、不要な承認を生んでいないかがわかります。多くのソフトウェア更新が500ドルの少し上に集中しているなら、経理部門は通常の支出の承認に時間を使いすぎ、珍しい支出の確認に手が回らなくなっているかもしれません。

次のような扱いにくいケースで、書いたルールをテストします。

• 通常の責任者が対応できる稼働中のコストセンターに計上する1,200ドルのホテル申請
• コストセンターの責任者が休暇中に提出された申請
• 通常の限度額を超える緊急修理で、より速い例外ルートが必要な申請
• 有効な経費なのにコストセンターがない申請、または責任者が現在設定されていないコストセンターへの申請

各ケースについて、申請を受け取る人、承認できる人、必要な証拠、誰も対応しなかった場合の処理を書きます。同じケースを2人が違うように解釈するなら、ルールをさらに詰める必要があります。

チームがフォームを設計する前に、経理部門と予算責任者に文書を承認してもらいます。確認対象は文言だけでなく、金額、ルートの順番、代理人の限度、例外を承認する権限です。承認済みの版をワークフローの作成物と一緒に保管し、後から変更するときの基準にします。

合意したルールからワークフローを作る

経理部門がルートマップに合意したら、各ルールをアプリケーションが保存して処理できるデータに変えます。申請には、金額、通貨、コストセンター、経費の種類、申請者、業務上の理由、領収書、日付などの項目が必要です。担当者には、「下書き」「提出済み」「マネージャーの承認待ち」「経理部門の確認待ち」「承認済み」「却下」「要修正」といった明確なステータスも必要です。

ポリシーと画面レイアウトは分けて管理します。限度額を500ドルから750ドルに変更したり、新しいコストセンター責任者を割り当てたりする場合、すべてのフォームを作り直すのではなく、ルールを変更すれば済むようにします。

申請画面より先にルートを作る

まず振り分けの条件を作ります。250ドル未満の申請はコストセンターのマネージャーに送り、250ドルから2,000ドルの申請はそのマネージャーと経理部門に送り、2,000ドルを超える申請には部門長も加える、といった設定です。顧客との接待は、金額にかかわらず領収書と経理部門の確認が必要になるかもしれません。

経理部門の担当者が、アプリケーションがなぜその承認者を選んだのか理解できるようにします。AppMasterでは、申請を保存し、必須項目を確認し、コストセンターの責任者を検索し、金額を判定し、適切な承認タスクを作成するビジュアルビジネスプロセスを作れます。ロールベースのアクセス権で、各承認者が見るべき申請だけに制限することもできます。

ロジックが安定してから申請画面を作ります。ルートの判断と経理部門の確認に必要な情報と、関連書類を集めます。質問を増やしすぎると入力に時間がかかり、回答も不統一になりやすくなります。

実際に提出される申請をテストする

公開前に、経理部門がアプリケーションで現実的なケースをテストします。

• 通常の運営コストセンターに計上する90ドルのソフトウェア契約
• マネージャーと経理部門の確認が必要な600ドルのホテル精算
• 追加承認が必要な3,500ドルの備品申請
• 通常の承認者が不在のときに提出された申請
• 領収書がなく、経理部門が修正のために差し戻す申請

各テストで、割り当てられた承認者、申請者に表示されるステータス、リマインダーのタイミング、監査記録を確認します。経理部門がルートを1、2文で説明できないなら、従業員が使い始める前にルールを簡単にします。

テストが終わったら、ワークフローを公開し、申請者が目にするステータスについて短いガイドを用意します。明確な経費承認ルールがあれば、誰かの受信箱に隠れた判断ではなく、予測できる手順として機能します。