本社の財務総監は尋ねました。「華東子会社が華北子会社に販売した商品について、なぜ両者の収益と原価が一致しないのですか？」IT部門が調べた結果、次のことが判明しました。両社がそれぞれ異なるExcelの顧客コードを使用しており、内部取引には統一された価格表がなく、承認手続きも別々の主体のWeChatグループ内で行われている――グループ内の複数主体が成長期に入ると、「各自が勝手に管理する」状態は、連結決算書の信頼性を急速に損なってしまいます。
まず組織モデルを描き、それからシステムを選定します
複数主体の場合、少なくとも次のように区分する必要があります：
- 法人主体：独立した会計・税務・銀行口座を持つ。
- 管理組織：事業部、地域、利益センター――法人とは一致しない場合もある。
- 運用組織：工場、倉庫、営業所――実行層。
システム上の「会社／帳簿セット」は法人に対応させるべきであり、管理組織については次元や組織ツリーで重ね合わせる方が適切で、各利益センターごとにERPをクローンする必要はありません。
マスターデータ：作成者・利用者・変更者は誰か
顧客・仕入先・材料・勘定科目――これら4種類のマスターデータが、主体間のトラブルの80％を左右する。
- ゴールデンレコード：グループMDMまたは本社のマスターデータ担当者がコードと核心属性を維持し、子会社は地域別の営業メモなど、ローカルなフィールドのみ拡張可能。
- 配布メカニズム：新規材料は承認後、各帳簿セットへ配布され、「同名異コード」を防ぐ。
- 変更監査：価格・与信枠・税区分の変更はバージョンを残し、連結決算書の遡及時に説明できるようにする。
よくある誤り：子会社が重複チェックなしで自由に顧客を新規作成できるよう許可すると、同一グループの顧客にN個のコードが割り当てられ、CRMの統計が歪む。
内部取引と移転価格設定
主体間の購買・移動・サービス決済には、内部価格表と自動発注ルールが必要です。システムは、一方が出庫すると関連する他方の入庫が即時確認されるよう支援し、片側だけの記帳を防ぐべきです。移転価格戦略（原価プラス・市場価格・協定価格）は、財務部門がルールを定め、ITが構成可能なエンジンとして実装します。
権限：データ隔離と主体間の協働
権限モデルの提案は「デフォルトでは非表示、明示的に権限付与」：
- 子会社のユーザーはデフォルトで自法人のデータしか見ることができず、グループ全体の集計を見るには役職とデータ範囲の設定が必要（例：事業部長が下部法人を見られる）。
- 共有機能（グループ購買・共有センター）は代理操作で対応：どの主体に代わって注文するのか、監査ログには両主体を記録する。
- 機密フィールド（グループ底価・戦略顧客割引）はフィールド単位で脱敏処理を行う。
OAの承認フローには必ず「所属主体」のコンテキストを付けること；そうでなければA社の管理者がB社の契約を承認するという法的リスクが生じる。
システム導入：単一システムか複数システムか
| モード | の利点 | のリスク |
|---|---|---|
| 単一インスタンス多帳簿セット | マスターデータの統一、アップグレードは一度で済む | 構成は複雑、性能分離はしっかり行う必要がある |
| 多インスタンス＋統合 | 子会社の自律性が高い | マスターデータ同期、インターフェースコストは高い |
| ハイブリッド：コアERP集中＋エッジシステム分散 | 管理のバランスと柔軟性の両立 | 境界と真相源は文書化すべき |
選定は、法人の自治度、業界規制（金融・医薬など）、ITリソースによって決まる。いずれにせよ、コード規則とインターフェース規格はグループで統一しなければ、統合は混乱を自動化するだけに終わる。
導入ペースと検収
第1段階：顧客・仕入先のマスターデータ統一＋内部取引の発注開始；第2段階：連結決算データソースの整合；第3段階：主体間在庫の可視化と移動最適化。検収指標の一例：同一顧客はグループ内に唯一のコードを持つこと；主体間移動は24時間以内に双方で帳簿が一致すること；権限浸透テスト（子会社アカウントがグループ内の他法人のデータを引き出すことはできない）。
グループまたは複数法人のスマート化プロジェクトには、組織モデル・マスターデータ・権限を同時に設計する必要がある。山東許願牛情報科技有限公司（許願牛科技／XYN Tech）は、政企および多組織の企業管理系システムを提供しており、現状の整理から段階的な導入まで対応可能。詳細は許願牛科技についてをご参照ください。技術情報は許願牛科技について、ニュースはxynadminニュース、をご覧ください。。
共有サービスセンターのモデル
グループの財務・人事・購買共有センターは、通常複数の法人に代わって伝票処理を行う。システムは「現在の操作主体」切り替え機能を備え、各伝票には操作者・代理人となる主体・タイムスタンプを印刷し、監査ログにも記録する。共有センターのパフォーマンスボードは主体ごとのSLAに基づいて統計し（支払いサイクル・購買サイクル）、一家族の遅延が平均化されるのを防ぐ。
連結決算と相殺仕訳
連結決算は単なるExcelの集計ではない：システム上で相殺ルール（内部販売・内部取引・未実現利益）を維持する必要がある。各子会社が同一会計期間に決算を終えた後、グループレベルで相殺仕訳の草稿を自動生成し、財務部門の再確認を経て正式に記帳する。もし子会社が異なる科目表を使用している場合は、マッピングテーブルを維持し、そうでなければ連結時に科目が合わなくなる。
海外子会社と多通貨
海外法人がある場合、機能通貨と報告通貨は分けて扱う必要がある。日常の記帳は現地通貨で行い、グループの看板は人民元または米ドルに換算して表示し、為替レートのタイプ（期末・平均）は基準に従って設定する。主体間の借入・配当・サービス料決済には外国為替と税務が関わるため、システムは為替レートのスナップショットと換算証憑を保存し、監査時に再現できるようにしておくべきである。
データの居住地とコンプライアンス：一部の国では、顧客・従業員のデータを国外に持ち出さないよう求められる。複数主体のアーキテクチャ設計時には、データ領域を明確に区別する必要がある：どのフィールドをグループで共有でき、どのフィールドをローカルに保管すべきか、インターフェースの同期ではフィールド単位のフィルタリングを行う。
導入時のチェックリスト
プロジェクト開始前にまず5つの質問に答えること：在庫の真相源はどのシステムにあるのか、記帳のタイミングは誰が決めるのか、予備は中央集権型か、棚卸しの差異は誰が承認するのか、財務証憑との連携はどうするのか。答えられないなら、急いでバーコードリーダーを導入するのは避けるべきだ――ハードウェアはプロセスの混乱をさらに拡大するだけである。導入後最初の週は毎日、可用量の恒常性をサンプリングする：ランダムに20のSKUを選び、システムの可用＝帳簿－占用－凍結と現場の棚卸しを比較する。
検収時には、必ずの実際の業務伝票を用いてでクローズド・ループを確実に回すことが重要であり、デモアカウントで数回クリックするだけで署名するのは適切ではありません。文書化された「在庫ステートマシン」および「帳簿記入時点」は、研修用PPTよりも部門間のもめ事を減らすのに効果的です。