ERPシステムの仕組み：モジュール、データフロー、そしてその根底にある総勘定元帳
ERPのすべてのモジュールを通過する1件の取引と実際の仕訳、そして総勘定元帳がなぜ他のすべてのデータの信頼できる唯一の情報源（単一の真実のソース）となるのかを解説します。
ERPシステムは、すべてのビジネスイベントを1つのデータベースに1回だけ保存し、各モジュールがその共有レコードを読み書きできるようにすることで機能します。出荷された注文データは、倉庫担当者、営業チーム、経理担当者の誰が確認してもまったく同じレコードです。システム全体の整合性を保つ中核となるモジュールが総勘定元帳（general ledger）です。金額を伴うすべてのイベントは、最終的に貸借が一致した仕訳としてそこに記録され、すべてのレポートはそれらの仕訳から導出されます。
この記事では、1件の販売取引が各モジュールをどのように流れるかを追い、それによって生成される仕訳を示した上で、ERPとの連携が画面の操作ではなく、イベントと総勘定元帳を中心に行われるべき理由を解説します。
共有データベース
ERPが登場する前は、各部門が独自のプログラムを運用していました。在庫は倉庫システムに、請求書は請求システムに、帳簿は会計パッケージにそれぞれ存在しており、月末にはその3つの突き合わせ（reconciliation）に追われていました。ERPソフトウェアとはではシステム全体の概要を解説していますが、それを支える仕組みの正体は単一のデータモデルであり、以下の特徴を持っています。
- **取引先（partner）**レコードは、販売、購買、元帳の間で共通して使用されます。
- **品目（item）**レコードは、在庫数量、先入先出法（FIFO）による原価レイヤー、販売価格、売上勘定を保持します。
- 伝票（document）（注文書、請求書、クレジットノート、仕入伝票、製造指図書など）は、取引先と品目を参照し、正確に1組の仕訳を生成します。
- **仕訳（journal entry）**はそれを生成した伝票を参照するため、レポート内のすべての数値を元の伝票まで遡って追跡できます。
レコードが共有されている場合、モジュール間で突き合わせを行う必要はありません。突き合わせが必要な残りの対象は、銀行の明細や税務申告といった外部世界との間のみです。
モジュールマップ
| モジュール | 書き込み対象 | 読み取り対象 |
|---|---|---|
| 販売 | 注文、請求書、クレジットノート | 取引先、品目、価格、VATルール |
| 購買 | 発注書、仕入先請求書 | 取引先、品目、費用勘定 |
| 在庫 | 在庫移動、FIFO原価レイヤー、棚卸 | 品目、倉庫 |
| 生産 | 製造指図、部品消費、完成品 | 部品表（BOM）、在庫 |
| 銀行 | 取引データ取り込み、入金突合 | 未決済請求書、銀行口座 |
| 給与 | 給与計算実行、社会保険料、申告 | 従業員、契約、税額表 |
| 固定資産 | 資産台帳、減価償却実行 | 資産グループ、耐用年数 |
| 税務 | VAT申告、EU販売リスト、Intrastat、電子請求書 | 発行済および登録済の伝票 |
| 総勘定元帳 | 仕訳、期間ロック | 上記のすべて |
| レポート | なし | 総勘定元帳および補助元帳 |
最後の2つを除くすべての行は、総勘定元帳への書き込みで終わります。これが、ERPを連携された個別のツールの集まりから区別する設計上のルールです。
実際のデータフロー
以下の例では、Nordletのエンドポイントと、リトアニアのデフォルト勘定科目表を使用しています。どのERPでも実行する手順は共通ですが、勘定科目コードやエンドポイント名は異なります。
1. 注文
ストアフロントが POST /v1/ecommerce/orders/create を通じて注文を行います。取引先、品目と数量を含む明細、出荷先国が指定されます。この時点ではまだ元帳には何も転記されません。注文は取引ではなく、あくまで約束（コミットメント）であるためです。
2. 在庫引当
orders/reserve により、別の注文で同じ在庫が販売されないよう数量が確保されます。ここでもまだ仕訳は起票されません。引当済みの在庫は引き続き自社が所有しているためです。
3. 出荷
orders/fulfill は倉庫からの商品の出庫を記録します。1回のデータベーストランザクション内で次の2つの処理が実行されます。
- FIFO原価で在庫が消費されます。各品目の最も古い原価レイヤーが最初に適用されます。これはFIFO在庫評価法（FIFO inventory valuation）の用語集エントリで説明されている方法です。
- それらのユニットの原価が仕訳として計上されます。借方は売上原価、貸方は在庫となります。
| 勘定科目 | 借方 | 貸方 |
|---|---|---|
| 6000 売上原価 | 600.00 | |
| 2040 在庫 | 600.00 |
また、出荷処理によって注文に対する**請求書下書き（draft invoice）**が作成され、出荷先国に基づいてEU VATエンジン（EU VAT engine）によりVATの処理が決定されます。
4. 請求書の発行
請求書の発行は、特定時点の販売（point-in-time sale）に対する収益が認識されるタイミングです。伝票には隙間のない連続した番号が割り振られ、貸借一致の仕訳が起票されます。総額が売掛金に、VATが仮受VAT勘定に、そして純額が売上勘定に計上されます。
純額1,000ユーロ、リトアニアのVAT税率21%の売上の場合：
| 勘定科目 | 借方 | 貸方 |
|---|---|---|
| 2410 売掛金 | 1,210.00 | |
| 5000 商品売上高 | 1,000.00 | |
| 4492 仮受消費税（出力VAT） | 210.00 |
明細に特定時点以外の収益認識方法が適用されている場合、純額は前受収益（deferred income）に計上され、収益認識エンジン（revenue recognition engine）によりスケジュールに従って順次計上されます。売掛金とVATの計上処理は変わりません。
請求書は、PDF、Peppol BIS 3.0電子請求書、または企業の所在国で義務付けられている国内の電子請求書フォーマットとして出力できるようになります。
5. 銀行突合
2週間後に入金として1,210ユーロが到着します。この入金データは、PSD2銀行フィードまたはcamt.053明細のインポートを通じて取り込まれます。銀行モジュールは、金額、支払参照番号、相手方名称、IBANに基づいて候補となる請求書のスコアリングを行い、bank/transactions/match が決済を転記します。
| 勘定科目 | 借方 | 貸方 |
|---|---|---|
| 2710 当座預金（銀行） | 1,210.00 | |
| 2410 売掛金 | 1,210.00 |
請求書のステータスが「支払済み」に変更され、sale_invoice.paid Webhookイベントが発行されます。支払消込（payment reconciliation）のエントリで、この突合ロジックの詳細を解説しています。異通貨での支払いの場合、実現為替差損益が同じステップで損益勘定に計上されます。
6. VAT申告
月末であっても、データの再入力は一切必要ありません。VAT申告書は発行済および登録済の伝票から自動計算されます。国内申告の場合は declarations/eu/vat-return/compute（リトアニアの場合はFR0600）、EUワンストップショップ（OSS）制度に基づくクロスボーダーの消費者向け販売の場合は declarations/eu/oss/compute が使用されます。上記の売上は、そのVATスキームが domestic であるため、国内申告書の標準税率の欄に計上されます。
7. 期間のロック
申告が完了したら、ledger/periods/lock により月次を締め切ります。これ以降、遅れて到着した銀行突合や再試行されたAPI呼び出しなど、その期間に属する日付の仕訳はすべてHTTP 409エラーで拒否されます。また、期間のロックを行うことで、期間末までに計上されるべき前受収益の認識処理がトリガーされるため、負債勘定に収益を残したまま月を締め切ることを防ぎます。
なぜ元帳が信頼できる唯一の情報源（システム・オブ・レコード）なのか
上記の各モジュールはそれぞれ**補助元帳（subledger）**を維持しています。顧客別の売掛金、仕入先別の買掛金、品目別の在庫、資産別の固定資産がこれに該当します。総勘定元帳（general ledger）には、それらの補助元帳が一致していなければならない合計金額が保持されます。補助元帳と総勘定元帳の違い（Subledger vs general ledger）でその関係性を解説していますが、実務上のポイントとして、元帳から作成したレポートと補助元帳から作成したレポートは必ず同じ数値を出力する必要があり、ERPは同じ仕訳（journal entry）から両者を生成することでそれを保証しています。
元帳が記録として信頼できるものであるために、次の3つの特性を備えています。
- 貸借一致の強制：Nordletでは、借方の合計が貸方の合計と一致しないエントリはデータベース側で拒否されます。モジュール側のバグによって貸借がアンバランスな仕訳が作成されることはありません。
- 履歴の追記型（append-only）：一度転記された仕訳が編集されることはありません。誤りがあった場合は、逆仕訳（reversal）と新しい仕訳の起票によって修正され、両者は元のエントリにリンクされます。不変元帳（immutable ledger）のエントリで、監査人がこれを強く求める理由を解説しています。
- 期間の締め切り：ロックされた月を変更することはできないため、申告した数値がそのままシステム内に保持されます。
連携：夜間バッチではなく、イベント駆動と冪等性
従来のERP連携では、夜間にファイルをやり取りしていました。注文をエクスポートし、それをインポートし、朝にエラーログを確認するという方法です。現代のERPはAPIを公開しているため、システム連携は次の2つの原則に基づいて行われます。
外向きのイベント：何らかの変更が発生すると、ERP側から通知が届きます。Nordletは、変更処理と同一のデータベーストランザクション内で各Webhookイベントを出力用キュー（outbox）に書き込むため、ロールバックされた伝票からイベントが発行されることはなく、イベントが消失することもありません。配信にはHMAC-SHA256による署名が付与され、指数バックオフを用いた再試行が行われます。これにより、5分おきに「何か支払いはありましたか？」と問い合わせるのではなく、自社システム側で sale_invoice.paid イベントにリアクトできるようになります。
安全な再試行（内向き）：ネットワーク障害は発生しうるものであり、再試行されたリクエストによって2重に請求書が作成されてはなりません。Nordletは、状態を変更するすべてのリクエストに対して Idempotency-Key ヘッダーを受け付けます。同じキーと同一のペイロードの場合は保存済みのレスポンスを返し、同じキーで異なるペイロードが送信された場合は拒否され、キーは24時間で失効します。冪等性（idempotency）の用語集エントリおよびAPI規約（API conventions）にその正確な動作が記載されています。
すべての操作が POST /v1/{module}/{resource}/{action} の呼び出しであり、アプリケーション側も同じエンドポイントを使用するため、システム連携によって画面を一切開くことなく、前述のデータフロー全体を実行できます。SaaSプラットフォームへのクラウド会計APIの組み込み方法（How to integrate a cloud accounting API into a SaaS platform）では、このような構築手順を詳しく解説しています。
レポートが読み取るもの
レポートは数値を保存しているわけではありません。レポートとは、特定の時点における元帳および補助元帳に対するクエリ（検索・集計）そのものです。
- 試算表、貸借対照表、損益計算書、キャッシュフロー計算書は、勘定科目および期間ごとに仕訳を読み取ります。
- **債権年齢調べ（aging report）**は、期日ごとの未決済の売掛金および買掛金を読み取ります。
- 在庫残高と在庫移動は、在庫補助元帳とそのFIFOレイヤーを読み取ります。
- VATサマリーは、発行済および登録済の伝票のVAT明細を読み取ります。
- コストセンター別レポートは、各仕訳明細上のコストセンターディメンションを読み取ります。
Nordletでは、レポートはバックグラウンドでXLSX、PDF、またはJSON形式として生成され、ファイルの準備ができたらWebhookが発火します。連結会計（consolidation）により、複数企業の元帳を持ち分の重み付けや通貨換算とともに結合し、グループ全体の数値を算出します。
実務で破綻するポイント
ERPで発生する問題の多くは、ソフトウェアの不具合ではなく、共有レコードの原則が守られないことに起因します。よくある事例：
- ERPで「できない」という理由で作成された並行スプレッドシート。帳簿の数値と一致しなくなります。
- 伝票を修正する代わりに、モジュールの出力を修正するために使用された手動仕訳。レポートからソースへの追跡可能性が損なわれます。
- 伝票ではなく残高を直接書き込む連携処理。元帳に誰も説明できない合計金額が残ることになります。
- 何ヶ月もロックされずに放置された会計期間。前四半期に申告した数値が後からズレていきます。
ERP導入が失敗する理由（Why ERP implementations fail）では導入プロジェクト中にこれらの悪癖がどのように形成されるかを解説しており、現実的なERP導入スケジュール（realistic ERP implementation timelines）ではプロジェクトのどの段階でそれらが表面化しやすいかを示しています。
FAQ
ERPシステムの核心は何ですか？
総勘定元帳と、その周囲にある共有データモデルです。すべてのモジュールが、貸借一致の仕訳を生成する伝票を書き込み、すべてのレポートはそれらの仕訳から導出されます。
データはERP内をどのように流れますか？
イベントは、伝票（注文書、請求書、在庫移動、給与計算実行など）として一度だけ記録されます。その伝票が元帳の仕訳と関連する補助元帳の増減を生成します。レポートや税務申告書はそれらの記録から計算されます。モジュール間でデータが手動でコピーされることはありません。
モジュールとインテグレーション（外部連携）の違いは何ですか？
モジュールは、システム内の他の部分と同じデータベースおよび同じ元帳に対して書き込みを行います。インテグレーションは、ERPのAPIを呼び出す外部プログラムです。APIファーストのERPであれば、インテグレーション側もモジュールが使用するのと同じエンドポイントを使用するため、両者の境界線はわずかなものになります。
ERPは自動的に会計仕訳を起票しますか？
はい。請求書の発行、注文の出荷、入金の消込、給与計算の実行、固定資産の減価償却のいずれにおいても、人間が借方と貸方を手動で組み立てることなく、それぞれ対応する仕訳が自動的に生成されます。使用される勘定科目は、企業ごとに変更可能な転記ルールに基づいています。
なぜERPは会計期間をロックするのですか？
一度報告または申告した期間の数値が後から変更されないようにするためです。ロックされた期間に対する新規の転記は拒否されるため、監査証跡が保護され、修正事項は現在進行形の期間に強制的に計上されて可視化されます。