AIに向けた財務データの準備:勘定科目表、ERP、マスタデータ

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
財務データの準備とは、勘定科目表、ERPの取引、マスタデータ(仕入先、顧客、品目)が、AIシステムがそれを読み取って、慎重なコントローラーと同じ答えにたどり着けるだけの正確さ、一貫性、つながりを備えている度合いのことです。 モデルには、「Acme Corp」「ACME Corporation」「Acme Corp.」が同じ仕入先であることや、3つの原価センターがコードは違っても同じ意味であることは分かりません。それぞれを別のものとして扱い、その上に積み上げられた予測、照合、差異の説明のすべてが、その分断を引き継ぎます。
本記事は、決算、買掛金、債権回収、予測、報告の分野でAIのパイロット導入を始めようとしていて、先にデータについて何が満たされていなければならないのかを知りたいCFO、コントローラー、財務ディレクター、財務マネージャー向けです。ACE Frameworkのデータ層(レベル0)にあたり、何かが予測されたり生成されたりする前に、IngestとAnalyzeが行われる段階です。財務部門全体の視点については財務におけるAIから、具体的なワークフローについてはAIの財務ユースケースをご覧ください。
重要なポイント
- RGPが2025年12月に米国のCFO 200人を対象に行った調査では、35%がAIのROIを妨げる最大の障壁としてデータへの信頼を挙げ、企業データを全面的に信頼していると答えたのは10%にとどまりました(RGP CFO survey)。
- 同じ調査で、CFOの86%がレガシーシステムがAIへの準備を制約していると答えました(RGP CFO survey)。
- Harvard Business Reviewの調査では、自部門で最近作成されたデータレコードを確認した経営幹部75人のうち、新しいレコードの47%に少なくとも1つの重大な誤りがあり、最も緩い基準でも許容可能と評価できるデータ品質スコアは3%だけでした(Nagle, Redman and Sammon, HBR, 2017)。これは財務に限らない一般的なビジネスデータで、やや古い調査であり、財務専用のベンチマークではありませんが、新しく作成されたレコードに関する教訓は、あらゆるマスタデータの入力フォームに当てはまります。
財務AIの成否がデータ次第である理由
財務AIのどのユースケースも、同じいくつかの場所からデータを読み取ります。請求書照合ツールは仕入先レコードと発注書を読みます。キャッシュフロー予測は売掛金、買掛金、銀行データを読みます。差異コメントのツールは総勘定元帳を読み、数字が動いた理由を伝えます。決算アシスタントは試算表と仕訳を読み、不自然に見えるものにフラグを立てます。
したがって、最初の問いは「モデルの出来はどうか」ではありません。「何を見ているのか」です。その答えが「ぐちゃぐちゃなもの」だった場合、3つの問題が起きます。
- モデルは、不整合をパターンとして学習します。 同じ経費が、誰が仕訳したかによって4つの勘定科目に入るとすれば、分類モデルは4つの習慣を学習し、どれも同じように妥当だと扱います。
- アシスタントは、誤った数字を説明します。 差異コメントを書く言語モデルは、その変動がマッピングの誤りであっても、売上の変動を流暢に説明します。これは財務の場面でのハルシネーションの問題です。流暢で、自信ありげで、帳簿の裏づけがありません。
- レポートが食い違います。 ERP、計画ツール、BI層が「地域」や「顧客」をそれぞれ違うように定義していると、最初のAI生成レポートは、意思決定ではなく定義をめぐる議論になってしまいます。
この取り組みは、AIを使うかどうかにかかわらず成果が出ます。決算の短縮、監査の円滑化、振替仕訳の減少は、同じ修正から生まれます。
財務データの3つの層
財務データは3つの層で考えてください。AIはその3つすべてに依存しており、下の層の不備は、その上のすべての層に表れます。

| 層 | 含まれるもの | 一般的な責任者 | AIの用途 |
|---|---|---|---|
| 勘定科目表とディメンション | 勘定の構造、原価センター、法人、製品、プロジェクト、グループ会社間コード | コントローラーまたは会計方針の担当者 | 取引の分類、レポートへのマッピング、明細行ごとの予測 |
| マスタデータ | 仕入先、顧客、品目または製品、従業員、銀行、税コード | 財務またはシェアードサービスのデータスチュワード(調達部門・営業部門と連携) | 書類の照合、重複の検知、与信と支払の判断 |
| 取引と書類 | 仕訳、請求書、発注書、領収書、銀行明細行、契約書、裏づけファイル | プロセスオーナー(AP、AR、トレジャリー、決算) | 抽出、照合、異常検知、説明文の下書き |
ほとんどのチームは、痛みが目に見えるところなので、取引から手をつけます。しかし勘定科目表とマスタデータが信頼できないままでは、取引をきれいにしても症状を治療しているにすぎません。
勘定科目表:AIが読む言語
勘定科目表は、財務の語彙です。分類、予測、説明を行うAIの機能はすべて、これを通して翻訳しています。特に問題を起こしやすい設計上の課題が4つあります。

勘定の乱立。 買収を重ねて大きくなった勘定科目表には、数千の勘定が含まれていることが多く、その多くは休眠中か、ほぼ重複しています(「旅費」「旅費 - 国内」「T&E その他」など)。分類モデルはその中から選ばなければなりませんが、正直なところ、人間も一貫しない選び方をしています。
勘定番号に潜り込んだ意味。 部門別や地域別の支出を把握したいのにシステムで対応できない場合、企業は「マーケティング - EMEA - イベント」のような勘定を作ります。これは、8つの地域、10の部門、そして組織再編が重なるまでは機能します。よりよい設計は、勘定を項目の性質のために保ち、部門、地域、製品、プロジェクトを別々のディメンション(原価センター、セグメント、タグ)に分けるものです。モデルは、巨大なフラットな一覧よりも、少数の整った勘定とディメンションの組み合わせのほうがはるかにうまく扱えます。
法人ごとの違いと各国会計基準の差異。 独自の現地勘定科目表を持つ子会社を、スプレッドシートでグループの勘定科目表にマッピングしている状態は、気づかれにくい誤りの典型的な原因です。マッピングが誰かのワークブックの中にあるなら、グループデータを読むAIツールには、それがいつ変わったのか知るすべがありません。
用途の文書化がないこと。 「その他」や「仮勘定」と名づけられた勘定に目的が書かれていないと、ごみ箱になってしまいます。モデルは、本当の「その他」と、未解決の項目を区別できません。
実務上の基準は、言葉にすると単純です。すべての勘定に、文書化された定義、責任者、使う場面と使わない場面のルール、外部報告の区分へのマッピングがあることです。それが整っていれば、基本的な自動化でもうまく働き、検索ベースのアシスタントは、検索拡張生成で説明されているように、定義を利用者に引用して返せます。
ERPのデータ品質:不備はどこから生まれるか
ERPは、単なるデータの供給源ではありません。自由入力、任意項目、手動の上書き、回避策を許すフォームによって、不備が作り出される場所でもあります。5つのパターンが何度も繰り返し現れます。
| 不備 | 見え方 | AIにとっての問題 | 最初の修正 |
|---|---|---|---|
| マスタレコードの重複 | 同じ取引先が、異なる税ID、銀行口座、表記で2回登録されている | 二重支払の検知、支出分析、3点照合がすべて細分化される | 作成時の重複チェックと、名称、税ID、銀行情報による定期的な照合レポート |
| リストであるべき箇所が自由入力 | 支払条件、原価センター、通貨が手入力されている | モデルがあらゆる表記を別の値として扱う | レコードを作成するフォームでの選択リストと必須項目 |
| 説明の乏しい手動仕訳 | 裏づけのない「調整」や「CFO指示による振替」 | 異常検知は通常の仕訳と特異な仕訳を区別できず、説明文のツールも説明できない | 手動仕訳への理由コードの義務づけと裏づけの添付 |
| 分断されたシステム | ERP、調達、経費、請求、計画の各ツールがそれぞれ独自の仕入先や顧客の一覧を持っている | 仕入先の支出や顧客のエクスポージャーを一元的に見られない | データ項目ごとに正本システムを定め、システム間を同期する |
| 古い参照データ | 閉鎖された銀行口座、元顧客、廃止された品目が有効なまま残っている | 誤った支払、誤った与信判断、すべてのモデルへのノイズ | 定期的な見直しと無効化のルール |
レガシーシステムがAIへの準備を制約していると答えたCFOが86%というRGPの結果は、この状況と合致します(RGP)。レガシーERPが使い物にならないわけではありませんが、レコードの作成方法に対する統制が最も緩く、レコード自体も最も古い傾向があります。
前進するために、ERPを入れ替える必要はありません。多くのチームは、レコード作成時の検証を追加し、特定のユースケースが読む少数の項目にクリーンアップを絞ることで、大きく前進しています。
マスタデータ:仕入先、顧客、品目
マスタデータとは、取引が指し示すレコードの集合です。これが間違っていれば、それを参照するすべての取引も、モデルには見えない形で間違っています。

仕入先。 仕入先マスタは、買掛金の自動化、支出分析、不正対策の統制を支えます。典型的な不備は、重複、税IDの欠落、承認の記録がないまま1社に複数の銀行口座が登録されていること、親会社と子会社の関係が記録されていないこと(そのため、4つの法人を通じて1つのグループから購入していることが見えません)です。請求書を発注書と照合するAIツールは、整った仕入先リストではうまく働きますが、同じ仕入先がさまざまな表記で現れるリストではうまく働きません。
顧客。 顧客マスタは、債権回収、信用リスク、収益分析、キャッシュフロー予測を支えます。重複した顧客アカウント、請求先と配送先の混同、階層の欠落(そのためグループ全体のエクスポージャーが見えません)、CRMとERPで食い違う支払条件に注意してください。支払遅延を予測する債権回収モデルには、何年分もの履歴にわたる一貫した顧客の同一性が必要です。
品目と製品。 品目またはSKUのマスタデータは、在庫、原価計算、製品別の収益が対象に含まれる場合に最も重要になります。単位の不統一、重複したSKU、原価やカテゴリー項目の欠落は、在庫評価、利益率分析、需要予測を損ないます。
3つに共通するルール。 各レコードに、再利用しない恒久的なIDを1つ付与します。名称と住所は、文書化された形式に標準化します。レコードを誰がいつ作成または変更したかを記録します。履歴のあるレコードは削除せず、無効のステータスを残します。そして、新規の仕入先、顧客、品目を誰が承認するかを決めてください。承認者こそが、データ品質の本当の統制ポイントだからです。
モデルが読めるようにこのデータをウェアハウスやレイクハウスに移す予定がある場合、その連携面についてはデータパイプラインで扱っています。
財務AIのデータ準備状況チェックリスト
パイロットを承認する前に使ってください。行ごとに「準備完了」「一部」「未整備」のいずれかを記入します。自社のユースケースが依存する行で「未整備」が2つ以上ある場合は、先にデータを直し、パイロットはその後にしてください。

| 領域 | 答えるべき問い | 準備完了の状態 | 最も重要になる場面 |
|---|---|---|---|
| 勘定科目表の設計 | 勘定は項目の性質を表し、部門、地域、製品は別のディメンションで保持されているか | すべての勘定に責任者と定義がある、文書化された勘定科目表 | 分類、予測、報告 |
| 勘定の衛生管理 | 休眠、重複、包括的な勘定は廃止または管理されているか | 「その他」と「仮勘定」の残高を定期的にレビューし、解消している | 異常検知、決算 |
| マッピング | 現地または法人の勘定からグループ報告へのマッピングは、個人のワークブックではなく管理されたシステムにあるか | 変更履歴を伴うバージョン管理されたマッピング | 連結、グループ報告 |
| 仕入先マスタ | 法的な仕入先ごとに、税ID、承認済みの銀行情報、責任者を備えたレコードが1つあるか | 重複レポートを決まった周期でレビューし、新規仕入先を第二の担当者が承認している | AP自動化、不正チェック |
| 顧客マスタ | 顧客ごとに、階層とCRM・ERP間で一貫した条件を備えたレコードが1つあるか | 与信限度額、条件、親子関係がシステム間で一致している | 債権回収、キャッシュフロー予測 |
| 品目マスタ | 品目に一意のID、標準単位、カテゴリーと原価の項目が入力されているか | 項目ごとに欠損率を測定している | 在庫、利益率、需要 |
| 作成時の統制 | フォームで選択リスト、必須項目、重複チェックを強制しているか | 自由入力が説明欄に限られている | すべてのユースケース |
| 手動の仕訳 | 手動仕訳に理由コードと裏づけがあるか | 裏づけのない仕訳はブロックまたはフラグが立つ | 異常検知、説明文の下書き |
| 連携 | 1つのシステムでの変更が、再入力なしに他のシステムへ届くか | 失敗時にアラートが出る、文書化された同期 | システム横断のレポート |
| 履歴 | モデルの種類に対して、一貫した履歴が十分にあるか | 勘定と法人の構造が安定した数年分、または文書化された遡及修正 | 予測、予想 |
| アクセス | AIとその利用者が見られる範囲を、ロールと法人で制限できるか | AI層が尊重するロールベースのアクセス | すべてのユースケース |
| 責任体制 | パイロット後のデータ品質に責任を持つ人がいるか | 指名されたデータスチュワードと、定期的な品質レポート | すべてのユースケース |
すべてのパイロットがすべての行を必要とするわけではありません。承認済みの管理レポートから説明文を下書きするツールは、主に勘定科目表とマッピングの行が必要です。買掛金のツールは、仕入先マスタと作成時の統制に大きく依存します。キャッシュフロー予測には、顧客マスタ、履歴、連携が必要です。
うまくいく進め方
始める前に、数年がかりのデータプログラムは必要ありません。勢いを保てる進め方は次のとおりです。
- まず1つのユースケースを選びます。 AIユースケースの優先順位づけの基準で選び、そこで必要な項目とテーブルだけを洗い出します。
- そのユースケースのデータをプロファイリングします。 まさにその項目について、重複、空白、不整合な値を数えます。データへの漠然とした不満よりも、1ページ分の数字のほうが経営陣を早く動かします。最近のレコードのサンプルをレビューし、誤りのないものがいくつあるかを数えるというHBRの簡単な方法は、最初の確認として有効です(HBR)。
- 下流ではなく、発生源で直します。 ERPが不良レコードを作り続けているのにウェアハウス内のコピーだけをきれいにしても、来四半期にまた同じ作業をすることになります。フォームに検証を追加し、項目を必須にし、自由入力を選択リストに置き換えてください。
- 不備を生むプロセスを直します。 重複した仕入先は、たいてい検索の手順を飛ばした登録依頼から生まれます。勘定の乱立は、誰でも新しい勘定を依頼できることから生まれます。そうした箇所に承認の関門を設けてください。
- 定義を文書化します。 各勘定、ディメンション、主要なマスタデータ項目が何を意味するかを書き留めます。これは、アシスタントが参照できる資料にもなります。
- スチュワードシップを割り当てます。 財務内の1人が各主要データセットの責任を持ち、財務リーダーシップチームに毎月の品質レポートを提出します。
- 人によるチェックを入れてパイロットを行い、その後に広げます。 整ったデータの範囲でパイロットを実施し、ヒューマン・イン・ザ・ループで説明されているようにレビュー担当者を関与させ続けます。最初のユースケースが安定したら拡大します。
回答するだけでなく、たとえば仕訳の転記や支払の実行のように、実際に行動するエージェントを検討している場合は、データと権限のハードルが上がります。それについては財務向けAIエージェントで扱っています。
よくある落とし穴
- 先にツールを買い、パイロットでデータの問題を発見します。 ベンダーは整ったサンプルデータでデモを行います。本番稼働の最初の1週間は、デモのようにはいきません。
- 一度きりのクリーニングです。 スチュワードと定期的なチェックがなければ、新しい仕入先、組織再編、買収が積み重なり、品質は1年以内に劣化します。
- パイロットの途中で勘定科目表を再設計します。 モデルが履歴から学習している最中に構造が変わると、比較が成り立たなくなります。構造を凍結するか、先に履歴を遡及修正してください。
- AIの出力を元帳に結びつけず信頼します。 AIツールが出すすべての数字は、総勘定元帳または名前の挙がった元のレポートに照合できなければなりません。
- アクセスの問題を飛ばします。 財務データには、給与、銀行情報、未公表の業績が含まれるため、アシスタントが読める範囲はロールによって制限してください。
- マスタデータをITの仕事とみなします。 新規の仕入先や顧客の承認者が、毎日データ品質を左右しています。それを財務の責任にしてください。
Head of Finance Strategy