第五回では、あるロットが最終的にどこへ行ったのかを問いました。今日の問いは会計の問題のように聞こえますが、完全に業務の問題です。あなたが請求したものは、倉庫から出ていったものと同じでしょうか。多くの工場で答えはノーであり、その差がどれほどなのかを正確に知る人はいません。

その理由は、電子インボイスがほとんどの企業に業務の入り口ではなく、コンプライアンスの入り口から入ってきたことにあります。請求書製品を購入し、当局と接続し、要件に適合した書類を発行すれば完了。こうして工場には二つのシステムが並存することになります。何が売れたかを知るシステムと、何が出ていったかを知るシステムです。そして両者が同じ出来事を記述しているという保証はどこにもありません。

請求書は締めの書類ではなく、移動の結果である

多くの工場経営者の請求に対する考え方は、紙の台帳から受け継がれたものです。仕事が終わったら机に向かい、それを要約する書類を書く。このメンタルモデルこそが問題の根源です。連携したシステムでは、請求書は後から書かれる要約ではないからです。それは倉庫で起きた物理的な出来事の財務上の結果です。特定の品目が、特定の数量で、特定のロットから、特定の時刻に、特定の顧客へ払い出されたという出来事です。

請求書がその出来事の上に構築されると、データは二つのコピーではなく一つになります。請求書上の数量は出庫時にスキャンされた数量です。品目は第二回で整理したのと同じコードです。ロットは第五回で追跡したのと同じロットです。請求書を別システムに手入力すると、同じ情報を二度目に入力することになり、再入力のたびに二つの数字がずれる新たな機会が生まれます。

システムが分かれているときに現れる四つの失敗

販売と倉庫が切り離されていても、一度の大きな障害として表れるわけではありません。工場で働いたことのある人なら誰でも見覚えのある、四つの繰り返し起こるパターンとして表れます。

  • 出庫のない請求書：請求書は発行され売上も計上されたが、記録上は商品が一度も倉庫を出ていない。帳簿残高は高いままで、次の棚卸で誰も説明できない不足が見つかります。
  • 請求書のない出庫：口頭の指示や手書きの納品書で商品が物理的に出ていき、請求されないまま。損失は二重です。売上の裏付けなしに在庫が消え、記録されていない販売について納税義務が生じます。
  • 在庫に戻らない返品：顧客が数量を返品し、財務上は値引きや伝票で処理されたが、商品はシステムに戻らないまま棚に戻った。利用可能在庫は実際より少なく表示され、すでに持っているものを購入することになります。
  • 存在しない在庫への受注：営業はファイル上で利用可能と表示された数量を約束するが、実際に空いている在庫は別の受注に引き当て済みか、検査で保留中。約束は遅延に変わり、遅延は違約金か顧客の喪失に変わります。

四つのどれも人の問題ではありません。真実の情報源が二つあることの必然的な結果です。工場が同じものについて二つの数字を持てば、それらは食い違います。問題はいつ、どれだけ食い違うかだけです。

正しい流れ：受注、次に出庫、そして請求書

連携した流れは三つのステーションを通り、それぞれが次を繰り返すのではなく、次を生み出します。

  • 受注：顧客に約束した内容、つまり品目、数量、価格、納期を記録します。同時に在庫を引き当て、同じ単位が二重に販売されないようにします。
  • 出庫と納品：倉庫はバーコードの回で説明したとおりに数量をピッキングしてスキャンするため、出ていくのはロット番号付きの実際の数量です。依頼数量と利用可能数量の差は、請求書に届く前にここで表面化します。
  • 請求書：受注からではなく、出庫イベントから生成されます。この点は重要です。百個の受注に対して九十個を納品した場合、請求書は自動的に九十個で作成され、残りは受注上で未完了のまま残ります。いったん請求してから後で伝票で訂正する必要はありません。

その結果、月末の照合は調査から確認へと変わります。倉庫台帳と販売レポートを突き合わせるために誰かが座り込む必要はありません。両者はそもそも分かれていなかったのですから。

統合フェーズが実務上意味すること

サウジアラビアの電子インボイスは、ザカート・税・関税庁（ZATCA）によって二つのフェーズで導入されました。まず生成フェーズ、次に統合フェーズで、後者の実施は2023年1月1日に始まり、当局が発表する納税者グループに順次適用され、対象企業には事前に通知されます。技術的な詳細は当局自身の文書で公開されており、非公式な解釈に頼るのは誤りです。

工場経営者にとって重要なのは技術用語ではなく、一つの帰結です。あなたの請求書を発行するシステムは今や、書類を印刷してメールで送るのではなく、定められた形式と定められたセキュリティ管理のもとで当局のプラットフォームと通信することが求められます。実務上、それは次のことを意味します。

  • 手書き請求書の抜け道はない：統合システムの外で発行されたものは、コンプライアンスの問題であると同時に会計の問題にもなります。
  • 品目データはきれいでなければならない：品名、単位、数量、価格は保有しているとおりに送信されるため、コードの乱れは社内レポートではなく、規制対象の書類に現れるようになります。
  • 差異はもはや黙って修正できない：発行済みの請求書を修正することは、削除して打ち直すことではなく、独自の手順を持つ訂正書類を発行することです。

要件は更新され、グループは段階的に発表されるため、頼れる唯一の参照先は当局の公式ページと文書です。契約する前に、ベンダーが表明している適合性をその情報源で確認するのが賢明です。

返品と貸方票：あらゆる隙間が露わになる場所

返品はあらゆる連携にとっての正念場です。販売は一方向に動き、管理は容易です。返品は同時に三方向に動きます。商品がどこかへ戻り、金額が調整され、その調整を反映する規制対象の書類が発行されます。

本当に連携したシステムと呼べるようになる前に、あなたのシステムが答えなければならない問いは次のとおりです。

  • 数量が戻ってきたとき、それは自動的に利用可能在庫に戻るのか、それとも検査が終わるまで隔離ロケーションに置かれるのか。両者を混同すると、損傷品が販売可能在庫に戻ってしまいます。
  • 貸方票は元の請求書に直接紐づいているのか、それとも後で照合しにくい単独の書類として発行されるのか。
  • 返品された商品が特定のロットに属する場合、システムは戻りの過程でそのロット番号を保持するのか。それがなければ、前回構築したトレーサビリティは最初の返品で途切れます。
  • 再販できない返品はどうなるのか。その価額で廃棄として計上されるのか、それとも帳簿から静かに消え、残高を膨らませたままにするのか。

Origami の視点

製造業と倉庫の分野では、私たちは電子インボイスの案件を経理からではなく倉庫から始めます。請求の問題を解決してほしいと依頼してくる経営者の多くは、最初のセッションの後で、請求書そのものに問題があるのではないことに気づきます。請求書を生成するはずだった出庫取引が記録されていなかったか、遅れて記録されたか、別のコードで記録されていたのです。

そのため私たちは作業の順序をそれに合わせて組み立てます。まず品目定義とスキャンされた在庫移動、そしてその後に初めて、受注、請求書、返品の流れを、隣り合うシステムとしてではなく一本の連鎖としてその上に構築します。コンプライアンスについては一つの固定ルールを守っています。基準はザカート・税・関税庁（ZATCA）が公表するものであり、適合性はマーケティング上の主張ではなく、その公式情報源で確認します。

次回

残るピースは一つ、順序です。ここまで、精度のギャップ、スキャン、製造指図、発注点、ロットのトレーサビリティ、請求書との連携を取り上げてきました。すべてを一度にやろうとするのは、失敗への最短ルートです。第七回、すなわち最終回は九十日間のロードマップです。どこから始め、どの順序で進め、その後どの指標で業務を運営するのかを解説します。

出典