会計ソフトの仕訳登録は、どこまで自動化できるのか

銀行口座やクレジットカードの明細を会計ソフトに取り込むと、まだ仕訳になっていない明細が並びます。仕訳とは、ひとつの取引を借方と貸方に分け、それぞれの勘定科目（取引の内容に付ける分類のラベル）を決めて帳簿に記録することです。毎月の顔ぶれはほとんど同じで、一件ごとの判断もほとんど変わりません。それでも一件ずつ選んで登録する以上、件数のぶんだけ時間は必ず掛かります。

この作業をAIに任せたい気持ちがあっても、会計データは間違えると決算や申告に響きます。試しに動かして壊すわけにいきません。任せてよい範囲を測る基準が手元にないと、全部任せるか全部手でやるかの二択に見えます。実際には、任せてよい明細と人が見るべき明細は性質がはっきり違います。

自社の会計データで、その線引きを決めた記録がこの記事です。土台にしたのはマネーフォワード クラウド会計の外部連携機能で、会計ソフトの外側から仕訳を登録できることはベンダーが公式に案内しています[1]。要点は次の3つです。

• 取引の摘要は極端に偏るので、大半は固定のルールで決まります
• 判断が要るものだけを人に回し、確信の高いものだけを自動で登録します
• 誤って登録すると元に戻せないので、迷ったら登録しない側に倒します

取引の大半は決まりきった相手との繰り返しです

取り込んだ明細には摘要が付きます。摘要は取引の内容を示す短い文字列で、銀行やカード会社が付けた店名や振込先の名義が入ります。過去の仕訳帳を摘要ごとに集計すると、分布は極端に偏っていました。上位のごく一部の摘要だけで全体の8割を超え、残りが長い裾を作ります。同じ摘要には、同じ勘定科目と同じ税区分が繰り返し使われていました。

この偏りが設計方針を決めました。8割を占める部分は摘要が一致した時点で答えが決まるので、毎月AIに考えさせる価値はありません。AIが要るのは残りの裾、つまり前例の乏しい取引だけです。

自動で登録するもの、人が確認するものを分けます

未仕訳の明細を全件同じ扱いにすると、確実なものまで人が目を通し、危ういものが確実なものに紛れます。そこで、勘定科目を過去の実績だけで一意に決められるかどうかを基準に、明細を4つの区分に分けました。

区分	条件	誰がどうする
自動登録	下の3条件をすべて満たす	人手を挟まず登録する
人が承認	表記を揃える処理で一致した	提案を画面で確認して登録する
社内で判断	前例が乏しく、税務の判断は要らない	担当者が勘定科目を決める
税理士に確認	税区分が揺れている、仕訳先が内訳で変わる	回答を待ってから登録する

どの区分に置けるかは、過去の帳簿がその明細について何を語れるかで決まります。自動登録の3条件は、どれか一つ欠けても推測が混ざります。

• 完全一致：摘要が過去のものと文字どおり同じ
• 実績の厚み：同じ摘要での登録が繰り返し積まれている
• 税区分の収束：その摘要の税区分が一つに定まっている

税区分は消費税の扱いを示す分類で、税率のほか課税・非課税・不課税などで分かれます。同じ相手への支払いでも用途で変わるため、揺れている摘要は自動登録から外しました。カード会社が書く店名も相手が同じで時期によって変わるので、揃える処理での一致は推測を含みます。実績が積まれた時点で自動登録に上げます。

税理士に回す取引は、総額が明細から分かっても割り振り先が帳簿の外で決まります。

登録の経路は会計ソフトの外部連携機能です[2]。仕様の一部が公開されておらず、実際に呼び出して確かめました。要求した権限の一部が黙って落とされる挙動もありました。公開情報のない外部連携の調べ方と、権限まわりの切り分けは ドキュメントに載っていないAPIの仕様は、どう調べるのか で説明しています。

誤登録は元に戻せないので、基準は保守側に倒します

間違いには2種類あり、是正の重さは対称ではありません。判定の厳しさはそこから逆算しました。

登録すべきものを見送っても、人がレポートで承認するだけで済みます。逆に登録すべきでないものを登録すると、仕訳を削除しても元の明細は未処理には戻りません。「対象外」に落ちて外部連携からの再登録は拒否され、是正は画面での手作業になります。

既定は「迷ったら登録しない」に置きました。条件を厳しくすると人が見る明細は増えますが、増えるのは安いほうの手間です。取り消せない操作を含む処理の組み立て方と、そこにAIの判断をどこまで入れてよいかの線引きは 取り消せない操作を含む処理は、どう自動化するのか で説明しています。

確定した判断はファイルに残して次回に効かせます

人が一度判断しても、記録しなければ翌月に同じ質問が戻ってきます。そこで判断の結果を1つのファイルに追記し、次回以降に効かせます。

各項目には、システムが提案しただけの状態と、人が承認した状態があり、判定に効くのは承認されたものだけです。判断ごとに、決めた日付と科目を選んだ理由を併せて書きます。訂正や削除の履歴が残る仕組みは、国税庁が「優良な電子帳簿」の要件の一つに挙げています[3]。

材料にする過去の仕訳は、厚いほど一致する明細が増えます。複数年度ぶんを投入すると一致率は上がり、同時に回帰が起きました。ある支払先の購入が、古い年度では別の科目で記帳されていたためです。完全一致を最優先にすると、古い表記に一致した明細が古い科目へ振り替わります。止めたのは、直近の年度に出現しない摘要を材料から外すガードと、一致の厳密さより実績の新しさを優先する並べ替えです。記帳の方針は年度をまたいで変わるので、履歴は多いほど良いとは限りません。

自動化の前に、帳簿そのものを確認します

自動化の仕組みは過去の帳簿を正しいものとして扱うので、誤りがあれば毎月そのまま拡大再生産します。ルールを作るために過去の仕訳を集計したところ、自動化とは無関係の記帳の欠陥が見つかりました。見つかった欠陥と原因は 経理を自動化しようとすると、なぜ先に帳簿の誤りが出てくるのか で説明しています。

残ったのは、毎回相手が変わる取引と税理士に聞く取引だけでした

手作業が残ること自体は失敗ではなく、残るべきものが残った状態です。明細の大半は自動または半自動で処理でき、残った手作業は2種類です。自社の口座間の振替は、振替先が毎回変わるため摘要から仕訳先が決まりません。もう1つは税理士に確認するものです。

まとめ

• 明細は自動登録・人が承認・社内で判断・税理士に確認の4区分に分けて扱う
• 誤登録は元に戻せないので、迷ったら登録しない側に倒す
• 承認された判断をファイルに残すと、自動化の範囲は回を追って広がる

どこまでを機械に任せ、どこから人が確認するかの線引きが、業務自動化の設計の中心になります。TARVOでは、こうした設計と実装を受託で承っています。詳しくは AI受託開発 をご覧ください。