立替精算まで自動化して分かった台帳設計5点｜領収書のその後
PR・アフィリエイトについて
当サイトはアフィリエイトプログラムを利用しており、紹介リンク経由での申込により報酬を得る場合があります。記事内で紹介するサービスには筆者が実際に使用しているものと、客観情報として比較掲載しているもの（未使用・PR表記あり）が含まれます。
領収書をスマホで撮って、AIに読ませて、スプレッドシートに1行入れる。ここまでは、いまのAIならかなり短い手数で作れます（筆者の場合は既存の下地があったこともあり半日ほどでしたが、環境や慣れで差は出ます）。実際、レシートのAI-OCR自動仕訳や領収書PDFの自動処理で書いたとおり、読み取り自体はもう難所ではありません。
詰まるのはその先です。
結論
経費の自動化が実務で止まる原因は、読み取り精度ではなく台帳の設計です。「金額をいくらで読めたか」より、誰が立て替えたのか／どの事業の経費なのか／返したのかが入っていない台帳は、月末に必ず人手でやり直しになります。ここを最初から持たせるかどうかで、続くか続かないかが分かれます。
この記事は、実際に自分で作って毎日動かしている経費台帳の構成をそのまま書いています。撮った写真をチャットに送ると、AIが読み取って台帳に1行入り、画像は月別フォルダに保存されてリンクが貼られる、という形です。手順の紹介というより、運用してから追加せざるを得なくなった項目の記録です。
読み取りだけ作ると、月末にこうなる#
最初に作ったものは、素直に「日付・店名・金額・勘定科目」の4項目でした。動きます。1行ずつ増えます。それで満足していたのですが、月末に集計しようとして手が止まりました。
| 月末にやりたいこと | 4項目の台帳でできるか |
|---|---|
| 今月いくら使ったか | できる |
| 科目別の内訳 | できる |
| 誰にいくら返せばいいか | できない（誰が払ったか無い） |
| どの事業の経費か | できない（レシートに書いていない） |
| もう返した分はどれか | できない（返済を記録する場所が無い） |
下3つが全部できません。そして経費精算で本当に必要なのは、たいてい下3つのほうです。合計金額は会計ソフトを見れば出ますが、「田中さんにまだ返していない額」は台帳にしか無い情報です。
結果として何が起きるか。月末に写真フォルダを見返して、「これは誰が払ったんだっけ」を思い出す作業が発生します。自動化したはずの作業が、形を変えて戻ってきます。
設計1：立替者は「必須項目」にする（推測させない）#
最初に足したのが立替者の列です。ここには2つの分かれ道があります。
AIに推測させるか、送信者から取るか。
レシートに立替者は書いてありません。書いてあるのはクレジットカードの下4桁くらいです。だからAIに推測させると必ず外します。採用したのは「チャットに写真を送った人＝立て替えた人」を既定にする方式です。送信者の表示名をそのまま入れます。
- 別の人が払った場合だけ、写真と一緒に「立替 山田」と書けば上書きされる
- 会社のカードや口座から直接払った回は「会社払い」と書けば、立替なしとして記帳され精算対象から外れる
- 何も分からなかった行は空欄ではなく「未設定」を入れて、シート上で赤く塗る
最後のが効きます。空欄は見逃しますが、赤いセルは月末に必ず目に入ります。自動化の設計として、判定できなかったものを黙って通すのが一番まずい。メールのAI仕分けでも同じ結論になりましたが、捨てるより赤くするほうが常に安全です。
名寄せが無いと精算が合わない#
これは運用してから気づきました。同じ人がチャットの表示名を変えたり、ニックネームと本名が混ざったりすると、同じ人が2人分に割れます。合計は合っているのに、誰への残高も正しくない、という状態になります。
対策は素朴で、別名→正式名の対応表を1枚持ち、記帳の前に必ず通すだけです。新しい別名が出てきたら「同一人物 ○○ △△」と登録すると、過去の行にも遡って適用されるようにしてあります。遡らないと、登録前の行が古い名前のまま残って残高が割れ続けます。
設計2：残高は「累計」ではなく「まだ返していない額」#
ここが台帳の中で一番設計を変えた場所です。
立替の集計というと、つい「今月いくら立て替えたか」を出したくなります。ですが精算の場で必要なのはまだ返していない額です。この2つは違います。
定義
残高 ＝ 立替累計 − 精算済み
「精算済み」を記録できる列が無いと、この引き算ができません。返しても台帳の数字が減らないので、翌月には累計だけが積み上がっていきます。
なので、明細に精算列を1つ足しています。空欄なら未精算、日付が入っていれば返済済み（その行は緑になる）。返したら「精算 ○○」、月を指定して「精算 ○○ 2026-08」、行を指定して「精算 3,5」で入ります。
そして、取り消せるようにしてあります。 「精算取消 ○○」で精算列を空に戻すだけ、つまり完全に可逆です。ここは意図的にそうしました。自動化で怖いのは、間違えたときに戻せない操作です。金額に触る操作ほど、元に戻す道を先に作っておくべきです。
もうひとつ決めごとがあります。過去の行を勝手に精算済みにしない。 「たぶんもう返しただろう」で埋めると、残高が実際より小さくなります。返したかどうかは台帳に書かれていない情報なので、AIにも自分にも推測させません。
設計3：「どの事業の経費か」を明細の時点で持たせる#
1つの会社の中に複数の事業があると、会社全体の合計だけでは事業ごとの採算が見えません。カフェの経費とイベント受託の経費が混ざったまま月次を締めても、どちらが赤字なのか分かりません。
そこで明細に「事業」の列を足しました。ここでも同じ問題にぶつかります。レシートに事業は書いていない。
決め方は3段階にしています。
- キャプションから拾う — 写真と一緒に「事業 ○○」でも「○○の分です」でも書いてあれば検出する
- 店名の記憶から引く — 過去に人が「この店はこの事業」と決めた実績があれば、それを再利用する
- どちらも無ければ未設定（赤くして人に聞く）
2番目は「AIの推測」ではありません。前に人間が決めた事実の再利用です。だから勝手な決めつけにはならない、と整理しています。「修正 事業 ○○」で直した時点で店名を覚え、同じ店の次のレシートから自動で入ります。
ただし「どこでも使う店」は覚えてはいけない#
これは実際に踏んだ罠です。100円ショップ・コンビニ・量販店・ホームセンター・ガソリンスタンドは学習対象から外しています。
理由は単純で、どの事業でも使う店だからです。一度「A事業」で覚えてしまうと、次にB事業のためにそこで買った分まで自動でA事業に入ります。しかも自動で入るので気づかない。合計は合っているのに事業別の数字だけが静かに狂う、一番たちの悪い壊れ方をします。
汎用的な店のリストを1つ持っておいて、そこに当たったら記憶しない。それだけで防げます。
設計4：二重計上は「警告する」で止める（自動で消さない）#
同じレシートを2回送ってしまうのは日常的に起きます。あとから思い出して送り直したり、複数人が同じ紙を撮ったりします。
対策として、記帳の前に「日付＋店名＋金額」が一致する行を探して、あれば「○行目と同じでは」と警告を出します。
ただし自動では消しません。 同じ店で同じ金額の別のレシートは普通にあり得るからです（同じ弁当を2日連続で買えば一致します）。警告だけ出して、消すかどうかは人が「取消 ○行」で決める。
この「検知はAI、削除は人」の分け方は、メールのAI仕分けで送信だけ人が押すのと同じ考え方です。取り消せる行為は全部渡し、取り消せない行為だけ人が押す。 経費台帳では、行の削除がそれに当たります。
なお、行を消しても保存した画像は消しません。証憑は残っているほうが安全なためです。
設計5：証憑のファイル名で経理処理が追えるようにする#
地味ですが、効果が大きかった一手です。
保存する画像のファイル名を、こう組み立てています。
20260805_ホームセンター○○店_4406円_消耗品費_立替樹下.png日付を先頭に置くと、フォルダを開いた瞬間に日付順に並びます。そして店名・金額・科目・立替者が入っているので、ファイル名だけで経理処理が追えます。台帳と突き合わせなくても、フォルダの一覧が実質的な索引になる。
月別フォルダ（YYYY-MM/）に入れておけば、税理士さんに渡すのもフォルダごとで済みます。
列は「番号」ではなく「名前」で引く#
もう1点、これから作る人向けの実務的な話です。台帳の列は必ず増えます。この記事で書いた「立替者」も「事業」も「精算」も、全部あとから足した列です。
なので、コードから列を指定するときに列番号を直書きしないでください。名前から引く関数を1つ挟んでおくと、列が増えても壊れません。あわせて、ヘッダを左から突き合わせて足りない列を挿し込む処理を記帳のたびに走らせておくと、列の追加が何度実行しても安全（冪等）になります。
読み取りエンジンの選び方：上位モデルは要らなかった#
技術的な選択で一点だけ、実測で結論が出たものを書いておきます。
読み取りは専用のOCRエンジンではなく、画像をそのまま読める汎用AIに投げています。渡すのは画像と、出力するJSONの形と、勘定科目の候補リストと、「どういう事業の経費か」という前提の説明文です。
そのうえで、上位モデルと標準モデルを同じレシートで比べました。
| モデル | 読み取り結果 | 応答時間 |
|---|---|---|
| 上位モデル | 標準モデルと同一 | 約2分40秒 |
| 標準モデル | 同上 | 約15秒 |
読み取り内容が変わらないなら、遅いほうを選ぶ理由はありません。チャットに送って15秒で返ってくるか、3分近く待つかは、続けられるかどうかを決めます。標準モデルを既定にしました。
AIツールの選定でよくある失敗が、「賢いほうが良いに決まっている」で上位モデルを既定にしてしまうことです。自分の素材で1回比べれば済む話です（→AIの使い分けをやめて司令塔を1つに固定した話）。
前処理で1つだけ必要なもの#
iPhoneで撮った写真は HEIC 形式のことがあります。そのままだと読めないケースがあるので、JPEGに変換してから渡す処理を入れています。Macなら標準コマンドで変換できます。ここだけは自動化しておかないと、「なぜかこの人の写真だけ失敗する」という原因不明の不具合になります。
読めなかったときの扱い#
AI-OCRの記事で一番書かれないのがここだと思うので、明記しておきます。
金額・日付・立替者を勝手に補完しません。
読めなければ空欄のまま記帳し、警告を残して、チャットで聞き返します。もっともらしい数字で埋めるほうが見た目はきれいですが、経費は財務データです。間違った数字が静かに台帳に入るほうが、空欄よりはるかに危険です。
そして読み取りの確度（高／中／低）も一緒に記録して列に入れています。あとから「確度が低い行だけ見直す」ができるようにするためです。
FAQ#
会計ソフトに直接入れたほうが早いのでは？#
最終的にはそうです。ただ、立替の精算と会計ソフトへの計上は別の仕事です。会計ソフトは「経費として計上したか」を見ますが、「誰にまだ返していないか」は持ちません。台帳を挟むのは、この2つを分けて扱うためです。会計ソフト連携そのものについては請求書作成とソフト連携の記事にまとめています。
AIに勘定科目を選ばせて大丈夫ですか？#
候補を17科目に絞ったうえで選ばせています。自由に書かせると表記が揺れて集計できなくなるので、選択肢を渡すのが前提です。さらに「この事業ではイベント会場の利用料は賃借料」といった前提の説明文を一緒に渡すと、判定が安定します。それでも最終判断は人が見ます。
個人事業主でも意味がありますか？#
立替者が自分1人なら、精算の列は要りません。ただ「事業の列」は、副業や複数の収入源がある場合は最初から入れておくことをおすすめします。あとから過去の行を埋め直すのが一番つらいからです。
スプレッドシート以外でもできますか？#
できます。この記事で書いたのは列の設計と判断のルールなので、データベースでもノーコードツールでも同じことです。スプレッドシートを選んでいるのは、税理士さんにそのまま渡せるという一点です。
まとめ#
- 経費自動化が止まるのは読み取り精度ではなく台帳の設計。誰が・どの事業で・返したか、が入っていないと月末に人手が戻る
- 立替者は推測させず送信者から取る。分からない行は空欄ではなく赤くする
- 残高は累計ではなく「まだ返していない額」。精算を記録する列を持ち、取り消せるようにする
- 事業は明細の時点で持たせる。店名の記憶は「人が決めた事実の再利用」だけに限り、どこでも使う店は覚えない
- 二重計上は警告まで。削除は人。取り消せない操作だけ人が押す
- 読み取りモデルは自分の素材で比べる。同じ結果なら速いほうが勝ち（実測 15秒 vs 2分40秒）
作るのが難しいのは読み取りではありません。月末に人が何をするかから逆算して列を決めることです。ここを先に決めておけば、あとは1行ずつ増えていくだけになります。
自動化の全体像をどう組み立てているかは個人で回している自動化20件の全体像にまとめています。
