補助元帳会計（SLA）の仕組みと追跡 SQL

この章の結論

• AP・AR・原価などの取引は、直接 GL 仕訳になりません。会計イベント → 補助元帳仕訳（SLA）→ GL 仕訳の順に作られます。
• 勘定科目や摘要は、元帳に割り当てた会計方法のルール（仕訳生成ルールセット・勘定ルール・マッピングセットなど）で決まります。勘定が想定と違うときはルールを見直します。
• 追跡の基本経路は XLA_TRANSACTION_ENTITIES → XLA_EVENTS → XLA_AE_HEADERS → XLA_AE_LINES → GL_IMPORT_REFERENCES → GL_JE_LINES です。取引の配分単位で追うときは XLA_DISTRIBUTION_LINKS を使います。
• 「会計したのに GL にない」は、ドラフトのまま・GL 未転送・GL 未転記のどれかです。補助元帳仕訳ヘッダーのステータスで切り分けます。

テーブル定義の確認状況（2026 年 10 月確認）

このページが使う表と列は、公式の Tables and Views for Financials で次のとおり確認しました。

• AP_INVOICES_ALL・AP_INVOICE_DISTRIBUTIONS_ALL・AP_INVOICE_PAYMENTS_ALL（25D）、GL_JE_LINES（26A）
• XLA_EVENTS・XLA_AE_HEADERS・XLA_AE_LINES・GL_IMPORT_REFERENCES（25D）、XLA_DISTRIBUTION_LINKS（26A）、XLA_TRANSACTION_ENTITIES（26B）
• GL_JE_HEADERS は、BIP 演習 が 25D で確認した列を使っています。GL_JE_BATCHES は、GL_IMPORT_REFERENCES の外部キーに表名があることだけを確認しており、列の定義は未確認です。

ステータス列などの コード値（P／U、F／D、Y／N、アプリケーション ID の 200、エンティティ・コードの AP_INVOICES など）は、これらの列定義に値の一覧がなく、確認できていません。このページの値は例として読み、SELECT DISTINCT で確かめてから使ってください。表の定義はリリースで変わることがあるため、自分の環境のリリースの Tables and Views も確認してください。

全体像

SLA の役割

補助元帳会計（Subledger Accounting、SLA）は、各補助元帳が共通で使う「ルールで仕訳を作るエンジン」です。補助元帳は取引から会計イベントを作るだけで、仕訳の勘定や金額の組み立ては SLA が担います。

取引の登録（例：AP 請求書の検証） → 会計イベント → 会計の作成（Create Accounting） → 補助元帳仕訳 → GL への転送 → GL 仕訳 → GL の転記 → 残高

テーブルで書くと次のとおりです。

AP_INVOICE_DISTRIBUTIONS_ALL → XLA_TRANSACTION_ENTITIES／XLA_EVENTS → XLA_AE_HEADERS／XLA_AE_LINES（＋XLA_DISTRIBUTION_LINKS） → GL_IMPORT_REFERENCES → GL_JE_BATCHES／GL_JE_HEADERS／GL_JE_LINES → GL_BALANCES

主な用語

用語（英語 UI 名）	意味
Accounting Event（会計イベント）	会計に影響する出来事。イベント・クラス（例：請求書、支払）とイベント・タイプ（例：検証、取消）で分類されます
Event Entity（イベント・エンティティ）	会計の対象となる取引の種類（例：AP の請求書、AP の支払）
Subledger Accounting Method（会計方法）	元帳に割り当てるルールの集合。補助元帳ごとに仕訳生成ルールセットを持ちます
Journal Entry Rule Set（仕訳生成ルールセット）	イベント・クラス／タイプごとに、どの明細ルール・勘定ルール・摘要ルールを使うかの組合せ
Journal Line Rule（仕訳明細ルール）	借方／貸方、会計クラス、明細を集約するかなど、明細の作り方
Account Rule（勘定ルール）	勘定組合せ全体、または特定セグメントの値の導き方。条件と優先順位を持てます
Mapping Set（マッピングセット）	入力値（例：品目カテゴリ、取引タイプ）からセグメント値への対応表
Description Rule（摘要ルール）	仕訳ヘッダー・明細の摘要の組み立て方
Supporting Reference（補足参照）	仕訳明細に取引の属性（例：仕入先、プロジェクト）を持たせ、その単位で残高を見るしくみ

設定・実装の手順

会計ルールの考え方

1. 元帳に会計方法を割り当てます（元帳の設定で指定）。標準で提供される会計方法をそのまま使うか、コピーして変更します。
2. 標準ルールで勘定が決まらない箇所だけ、勘定ルールやマッピングセットを追加します。例：「品目カテゴリ別に費用勘定を変える」はマッピングセット＋勘定ルールで実現します。
3. 変更した仕訳生成ルールセットと会計方法を有効化（検証）します。未検証のルールは会計の作成で使われません。
4. テスト取引で会計の作成をドラフトモードで実行し、仕訳の勘定・金額・摘要を確認してから本番の運用に移ります。

会計の作成と GL への転送

1. 補助元帳で取引を完了させます（AP なら請求書の検証、AR なら取引の完了）。この時点で会計イベントが作られます。
2. スケジュール済プロセス（Scheduled Processes）で Create Accounting を実行します。主なパラメータは次の 3 つです。
   • Accounting Mode：Draft（ドラフト。確認用で何度でも作り直せる）または Final（最終。変更不可で GL 転送の対象）
   • Transfer to General Ledger：最終仕訳を GL に転送するか
   • Post in General Ledger：転送した仕訳を GL で転記まで行うか
3. 実行結果のレポート（出力）でエラーのイベントを確認します。勘定が導出できない、期間がオープンでない、などが典型です。
4. GL 側で仕訳バッチ・仕訳を確認し、未転記なら転記します。GL の仕訳ソースは補助元帳名（例：Payables）になります。

ノート

転送時の集約（要約）の設定によっては、複数の補助元帳仕訳明細が 1 つの GL 仕訳明細にまとめられます。このため GL 仕訳明細 1 行に対して補助元帳仕訳明細が複数行対応することがあり、その対応を記録しているのが GL_IMPORT_REFERENCES です。

XLA テーブルの関係

テーブル	1 行が表すもの	次の表への結合	主キー・確認したリリース
XLA_TRANSACTION_ENTITIES	会計対象の取引 1 件（例：請求書 1 件）	ENTITY_ID で XLA_EVENTS へ	主キーは ENTITY_ID（26B）
XLA_EVENTS	会計イベント 1 件（例：請求書の検証）	EVENT_ID で XLA_AE_HEADERS へ	主キーは EVENT_ID＋APPLICATION_ID。LEDGER_ID 列はなく、TRANSACTION_LEDGER_ID（NULL 可）がある（25D）
XLA_AE_HEADERS	補助元帳仕訳ヘッダー（元帳ごと）	AE_HEADER_ID で XLA_AE_LINES へ	主キーは AE_HEADER_ID＋APPLICATION_ID（25D）
XLA_AE_LINES	補助元帳仕訳明細	GL_SL_LINK_ID＋GL_SL_LINK_TABLE で GL_IMPORT_REFERENCES へ	主キーは AE_HEADER_ID＋AE_LINE_NUM＋APPLICATION_ID（25D）
XLA_DISTRIBUTION_LINKS	取引の配分と仕訳明細の対応	AE_HEADER_ID＋AE_LINE_NUM で XLA_AE_LINES へ	主キーの定義はなく、一意索引は APPLICATION_ID＋REF_AE_HEADER_ID＋TEMP_LINE_NUM＋AE_HEADER_ID（26A）
GL_IMPORT_REFERENCES	補助元帳仕訳明細と GL 仕訳明細の対応	JE_HEADER_ID＋JE_LINE_NUM で GL_JE_LINES へ	主キーの記載はなく、外部キーは GL_JE_BATCHES・GL_JE_HEADERS・GL_JE_LINES（25D）

取引とエンティティは、APPLICATION_ID（補助元帳）、ENTITY_CODE（取引の種類）、SOURCE_ID_INT_1（取引の主キー）の組で結びます。AP 請求書なら、エンティティ・コード AP_INVOICES の SOURCE_ID_INT_1 が INVOICE_ID です。ただし公式の列の説明は SOURCE_ID_INT_1 が「Flexible source identifier（Integer）」とあるだけで、INVOICE_ID が入ることや AP_INVOICES という値までは書かれていません。検索用の索引は、APPLICATION_ID・LEDGER_ID・ENTITY_CODE・SOURCE_ID_INT_1 などの順です（26B）。値は後述の確認用 SQL で確かめてください。

公式の説明では、GL_IMPORT_REFERENCES には、ジャーナル・ソースの「Import Journal References」が Yes のものについて、フィーダー側の取引ごとに 1 行が作られます（25D）。補助元帳仕訳明細から GL 仕訳明細へたどれないときは、この設定も確認ポイントになります。

近道もあります。AP 配分の ACCOUNTING_EVENT_ID と AP 請求書支払の ACCOUNTING_EVENT_ID は、その行を会計した会計イベントの ID です（25D の Tables and Views で確認）。イベントが分かれば、エンティティ表を経由せずに仕訳ヘッダーへ進めます。

ステータスの列は次のように使います。XLA_ の列は Tables and Views で確認済みですが、値の一覧は公式の列定義にありません。下の値は一般に使われる例で、全量は環境で SELECT DISTINCT して確認します。

確認したいこと	見る列	値の例
イベントが会計済か	XLA_EVENTS.PROCESS_STATUS_CODE	P（処理済）、U（未処理）、D（ドラフト）、E（エラー）
仕訳がドラフトか最終か	XLA_AE_HEADERS.ACCOUNTING_ENTRY_STATUS_CODE	F（最終）、D（ドラフト）
GL に転送済か	XLA_AE_HEADERS.GL_TRANSFER_STATUS_CODE	Y（転送済）、N（未転送）
GL で転記済か	GL_JE_LINES.STATUS	P（転記済）、U（未転記）

列の型は、XLA_EVENTS の PROCESS_STATUS_CODE と EVENT_STATUS_CODE が VARCHAR2(1)、XLA_AE_HEADERS の ACCOUNTING_ENTRY_STATUS_CODE と GL_TRANSFER_STATUS_CODE が VARCHAR2(30) です（25D）。後者は 1 文字とは限らないため、上の表にない値が返ることを想定して、条件には確認した値だけを使います。公式の列の説明は、PROCESS_STATUS_CODE が「生成された会計仕訳のステータスを追跡する略号」、EVENT_STATUS_CODE が「このイベントで生成された会計仕訳に関連するステータスの名前」です。このほか XLA_EVENTS.ON_HOLD_FLAG は、公式の説明に Y（はい）／N（いいえ）とあります。

コード例

AP 請求書 → SLA → GL を 1 本でたどる

BIP のデータモデルで実行する前提です。:P_INVOICE_ID に請求書 ID を渡します。AP のアプリケーション ID は一般に 200 ですが、環境で確認してから使ってください（確認用 SQL は後述）。

AP 請求書から GL 仕訳明細まで（列は確認済み。ステータスのコード値は例）

SELECT aia.invoice_num,
       xe.event_id,
       xe.event_type_code,
       xah.ae_header_id,
       xah.ledger_id,
       xah.accounting_date,
       xah.accounting_entry_status_code,   -- 例：F＝最終 / D＝ドラフト（値は環境で確認）
       xah.gl_transfer_status_code,        -- 例：Y＝転送済 / N＝未転送（値は環境で確認）
       xal.ae_line_num,
       xal.accounting_class_code,
       xal.code_combination_id,
       xal.accounted_dr,
       xal.accounted_cr,
       gjh.name          AS je_name,
       gjl.je_line_num,
       gjl.status        AS je_line_status  -- 例：P＝転記済 / U＝未転記（値は環境で確認）
FROM   ap_invoices_all aia
       JOIN xla_transaction_entities xte
         ON  xte.application_id  = 200
         AND xte.entity_code     = 'AP_INVOICES'
         AND xte.source_id_int_1 = aia.invoice_id
       JOIN xla_events xe
         ON  xe.application_id = xte.application_id
         AND xe.entity_id      = xte.entity_id
       JOIN xla_ae_headers xah
         ON  xah.application_id = xe.application_id
         AND xah.event_id       = xe.event_id
       JOIN xla_ae_lines xal
         ON  xal.application_id = xah.application_id
         AND xal.ae_header_id   = xah.ae_header_id
       LEFT JOIN gl_import_references gir
         ON  gir.gl_sl_link_id    = xal.gl_sl_link_id
         AND gir.gl_sl_link_table = xal.gl_sl_link_table
       LEFT JOIN gl_je_lines gjl
         ON  gjl.je_header_id = gir.je_header_id
         AND gjl.je_line_num  = gir.je_line_num
       LEFT JOIN gl_je_headers gjh
         ON  gjh.je_header_id = gjl.je_header_id
WHERE  aia.invoice_id = :P_INVOICE_ID
ORDER  BY xah.ledger_id, xe.event_id, xal.ae_line_num

GL 側を LEFT JOIN にしているのは、未転送の仕訳も一覧に残して「どこで止まっているか」を見るためです。

配分単位でたどる（XLA_DISTRIBUTION_LINKS）

AP 配分 1 行が、どの仕訳明細になったか（列は確認済み。配分タイプの値は環境で確認）

SELECT aida.invoice_distribution_id,
       aida.amount,
       aida.dist_code_combination_id,
       xdl.ae_header_id,
       xdl.ae_line_num,
       xal.code_combination_id,
       xal.accounted_dr,
       xal.accounted_cr
FROM   ap_invoice_distributions_all aida
       JOIN xla_distribution_links xdl
         ON  xdl.application_id               = 200
         AND xdl.event_id                     = aida.accounting_event_id
         AND xdl.source_distribution_id_num_1 = aida.invoice_distribution_id
       JOIN xla_ae_lines xal
         ON  xal.application_id = xdl.application_id
         AND xal.ae_header_id   = xdl.ae_header_id
         AND xal.ae_line_num    = xdl.ae_line_num
WHERE  aida.invoice_id = :P_INVOICE_ID
-- 配分の種類は SOURCE_DISTRIBUTION_TYPE 列で区別されます。値は下の確認用 SQL で調べてから条件に加えます

XLA_DISTRIBUTION_LINKS には、SOURCE_DISTRIBUTION_TYPE・SOURCE_DISTRIBUTION_ID_NUM_1 などの順の索引（N1）と、AE_HEADER_ID＋AE_LINE_NUM の索引（N3）があります（26A）。配分タイプを確認して条件に加えると、N1 を使いやすくなります。公式の列の説明は、SOURCE_DISTRIBUTION_TYPE が「取引の配分の分類」、SOURCE_DISTRIBUTION_ID_NUM_1 が「取引の配分の識別子（数値）」で、AP_INV_DIST のような値は書かれていません。

値を確かめる確認用 SQL

固定値（アプリケーション ID、エンティティ・コード、配分タイプ）は、推測で書かずに環境で確かめます。

AP 請求書のエンティティから固定値を確認する

SELECT DISTINCT xte.application_id, xte.entity_code
FROM   xla_transaction_entities xte
       JOIN ap_invoices_all aia ON aia.invoice_id = xte.source_id_int_1
WHERE  aia.invoice_id = :P_INVOICE_ID;

SELECT DISTINCT xdl.source_distribution_type
FROM   xla_distribution_links xdl
       JOIN ap_invoice_distributions_all aida
         ON aida.accounting_event_id = xdl.event_id
WHERE  aida.invoice_id = :P_INVOICE_ID;

GL 仕訳から元の取引へ逆にたどる

GL 仕訳明細 → 補助元帳仕訳 → 取引（列は確認済み）

SELECT gir.je_header_id,
       gir.je_line_num,
       xah.application_id,
       xte.entity_code,
       xte.source_id_int_1,      -- AP 請求書なら INVOICE_ID
       xte.transaction_number,   -- 取引番号（請求書番号など）
       xal.accounted_dr,
       xal.accounted_cr
FROM   gl_import_references gir
       JOIN xla_ae_lines xal
         ON  xal.gl_sl_link_id    = gir.gl_sl_link_id
         AND xal.gl_sl_link_table = gir.gl_sl_link_table
       JOIN xla_ae_headers xah
         ON  xah.application_id = xal.application_id
         AND xah.ae_header_id   = xal.ae_header_id
       JOIN xla_transaction_entities xte
         ON  xte.application_id = xah.application_id
         AND xte.entity_id      = xah.entity_id
WHERE  gir.je_header_id = :P_JE_HEADER_ID

AR・原価の追跡の考え方

経路は AP と同じで、変わるのは「アプリケーション ID」「エンティティ・コード」「配分の表」です。

• AR：取引（請求書・クレジットメモ）、入金、修正がそれぞれ別のエンティティになります。取引の配分は RA_CUST_TRX_LINE_GL_DIST_ALL、入金・消込・修正の配分は AR_DISTRIBUTIONS_ALL が XLA_DISTRIBUTION_LINKS の配分側になります（表と列は要確認）。なお、XLA_EVENTS の公式ページ（25D）の外部キー欄には、RA_CUST_TRX_LINE_GL_DIST_ALL・AR_ADJUSTMENTS_ALL・AR_CASH_RECEIPT_HISTORY_ALL・AR_MISC_CASH_DISTRIBUTIONS_ALL が EVENT_ID で XLA_EVENTS を参照する表として載っています。エンティティ・コードと配分タイプの値は、上の確認用 SQL と同じ方法で調べます。
• 原価管理・受入会計：在庫取引や受入取引から、まず原価側の配分（CST_／CMR_ で始まる表）が作られ、それを会計の作成で SLA 仕訳にします。補助元帳としては「原価管理」「受入会計」が AP・AR とは別に存在するため、追跡では原価側の配分 → SLA → GL の順にたどります。流れは 在庫と原価・会計の流れ と 受入会計 を参照してください。

落とし穴とベストプラクティス

よくあるミス

• APPLICATION_ID を結合条件に入れず、別の補助元帳の同じ ID の行と結び付けてしまう（性能も大きく落ちる）
• 主元帳と副元帳（セカンダリ元帳）・報告通貨の仕訳を区別せずに合計し、金額が 2 倍・3 倍になる（LEDGER_ID で絞る）
• ドラフトの仕訳を最終と同じように集計する（ACCOUNTING_ENTRY_STATUS_CODE を確認）
• GL 仕訳明細と補助元帳仕訳明細を 1 対 1 だと思い込む（集約されると 1 対多）
• 取消・再検証で作られた逆仕訳や追加イベントを見落とす（イベントは 1 取引に複数ある）

• 調査はまず「取引 1 件」に絞って上から順に結合し、各段の件数を確認します。いきなり期間全体で流すと原因が分からなくなります。
• 勘定が違うときは、SQL ではなく会計方法のルール（勘定ルール・マッピングセットの条件と優先順位）を見直します。データを直すのではなく、ルールを直してから再度会計の作成を実行するのが基本です（最終仕訳は修正できないため、ドラフトで確認してから最終にします）。
• 月次の照合では「補助元帳の残高（例：AP の未払残高）」「SLA の仕訳」「GL の残高」の 3 点を比べます。差異の原因の多くは、未会計・未転送・未転記・手入力の GL 仕訳です（期間締め）。

試験対策ポイント

• SLA の概念（会計イベント、会計方法、仕訳生成ルールセット、勘定ルール、マッピングセット、ドラフトと最終、GL への転送と転記）は GL・AP・AR の各実装試験に関係します。GL 模擬テスト、AP 模擬テスト、AR 模擬テスト で確認しましょう。
• 原価・受入会計の仕訳が SLA を通ることは 原価管理 模擬テスト の範囲にも関係します。
• 判断ポイント：勘定を変えたいときに直すのは「ルール」であり取引データではない、ドラフトは GL に転送されない、副元帳の仕訳も SLA が作る。

公式ドキュメント

• Tables and Views for Financials（26D）
• GL_JE_LINES（26A）
• XLA_TRANSACTION_ENTITIES（26B）
• XLA_EVENTS（25D）
• XLA_AE_HEADERS（25D）
• XLA_AE_LINES（25D）
• XLA_DISTRIBUTION_LINKS（26A）
• GL_IMPORT_REFERENCES（25D）
• AP_INVOICE_DISTRIBUTIONS_ALL（25D）
• AP_INVOICE_PAYMENTS_ALL（25D）
• Oracle Financials 26D：APIs, Business Objects, & Schema

関連ページ

• SQL 演習：AP 請求書から GL 仕訳まで追跡する
• 主要テーブルマップ
• 共通設定・税・会計・期間締め（AP）
• 仕訳（作成・インポート・承認・配賦）
• R2R：記帳から決算・連結・EPM まで