月次会計を「確認してから取り込む」流れにした

月次会計の作業を少し自動化していました。

最初は、銀行やカードのデータを集めて、仕訳っぽいCSVを作れば終わりかなと思っていました。

でも、実際に使う流れを考えると、CSVを作るところと会計システムへ取り込むところは分けた方が良さそうでした。

CSVを作って終わりではなかった

自動で作ったデータは、あくまで候補です。

取引先の名前が少し違っていたり、同じ金額の取引が複数あったり、口座間の資金移動が経費っぽく見えたりします。

この状態でいきなり正式な仕訳として取り込むのは怖い。

そこで、まず journal-candidates.csv という候補台帳を作る形にしました。

これは会計システムのアップロードファイルではありません。

どの取引をどう判定したかを、人間が確認するための中間データです。

CSVだけだと、機械的な確認には便利ですが、月次のレビューでは少し読みにくいです。

そこで同じ内容からMarkdownとHTMLも出すようにしました。

一覧で怪しい行を探したり、摘要や証憑の有無を確認したりするには、表になっている方が見やすいです。

この段階で「レビュー用の成果物」と「実際に取り込むファイル」を分けておくと、確認前に間違って取り込む事故を減らせます。

正式に取り込む時は、会計システムから出した仕訳帳のテンプレートを元にExcelを作ります。

候補CSVの列をそのままExcelに合わせるのではなく、テンプレートの年月日、金額、摘要、税区分などに合わせて別のファイルを生成する形です。

少し手間は増えます。

ただ、レビュー用のデータをそのまま本番の取込ファイルとして扱わなくて済むので、境界は分かりやすくなりました。

レビューが終わって、取り込んでよいと判断してから、次のファイルを作る流れです。

Excelの取込が成功しても、それだけで銀行やカードの取引と一致したとは言えません。

受信データ側で、計上済みの仕訳と取引内容が一致しているかを見る必要があります。

新しい取引先、税区分が変わった取引、用途がよく分からない支出は、候補のまま通さず個別に確認することにしました。

自動化できる部分を増やすほど、最後の確認条件を曖昧にしない方が大事になりそうです。

2026年6月分では、証憑から見つかった未計上の立替経費や、処理が一部だけ終わっている状態も扱えるようにしました。

普通預金から普通預金への移動も、費用ではなく銀行連携のその他の動きとして分類しました。

検証では、元データ816行、ワークフロー対象60行、候補1行という結果になりました。

数字が合っているだけでなく、候補がなぜ残ったのかを追えることを重視しています。

完全自動で会計処理が終わるところまでは行っていません。

むしろ、確認が必要な場所を残したまま、面倒な集計や分類だけを先に自動化した感じです。

この形なら、月が変わっても同じレビューを繰り返せそうです。

あとで会計システムへ取り込む時も、どのファイルが候補で、どれが承認済みなのかが分かりやすい。

無理に全部を自動化するより、確認の境界を作る方が先だったのかもしれません。