在庫を考える2つの方法

最近、TallyPrime の Inventory 設計を研究する時間を取りました。

Tally は長い歴史を持つ会計ソフトであり、その在庫の扱い方には、伝統的な中小企業の非常に典型的な仕事の習慣が表れています。

よくある方式のひとつが Periodic Inventory（定期棚卸） です。

企業は商品や原材料を購入したときに Purchases を記録し、販売したときに Sales を記録します。在庫は、会計取引のたびにリアルタイムで Inventory Ledger に出入りするとは限りません。

同時に、Tally には独立した Inventory Module があり、Stock Item、数量、評価額を記録します。決算日には、実際の棚卸から Stock-in-Hand を計算し、古典的な会計公式によって売上原価を求めます。

COGS = Opening Stock + Purchases − Closing Stock

この設計は実に実用的です。

伝統的な中小企業の多くは、毎日正確なリアルタイムの在庫価値を知る必要がありません。いつも通りに購入と販売を記録し、月末、四半期末、あるいは年末に棚卸をして、その時点で初めて本当のコストと利益を確定する習慣があります。

これが Periodic Inventory の強みです。シンプルで、日常オペレーションへの要求が低い。

もうひとつの方式は Perpetual Inventory（継続記録法） です。

購入のたびに Inventory が増え、販売のたびに Inventory が減って COGS が認識されます。

つまりシステムはいつでも答えられます。

今、在庫はどれくらいあるか？価値はいくらか？すでに販売した商品の原価はいくらか？リアルタイムの粗利益はいくらか？

EC、小売、卸売、標準化された製造業にとって、この方式はますます重要になっています。注文、購買、在庫はすでにデジタル化されているので、システムがこれらの情報をリアルタイムに維持することは十分可能です。

だから SnapLedger の設計思想は、単純に Periodic か Perpetual かを選ぶのではなく、基盤に異なる Cost Flow を理解させることです。

現実の中小企業は、すべて同じモデルに当てはまるわけではないからです。

EC 企業が必要とするのは、次のような流れかもしれません。

Purchase → Inventory → Sale → COGS

ごく小さな商社がより慣れているのは、次のような流れかもしれません。

Purchases → Period-End Stock Count → Closing Inventory

そして顧客の注文に応じて生産する家具会社には、伝統的な意味での在庫がほとんど存在しないかもしれません。

顧客が先に注文し、その後で企業が木材や金物を購入し、人件費と外注費を投入し、完成してから納品します。

このような企業にとって、より自然な流れは実はこうです。

Customer Order → Project → Materials & Labour → WIP → Delivery → COGS

ここで最も重要な資産は、伝統的な Stock-in-Hand ではなく、Work in Progress（WIP、仕掛品） かもしれません。

だから SnapLedger では、ソフトウェアが先に企業の在庫管理のあり方を決めることはしたくありません。

基盤は Perpetual Inventory も Periodic Inventory もサポートでき、さらに Project Costing と WIP もサポートできます。

そして Snappy が本当に理解すべきなのは、次の問いです。

あなたは実際にどう商売をしているのか？

先に在庫を積んで、顧客が買うのを待ちますか？

それとも顧客が注文してから仕入れますか？

すべての SKU の在庫を常時把握する必要がありますか？

それとも、各顧客プロジェクトにこれまでどれだけコストが投入され、どれだけ稼げそうかの方が気になりますか？

従来の会計ソフトはしばしば "How should inventory be recorded?" から始まります。

私たちは別の問いから始めたい。

"How does your business actually work?"

そして会計処理に、実際の業務プロセスへ適応させるのです。

SnapLedger, your life easier.