日本本社とインド子会社を1つのERPで：2026年の越境クロスボーダー戦略

大阪の経理チームは日本円で決算を締めます。プネ（インド）の工場チームはルピーで締めます。それぞれ独自の帳簿、独自の勘定科目、独自の税ロジックを持ち、毎月、誰かが深夜にスプレッドシートでつなぎ合わせています。これに心当たりがあるなら、あなたは越境オペレーションで最もコストの高いワークフローを生きています。良い知らせは、1つのERP、つまり1つの基幹システムで両方の会社を保持し、データを分離したまま、両方の言語を同時に扱えるということです。この記事は、2つのシステムの突合をやめて1つの基幹システムで運用したいグループCFOと情報システム責任者向けの実践ガイドです。

課題：2つのシステム、突合地獄、そしてデータサイロ

インドに拠点を持つ日本本社の多くは、最初から2つのシステムを計画したわけではありません。東京のオフィスは日本の消費税に合った会計ソフトを導入しました。数年後に設立されたインド子会社は、初日からGST対応とルピー建ての報告を必要としたため、インド市場向けに作られた別のツールを選びました。

当時は合理的に見えた選択が、今は経理機能への構造的な負担になっています。2つのシステムは決して一致しません。日本の売掛金はグループとしてある残高を示し、インドの買掛金は別の残高を示します。為替換算は、双方が異なる日に異なるレートを使うためズレます。親会社と子会社の生命線である会社間取引は、互いに見えない2つの場所に存在します。

結果は「突合地獄」です。月末決算は第2週にまで伸びます。グループ管理者は両システムから試算表をエクスポートし、共通の勘定科目にマッピングし、為替を換算し、会社間のすべての仕訳を手作業で確認します。勘定コードの入力ミス1つでやり直しです。監査人が来ると、プネの請求書から連結されたグループの貸借対照表までを1本のきれいな糸で示すことができません。

これは決して人の問題ではありません。あなたのチームは有能です。これはアーキテクチャの問題です。どれだけ深夜残業を重ねても、切離された2つのシステムから単一の信頼できる情報源は生まれません。越境グループには、両社をつなぐ1つの基幹システムが必要です。

何が変わるか：1つのシステム、分離された会社、バイリンガル、二重税設定

解決策は、既存のツールに統合プロジェクトを上書きすることではありません。解決策は、複数の会社を保持しながらデータを完全に分離できる1つのERPです。1つのシステム、複数の事業体と考えてください。システム内の各会社は独自の閉じた空間で動きます。大阪の本社とプネの工場は、台帳ではなくプラットフォームを共有します。グループCFOは連結された可視性を得て、各拠点の管理者はクリーンで邪魔されない帳簿を得ます。

これが重要な理由は、モダンなクラウドERPが実際どのように作られているか、3つの具体的な点に裏打ちされています。

第1に、データ分離は真の分離です。システム内の各会社は専用のデータストアに対応し、そのレコードは他のすべての会社から完全に分離されています。インドの事業体は日本の給与を見ることができません。日本本社が誤ってインドの税勘定に仕訳を計上することもありません。連結は得られますが、混線は起きません。これは1つのプラットフォームが無関係の複数企業を安全に支えるのと同じ分離パターンであり、グループ内の2つの事業体でも同じように機能します。

第2に、インターフェースは両方の言語を話します。バイリンガルERPとは、翻訳の後付けではありません。プラットフォームは英語をフォールバック言語として、完全な日本語ロケールを備えて出荷されるため、大阪の経理責任者は日本語で、プネの運用責任者は同じシステムで英語で働きます。レポート、項目ラベル、エクスポートは各ユーザーが期待する言語を尊重します。英語だけの画面をスクリーンショットして下に日本語の説明を打ち込んで転送する作業はもう不要です。

第3に、税は会社ごとに設定可能で、ハードコードされません。日本の消費税とインドのGSTは全く異なる制度であり、ERPはそのように扱わなければなりません。適切な税設定レイヤーでは、税名、0から100パーセントまでの税率、売上税と仕入税の別々の勘定を定義できます。売上税は負債勘定に計上され、仕入税は資産勘定に計上されます。システムは計上時にこれを検証するため、設定ミスのある税行は帳簿に届く前に拒否されます。大阪は日本の税率で消費税を設定します。プネは適用されるインドの税率でGSTを設定します。同じ画面、同じ構造、2つの正しい結果です。

実際のシナリオ：大阪本社とプネの工場

中堅の日本の製造業者を考えてみてください。大阪の本社が中核事業を担い、グループの財務、連結報告、日本のサプライチェーンを管理しています。2年前、グループはインドの自動車顧客に対応し南アジアへのリードタイムを短縮するため、プネ郊外に部品工場を開設しました。

今日、このグループは2つのシステムを動かしています。大阪は日本円で報告し、日本の消費税の下で、適格請求書のルールに従います。プネの事業体はルピーで報告し、GSTの下で月次申告を行い、数百のベンダー請求書にわたる仕入税額控除を管理します。部品の会社間出荷が毎週大阪からプネへ流れ、その出荷の1つ1つを2つの互いに通信しない台帳間で価格設定し、課税し、請求書を発行し、突合しなければなりません。

1つのERPでは、状況が変わります。大阪が会社1、プネが会社2です。両方ともデータを分離した1つのプラットフォームに存在します。大阪の経理チームは日本語で、プネのチームは英語で働きます。大阪は標準10パーセントの税率で消費税設定を持ち、該当する取引には別の軽減税率を持ち、それぞれ正しい売上税と仕入税の勘定に紐付きます。プネは同じ構造でGST設定を持ち、出力税を負債勘定に、入力税を資産勘定に、その事業体に適用される税率で持ちます。

部品が大阪からプネに出荷されると、取引は1回で記録されます。日本側が出力を計上し、インド側が入力を計上します。通貨は会社レベルで処理され、大阪は円、プネはルピーであるため、どちらのチームも手動換算しません。月末、グループ管理者は2つのエクスポートとスプレッドシートの代わりに1つのプラットフォームから連結数値を取り出します。かつて10日かかった作業がその何分の一かになり、すべての数値が監査人が追える元の書類にまで遡れます。

なぜ重要か：消費税、GST、連結、そして監査

ここでの利害は単なる運用上ではなく、規制上のものです。日本もインドも、ずさんな記録を罰する税制度を執行しますが、その方法は全く異なります。

日本は、仕入税額控除の請求方法を厳格化するために適格請求書制度（いわゆるインボイス制度）を導入しました。適格請求書発行事業者として登録された事業者のみが、控除を支える書類を買い手に渡すことができ、買い手は今やすべての請求書に登録番号を求めています。ERPは消費税率と紐付く勘定を正しく設定できなければならず、さもなければ仕入控除のワークフローが壊れます。制度開始時点で約370万事業者が適格請求書発行者として登録し、コンプライアンスの期待はその後さらに厳しくなっています。

インドはGSTを運用しています。これは目的地原則の税制で、月次申告、仕入税額控除の突合、厳格な請求書ルールがあります。GSTの納税者ベースは1,500万を超えるアクティブ登録にまで成長しました。日本本社のグループにとって、インド事業体は正確かつ期限内に申告しなければ、罰則と控除の喪失に直面します。

1つのERPは、税レイヤーが会社ごとに設定可能であるため、両方を妥協なく扱います。日本の消費税ロジックをインドの事業体に押し付けることも、GSTを日本の勘定科目に無理やり当てはめることもありません。各会社は実際に運用する制度を得ます。

連結は形だけのものではなく、真のものになります。1つのシステムを動かすグループは、基礎となるデータが複製も手動で橋渡しもされていなかったため、実際に合致する連結報告を生成できます。会社間仕訳は構造上一貫しています。通貨は会社レベルにあります。そして監査は、火災訓練ではなく対話になります。日本の監査人が消費税勘定の提示を求めれば、そこにあります。インドの監査人が仕入税額控除の追跡を求めれば、そこにあります。1つのプラットフォーム、2つのコンプライアントな事業体です。

あなたのビジネスに適しているか？

このアプローチは特定の組織の形に合います。あなたはおそらく、数十人から数百人程度の日本本社のグループで、インドに1つ以上の事業体を持っています。インドで操業する約1,500社の日本企業のうち約半数が製造業であることを考えると、製造が最も一般的なケースですが、同じ論理は商社、エンジニアリングサービス、流通グループにも当てはまります。

もし月末決算が恒常的に第1週を超えて流れ、グループ管理者が連結スプレッドシートに何日も費やし、監査人が会社間の不一致を指摘したことがあるなら、この痛みを最も感じています。また、日本チームとインドチームが事実上2つのツールセットと2つの暗黙知で2つの経理機能を動かしている場合にも感じます。

越境事業体のない単一国の運用であれば、この記事は必要ありません。単一会社の設定で十分です。しかし、ある国に本社を持ち、別の国に実際の操業事業体を持った瞬間に、2つの切離されたシステムのコストは四半期ごとに上がります。

よくある質問

1つのERPで親会社と海外子会社のデータを分離しながら連結できますか？

はい。各会社は独自の分離されたデータストアに対応するため、レコードはストレージレベルで完全に分離されています。連結は帳簿を統合することなく会社間を読み取ります。事業体レベルの完全性を失うことなく、グループの可視性を得られます。

消費税とGSTを同時にシステムはどう扱いますか？

税設定は会社ごとに設定可能です。税名、0から100パーセントまでの税率、売上税と仕入税の別々の勘定を定義します。親会社は10パーセントの消費税設定を動かし、海外子会社はGST設定を、それぞれ正しい負債および資産勘定に紐付けて動かすことができます。

複数事業体間のチームは同じ言語を使わなければなりませんか？

いいえ。プラットフォームは英語をフォールバックとし、完全な日本語ロケールを備えて出荷されるため、各ユーザーは好みの言語で働きます。親会社のチームは日本語で、海外子会社のチームは同じシステムで英語で運用できます。

💡 ポイント

越境での成長が、切り離された帳簿を意味する必要はありません。日本本社とインド子会社を分離された会社として保持し、バイリンガルのインターフェースと会社ごとの税設定を持つ1つのERP、つまり真の基幹システムは、突合地獄を単一の信頼できる情報源に変えます。毎月の火災訓練は、ルーチンの決算になります。

Kikan Systemで始める

基幹システムは、まさにこの形のグループのために作られた基幹システムです。データを分離された複数の会社、英語と日本語にまたがるバイリンガルインターフェース、そして各事業体が独自の消費税またはGSTの設定を動かせる税設定レイヤー、これらすべてが勘定科目に対して検証されます。日本本社とインド子会社がまだ2つのシステムで生きているなら、最大2ユーザーまで対応し、クレジットカード不要の無料プランから始めてください。/#get-startedにアクセスして始めましょう。

関連記事

• 複数会社のデータ分離
• 日本向けバイリンガル基幹システム
• 複数事業体の統合事例
• 税設定：売上税と仕入税の分離
• GSTの出力税・入力税元帳構造