新規クライアント登録から記帳自動化まで

朝、新規クライアントの資料一式がDropboxに届いていた。レシートPDF 84枚、クレカ明細のCSV、勘定科目マスター。これを今日中にMFへ流し込めるところまで持っていく。手を動かし始めてから仕訳CSVが164件吐き出されるまで、一日中ターミナルとスプレッドシートを行き来した記録。

クライアント登録と初期設定

個人事業主（デザイナー、12月決算）として登録した。登録自体は数分で終わるが、帳票タイプのデフォルト設定で手が止まった。

既存のデフォルト設定には売上電表、スクエア明細、クレカ明細など複数の帳票タイプが並んでいた。今回のクライアントが実際に使うのは2種類だけ -- 領収書レシートと仮払金明細CSV。使わない帳票タイプが残っていると取込時の選択肢が増えてオペレーションミスの温床になる。売上電表、スクエア明細、クレカ明細の3つを削除して2つに絞った。

帳票タイプを減らしたことで、取込画面を開いたときの選択肢が2つしか表示されなくなる。迷う余地が消える。この「選択肢を減らす」設計は、自分が使う分には気にならないが、クライアントや他のオペレーターが触る場面では効いてくる。

レシートPDF 84枚のOCR一括取込

84枚のPDFを一括でOCRにかけた。OCR処理自体は既存のパイプラインが動くので待つだけだが、取込後に全件の目視確認が待っている。

OCR結果をスクロールしながら見ていくと、金額の読み取りミスが数件、店舗名の揺れ（「ファミリーマート」と「ﾌｧﾐﾘｰﾏｰﾄ」など半角カナ混在）が数件。手動で修正した。84枚を一気に処理できるのはパイプラインの恩恵だが、最後の確認は人の目でやるしかない。

クレカ明細の補助元帳取込

三井住友カードの利用明細CSVを補助元帳として取り込んだ。カード明細はクレジットカードごとに1ファイルで、今回は1枚分。

並行して勘定科目マスターCSVのMFインポートも実行した。順番が大事で、MF側にクライアント固有の補助科目を先に登録しておかないと、後で仕訳CSVをインポートしたときに科目不一致でバリデーションに弾かれる。ここを後回しにして痛い目を見たことがあるので、今回はクレカ取込と同時に済ませた。

事業主勘定の一括振替とバグ修正

特定カード支払い分は全額プライベート利用のため、一括で事業主貸に振り替える処理を走らせた。ところがこの一括処理で、レシートが紐付いている5件まで事業主貸に上書きされてしまった。

仕訳一覧を眺めていて「あれ、この5件は消耗品費のはずなのに全部事業主貸になっている」と気づいた。原因を追いかけると、一括振替処理がレシート紐付きかどうかを見ずに全件を対象にしていた。

レシートが紐付いている明細はレシート側の勘定科目を優先すべきなので、一括振替の対象からレシート紐付き明細を除外する条件を追加して修正。対象件数を事前にログに出すようにもした。

Amazon明細の勘定科目照合

Amazon利用明細はクレカのCSV上では「AMAZON.CO.JP」としか表示されない。何を買ったのか分からないと勘定科目が決まらない。

スプレッドシート連携でAmazonの注文履歴から商品名を引っ張ってきて、クレカ明細の日付・金額で突合させた。商品名が入ると「消耗品費」「新聞図書費」「通信費」の振り分けが一気に進む。

重複チェックと確定処理

レシートとクレカ明細の両方に同じ取引が載っているケースがある。たとえばコンビニで買い物した場合、レシートPDFとクレカ利用明細の両方にデータが存在する。二重計上を防ぐために重複チェックが必要になる。

日付・金額でマッチングをかけて重複候補をリストアップした。金額が完全一致かつ日付が1日以内のものを重複候補として抽出。確認後に一括確定処理を走らせて、レシート側を正とする仕訳に統合した。

マイナス金額（返品）の借方/貸方反転ロジック

返品によるマイナス金額の明細が混じっていた。CSVエクスポートした仕訳を確認すると、マイナス金額の行が借方・貸方ともにマイナスのまま出力されている。MFに投げたら当然弾かれる。

既存のロジックは金額が常にプラスの前提で組まれていた。返品の場合、金額の符号を反転させるだけでなく、借方と貸方の勘定科目も入れ替える必要がある。

# 返品時は借方/貸方を反転
if row.get("is_refund"):
    debit_account, credit_account = credit_account, debit_account
    amount = abs(amount)

is_refundフラグを見て借方/貸方を反転させる処理を追加した。金額はabs()で正の値に戻す。単純だが、このパターンを見落としていると仕訳全体が狂う。

未確定明細のスプレッドシート作成

勘定科目が自動で決まらなかった21件が残った。仕訳ルールにも引っかからず、レシートからも科目が特定できなかった明細。

これをスプレッドシートに書き出して、クライアントに確認依頼を送った。各行に日付、金額、利用先を並べて、勘定科目の選択肢をドロップダウンで用意した。「この取引は何ですか？」とメールで聞くよりも、スプレッドシートに選択肢を並べて渡した方が回答が速く返ってくる。回答が戻ってきたらCSVに反映してMFに追加インポートする流れ。

MF仕訳CSVエクスポートと貸方補助科目のバグ

最後にMF仕訳CSV形式で164件をエクスポートした。CSVをMFにインポートしてみたら、貸方補助科目が空欄になっている行が数件あった。

クレカ明細経由の仕訳では貸方補助科目にカード名を入れる必要がある。「未払金 / 三井住友カード」のように、貸方の勘定科目と補助科目がセットで入る。ところが特定の経路（レシート紐付き確定→仕訳変換）を通ったデータで、カード名が途中で落ちていた。

原因はJOINの順序。レシート紐付きの場合はレシートテーブル経由で勘定科目を取るが、その経路ではクレカ明細テーブルのcard_nameカラムを参照していなかった。

# card_nameが空の場合、クレカ明細レコードからフォールバック
credit_sub = row.get("credit_sub_account") or row.get("card_name", "")

フォールバックを1行追加して修正。

デフォルト貸方勘定科目の修正

仕訳のデフォルト貸方勘定科目が「仮払金」になっていた。法人クライアントではこれで正しいが、個人事業主の場合は「事業主借」が正しい。

法人は従業員への仮払金を経費精算で消し込む運用だが、個人事業主にはその概念がない。事業用の支出を個人資金で立て替えた場合は「事業主借」で処理する。

登録時のクライアント属性（法人/個人）を見てデフォルト貸方科目を切り替えるように修正した。

今日の処理サマリー

振り返り

一日で登録からMFインポートまで完走できたのは、OCRパイプラインや仕訳ルールエンジンなど既存の仕組みが回ってくれたおかげだ。ただ、手が止まったのはバグ修正の時間帯。一括振替の5件上書きバグと返品の借方/貸方反転で合計2時間ほど持っていかれた。

一括振替のバグは、仕訳一覧を1行ずつ目で追って「消耗品費が事業主貸に化けている」と気づいた瞬間に原因の見当がついた。一括処理は常に例外ケースを踏む。次のクライアント登録では、一括処理の前にレシート紐付き件数を表示するプレビューステップを挟みたい。「この処理で N 件が対象になります。うちレシート紐付き M 件は除外されます」と表示するだけで、誤操作を防げる。

もう一つ、法人/個人でデフォルト貸方科目が異なる点は、今回初めて個人事業主を扱って発覚した。既存クライアントが全て法人だったので、仮払金がデフォルトのまま放置されていた。「動いているコードは正しいコードとは限らない」を地で行く話だった。