請求書の自動仕訳で任せられる範囲の早見表
請求書の自動仕訳とは、受け取った請求書から勘定科目・税区分・部門・計上月を決めて仕訳データを作る工程を指します。全件を機械が確定させる話ではありません。科目が一意に決まる請求と、経理が例外として見る請求を先に分け、前者だけを自動で通す形が実務では扱いやすくなります。分け方の目安を先に置きます。
| 請求の型 | 自動仕訳で任せられるか | 分かれ目になる条件 |
|---|---|---|
| 家賃、通信費、リース料のように取引先で科目が決まる | 確定まで任せられる | 取引先マスタに既定の科目を登録してあるか |
| ソフトウェアの月額利用料のように品目で科目が決まる | 確定まで任せられる | 品目と科目の対応表にあり、表記のゆれを吸収できるか |
| 毎月同じ内容が続く継続的な取引 | 確定まで任せられる | 直近の計上が同じ科目に揃っているか |
| 同じ取引先から性質の違う請求が混じる | 候補の提示まで | 明細の品目まで見ないと科目が割れる |
| 対応表に無い品目、初めての取引先からの請求 | 候補の提示まで | 科目の初回登録と振込先の確認が要る |
| 資産計上か費用かの境目にある金額 | 人が決める | 社内の基準額と、少額資産の特例を使うかの判断 |
| 複数の部門やプロジェクトにまたがる費用 | 人が決める | 按分の割合を何を根拠に置くか |
| 立替金、海外取引、非課税や不課税が混じる | 人が決める | 税区分の扱いが自社の会計処理の方針で変わる |
上の3行は、判定の材料が社内のデータに揃っている取引です。ここは人の確認を挟まずに確定まで通せます。中の2行は、機械が候補と根拠を出し、人が選ぶ形にします。下の3行は、会計処理の方針や税務の判断に関わるため、機械が確定させると後から仕訳を直す作業が増えます。
どの型が件数のどれくらいを占めるかは会社によって違うため、割合は自社の過去の仕訳を数えて確かめます。この早見表だけで自動化の範囲は決められますが、以降では線引きの根拠と、支払データや会計システム連携をどう組むかを順に見ていきます。
読み取りが終わった後に残る決めごと
請求書から金額や期日を取り出せるようになっても、支払と仕訳が自動で決まるわけではありません。抽出は請求書に書いてあることを取り出す作業です。その後に続くのは、書いていないことを自社側の情報から決める作業になります。経理の現場で自動仕訳と呼ばれるのは、たいていこの後ろ側を指します。
決めることは3つあります。いつ誰にいくら払うか（支払）、どの勘定科目と税区分で計上するか（仕訳）、どの月の数字として載せるか（計上日）です。いずれも請求書だけを見ても決まりません。取引先マスタ、科目の対応表、過去に同じ取引をどう処理したかの記録、契約や発注の条件、そして自社の支払サイトを突き合わせて初めて確定します。
この違いは、精度の上げ方にも表れます。読み取りの精度は書式のばらつきに左右されますが、支払と仕訳の精度は社内のマスタがどれだけ整っているかに左右されます。読み取り側の設計は 請求書処理の自動化をAIで進める で扱っているので、ここでは抽出が済んだ状態から先を見ていきます。
勘定科目を機械的に決められる範囲
勘定科目の判定を「AIが文脈を読んで決める」ものとして考えると、範囲が曖昧になります。実際には、材料ごとに決まる条件がはっきり分かれます。
| 判定の材料 | 機械で決められる条件 | 決まらないときの扱い |
|---|---|---|
| 取引先 | その取引先からの請求が1つの科目にしか対応しない（家賃、通信、リース料など） | 同じ取引先から性質の違う請求が混じる場合は人へ |
| 明細の品目名 | 品目と科目の対応表に登録済みで、表記のゆれを吸収できる | 表に無い品目は候補を示して人が選ぶ |
| 過去の仕訳 | 同じ取引先と品目の組み合わせで、直近の計上が同じ科目に揃っている | 過去の科目が割れている場合は人へ |
| 金額 | 資産計上か費用かの社内基準を明確に下回る | 基準額の前後、少額資産の特例を使うかの判断は人へ |
| 部門・プロジェクト | 契約や配賦のルールで割り当て先が一意に決まる | 複数部門にまたがる按分は人へ |
| 税区分 | 税率ごとの内訳と登録番号が記載され、標準的な課税取引に当てはまる | 立替金、海外取引、非課税・不課税が混じる場合は人へ |
取引先で決まる取引が、最初に自動化できる範囲です。家賃、通信費、サブスクリプションの利用料のように、その取引先から届く請求が毎回同じ科目になるものは、取引先マスタに既定の科目を持たせるだけで判定が済みます。ここは判定というより登録の話で、AIを使う必要すらありません。
明細の品目で決まる取引は、対応表を作れるかどうかで分かれます。品目名の表記がぶれる場合は、ぶれを吸収する処理が要ります。同じサービスが「月額利用料」「ライセンス料」「基本料金」と書かれても同じ科目に寄せる、という判断です。この寄せ方は、意味が近い表現をまとめる処理が向いています。
過去の仕訳で決まる取引は、実務でいちばん効きます。同じ取引先と品目の組み合わせで前回どう計上したかを引いて、直近の計上が揃っていればそれを踏襲します。揃っていない場合は、揃っていないこと自体が人へ回す理由になります。
決められないものを無理に決めないことも設計です。資産計上か費用かの線引き、部門をまたぐ費用の按分、立替金や海外取引の税区分は、自社の会計処理の方針や税務の判断に関わります。ここを機械が確定させると、後から仕訳を直す作業が増えます。
税区分の判定でどこまでを機械に任せるか
科目と並んで仕訳を確定させる材料が税区分です。科目が社内のマスタから決まるのに対し、税区分は請求書の記載そのものが判断材料になります。税率ごとの内訳が分けて書かれているか、登録番号が記載されているか、税額が記載の合計と合うかは、読み取った値を突き合わせれば点検できます。
点検の結果をどう扱うかは、自社の会計処理の方針に依存します。登録番号の記載が無い請求書を取引先へ差し戻すのか、免税事業者からの仕入として経過措置を適用したうえで計上するのかは、取引先との関係と社内で決めた運用によって変わります。機械が持つのは記載の点検と、方針から外れた請求書を経理へ回すところまでで、控除の可否を確定させる判断は人の側に残します。この工程の組み立ては インボイス制度に対応した請求書チェックをAIで自動化する で扱っています。
判定はマスタ、ルール、AIの順に置く
判定をひとつのモデルにまとめて任せると、なぜその科目になったかを説明できなくなります。順番を付けます。
- 取引先マスタの既定科目 … 一意に決まる取引をここで抜く
- 品目と科目の対応表 … 登録済みの品目をここで抜く
- 過去の仕訳の照合 … 同じ組み合わせの直近の計上を引いて踏襲する
- AIによる候補の提示 … 1〜3で決まらなかったものだけを対象にする
AIが担うのは4だけです。ここでの出力は、科目を確定させることではなく、候補と根拠を並べることになります。根拠とは、参照した過去の仕訳、明細のどの文言を手がかりにしたか、他にどの科目が候補になったかです。人が確認する画面には、この根拠が見えている必要があります。根拠が無いまま科目だけが提示されると、確認する人は結局ゼロから判断することになり、確認の負担が減りません。
自動で確定してよい条件は、確信度の数値だけで切らないほうが扱いやすくなります。モデルが返す数値は取引の種類ごとに意味が変わるためです。代わりに、候補が1つに絞れていること、過去の計上と一致していること、金額が定めた上限の範囲内であることを条件にすると、なぜ自動で通ったかを後から説明できます。
支払データを作るところで詰まる条件
仕訳と並行して、支払データも組み立てます。請求書に書かれた支払期日をそのまま使えば済む、という前提は実務では崩れます。
- 自社の支払サイトと請求書記載の期日が食い違う。 どちらを優先するかを取引先ごとに持たせないと、期日が混ざります
- 金融機関の休業日にあたる。 前倒しか後ろ倒しかを社内で決めておきます
- 支払方法が分かれる。 振込、口座振替、カード決済で、そもそも支払データを作る必要があるかが変わります
- 同じ取引先の複数の請求をまとめる。 締め単位でまとめるのか、請求書ごとに振り込むのかで振込手数料の扱いも変わります
- 振込手数料の負担が取引先ごとに違う。 差し引いて振り込む取り決めがある場合、差額が未消込として残ります
支払と仕訳を1本の流れとして作ると、どちらかの都合でもう一方が止まります。期日の判断が付かない請求書が、仕訳の登録まで止めてしまう形です。同じ請求データから分岐させ、承認の場所だけを共通にすると、この止まり方を避けられます。
会計システム連携の渡し方と、二重計上への備え
渡し方は会計システム側が用意している口で決まります。設計を始める前に確認しておく項目です。
| 渡し方 | 向いている条件 | 気をつけること |
|---|---|---|
| インポート形式のファイル | 会計側に接続の口が無い、月次でまとめて登録する運用 | 取込の前後で件数と合計金額を照合する。取込済みの印を元データ側に持たせる |
| 接続の口を使った登録 | 提供されていて、承認のたびに反映したい | 通信が途中で失敗したときに同じ登録が二度走らないよう、こちら側で発行したキーを付ける |
| 連携用のデータを挟む | 会計システムを入れ替える可能性がある、支払と会計で渡し先が分かれる | 挟んだ場所で止まっているデータを誰が見るかを決めておく |
連携の前に会計システム側へ確認しておく項目
渡し方を決めても、会計システムが受け取れる形と自動化する側が作る形が食い違うと、取込のたびに手直しが残ります。着手前に確認しておくと設計が変わらずに済む項目です。
| 確認する項目 | 何を見るか | 食い違ったときに起きること |
|---|---|---|
| 仕訳の項目 | 補助科目、部門、プロジェクト、税区分のコードをどの粒度で持てるか | 判定した情報が渡らず、会計側で入れ直しになる |
| 取込の単位 | 伝票単位か明細単位か、1伝票に載せられる明細の数に上限があるか | 明細の多い請求書が分割され、請求書と仕訳の対応が追えなくなる |
| 締めの状態 | 締め済みの月かどうかを外から読めるか、締め後の登録が拒否されるか | 確定した月へ登録が入り、報告済みの数字が動く |
| 重複の判定 | 取込側で重複を弾く仕組みがあるか、そのキーに何を使えるか | 同じ仕訳が二重に登録される |
| 取消の登録 | 取り消しの仕訳を同じ経路で登録できるか | 修正だけ手作業に戻る |
| エラーの返り方 | 1件でも不備があると全件が戻るのか、不備の行だけ落ちるのか | 一部だけ登録された状態に気付けない |
このうち締めの状態と取消の登録は、後から足そうとすると連携の作り直しになります。取込のエラーがどう返るかも先に見ておきます。行単位で落ちる仕様なら、落ちた行を拾い直す入れ物が要ります。
二重計上が起きる3つの経路
二重計上は、経路が3つあります。同じ請求書が2回届く場合、取り込み処理を再実行する場合、そして支払側と会計側の両方で仕訳が立つ場合です。
1つ目は、請求書番号と取引先と金額の組み合わせを一意のキーとして持ち、登録済みのものを弾きます。取引先によっては請求書番号が振られていないことがあるため、その場合は請求期間と金額を含めたキーに切り替えます。
2つ目は、取り込みを何度実行しても結果が変わらない作りにします。同じキーのデータが既にあれば、無視するか上書きするかをあらかじめ決めておきます。ここを決めずに再実行できる仕組みだけ用意すると、締めの直前に件数が合わなくなります。
3つ目は、計上のタイミングと支払の消込を分けることで避けます。請求を受け取った時点で費用と未払を立て、支払を実行した時点で未払を消す形です。支払データの生成と会計への登録を別々の仕組みで動かす場合、どちらが仕訳を立てるのかを片方に寄せます。
締めた後の修正への備え
自動化した後で問題になりやすいのが、確定した月の数字を後から書き換えてしまう動きです。取り込みの再実行や、遅れて届いた訂正請求書の反映が、締めた月の残高を動かすと、報告済みの数字と合わなくなります。
確定した期間には触らないという前提を、連携する側に持たせます。具体的には、会計側が持つ締めの状態を読み取り、締め済みの月に該当する仕訳は自動で反映せず、人の確認へ回します。反映が必要な場合は、当月で取り消しの仕訳を立てて計上し直す形にします。
そのために、自動化する側は2つの機能を持っておきます。1つは、生成した仕訳に対する取り消しの仕訳を作れること。もう1つは、どの請求書がどの仕訳になったかを追えることです。後者が無いと、修正のたびに元の請求書を探すところから始まります。
訂正請求書や値引きが遅れて届いたとき
締めた後に届く書類は、扱いが分かれます。金額の誤りを直した請求書が送られてきた場合は、元の請求書と同じものの差し替えなのか、別の請求書として起票するものなのかを先に判別します。判別に使えるのは、請求書番号、請求期間、取引先の3つです。差し替えだと分かれば元の仕訳に紐づけ、当月で取り消して立て直します。
返品や値引きのように、後から金額が減る取引は、元の請求とは別の書類として届きます。売手側が返還の書類を出す扱いになるものもあるため、どの書類をもって減額を計上するかは取引先との取り決めと自社の方針で決めます。自動化する側では、減額の書類を元の請求書と支払に結び付けられる状態にしておきます。既に支払を実行した後の減額は、次回の支払から差し引くのか、返金を受けるのかで消込の相手が変わります。
いずれの場合も、判別が付かないものは自動で処理しません。取引先も金額も近い書類が2通ある状態は、二重計上と計上漏れのどちらにも転びます。
訂正や削除の履歴をどう残すかは、保存の要件とも関わります。制度側の要求は 電子帳簿保存法に対応した請求書処理の自動化 で扱っています。
承認と証跡をどう残すか
支払と計上は、後から「なぜこの処理になったか」を説明できる状態にしておく必要があります。自動化の範囲を広げるほど、人が目で見ていない処理が増えるため、記録の設計が重要になります。
残す対象は4つに整理できます。入力（受け取った請求書の原本と抽出した値）、判定（どのルールまたはモデルが、何を根拠に、いつ判定したか）、人の操作（変更前と変更後の値、承認した人、時刻）、出力（どの支払データとどの仕訳になったか）です。この4つが同じIDでつながっていれば、1件の請求書について経路をたどれます。
承認は段階を分けます。全件を1人が承認する形は、件数が増えると形式的な承認になります。金額の上限、例外の種類、取引先の新規登録の有無で分岐させ、通常の取引は担当者の承認だけで通し、上限を超えるものと新規の振込先だけを上位の承認に回す形が扱いやすくなります。
承認をどこで行うかも決めます。会計システムのワークフロー機能を使うか、普段使っているチャットの上で承認するかで、証跡が残る場所が変わります。チャット上で承認する場合は、承認の結果を処理側へ確実に戻す仕組みが要ります。承認をチャットで受ける設計の例は 契約書レビューをAIで行う でも扱っています。
どこから自動化に回すか
一度に全工程を置き換えると、締めの時期に問題が出たときの戻し先が無くなります。段階を分けます。
| 段階 | 自動で行うこと | 人が持つこと |
|---|---|---|
| 1 | 仕訳の下書きを生成し、根拠を添えて提示する | 全件を確認して登録する |
| 2 | 条件を満たした仕訳を自動で確定する | 条件を外れたものと、上限額を超えるものを承認する |
| 3 | 支払データを組み立てて期日ごとにまとめる | 支払実行の承認と、振込先の確認 |
| 4 | 会計システムへの登録を自動で実行する | 締め処理と、例外の処理 |
段階を上げてよいかの判断は、記録から決めます。段階1を締め1回分続ければ、科目の修正がどの取引先とどの品目に集中しているかが分かります。修正がほとんど発生しなかった範囲から、段階2の条件に組み入れます。
測る対象は3つです。項目別の修正率（科目、税区分、部門のどれが直されたか）、人へ回った件数の割合、締めから支払実行までにかかる日数です。最後の1つは、自動化の効果が業務側の数字として出る場所になります。効果をどう測って投資判断につなげるかは AI導入の効果測定と投資判断 で扱っています。
着手する前に用意しておくものは、取引先マスタと既定科目の対応、品目と科目の対応表、過去の仕訳データ、会計システムが用意している受け取り口の仕様、支払サイトと承認の権限、そして運用を直し続ける担当です。特に最初の3つが整理されていないと、判定の材料が無い状態で精度の議論だけが続きます。開発全体の進め方と見積の考え方は AIエージェント開発の進め方 を参照してください。
まとめ：請求書の自動仕訳と支払を設計するときの要点
- 抽出が終わっても、支払期日、勘定科目と税区分、計上月は自社側の情報を突き合わせて決める必要がある
- 勘定科目は、取引先で一意に決まるもの、品目の対応表で決まるもの、過去の仕訳を踏襲できるものから自動化する。資産か費用かの線引き、按分、例外的な税区分は人が持つ
- 税区分は、税率ごとの内訳と登録番号の記載、税額の検算までを機械で点検し、控除の可否を確定させる判断は人が持つ
- 判定はマスタ、対応表、過去の仕訳、AIの順に置く。AIは候補と根拠を出す役に限り、確信度の数値だけで自動確定の条件を切らない
- 支払データは、支払サイト、休業日、支払方法、まとめ方、振込手数料の負担で決まる。仕訳と分岐させ、承認の場所だけを共通にする
- 二重計上は、同じ請求書の重複、取り込みの再実行、支払側と会計側の両方での起票という3経路で起きる。一意キーと再実行しても結果が変わらない作りで防ぐ
- 会計システム連携は、仕訳の項目、取込の単位、締めの状態、重複の判定、取消の登録、エラーの返り方を先に確認する。締めの状態と取消は後から足すと作り直しになる
- 締めた月には遡らず、当月で取り消して立て直す。取り消しの仕訳を作れることと、請求書と仕訳の対応をたどれることを持たせる
- 遅れて届いた訂正請求書は、差し替えか別起票かを請求書番号・請求期間・取引先で判別する。判別が付かないものと、支払後の減額は自動で処理しない
- 入力、判定、人の操作、出力を同じIDでつなぎ、承認は金額と例外の種類で段階を分ける
Augueでは、請求書の読み取りから勘定科目の判定、会計システムへの連携までを含めたAIエージェントの開発に対応しており、どの工程を自動で通しどこに承認を残すかの線引きから一緒に設計できます。自社の経理業務のどこまでを自動化に回せるか整理したい方は、是非ご相談ください。
関連する記事
前工程にあたる請求書の取込は 発行元ごとに書式が違う請求書をAIで取り込む、適格請求書の要件確認は インボイス制度に対応した請求書チェックをAIで自動化する、保存要件との関係は 電子帳簿保存法に対応した請求書処理の自動化、開発の進め方と見積の考え方は AIエージェント開発の進め方 を参照してください。
よくある質問
会計ソフトに付いている自動仕訳の機能とは何が違いますか？
会計ソフトの自動仕訳は、銀行明細やカード明細のように会計側へ既に取り込まれたデータを対象に、摘要の文字列と過去の登録内容から科目を当てる仕組みが中心です。請求書を起点に組む場合は、その手前にある明細の品目や契約の情報まで材料に使えます。既存の機能で当たる範囲は残し、当たらない取引だけを自前の判定に回す構成にすると、作る範囲を小さく保てます。
税理士や会計事務所に記帳を任せている場合でも自動化する意味はありますか？
記帳を外部に任せていても、請求書を集めて内容を確かめ、支払を実行する工程は社内に残ります。自動化の対象はその部分になり、外部へ渡す資料の形をそろえる効果も出ます。どこまでを社内で判定し、どこから先を事務所側の確認に委ねるかは、契約している業務範囲に沿って決めてください。
見積を依頼する前に、社内で測っておくとよい数字は何ですか？
月あたりの請求件数と、そのうち勘定科目が一意に決まらない取引の割合、締めてから支払を実行するまでに要している日数の3つです。規模を左右するのは会計システムが持つ受け取り口の種類と、取引先マスタや科目の対応表がどこまで整理されているかなので、この2点の現状も合わせて伝えると話が早くなります。
判定の精度はどれくらい出ますか？
取引の内容によって差が大きく、一律の数字は示せません。判断材料になるのは、締め1回分の仕訳を下書きとして生成し、人がどの項目をどれだけ直したかを項目別に記録した結果です。全体の一致率よりも、科目が割れやすい取引先と品目がどこに集中しているかを見たほうが、自動で通してよい範囲を決めやすくなります。
インボイス制度の登録番号の確認まで自動化できますか？
登録番号が請求書に記載されているかの確認と、桁数や形式の点検は機械で行えます。番号が有効かどうかは国税庁が提供する公表サイトや外部サービスへの照会で確かめる形になりますが、照会結果をどう扱うか、控除の可否をどの時点で確定するかは自社の会計処理の方針に依存するため、判定そのものは人が持つ範囲として設計してください。