産業機器メーカーで14日間の請求遅延を解消し、設計変更の請求を実現

課題

工場は近代的でしたが、バックオフィスはそうではありませんでした。機器は紙の移動票とともに現場を出荷され、その後、経理担当者が出荷実績を1件ずつ開き、運送会社のサイトで追跡番号を確認し、支払条件を確認して請求書を入力していました。これはトラックが出発してから平均12〜14営業日後のことでした。一方、請負業者は製造途中でダクト寸法やモーター仕様を変更し、設計部門は図面をメールとExcelで改訂していましたが、受注は更新されませんでした。その結果、会社は改訂後の部品を製作し、そのコストを自社で負担していました。

1. 14日間の請求遅延

   出荷済みの注文はすべて手作業の請求キューで待機していました。顧客が支払うべき請求書を受け取る前に、数百万ドル規模の売掛金が2週間滞留していました。

2. スプレッドシートによる設計管理の落とし穴

   設計変更依頼は商取引上のイベントです。スプレッドシート経由で処理されると、すべての商業ビルドで請求されない個別仕様対応となり、ときには生産ラインのミスにもつながりました。

実施内容

2週間のスプリント1回で、稼働するコードを2つ導入しました。ネイティブのSuiteScript 2.1 Suiteletが設計変更要求を担います。記録された変更が下流の製造チケットをロックし、原材料費に基づいて再価格設定を行い、プロジェクトマネージャーの電子承認を待ち、その後、受注明細と作業指示を1つのトランザクションで更新します。自動化されたペア取引エンジンが請求を担います。ShipStationの運送会社スキャンがNetSuiteへWebhookを発火し、Map/Reduceジョブが出荷実績、承認、条件を検証し、請求書を作成・計上して、パレットがまだ運送会社のドックにあるうちに、追跡リンクと船荷証券を添えてメール送信します。

この図はワークフロー設計の一つであり、統制ポイントと関連するエビデンスを含みます。

仕組みの概要

1. 元帳内で完結する設計変更依頼

   エンジニアがSuiteletで仕様変更を記録すると、生産チケットがロックされ、現在の材料費に基づいて価格が再計算され、プロジェクトマネージャーが差異を承認してから生産が再開されます。受注明細と作業指示はアトミックに更新されるため、出荷されるものと請求されるものが一致します。

2. イベントとしての請求

   運送会社のスキャンがトリガーです。Map/Reduceジョブが出荷実績の完了を検証し、条件（ネット30、出来高請求、カード）を確認して、ネイティブの請求書を作成し、追跡情報、船荷証券、仕様書を埋め込んだPDFを生成します。買掛金担当者は、トラックが構内を出る前にそれを受け取ります。

結果

この事例から得られる示唆

1. 請求は人手の作業ではなく、イベントであるべきです

   フォークリフトがパレットを積み込み、運送会社が船荷証券をスキャンした時点で、請求書に必要な事実はすべてソフトウェアに揃っています。その間に入る人手の事務作業は、純粋な摩擦です。

2. 設計変更をERPの外に置かない

   設計の改訂は契約上のイベントです。承認が受注伝票から切り離されていると、カスタム加工のたびにマージンが流出します。

3. 対になる取引が監査証跡になります

   受注伝票から作業指示、出荷、請求書までをプログラムで連結することで、すべての明細を外部監査人がスプレッドシートでの説明なしに追跡できます。

複合事例の振り返りです。クライアントは典型例として示しており、数値は仕組みを説明するための例示です。関連: 投資先企業全体での印刷・スキャン・計量の統合