掛け売りは、最初の出荷の前に四つのステップで管理できます。顧客を追加するときに一度だけ二つの無料の公的情報源で確認する顧客マスター、オーナーが顧客ごとに設定する与信限度額と支払条件、受注と納品のたびに未回収残高・未請求額・延滞請求書と照らし合わせてシステムが行うチェック、そして電話ではなく、理由・氏名・時刻を伴う承認として記録される限度額超過です。そのうえで、オーナーは顧客ごとに適した担保を選びます。前受金、銀行保証、または Nafith プラットフォーム上の電子約束手形で、これは執行法第 9 条が執行名義に含める商業証券です。

見積もりから最初の掛け売り出荷まで

第二回では、価格の出どころが一つになり、見積もりは版が保存されるようになり、すべての値引きに誰もが知る承認者がつきました。そこでは、見積もりにはオーナーがその顧客に設定した支払条件が記載されるとも書きました。今回はその条件と、それを裏付けるものについてです。掛け売りとは、自社の資金で提供する融資です。今日商品を納めるか作業を終え、約束の日まで入金を待ちます。最初の出荷の前に問うべきは、この顧客を信頼するかどうかではありません。第一回で見たように、支払い遅延の多くは書類の不足や、請求書が間違った人に届いたことが原因だからです。問うべきは、この顧客に対していつの時点でもいくらまでなら未回収を許容できるか、どんな条件でか、そして支払いが遅れたときに何が自社を守るのか、です。

顧客マスター:一度だけ登録し、追加時に確認する

受注、請求書、入金はすべて、後で顧客にひも付きます。一つの顧客が三つの名前で登録されると、残高は三つのマスターに分散し、実際にいくら未払いなのか誰にもわからず、次の注文は限度額チェックを通過してしまいます。それぞれのマスター単体では限度額を下回っているからです。だから与信は顧客マスターから始まり、良いマスターには五つの基本項目があります。

  • 商業登記に記載された名称。プロジェクト名や、営業担当者がやり取りする購買担当者の名前ではありません。略称は検索用の項目として残してかまいませんが、契約書と請求書に載るのは正式名称です。
  • 事業者の統一国民番号。決して重複しない識別子です。システムは同じ番号の二つ目のマスターを拒否し、作成前に似た名前を検索するので、担当者の記憶に頼るのではなく、顧客がすでに存在することを本人に知らせます。
  • VAT 番号。顧客が VAT 登録している場合です。請求書そのものについては第五回で改めて扱います。
  • 登録上の住所。納品先やサービス提供先の現場・支店が複数ある場合は、それぞれの住所も加えます。
  • 請求書を受け取り承認する権限を持つ人:氏名、役職、連絡先、そして顧客の経理部門が請求書を受け付ける前に求めるもの、たとえば発注書番号や現場技術者の署名です。この一項目だけで、承認者ではなく営業担当者に請求書が送られることから始まる遅延の多くを防げます。

顧客をリストに加える前には、二つの無料の公的確認で十分です。見積もりから発注書へ:確認済みの仕入先、確定した価格で買い手の側から説明したものと同じ二つです。

  • ザカート・税務・関税庁(ZATCA)の VAT 登録確認。納税者と一般に公開されたサービスで、VAT 番号、商業登記番号、VAT 証明書番号で検索し、事業者の登録状況を確認できます。
  • 商務省の商業登記照会。事業者名または統一国民番号で検索できる、即時・無料のサービスです。

目的は顧客を疑うことではなく、商業登記上の名称、VAT 番号にひも付く名称、発注書や契約書上の名称が一致していることを確かめることです。一致しなければ、最初の延滞請求書の後ではなく、今、最初の出荷の前に質問します。

では、SIMAH による信用照会は?SIMAH は信用情報会社の一つで、サウジ中央銀行(SAMA)の規則集に掲載されている信用情報法施行規則は、消費者を信用取引のある自然人または法人と定義しているため、事業者も含まれます。しかし照会は、望めばどの会社でもできるわけではありません。規則上の会員とは、信用情報会社と信用情報交換契約を結んだ事業体であり、第 40(1) 条は会員に対し、照会の前に消費者の書面による同意を得ることを求めています。つまりこの方法には会員資格が必要で、照会のたびにその前に顧客の書面による同意が必要です。

与信限度額と支払条件:オーナーが決め、システムがチェックする

与信限度額とは、ある顧客に対していつの時点でも許容できる債権の上限額です。支払条件とは、各請求書の支払いまでの期間と、一部を前払いするかどうかです。どちらも、オーナーまたはオーナーが権限を委ねた人が顧客ごとに下す判断です。会社の資金繰り、その顧客との取引実績、注文の規模、手元の担保を反映するものだからです。どの会社にも合う限度額も、どの業界にも合う支払期間もありません。他社から借りてきた数字は、販売を止めてしまうか、何も守らないかのどちらかになりかねません。

限度額と条件は、営業担当者の記憶ではなく顧客マスターに記録し、誰がいつ承認したか、次回の見直し日も併せて残します。次に、記憶にはできない部分です。システムは口座開設時だけでなく、注文のたびに限度額をチェックします。チェックでは一つではなく三つの金額を合計します。

  • 未回収残高:発行済みで未払いの請求書。
  • 未請求額:承認済みで未納品の受注、顧客が受領署名したがまだ請求していない納品、そしてまだ出来高請求に含まれていない完了済みの作業。
  • 新しい注文そのもの。

合計が限度額を超えるか、顧客に支払期日を過ぎた請求書があれば、注文は決まった地点で止まり、営業担当者には理由が表示されます。どの請求書が延滞しているか、注文が限度額をいくら超えているかです。チェックは受注入力時だけでなく納品時にも再度行われます。受注は出荷の何週間も前に承認されることがあり、その間に以前の請求書が延滞になることがあるからです。チェックは業種ごとに形を変えます。

  • 工場または卸売業者。毎週繰り返し注文があるため、注文のたび、積込指示のたびにチェックし、限度額を超えた顧客にトラックが誰にも知られずに出ていくことはありません。
  • 保守会社、不動産運営会社、ホテル。月額契約や法人アカウントで、請求書の発行前にサービスが積み上がるため、全体像から抜け落ちがちなのは未請求の部分です。
  • 建設業者。ここでは限度額を注文単位ではなく契約単位で見ます。これについては後ほど触れます。

限度額の超過:電話ではなく、理由を添えて記録される承認

限度額を超えて納品しなければならない日は必ず来ます。繁忙期の大口顧客、資材が届かなければ止まる現場、あるいは顧客側ではなく自社側で納品書を紛失したために遅れている延滞請求書などです。ここでの管理とは、システムが常にノーと言うことではありません。例外を、責任者がはっきりした判断にすることです。営業担当者は自分の画面から理由を添えて例外を申請し、その申請は承認者のスマートフォンに、必要な数字とともに届きます。限度額、未回収残高、未請求額、延滞額とその期間、そして手元の担保です。承認は、承認者の氏名、時刻、適用範囲とともに記録されます。この注文だけか、決められた日までの追加額かです。

これは第二回の値引きマトリクスと同じ考え方です。オーナーが段階を決め、誰も自分の例外を承認せず、権限は人ではなく役職に属し、各承認者には不在時のための指名された代理人がいます。同じ顧客で例外が繰り返されるのは違反ではなくサインです。その顧客の限度額が取引規模に合わなくなっていて見直すべきか、次の注文の前に支払い遅延について話し合う必要があるかのどちらかです。いずれにせよ、オーナーはそれを月末の電話ではなくレポートで目にします。

担保:掛け売りの前にオーナーが選ぶもの

担保は与信限度額の代わりにはなりません。顧客が期日を守らなかったときに、どれだけのリスクを負うかを決めるものです。すべての顧客に担保が必要なわけではなく、すべての担保がすべての顧客に合うわけでもないため、これはオーナーが顧客ごと、または顧客グループごとに下す判断です。選択肢には次のものがあります。

  • 前受金。納品前または着工前に支払われる一部の金額で、支払い遅延にさらされる金額を減らします。誰も注文とひも付けられない銀行口座上の金額としてではなく、受注または契約に対する残高として記録し、合意どおり請求書で取り崩していきます。
  • 銀行保証。顧客の取引銀行が、あなたを受益者として、決まった金額と期間で発行するものです。金額、有効期限、対象となる契約とともに顧客マスターに記録し、システムは期限切れの一定期間前に警告します。その期間はオーナーが決めます。誰も気づかないうちに期限切れになった保証は保証ではないからです。文言と条件は、取引銀行と弁護士に相談すべき事項です。
  • Nafith プラットフォーム上の電子約束手形。事業者に最も知られていない選択肢なので、ここで説明します。

Nafith は約束手形を作成するための電子プラットフォームで、司法省の執行サービスガイドが承認済み電子プラットフォームの例として挙げており、サウジアラビアに登録された個人と事業者が利用できます。プラットフォームによれば、手形作成の申請は債権者、つまりあなたが行い、債務者はその後、国のシングルサインオンである Nafath を通じて受け取った確認コードで承認します。これが債務者による手形の作成とみなされます。手形は承認後に変更できません。債権者は取り消せますが、債務者は取り消せません。プラットフォームでは、一つの申請に支払期日の異なる複数の手形をひも付けることもでき、それぞれを個別に執行できるため、分割払いの合意に適しています。

なぜこれが重要なのでしょうか。執行法第 9 条は、強制執行は金額が確定し期限が到来した権利についての執行名義によってのみ可能と定め、第 4 号で商業証券を執行名義に含めているからです。約束手形は商業証券です。したがって、期日に支払われなかった手形は、事前の訴訟なしに直接執行手続きに進みます。司法省のガイドは、Nafith のような承認済みプラットフォームで発行された名義は Najiz の自動化ルート(バーチャル裁判所)で申し立てられると説明しています。申立人が手形番号を入力すると、その内容が自動的に読み込まれます。さらに、改正後の同法第 46 条は、債務者が執行命令の通知から 5 日以内に支払わず、または支払いに足る資産を開示しない場合、その債務者は不履行者とみなされ、執行裁判官は直ちに、出国禁止や認可を受けた信用情報会社への不払いの通知を含む措置を命じると定めています。

これは条文の内容であり、すべての顧客に手形を求めるよう勧めるものではありません。手形には固定の金額と決まった日付がある一方、未回収残高は毎週変わります。そのため、手形の金額、いつ求めるか、残高が手形を超えたらどうするかは、法的措置に進むかどうかと同様に、弁護士に相談すべき事項です。システムで重要なのは、すべての担保を顧客マスターに記録することです。種類、金額、支払期日または有効期限、何を対象とするか、原本またはプラットフォーム上の番号の保管場所です。そうすれば、限度額を承認する人は判断の前に手元の担保を確認できます。

建設業者:前払金と保留金を契約上の残高として管理する

建設業者の掛け売りは異なります。出荷して請求するのではなく、何週間も工事を行い、発注者側の技術者やコンサルタントが承認する出来高請求を提出し、それから支払いを待ちます。ほとんどの契約には、延滞請求書として表示されないために通常の回収管理から漏れてしまう二つの残高があります。

  • 前払金。建設業者が契約開始時にプロジェクトの発注者から受け取り、その後、契約の定めに従って出来高請求から差し引かれます。受け取った額、これまでに差し引かれた額、残りの額を契約上の残高として管理してください。そうしないと二重に差し引かれるか、まったく差し引かれず、その差額は最終精算時に紛争として表面化します。
  • 保留金。引き渡しや瑕疵担保期間の終了など、契約上の条件が満たされるまで、発注者が出来高請求ごとに留保する部分です。これはあなたのお金ですが、まだ支払期日は来ていません。解放条件と予定日を伴う独立した残高として管理しなければ、引き渡し後に忘れられるか、延滞ではないのに年齢調べ表で延滞として表示されます。

建設業者の場合、与信限度額は契約単位で見ます。完了したがまだ請求していない工事、提出したが未承認の出来高請求、承認されたが未払いの出来高請求、そしてまだ解放されていない保留金です。この四つの残高の合計が、建設業者がその日に実際に発注者のために立て替えている金額です。出来高請求の仕組みとコストをプロジェクトに配賦する方法は原価管理と出来高請求で扱いました。今回付け加えるのは、同じ発注者から追加工事や新しい契約を受ける前に、四つの残高をまとめて見ることです。

Origami の視点

ある会社の与信ワークフローを構築するとき、私たちは今その会社がどのように掛け売りをしているかから始めます。新規顧客の支払条件を誰が決めるのか、限度額があるならどこに記録されているのか、延滞請求書がある大口顧客から出荷を求められたとき誰が承認するのか、担保とその有効期限はどこに保管されているのか。電話で与えられた例外は、どこで管理を強めるべきかよりも先に、今の承認がどこで遅すぎるのかを教えてくれます。

次に、それをシステムが徹底するワークフローに変えます。決して重複しない識別子を持つ顧客マスター、オーナーがプログラマーなしで調整できる限度額と条件、受注と納品のたびに未回収残高と未請求額を合算するチェック、承認者のスマートフォンに届き記録される例外、期限切れ前に警告する担保台帳、そして各契約の前払金と保留金の残高。これらすべてが会計システムと電子請求書に連携します。これは私たちのサービスの一環として構築するカスタムシステムの一部です。

今週の課題:掛け売りの上位二十社を見直す

どんなシステムよりも先に、掛け売りと、存在すると思っている限度額との間で実際に何が起きているのかを把握する必要があります。財務マネージャーと営業マネージャーが一、二回の打ち合わせで実施できます。

  • 上位二十社の顧客を選びます。基準は今日時点の未回収残高です。
  • 各顧客の限度額と支払条件を書き出します。誰かの記憶ではなく、書面にあるとおりにです。書面で見つからなければ、そのことを記録します。
  • 実際の債権額を合計します:未回収の請求書、未請求の納品、承認済みで未納品の受注、建設業者なら保留金も含めます。そして合計を限度額と比べます。
  • マスターを確認します:名称は商業登記どおりか、マスターは一つか複数か、請求書を受け取る権限を持つ人はわかっているか。
  • 保有している担保を一覧にします。顧客ごとに、それぞれの有効期限と原本の保管場所も記します。

書面の限度額がない顧客の数と、誰も名前を挙げられる承認なしに実際の残高が限度額を超えている顧客の数が、今回の出発点です。次に、一枚の紙に書きます。新規顧客の限度額を誰が決めるか、いつ見直すか、超過を誰が承認するか、どの顧客グループにどの担保を求めるか。その一枚と、二十社で見つけた実態との差が、システムが埋めるべきものです。

次回

これで、どの顧客にも確認済みのマスターがあり、受注と納品のたびに検証される限度額があり、誰もが所在と期日を確認できる担保があります。次回は、販売が請求できるものに変わる瞬間、つまり納品の証明に移ります。請求書は受注からではなく、顧客が署名した納品書や先方の技術者が承認した出来高請求から始めるべき理由と、その証明を玄関先や現場でスマートフォンを使ってどのように記録するかを説明します。そうすれば、後の紛争にも一週間ではなく一分で答えられます。

出典