請求書の到着を待たない、ベンダー請求書トラッキング

なぜ請求書トラッカーは実態と乖離してしまうのか

仕入先請求書トラッカーは、作成した当日は機能しますが、誰も更新しなくなった週から機能しなくなります。

スプレッドシートには、昨夜サプライヤーが新しい請求書を発行したことや、支払期限が変更されたこと、あるいは3月に入力した請求書が6月に別の番号で再送されてきたことを知る術がありません。こうした事実はすべて、誰かがわざわざ確認し、シートに手入力しなければ反映されません。この問題に関する検索結果で「シートの作り方」を教える動画が上位を占め、同じ人が半年後にまた同じ質問をするのは、まさにこのためです。

追跡そのものは難しいことではありません。難しいのは、常に最新の状態を保つことなのです。

‍

請求書の取得、支払期限による並べ替え、重複の特定

Saiは、会計システムの連携がカバーしきれない部分を補完します。請求書を発行するサプライヤーのポータルサイトにログインして前回の実行以降に発行された請求書をダウンロードし、同時にメールの受信トレイから請求書を抽出します。

そして、スプレッドシートには不可能な2つの処理を行います。1つ目は、実際の支払期限に基づいてすべてを整理し、次の給与支払日を基準に仕分けを行うことです。これにより、「金曜日までに支払うべきものは何か」という問いに、聞かれる前に答えることができます。2つ目は、新しい請求書を過去のすべてのデータと照合することです。その際、請求書番号ではなく、仕入先、金額、期間を基準にします。同じ請求書が二重に届く場合、最も変更されやすいのが請求書番号だからです。Saiはどちらが正しいかを判断するのではなく、2つの記録を並べて表示し、異なる項目を指摘します。

同じ問題は、経費精算の現場でも発生しています。 は簡単ですが、領収書が不足していることが問題なのです。

‍

ログインが必要な請求書の追跡

障害となるのは、計算そのものではありません。請求書が、自動化を想定していない場所に散在していることです。独自のログインが必要なサプライヤーの請求ポータル、取引先から指定された支払いポータル、3週間前のメールスレッドに添付されたPDFなど、これらはAPIを公開しておらず、今後も公開されることはないでしょう。

Saiは、人間と同じように、実際のブラウザ上で、ログイン済みのセッションを通じて請求書にアクセスします。すでにシステム内にある請求書を報告するツールと、システム外にある請求書を自ら取得しに行くツール。この違いこそが、Saiの真価です。

‍

Saiが買掛金管理において行わないこと

Saiは、請求書の承認、支払いのスケジュール設定、資金の移動は行いません。Saiが行うのは、読み取り、収集、そして発見した内容の報告です。読み取れなかったものも報告対象に含まれます。支払期日が記載されていない請求書は、支払い条件から逆算して勝手に日付を割り当てるのではなく、「期日不明」としてリストアップします。二段階認証を求められたポータルは、無理に突破しようとせず「ブロック中」として報告します。

買掛金管理において、誤った情報を「正しい」と判断して処理してしまうことは、誤った支払いという直接的な損失につながります。そのため、この領域では正確性が何よりも重要です。記録を最新の状態に保つ作業は繰り返されるべきですが、何を支払うべきかという判断は、自動化すべきではありません。