仕入先請求書承認キューの簡単な設定ガイド

請求書の承認状況が分かりにくくなる理由

請求書の承認は、仕入先がPDFをメールで送り、誰かが確認し、財務部門が支払うという単純な作業から始まることが多いものです。しかし、請求書が定期的に届いたり、複数人の承認が必要になったり、発注後に購入内容が変わったりすると、この流れはすぐに崩れます。

メールは支払い状況の管理には向いていません。あるレビュアーは送信者だけに返信し、別のレビュアーは過去のやり取りを含めずに請求書を転送するかもしれません。同じ添付ファイルが複数の受信トレイに残ることもあります。その結果、財務部門は請求書が確認中なのか、異議があるのか、承認済みなのか、すでに支払われたのかを確認するために、何度も質問することになります。

共有スプレッドシートを使えば見通しはよくなりますが、別の問題が生じます。セルが上書きされたり、行の更新が忘れられたり、「対応中」「保留」「要確認」といったラベルが人によって違う意味で使われたりします。スプレッドシートで請求書の一覧は作れても、なぜ高い金額が承認されたのか、次に誰が対応すべきなのかまで説明できることは少ないでしょう。

仕入先請求書承認キューでは、各請求書に一つのレコードと現在のステータスを持たせます。仕入先、請求書番号、金額、支払期日、発注情報、担当レビュアー、判断履歴を表示します。関係者全員が同じレコードを確認できるため、メッセージを読み返して経緯を組み立てる必要がありません。

キューでは、請求書と会社が購入しようとしていた内容も照合します。仕入先、発注書番号、品目またはサービス、数量、価格を比較できます。たとえば、オフィスがモニターを1台180ドルで20台注文したのに、仕入先の請求書に22台と記載されていたとします。この場合、支払いを承認する前に360ドルの差額を検出できます。

差異が正当な場合もあります。送料、分納、合意済みの価格変更などによって、元の購入内容と金額が一致しないことがあります。レビュアーが理由を記録し、補足メモを添付できる場所を用意しましょう。そうしないと、財務部門は説明のない例外として扱い、同じ調査を何度も繰り返すことになります。

担当者が不明確だと、遅延はさらに長くなります。チームリーダーは購買部門が発注を確認すると考え、購買部門は依頼者が納品を確認すると考え、財務部門は両者を待つかもしれません。仕入先から支払いについて問い合わせが来るまで、請求書が放置されることもあります。

担当レビュアーとバックアップ担当者を名前で割り当てれば、この問題を防げます。レビュアーは請求書を承認、却下、または追加確認に回します。明確な支払い承認プロセスには、最終判断をした人、判断日時、理由が記録されます。チームは支払いを遅らせずに済み、後から古いメールを探さなくても質問に答えられます。

キューに必要な情報を決める

仕入先請求書承認キューは、すべての請求書に同じ基本情報が入っていると効果を発揮します。判断の前に複数のファイルを開いたり、買掛金担当者へ不足情報を尋ねたりする必要がなくなります。

まず請求書レコードを作ります。各レコードに固有の社内IDを付け、仕入先名、請求書番号、請求日、合計金額、通貨、支払期日、元の請求書ファイルを登録します。仕入先請求書番号は専用の項目に保存しましょう。仕入先が違えば、同じ番号を使うことがあるためです。

請求書の情報の隣に購入情報を置きます。レビュアーには、発注書番号、品目またはサービスの説明、発注数量、受領数量、合意済み単価、発注書の合計額が必要です。サービスの場合は、受領数量の代わりに「作業確認済み」のような項目を使います。これなら、すべての請求書に入荷数量を無理に求めずに済みます。

実用的な請求書レコードには、次の情報を含めます。

• 仕入先、仕入先の連絡先、請求書番号、請求書ファイル
• 請求日、支払期日、金額、税金、通貨、支払条件
• 発注書番号、発注金額、受領金額、合意済み価格
• 現在のステータス、担当レビュアー、判断日、レビュアーのメモ
• 不一致の種類、不一致金額、関連書類

実際の支払い承認プロセスを表すステータスを使います。「新規」はまだ確認していない状態、「レビュー中」は担当者が決まっている状態です。「修正待ち」は仕入先または購入担当者の返答が必要な状態を示します。「承認済み」なら財務部門が支払いを予定でき、「却下」なら理由を記録して依頼を終了します。

「保留」のような曖昧なラベルは避けましょう。管理者の確認を待っているのか、入荷確認を待っているのか、価格の修正を待っているのかが分からないためです。具体的なステータスなら、上司がキューを絞り込み、次の対応をすぐに確認できます。

項目と同じように、権限も慎重に決めます。部門管理者は商品が届いたことを確認する必要があっても、銀行情報やすべての仕入先の価格を見る必要はないかもしれません。財務担当者には通常、支払金額、税務情報、支払い状況が必要です。購買担当者には発注書と価格の情報が必要です。各役割には、業務に必要なレコードと項目だけを見せます。

たとえば、倉庫のレビュアーが、50脚の注文に対して48脚しか届いていないことを確認するとします。キューには2脚の不足を表示し、請求書をレビュー中のままにして、購入担当者へ送ります。一つのレコードに遅延の理由が残るため、早すぎる支払いを防げます。

構築前に承認ルートを決める

項目、画面、自動化を作る前に、請求書がたどるルートを書き出します。ルートを決めておけば、共有受信トレイで誰もが「誰かが対応するだろう」と考え、請求書が放置される事態を防げます。

プロセスは、買掛金担当者が請求書を入力するか、ファイルをアップロードした時点で始まります。仕入先、請求書番号、日付、合計、部署、発注書番号、支払期日を記録します。項目を「受領済み」にして、すぐに担当者を割り当てます。

次に、請求書と購入情報を照合します。仕入先、購入した品目またはサービス、数量、価格、合計を比較します。一致していれば先へ進めます。発注書がない場合や合意額を超えている場合は、レビュアーに推測させず、不一致ステータスへ移します。

請求書の種類ごとにレビュアーを選ぶ

一つの承認ルートですべての請求書を処理する必要はありません。75ドルの事務用品と、25,000ドルのコンサルティング請求書では確認内容が異なります。請求書レコードにすでに登録されている情報を使って、割り当てルールを作成します。

たとえば、請求書承認ワークフローは次のように設定できます。

• マーケティング関連の請求書をマーケティング予算の責任者へ送る
• 設定した金額を超える請求書を部門管理者と財務担当者へ送る
• 機器の購入を、購入を依頼した従業員へ送る
• 発注書がない請求書を、その部門の責任者へ送る
• 継続的な仕入先請求書を、最初の承認済み請求書で条件を確認した後、財務部門へ送る

不在に備えてバックアップレビュアーを割り当てます。通常の請求書なら2営業日後など、適切な期間でリマインダーを設定します。キューには、誰が請求書を担当しているか、いつ受け取ったか、なぜその人に割り当てられたかを表示します。

支払い判断を明確に記録する

必要なレビュアーがすべて承認したら、請求書を「支払い準備完了」に移します。財務部門は支払い判断として、支払い承認、保留、却下のいずれかを記録します。同じレコードに判断日、判断者、短い理由を残します。

却下された請求書は、買掛金担当者や依頼者など、決められた担当者に具体的な理由を付けて戻します。「3行目の価格を確認」なら明確な作業になりますが、「要確認」だけでは不十分です。

このルートによって、請求書の不一致も追跡しやすくなります。不一致が解決するまで表示されるため、メールのやり取りに埋もれません。明文化したルートなら、通常の請求書には同じ手順を適用し、例外的な購入だけを適切な担当者へ振り分けられます。

キューを段階的に作る

まず、仕入先と請求書という2つの関連レコードを作ります。仕入先レコードには、仕入先名、連絡先、支払条件、税務情報を保存します。請求書レコードには、請求書番号、発行日、支払期日、金額、通貨、添付書類を保存します。

購入情報を別のスプレッドシートに置かず、請求書レコードに追加します。各請求書を発注書、1件以上の入荷記録、またはその両方に関連付けます。この関係により、レビュアーは支払いを承認する前に必要な数値を確認できます。

AppMasterでは、Data Designerでこれらのレコードを作り、リレーションで関連付けます。一つの仕入先に複数の請求書を関連付けられます。また、仕入先が複数の注文をまとめて請求する場合、一つの請求書に複数の明細行を登録できます。

レビュアーが使う項目を追加する

すべての請求書に明確なステータスを付け、選択肢をシンプルにします。

• 下書き、請求書を入力したがレビューに回していない状態
• レビュー待ち、担当レビュアーの対応が必要な状態
• 要確認、金額や購入情報が一致しない状態
• 承認済みまたは却下、レビュアーが判断を記録した後の状態
• 支払済み、財務部門が支払いを確認した後の状態

担当レビュアー、判断日、レビュアーのコメント、不一致の理由も追加します。レビュアーには「発注書と価格が異なる」「商品を受領していない」などの理由を選ばせ、曖昧なメモを防ぎます。必要に応じて、状況を補足する短いコメントも追加できます。

請求書の入力フォームには重複チェックを追加します。ユーザーが請求書番号を入力したら、同じ仕入先と請求書番号を持つ既存レコードを検索します。見つかった場合は保存を止め、既存の請求書を表示します。請求書番号は仕入先ごとに重複する可能性があるため、番号だけでなく仕入先との組み合わせを確認します。

作業用キューを作る

財務担当者とレビュアー向けにキュー画面を作ります。仕入先、請求書番号、金額、支払期日、ステータス、担当レビュアー、不一致フラグを表示します。未払いの請求書は支払期日の順に並べ、レビュー待ちの項目を下書きより上に置きます。

レビュアーには自分に割り当てられた請求書だけを表示し、財務担当者にはすべての未処理項目を表示するなど、フィルターを使います。期限超過の請求書を赤く表示すると便利ですが、却下済みのレコードも別のステータスフィルターから確認できるようにします。チームには完全な支払い履歴が必要です。

たとえば、金曜日が支払期日で価格に不一致がある請求書は、「要確認」と表示し、差異が解決するまで支払い承認に進めないようにします。キューには次の対応をする人と、請求書が止まっている理由が表示されます。

照合と不一致のルールを設定する

照合ルールによって、手動確認なしで先へ進められる請求書が決まります。最初はシンプルに、仕入先の請求書、発注書、入荷記録を比較します。受領数量を記録していない場合は、請求書と発注数量を比較し、例外を支払い前に購入担当者へ送ります。

3つのレコードがそろっている場合は、3点照合を使います。キューで、会社が注文したもの、届いたもの、仕入先が請求したものを確認します。たとえば、仕入先が20個を請求し、発注書にも20個とある一方で、倉庫には16個しか届いていないという問題を検出できます。

小さな差異には明確な許容範囲を設定します。1セントの丸め差で請求書を止める必要はありませんが、10％の価格上昇は確認すべきでしょう。キューを使い始める前に、財務部門と購買部門で限度を合意します。

すべての請求書で次の内容を確認します。

• 請求数量と受領数量または発注数量
• 単価と承認済み発注書の価格
• 売上税、VAT、その他の税金と想定税率
• 送料、取扱手数料、追加料金と購入条件
• 請求書の合計と計算上の合計

キューが差異を見つけたら、「エラー」のような曖昧なステータスは使いません。問題を説明する理由を記録します。「請求数量が受領数量を4個上回っている」なら、購入担当者が確認すべき内容が分かります。「税額が想定より18.40ドル高い」なら、買掛金担当者が調べる場所が明確です。

不一致ごとに、カテゴリー、短いメモ、担当者、期限を設定します。カテゴリーには、数量、価格、税金、送料、重複請求書、発注書なしなどを使えます。担当者は、購入担当者、受入担当者、仕入先の連絡先など、名前または役割で明確にします。期限を設定すれば、請求書が何週間もフラグ付きのまま残ることを防げます。

問題に応じて請求書を振り分けます。価格の不一致は購入を承認した担当者へ、納品記録の不足は受入担当者へ送ります。仕入先が誤った金額を請求した場合や、承認されていない手数料を追加した場合は、仕入先の連絡先に修正版を依頼します。

重大な不一致が解決するまで支払いを止めます。会社の方針で一部支払いが認められている場合は、金額、理由、判断をキューに記録したうえで承認できます。担当者が問題を解決したら、解決内容を添付して請求書を承認段階に戻します。

一般的な請求書の流れを確認する

施設管理の担当者が、成長中のチーム向けにオフィスチェアを20脚注文するとします。発注書の単価は180ドルで、商品の合計は3,600ドルです。発注書では購買マネージャーをレビュアーに指定し、支払条件を30日としています。

仕入先が請求書を送ると、買掛金担当者が仕入先請求書承認キューに追加します。仕入先名、請求書番号、日付、支払期日、発注書番号、金額、請求書のコピーを入力します。キューは一致する発注書を見つけ、内容を比較します。

仕入先、発注番号、チェアの数量20脚は一致しています。しかし、請求書の単価は190ドルで、商品の合計は3,800ドルです。200ドルの差額はチームが許容する価格差を超えているため、請求書承認ワークフローはステータスを「要確認」に変更します。

レビュアーが差異を解決する

キューは、注文した購買マネージャーに項目を割り当てます。マネージャーはメールのやり取りを探さず、元の発注書と請求書を並べて確認できます。

マネージャーが仕入先のメッセージを確認すると、元のチェアが在庫切れで、代替モデルになったことが分かりました。マネージャーは高い価格の代替モデルを承認していましたが、発注書は更新されていませんでした。そこで「1脚190ドルの代替チェアを承認。発注書を3,800ドルに更新」とコメントし、請求書を却下せず「修正を承認」を選びます。

コメントはレコードに残ります。買掛金担当者は金額が変わった明確な理由を確認でき、後の支出レビューにも利用できます。

レコードを支払いへ送る

チームのルールに応じて、キューは発注金額を3,800ドルに更新するか、修正対象としてマークします。マネージャーの名前、判断、コメント、判断時刻を記録します。これで数量と承認済み価格が一致した請求書になります。

次に、キューは支払いを予定する担当者へレコードを送ります。担当者には承認金額、支払期日、支払条件、マネージャーのメモが表示されます。合意した日に3,800ドルの支払いを予定し、ステータスを「支払い予定」に変更します。

各担当者には一つの明確な作業があります。施設管理担当者は請求書が進んだことを確認でき、マネージャーは例外を担当し、支払い担当者は未確認の請求書ではなく承認済みのレコードを使って処理できます。

支払いを遅らせる失敗

すべての請求書を同じように扱うと、仕入先請求書承認キューの処理が遅くなります。発注書と入荷記録に一致する通常の請求書を、5人の承認待ちにする必要はありません。金額、部署、仕入先、不一致の有無に応じて承認レベルを設定します。判断が必要な人だけに請求書を送ります。

たとえば、180ドルの事務用品請求書は、照合後に予算責任者へ直接送れます。発注書を1,200ドル超える請求書は、購入担当者と財務レビュアーへ送ります。通常の支払いを進めながら、例外には慎重な確認を行えます。

差異を見つけたとき、元の請求書の金額を修正後の金額で上書きしないでください。仕入先が提出した金額、発注書の金額、修正後の金額を別々の項目に保存します。財務部門には、何が届いたのか、何を想定していたのか、なぜ最終支払額が変わったのかを示す記録が必要です。

仕入先が2,300ドルの発注書に対して2,450ドルを請求した場合、キューには両方の金額を残します。追加の150ドルが承認済みの変更、送料、誤りのどれに当たるかをレビュアーが記録できます。元の金額を上書きすると、不一致の追跡が難しくなり、監査でも混乱を招きます。

却下や修正依頼にも、文章による理由が必要です。ステータスだけでは、次の担当者に十分な情報が伝わりません。「数量が入荷記録と一致しない」「追加サービス時間の管理者承認を添付してください」のような短いメモを必須にします。仕入先の連絡先、購入担当者、財務チームが推測せずに対応できます。

役立つルールには次のようなものがあります。

• 照合済みで少額の請求書は、短い承認ルートに送る
• 受付後は元の請求書情報をロックし、修正は別途記録する
• 却下または差し戻しの際に、理由とメモを必須にする
• 各レビュアーに期限を設定し、期限超過前にリマインダーを送る
• ユーザーの役割または部署に割り当てられた請求書だけにアクセスさせる

支払い承認と、購入の依頼は分けて管理します。購入依頼は、チームが支出を決める前に許可を求めるものです。支払い承認は、仕入先が合意したものを納品し、請求書が正しいことを確認するものです。この2つを一緒にすると、レビュアーが以前の購入依頼を承認した記憶だけを頼りに、支払いまで承認してしまうおそれがあります。

AppMasterでは、これらの段階を一つのノーコードアプリで管理しながら、購入依頼、発注書、請求書、レビュアーのメモ、支払い判断を別々のレコードとして保存できます。請求書を再確認する必要が生じても、財務部門は明確な履歴を確認できます。

利用開始前に簡単なチェックを行う

短いテストで、請求書が誤ったキューに入る問題を事前に見つけられます。空のサンプルではなく現実的な請求書を使い、承認や支払いを担当する人に画面を実際に試してもらいます。

請求書ごとに必要な情報を確認します。仕入先、支払期日、合計金額、請求書ファイルがないと送信できないフォームにします。これらの項目があれば、レビュアーは判断でき、財務部門も後から確認できます。

キュー画面も確認します。各行に仕入先、金額、支払期日、現在のステータス、担当レビュアー、次の対応を表示します。レビュアーは複数のレコードを開かなくても、承認、却下、修正依頼、他の担当者待ちのどれを選ぶべきか判断できる必要があります。

請求書承認ワークフローには、次の2つのテストケースを使います。

• 仕入先、発注内容、数量、価格がすべて一致する請求書を送信する。意図したレビュアーに届き、支払い承認へ進められることを確認する
• 価格に差がある請求書を送信する。キューが不一致を検出し、理由を記録し、適切な担当者が解決するまで支払いを止めることを確認する

両方のレコードをすべてのステータスで追跡します。レビュアーが不在のときに再割り当てできるか、担当者が変わっても支払期日が表示されるかを確認します。通知を送る場合は、実際のチームのアドレスでテストし、誰にどのメッセージが届くかを確認します。

監査履歴もテストします。一つの請求書を承認し、もう一つを却下または差し戻しにします。その後、仕入先または請求書番号で各レコードを検索します。最終的な支払い判断、判断者、判断日時、追加したコメントが表示される必要があります。この履歴があれば、支払いが変更または遅延した理由を仕入先から尋ねられても対応できます。

公開前に権限を一度確認します。依頼者は請求書を提出できても、自分の依頼を承認できないようにします。支払い担当者には承認済み請求書へのアクセスが必要ですが、他のユーザーには役割に必要なレコードだけを表示します。請求書が届いてから不明確なプロセスを直すより、公開前に問題を解決する方が簡単です。

AppMasterでキューを日常業務に取り入れる

小さく始めます。特別なケース、追加の部署、複数の支払いルールを加える前に、一つの請求書タイプを一つの承認ルートで処理します。たとえば、標準的な発注書付き請求書を、購入担当者、財務担当者、支払い承認者の順に進めます。

AppMasterなら、コードを書かずにこのアプリを作成できます。Data Designerで仕入先、発注書、請求書、請求書明細、レビュアー、不一致メモ、支払い判断のレコードを作成します。各請求書に「下書き」「レビュー待ち」「修正が必要」「承認済み」「却下」などの明確なステータスを付けます。

Business Process Editorで、各操作の後に何が起きるかを定義します。担当者が請求書を追加すると、関連する購入情報と仕入先、発注番号、数量、合計を比較できます。金額が設定した限度を超えて異なる場合は、通常の支払い承認ではなく、不一致レビューへ送ります。

実際の業務でテストする

購買部門から1人、財務部門から1人を選び、チームが実際に処理した請求書で最初のバージョンをテストしてもらいます。内容が一致する請求書、合計が間違っている請求書、対応する発注書がない請求書を含めます。身近な例を使うと、不足している情報をすぐに見つけられます。

テスト中、レビュアーはスプレッドシートを開いたりメールを送ったりせず、次の質問に答えられる必要があります。

• この請求書を裏付ける発注書はどれか
• 今、誰が承認する必要があるか
• なぜキューは不一致を検出したのか
• 各レビュアーはどの判断をしたか
• 財務部門は最終的な支払い判断を確認できるか

机で作業するスタッフ向けにWeb画面を作り、管理者が外出先で承認することが多ければモバイル画面も追加します。レビュアーは一つの画面で請求書の詳細、照合結果、コメント、添付ファイル、判断ボタンを確認できるようにします。任意項目を増やしすぎると通常の承認が遅くなるため、最初の画面は簡潔にします。

見つかった不足に合わせてキューを更新する

最初のリリースは完成品ではなく、実際に使えるたたき台として扱います。財務担当者が税コードを何度も確認しているなら、請求書レコードに追加します。購買担当者が価格変更の説明を必要としているなら、不一致理由とコメント項目を追加します。高額請求書に2回目の承認が必要なら、スタッフの記憶に頼らずルーティングを更新します。

AppMasterは要件が変わるとアプリを再生成できるため、手作業でアプリを作り直さずに、データモデル、承認ロジック、画面を修正できます。テストグループが安心して使えるようになったら、キューをAppMaster Cloudまたは自社のインフラにデプロイします。

すべての判断に担当レビュアー、タイムスタンプ、明確な理由が残っていると、仕入先請求書承認キューは信頼されます。まずその基盤を作り、日々の運用が定着してから請求書の種類と承認ルートを増やしていきましょう。