AIで経費データから仕訳候補を作る方法｜最終確認は人が行う

経費データから仕訳候補を作るAIは、登録を確定させる役ではなく、証憑・明細・過去処理をそろえて人の確認を助ける役として設計します。支払先名や摘要だけで勘定科目、税区分、事業用途を決めないでください。取引の実態や組織の会計方針が不明なら「要確認」とし、税務上の判断をAIのもっともらしい説明で置き換えません。

入力の正本と候補を分ける

候補生成に使う前に、銀行・カード明細、領収書、請求書、社内申請、過去仕訳を区別します。明細は支払の記録、証憑は取引内容の根拠、過去仕訳は参考例であり、同じ役割ではありません。

表は横にスクロールできます

項目	候補作成での使い方	確認点
取引日・支払先・金額	取引を特定	明細と証憑の金額・日付
摘要・利用目的	何の支出かを説明	私用と事業用の区別
領収書・請求書	内容・相手・税情報を確認	欠損、重複、対象取引
決済口座	支払経路を確認	立替や口座振替の区別
過去仕訳	同一条件の参考	方針変更・例外の可能性

過去に同じvendorを同じ科目へ登録した事実は参考ですが、vendor名だけで今回の取引を確定しません。継続契約、私用混在、返金、割引、複数明細の合算があると、同じ支払先でも扱いが異なる場合があります。

AI出力を候補にとどめる

出力schemaを「科目候補」「理由」「参照したfield」「不足情報」「要確認」に分けます。Confidenceを数値で出させても、会計判断の確実性や税務適合性が証明されたわけではありません。理由が原資料に結び付かない場合は候補を採用しません。

例として、会議施設の利用料から会議費候補が出る場合でも、実際の用途、参加者、社内方針を確認します。月額software subscriptionも、導入目的、契約期間、組織の科目規則を見ます。これらは一般的な検討例であり、特定取引の正しい仕訳を提示するものではありません。

freeeの機能とAI候補を区別する

freeeの「自動で経理」は同期した口座明細をもとに取引登録を支援し、自動登録ルールを設定できる機能です。freeeの公式ヘルプには、確認せずに自動登録まで任せる設定に関する説明もあります。AIが生成した候補と、会計softwareのruleによる自動登録は別の仕組みです。自動登録を有効にする場合、適用条件、対象口座、例外、登録後のreview手順を管理者が確認してください。この記事では会計softwareの自動機能を無条件に有効化する推奨はしません。

Review Matrix

表は横にスクロールできます

条件	AIの扱い	人が確認すること
摘要が具体的・証憑一致	候補を提示	科目ルールとの一致
支払先が初回	要確認を付ける	取引実態、用途
私用・事業用が混在	自動登録しない	按分根拠、社内方針
税区分・適格請求書が不明	候補を保留	証憑と適用基準
金額・日付が明細と不一致	候補を止める	原本、返金・分割
過去処理と異なる	例外として確認	方針変更か誤登録か

各組織で承認済みルールがある場合はそちらを優先します。高額取引などの閾値を独自に固定せず、権限表、締め処理、承認フローに合わせます。

AIを使う前の処理

1. 明細と証憑を取引IDで結び、欠損や重複を検出する。

2. 支払先、日付、金額、通貨、摘要を正規化し、元表記も保持する。

3. 個人情報や不要なbank/account情報を除いた最小fieldを用意する。

4. 会計方針、過去仕訳、例外ルールの対象範囲を指定する。

5. AIへ候補と根拠、不足情報を構造化して出力させる。

6. 証憑へ戻れない候補、相反する情報、税務判断を人へ回す。

7. 人の承認後に会計systemへ登録し、登録者・承認者・元資料を記録する。

AIへ元データを渡すときは契約、アクセス権、保存条件を確認します。全取引の明細を無条件に外部serviceへ送らず、必要な期間とfieldを限定してください。

監査と再処理

自動処理を採用する場合も、candidateと登録済みを区別できるlogが必要です。record ID、source document、AI出力version、担当者判断、freee等への登録ID、修正理由を保存します。同一取引を再処理したときは、既存登録との重複を照合します。誤仕訳が見つかった場合にAIが自動で修正登録するのではなく、会計担当者が訂正ルールと影響期間を判断します。

AIものさしの判断

価値が出るのは、AIへ勘定科目を決めさせることではなく、証憑との照合や候補の整理で人が確認する範囲を絞ることです。会計方針、事業用途、税区分、証憑要件が決められない取引は登録せず、会計担当者や税務専門家へ回してください。

候補生成の前に原本をそろえる

領収書画像、カード明細、申請フォーム、過去仕訳のどれを一次の取引証拠として扱うかを先に決めます。各値には「原本から読んだ値」「人が補正した値」「過去ruleから作った候補」を混在させず、sourceと更新者を記録します。画像のOCRが返す日付や金額は転記候補であり、支払先の名称や摘要を補うために別資料を参照したなら、その参照元も分かるようにします。

出力例と承認境界

表は横にスクロールできます

フィールド	候補	根拠	人の確認
account_title_candidate	消耗品費	購入品と用途の説明	組織の科目ruleと事業用途
tax_category_candidate	未確定	取引情報だけでは判断できない	証憑・適格性・適用条件
amount	原本読取値	レシート合計欄	数字、通貨、税込/税抜
review_status	needs_review	必須情報または判断が不足	会計担当が承認するまで登録しない

この例は仕訳の正解を示すものではありません。AIの出力には確定値と誤解される「勘定科目」だけでなく、candidate、根拠、欠損、要確認理由を付けます。回答形式を固定すると、判断の前提を監査しやすくなります。一方、LLMが返したJSONが形式上validでも、内容の正しさは保証しないため、型検証と業務上の確認を分けます。

freee側の自動登録設定を区別する

freeeの「自動で経理」には明細から取引登録へ進む機能があり、自動登録ruleの設定によっては確認を挟まず登録する動作もあります。これはAIが経費から仕訳候補を出す設計とは別の機能です。導入時は、対象口座、rule条件、自動登録の有無、既存の登録済み明細との重複を現在の画面と公式ヘルプで確かめてください。記事で示す人のreviewは慎重な運用設計の推奨であり、freeeの全設定が必ず承認待ちになるという意味ではありません。

例外を一般化しない

同じ店名でも、消耗品、会議、個人利用、返金など内容は変わります。過去に承認された一件だけで店名から科目を固定すると、別用途の取引で誤ります。候補ruleを更新する際は、該当する取引種別、金額帯、摘要、証憑、適用開始日を明らかにし、以前の処理へ遡及して適用するかは会計担当者が決めます。自動学習で例外を無条件に取り込む運用は避けます。

実務でのQA順

1. 原本から日付、支払先、金額を抽出し、各値にsourceを付ける。

2. 重複候補を口座・日付・金額・証憑で照合し、同額だけで除外しない。

3. 仕訳候補と理由、不足情報を並べて表示する。

4. 人が承認または修正し、承認者と時刻を残す。

5. freeeへ登録する前に、会計期間、税区分、証憑添付、登録済み状態を確認する。

6. 誤りが後日判明した場合は、対象期間と連携先を特定して訂正する。

大量の明細を扱う場合は、まず過去データの一部を匿名化して検証し、担当者が付けた正解との違いを分類します。「科目違い」「税区分違い」「証憑不足」「用途不明」のどこで誤るかを見てから、自動候補の範囲と要確認条件を調整してください。税務上の結論や必要な証憑は個別の事情で変わるため、記事だけで確定せず専門家へ相談する場面を残します。

段階導入と停止条件

いきなり全明細を処理せず、まずは取引種類と担当者が限られた範囲で候補だけを作ります。入力の欠損率、担当者が候補を修正した割合、要確認へ回った割合、登録後に訂正された割合を記録し、AIを使わない従来処理と比較します。候補が多くても、確認時間が減らなかったり誤分類が見逃されたりするなら、対象範囲を広げる理由にはなりません。

次の場合は自動登録へ進めず、候補作成の段階で止めます。原本と明細の金額が一致しない、取引先が新規または表記が不明、私用・事業用の区別がつかない、税区分に判断が必要、同一取引の重複可能性がある、証憑が不足している場合です。担当者が判断できないときは、税務・会計の専門家へ確認する経路を用意します。修正履歴は次回の候補改善に使えても、確認者の承認なしに既存取引へ一括適用しません。

読者が持ち帰る実行順

最初に社内の科目・税区分ruleと証憑要件を確認し、次に明細と原本を同じ取引として結び付けます。その後、候補、理由、不足情報を人へ提示し、承認・修正・差戻しの状態を記録します。AIの出力をfreeeへ入れる連携を組む場合でも、登録の前に既存ruleの自動登録設定を確認し、候補作成と取引登録の境界を明示してください。これならAIの役割は手作業の整理補助に留まり、会計上の最終判断を誰が行ったかを追跡できます。