第六回でルートは完成しました。支払いには一度だけ承認するスケジュールができ、仕入先の口座情報の変更には二段階の手順と記録ができ、各仕入先の残高明細にはすべての差異を説明する月次の照合ができました。これで、仕入先に支払うすべてのリヤルに、終点から起点までたどれる完全な記録が残ります。承認済みの依頼、発注書、記録に残る受領、照合済みの請求書、そして予定された支払いです。

答えが出ないままの問い：いくら使っているのか？

残る問いが一つあります。オーナーや財務責任者が尋ね、ほとんどの会社ではすぐに答えが返ってこない問いです。私たちはいくら、何に、誰に使っていて、まだ届いていないものにいくら約束しているのか？この最終回では、構築したチェーンを一つの支出ビューに変える方法と、シリーズのすべての要素を、購買を一日たりとも止めない順序で導入する九十日計画を扱います。

支出の可視化：毎月のプロジェクトではなく、リアルタイムのビュー

ほとんどの会社では、何にいくら使っているかを知ることは繰り返されるプロジェクトです。オーナーが購買の全体像を求めると、経理担当者はメールから請求書を、銀行明細から支払いを、購買担当者が管理するファイルから発注書を集め、何日もかけて仕入先名を統一し、請求書を手作業で分類します。表計算ソフトはこの作業に適した道具ですが、レポートが届くのはその月が終わった後で、翌月にはまた同じ作業が始まります。

すべての購買が私たちの構築したステーションを通ると、各書類は生まれた時点からレポートに必要なデータを持っています。前後のすべてと結びつける依頼番号、仕入先の一意の識別子、費用が属するプロジェクト・拠点・物件、そして購買カテゴリです。分類は請求書の後ではなく依頼の時点で行われているため、月末に誰かが何かを集める必要はありません。こうして支出の可視化は誰かが作るレポートではなく、開けば今時点のデータが見えるビューになり、四つの軸で切り替えられます。

  • 仕入先別：各仕入先からいくら購入したか、未完了の発注でその仕入先との間にまだいくら残っているか、そしてその請求書のうち何件が差異のために保留になったか、その理由は何か。
  • カテゴリ別：建設資材、交換部品、原材料、保守サービス、消耗品など、自社に合った区分です。重要なのは、カテゴリがオーナーの承認した短いリストで、依頼者がそこから選ぶ形になっていることです。社員がそれぞれ自由に書くテキストではありません。
  • プロジェクト・拠点・物件別：各建設プロジェクト、生産ライン、住宅タワー、ホテルに計上された金額です。これは第二回で購買依頼の必須条件にした項目です。
  • 段階別：何を約束したか、何が請求されたか、何が支払われたか。この軸が最も重要なので、次に取り上げます。

新たな約束の前に確認する三つの数字

ほとんどの購買レポートは請求書から始まります。経理に届く書類だからです。しかし請求書は遅れてやってきます。お金が約束されたのは請求書が届いた日ではなく、発注書を出した日です。そのためオーナーには、プロジェクト・拠点・物件ごと、そして仕入先ごとに、三つの数字を並べて見る必要があります。

  • 発注済み：まだ請求されていない未完了の発注書の残高。発注したが納品されていない資材、納品済みでまだ請求されていない資材、あるいは出来高請求がまだ届いていない下請業者に発注した工事です。
  • 請求済み：受け取って照合済みだがまだ支払っていない請求書。それぞれ、仕入先レコードの支払条件から計算した支払期日が付いています。
  • 支払済み：予定された支払処理で、あるいは記録された緊急支払いとして、実際に出ていった金額です。

この三つを比べることが、オーナーが次の約束に署名する前に必要な数字です。原価管理と出来高請求では各プロジェクトの実際原価を数量明細書の見積額と比較し、第三回では未完了の発注という層を加えました。ここで全体像が完成します。請求書だけを見れば予算に余裕があるように見えるプロジェクトが、未完了の発注で予算のほぼ全額をすでに約束しているかもしれません。請求済みの金額とその支払期日は、今後数週間でどれだけの現金が出ていくかを財務責任者に示し、発注済みの金額はその後に何が来るかを示します。

発注済みの数字を正直に保つには、一つの規律が必要です。第三回で述べたように、残りを誰ももう待っていない発注は、理由を書面に残して締めます。忘れられた未完了の残高は画面上の約束額を膨らませ、オーナーはそのお金がすでに使い道が決まっていると思い込んで、妥当な判断を先送りしてしまいます。

ビューが一分で答える問い

ほとんどの会社では、これらの問いに表計算ソフトから答えることはできますが、何日もかけて集めた後で、しかも答えを必要としていた判断がすでに過ぎてしまってからのことが多いのです。購買がチェーンを通っていれば、ビューは一分で答えます。

  • 重複した名称を統合すると、本当の最大の仕入先は誰か？第三回で、すべての仕入先レコードを統一国家番号に紐づけ、重複を統合しました。そうして初めて本当の順位が見えてきます。支出が三つの名称に分かれていた仕入先が、実は取引先の中で最大かもしれません。これは交渉の場で重要であり、その仕入先がつまずけば複数の拠点が止まりかねないと気づいたとき、さらに重要になります。
  • 約束済みでまだ請求されていない金額はいくらか？プロジェクト・拠点・物件ごと、仕入先ごとに。どの発注が出たのかを購買担当者に電話で尋ねる必要はありません。
  • 発注書を通さずに購入されているカテゴリはどれか？発注書なしで届いた請求書は、そのカテゴリと部門とともに請求書受付窓口に表示されます。あるカテゴリでそれが繰り返される場合、たいていは誰かがプロセスを回避したということではありません。プロセスがそのカテゴリに合っていないということです。毎週購入する消耗品には、毎回見積もりを一巡させるのではなく、価格協定を結び、その下で発注を順次出す形が必要です。
  • 緊急購買が最も多いのはどこか？各拠点や部門で緊急ルートを通った依頼の割合です。第二回で述べたように、これは誰かの落ち度ではなく、計画や遅い承認を示しています。
  • どの仕入先の請求書が最も頻繁に保留になり、その理由は何か？第四回の三者照合で止まった数量と価格の差異を、仕入先と理由ごとにまとめたものです。差異が繰り返される仕入先とは話し合いが必要です。一つの拠点ですべての仕入先に同じ差異が繰り返されるなら、その拠点の受領を見直す必要があります。
  • 同じ品目の価格はどう推移しているか？同じ品目について、同じ仕入先や他の仕入先からの連続した発注書の単価です。これは品目に一つのコードがある場合にのみ可能で、仕入先に適用したのと同じルールです。

AIの出番はどこか

チェーンが整えば、AIには購買で本当の仕事があります。写真やスキャン画像で届く仕入先請求書を読み取って打ち直す代わりにデータに変えること、その品目としては異常な単価や、似た仕入先名ですでに登録された請求書に似た請求書を検知すること、そして調達と在庫管理におけるAIで取り上げた需要予測です。

しかしその成果はチェーンの後に来るもので、前ではありません。異常な価格を検知するには比較の基準となる通常の価格が必要で、それは一つの品目コードで記録された発注書を意味します。重複した請求書を見つけるには、各仕入先にレコードが一つだけである必要があります。三つの名称を持つ一つの仕入先と発注書のない請求書の上で動くAIは、ノイズの多いデータ同士を比べているにすぎません。そしてアラートはあくまでアラートです。案件を担当者に上げ、判断は人が下します。

Origamiの視点

私たちが企業の購買サイクルを構築するとき、支出の可視化は最初ではなく最後に構築します。ビューはその前のステーションが生み出すものを読み取ります。レコードが整う前に作ったダッシュボードは、きれいで間違った数字を示すため、オーナーは信頼を失い、また手作業のレポートを求めるようになります。だからこそ私たちは仕入先台帳、購買カテゴリ、依頼のプロジェクト項目から始め、各ステーションを前のステーションの上に積み上げていきます。

私たちは、会社が実際にどのように購買しているかを中心にサイクル全体を構築します。誰が現場から依頼し、誰がスマートフォンで承認し、仕入先の請求書がどのように届くのか。会社がすでに使っている会計システムや電子インボイスに置き換えるのではなく接続します。これは私たちのサービスで紹介している、私たちが構築するカスタムシステムの一部です。

購買を決して止めない順序で進める九十日計画

よくある失敗は、サイクル全体を一日で稼働させようとすることです。日々の購買を守る順序は、何から移行するかで示した順序です。まずマスターデータ、次に取引。さらに各段階は、全社に展開する前に一つの拠点や部門から始められます。

  • 一か月目：仕入先台帳、承認マトリクス、購買依頼。仕入先台帳を整理して統一国家番号に紐づけ、重複レコードを統合し、各仕入先には第三回で述べた二つの公的確認を経たVAT番号、支払条件、そして公式書簡に基づくIBANを登録します。オーナーは承認マトリクスの上限、購買カテゴリのリスト、緊急ルートの条件を定めます。その後、購買依頼をスマートフォンから始め、承認は依頼そのものの上で行います。この月は発注、受領、支払いをこれまでどおり行うので、何も止まりません。
  • 二か月目：発注書と記録に残る受領。発注書は納品前に承認済みの依頼から発行し、受領は門や現場で発注書の明細行に対して記録し、下請業者やサービスについては完了記録を承認します。この月で最も重要なのは、システム導入前に発行した未完了の発注を期首残高として登録することです。そうしないと、発注済みの数字は初日から少なく始まってしまいます。
  • 三か月目：請求書受付窓口、照合、支払処理、残高確認、そして支出ダッシュボード。仕入先請求書の宛先を一つに定め、すべての請求書に三者照合を行い、予定された支払処理を始め、最大の仕入先から順に残高明細を照合します。月末、各ステーションがデータを生み出すようになったところで、支出ビューを有効にします。

各段階には、オーナーが定めて告知する旧ルートの終了日があります。ある日付以降は承認済みの依頼からでなければ発注を出さず、別の日付以降は記録された緊急ルートを通るものを除き、照合が済むまで請求書を支払いません。告知された日付がなければ、二つのルートが並行して続き、楽な方が勝ちます。毎月末には、システム自体から読み取れる三つの指標を確認してください。システムを通った依頼の件数、発注書付きで届いた請求書の件数、そして保留になった請求書の件数とその理由です。これらの数字の月ごとの推移は、最初に設定したどんな目標よりも正直です。

システム導入前に存在していたもの、つまりファイル、メール、紙の書類は、移行後も一切削除しません。VAT施行規則第66(1)条は、課税事業者に対し、保存義務のある請求書、記録、会計書類を、それらが関係する課税期間の終了から少なくとも六年間保存することを求めており、資本資産に関する記録については同じ項でより長い期間が定められています。したがって、旧アーカイブは保存され、いつでも参照できる状態に保たれ、新しいシステムは期首残高から始まります。自社の状況に固有の事項については、会計士や税理士に相談してください。

シリーズを終えるにあたって

七回にわたり、購買サイクルをステーションごとにたどってきました。七つのステーションとそのよくある断絶点を整理し、次に購買依頼と承認マトリクス、次に確認済みの仕入先レコードと拘束力のある発注書、次に記録に残る受領と三者照合、次に仕入先請求書のVATを控除する前に確認すべきこと、次に予定された支払いと残高照合、そして最後に支出の可視化とすべてを導入するための計画です。

心に留めておきたいのは、購買のデジタル化は購買に携わる人を疑うことではない、という点です。それは、仕入先に支払うすべてのリヤルに、依頼した人、承認した人、受領した人、支払った人を守る書面のルートがあり、オーナーが支払った後ではなく、約束する前に判断できる全体像を手にすることを意味します。始まりは今週踏み出せる小さな一歩です。今この時点で未完了の発注書のリストを求め、そのうち何件を誰かが本当にまだ待っているのかを尋ねてみてください。

出典