インドの製造業ERP:BOM・製造オーダー・GSTを一つにまとめる
製造業向けの基幹システムがBOM・製造オーダー・GSTをひとつの元帳に統合し、仕入税額控除の確実な取得から監査対応までを整理する実践導入ガイドです。
インドで製造業を営む方なら、毎日の煩雑さををご存じのはずです。技術部門は部品表(BOM)をあるスプレッドシートで管理しています。現場は別の台帳で生産を追跡します。経理は材料消費、労務費、GSTを、もともと連携を想定していない3つのツールにまたがってつき合わせるのに四苦八苦しています。GSTの申告期限が来ると、誰かが残業して手作業で数字を縫い合わせます。
これは道具の問題ではありません。アーキテクチャの問題です。そして、目に見えない誤差、取り逃がした仕入税額控除、監査へのストレスでインドの製造業者が利益を失う最大の理由でもあります。BOM、製造オーダー、GSTを1つの元帳に載せる基幹システムが、根本から解決します。本稿では、モジュールが実際にどう動くかに基づき、3つが一緒に動くと何が変わるかを説明します。
問題:3つの真実が一致しない分断された体制
インドの中堅・中小製造業者の多くは、分断された体制で動いています。BOMは技術部門所有のスプレッドシートにあります。生産は現場のホワイトボードや会計ソフトで追跡します。GSTは月末に別の請求発行ツールで計算します。
そこで3つの失敗が繰り返され、しかも複利で効いてきます。
第一に、BOMが現実から乖離します。技術部門が原材料のグレードを変更しても、購買は古い仕様のまま発注し、経理は古い価格で完成品を原価計算します。多階層BOMでは、副次アセンブリの小さな変更が親製品すべてに静かに伝播します。誰も気づかないまま、マージンが崩れます。
第二に、製造オーダーが原価の会話に遅れて到着します。現場で金曜に製造オーダーを完了しても、材料消費が帳簿に届くのは翌水曜です。元帳に着く頃には期間が閉じており、差異は誰も説明できない謎になります。
第三に、GSTが物理的な出来事と結びつきません。鋼材の払出、鋳物の廃棄、完成品の販売は、それぞれ原因となった在庫移動から切り離された手作業の仕訳行になります。GSTの監査人が仕入税額控除の主張の根拠を求めたとき、答えは印刷物の山と、多くの祈りです。
個々の道具は動いています。それらを結ぶ接続が動いていません。製造業者にとって、真実はその接続の中にこそあります。
何が変わるか:BOM・製造オーダー・税対応の会計を一緒に
基幹システムとしての製造業ERPは、BOM、製造オーダー、税設定を1つの連動する元帳の一部にすることでこれを解決します。現場が承認済みBOMに対して原材料を消費すると、在庫移動と会計仕訳が同じ取引で起きます。GSTも同じ記録の上を流れ、正確な出力税・仕入税の勘定にマッピングされます。
各部品が実際のERPでどう動くか、実装に基づいて見ていきましょう。
レシピとしての部品表(BOM)
BOMは、1つの基準数量の完成品を一連の構成行から製造するためのレシピです。各BOMは、完成品、基準生産数量、単位、および順序付きの構成行リストを持ちます。各構成行は原材料製品、その単位、基準ロットあたりの消費数量を参照します。
すべての製造オーダーがBOMから材料消費を調達するため、これが重要です。技術部門が構成を更新すると、変更は版管理され、新しい製造オーダーはすべて自動的にそれを取り込みます。スプレッドシートの乖離は、真実が1つ(3つではなく)になることで消えます。
製造オーダーとしてのワークオーダー
製造オーダーは、原材料を完成品に変える生産指示です。各オーダーは、完成品、製造すべき需要数量、包装単位、計画開始日、原材料払出の元倉庫、完成品受入の先倉庫を持ちます。
オーダーは明確なライフサイクルを進みます。ドラフトとして始まり、確認によって材料を予約し、生産完了で完成します。完了ステップは実質的な作業をします。元倉庫から原材料を控除し、完成品の在庫ロットを作成または検証し、完成数量を先倉庫で受入れます。ヘッダーと明細のステータスが同時に更新されるため、帳簿とビンがすべての段階で一致します。
部分生産も正直に扱われます。生産が需要に満たない場合、システムは残数量を親にリンクされた子オーダーとして分割できます。ごまかした数字ではなく整理されたバックオーダーが得られ、不足数量は明示的に記録されます。
GSTの基盤としての税設定
GST対応は税設定の中にあり、ここで正直さが重要です。税エンジンは汎用の設定可能な税率システムであり、製造業専用のGSTモジュールではありません。各税設定は、ゼロから百までのパーセンテージで税率を定義し、出力GST用の負債勘定となる販売税勘定と、仕入GST用の資産勘定となる購買税勘定を持ちます。勘定のサブタイプは書き込み時に検証されるため、出力税が誤って資産勘定に落ちることはありません。
これが製造業者にとって意味するのは、GSTが月末に後付けされるのではなく、製品と取引のレベルで付与されるということです。完成品を販売すると、出力GSTが正しい負債勘定に計上されます。原材料を購入すると、仕入GSTが正しい資産勘定に計上され、仕入税額控除の消し込み待ちになります。BOMと製造オーダーは在庫の作業を、税設定は会計の作業を、互いを参照する記録の上で行います。
これがアーキテクチャの転換です。3つの道具が1つの元帳になります。
実際のシナリオ
プネの中堅精密部品メーカーを考えます。従業員140名、二交代制で、自動車・産業向けに月産約18,000個の完成アセンブリを製造しています。年商は約4億8,000万円です。
統合ERPの前、技術部門は共有スプレッドシートで200行の多階層BOMを管理していました。現場はホワイトボードで生産を動かしていました。経理はGSTに別の請求ツールを使っていました。毎月、3つの失敗が繰り返されました。
ベアリングの納入業者が代わった際、副次アセンブリのBOMが変更されました。購買は3週間、古い部品を発注し続けました。原価チームは2か月間、古いレートでアセンブリを評価しました。気づく前に、目に見えない誤差で約140万円を失いました。
生産の不足は黙って吸収されていました。2,000個のオーダーが1,860個で完了し、残りの140個は口頭のメモに消えました。消費された原材料に対する仕入税額控除は、消費の出来事とGSTの記録が別のシステムにあったため、宣言された出力ときれいに消し合いませんでした。
1つの基幹システムに移行した後、BOMが唯一のレシピになりました。すべての製造オーダーがそれを参照します。原材料消費は、元倉庫と元帳に1つの取引で計上されます。販売時の出力GSTと購買時の仕入GSTは、それぞれ税設定によってマッピングされた専用の勘定に着地します。以前は3日かかっていた月次GSTの消し込みは数時間になり、すべての原価数値の背後にある監査証跡は1クリックです。
インドのなぜ製造業にとって重要なのか
インドは製造業に重い圧力を積み上げます。GST対応、中小企業優遇、Make in Indiaの調達期待、そして厳しさを増す監査環境は、すべて整理された連動する記録を求めます。分断された体制は4つすべてに失敗します。
GSTはすべての取引を税率と1対の勘定(出力用と仕入用)に結びつけることを求めます。統合された基幹システムは、税設定が在庫移動と同じ記録の一部であるため、これを既定で実現します。仕入税額控除の消し込みは捜査作業ではなく、レポートになります。
中小企業優遇とMake in Indiaはどちらも、国内付加価値と整理された原価証跡を証明できる製造業者に報います。BOM、製造オーダー、税設定が一緒に存在すると、何が完成品に入り、いくらかかり、いくつのGSTが支払われ徴収されたかを、断片から再構築することなく示せます。
監査人が最後の試練です。GSTの査察官が控除の根拠を求めた瞬間、分断された体制は崩れます。統合された基幹システムは、製造オーダー、それが消費したBOM、それが作成した在庫ロット、それが計上した税勘定を、すべてリンクした状態で差し出します。
あなたのビジネスに合っているか
BOM、製造オーダー、GSTが統合された基幹システムは、次のいずれかがあなたの週を描写する場合に適切な選択です。
月末に材料消費をGST申告と手作業でつき合わせている。BOMが1人の技術者しか完全に理解できないスプレッドシートにある。生産の不足が紙で追跡されているか、まったく追跡されていない。仕入税額控除の消し込みに1日以上かかる。原価証跡の監査依頼がチームを印刷物のパニックに陥れる。
これらの2つ以上が真なら、分断された体制はすでに移行コスト以上のものを失わせています。解決策は別の単独ツールではありません。レシピと現場と税務署を結ぶ、1つの元帳です。
よくある質問
GSTエンジンは製造業固有のGSTルールに対応していますか
税エンジンは汎用の設定可能な税システムであり、製造業専用のGSTモジュールではありません。ゼロから百までの任意の税率を定義し、出力GSTを負債勘定に、仕入GSTを資産勘定にマッピングし、それらの税率を製品と取引レベルで適用できます。ほとんどの製造業者にとって、これは原材料購入と完成品販売のGSTをきれいにカバーします。製造業固有の特別なGST取扱いは、専用モジュールとしてではなく、これらの設定を通じて構成する必要があります。
部分生産や不足を追跡できますか
はい。製造オーダーは需要数量と生産済数量を記録します。生産が不足した場合、システムは残数量を親にリンクされた子オーダーとして分割でき、不足数量は明示的に記録されます。ごまかした数字ではなく整理されたバックオーダーと、正直な数値が得られます。
税率やBOMを開発者なしで変更できますか
はい。税設定も部品表も設定可能なマスターデータです。税率の追加、勘定の再指定、構成行の更新、基準数量の変更はすべて設定変更で行えます。BOMは版管理されるため、変更は新しい製造オーダーに自動的に反映されつつ、古いレシピで製造された履歴も保持されます。
💡 ポイント:BOM、製造オーダー、GSTを別々のツールに置く分断された体制こそ、製造業者がマージンを失い、仕入控除を逃し、監査リスクを招く場所です。レシピと現場と税務署を1つの元帳に載せる基幹システムは、症状ではなく土台を直します。
手作業の消し込みをやめましょう
Kikan System は、BOM、製造オーダー、税対応の会計を1つの元帳に統合し、材料が動いた瞬間にGSTが正しい勘定に計上されるようにします。最大2ユーザー、クレジットカード不要の無料プランで、/#get-started から始めましょう。
関連記事:
関連記事
インド製造業向けBOM管理の実践ガイド:基幹システムで実現する原価と税務の一本化
インドの製造業向けBOM管理ガイド。中小企業のクラウドERP基幹システムで、部品表の原価・消費税・在庫・監査を一元化する実践手法を詳しく解説します。
続きを読む→インド新工場をクラウドERP基幹システムで立ち上げた事例:GST対応の全工程
インドの新工場立ち上げに必要なERP。GST会計、BOM、製造オーダーを備えたクラウドERP基幹システムが数週間で実現する成果と導入事例を解説。
続きを読む→基幹システムで実現する自動車部品製造とGST:BOM・製造指図・税連動の一本化
BOM・製造指図・ロットを税エンジンに直結する基幹システムが、自動車部品製造のトレーサビリティとGST連動の課題を解消する仕組みを解説します。
続きを読む→