BackOps

会計ソフトをやめて Notion で仕訳帳を持つ：移行編（事例）

小規模法人の記帳を MoneyForward から Notion に移した事例。やめた理由、仕訳帳の設計、1期分3,692行を移したときのハマりどころ。

帳簿からデータベースへ仕訳を移すイメージのイラスト

AIでバックオフィス自動化を専門にしている mzohya です。 今回は、自社（小規模の物販法人）の記帳を MoneyForward クラウド会計（以下 MF）から Notion に移した話。運用してみた結果は後日の続編で書きます。

結論

  • 新しい期から MF を解約し、仕訳帳は Notion の年度別データベース で持つことにした
  • 前期の全仕訳 3,692行 を MF から移し、借方＝貸方・残高一致を確認してロック
  • 起票は Claude が行う。人間は月1回、明細 CSV を渡して結果を確認するだけ
  • 決算書・申告書は前期から仕訳データをもとに自前で生成しており、会計ソフトに残っていた役割は「仕訳の置き場」だけだった

なぜやめたか

理由は4つ。

  • コスト: 使っている機能に対して年数万円の利用料が見合わなくなった
  • AI から操作しにくい: 連携ツール（MCP）に削除操作がない、取得（GET）は税抜・登録（POST）は税込で金額の意味が違う、など。Claude が主体で記帳する運用と噛み合わない
  • 申告まで自前でできた: 前期の決算書・法人税・消費税の申告書を、仕訳データから様式に重ね書きして作成できた。会計ソフトの集計・帳票機能を使わなくなった
  • データを手元で持ちたい: 請求書・取引先・業務手順など、他の業務データはすでに Notion にある。仕訳も同じ場所に置けば Claude が横断して扱える

逆に言うと、決算・申告を会計ソフトや税理士に頼っている状態なら、この移行はおすすめしません。集計と帳票の仕組みを自分で持てていることが前提です。

仕訳帳の設計

1期1データベース

仕訳帳_202609（2026年9月期）のように、事業年度ごとに1つの DB を作ります。期が終わって申告まで済んだら DB をロックして、確定版として凍結します。

1つの DB に全期間を入れない理由は、期末の締めを「ロック」という操作で明確にしたいから。過去期を誤って書き換える事故も防げます。

1行 = 借方または貸方の1明細

プロパティ内容
伝票No同じ伝票の行をまとめるキー。「1」は期首残高
日付取引日
借/貸借方 / 貸方
勘定科目・補助科目補助科目は銀行口座・取引先別の未払金など
税区分課対仕入内10%適格、区分70%（経過措置）など
金額・消費税額税込。貸方はマイナス
決算決算整理仕訳は「本決」
識別フラグ弥生形式（2000=1行伝票、2110=先頭、2100=中間、2101=最終）

ポイントは 貸方をマイナスで持つ こと。伝票ごと・期間ごとに金額を合計すれば必ず0になるので、整合チェックが単純な足し算で済みます。試算表も「勘定科目でグループ化して合計」だけで作れます。

識別フラグは弥生会計のインポート形式に合わせています。将来どこかの会計ソフトに戻したくなっても、CSV で書き出せばそのまま取り込める状態にしておくための保険です。

移行の流れ

  1. MF の API で前期の仕訳と勘定科目を JSON で取得
  2. Python スクリプトで Notion 取込用 CSV に変換（Claude Code に書いてもらった）
  3. Notion の CSV 取込で DB にマージ
  4. 借方＝貸方、科目別残高が MF の試算表と一致することを確認
  5. 一致したら DB をロック

変換スクリプトは60行ほど。最後に借方合計と貸方合計を突き合わせ、一致しなければ CSV を書き出さないようにしています。

debit = sum(r["金額"] for r in out if r["借/貸"] == "借方")
credit = -sum(r["金額"] for r in out if r["借/貸"] == "貸方")
assert debit == credit, (debit, credit)

ハマりどころ

ハマり1: MF の取得 API は税抜

MF の仕訳取得 API が返す value は 税抜（消費税は tax_value に別出し）。一方、仕訳登録 API の value は税込です。同じ名前で意味が違います。

Notion 側は税込で持つので、value + tax_value に直して移しています。

gross = x["value"] + (x["tax_value"] or 0)  # GET /journals の value は税抜

ハマり2: 未実現の仕訳が混ざる

MF の取得結果には未実現の仕訳（is_realized: false）が含まれます。そのまま入れると預金や売掛金の残高がずれます。除外が必要です。

ハマり3: Notion の CSV 取込で日付が消える

2025/10/01 形式で取り込むと、日付列がエラーも出ずに 空欄 になりました。Notion が CSV 書き出しで使う October 1, 2025 形式に揃えたら確実に入りました。

3,692行を入れたあとに気づくと痛いので、最初は数行で試すのがおすすめです。

ハマり4: 期首の振り戻しをするかどうか

通常は期首に前期末の売掛金・買掛金などを振り戻し（洗い替え）ます。ただ当期から消費税の計算方法が変わる（簡易課税 → 本則課税）ため、振り戻すと前期分の取引に当期の税区分が混ざります。

そこで当期は振り戻しをせず、入出金のたびに前期末の残高と照合して消し込む方式にしました。会計ソフトなら自動でやってくれる部分を自分で決める必要がある、という例です。

移行後の月次運用

月1回、銀行・カードの明細 CSV と、EC のレポート・請求書・現金出納帳を Claude に渡します。Claude が勘定科目と税区分を判定して Notion に起票し、伝票ごとの借方＝貸方と試算表で確認します。

  • 期中は入出金ベースで記帳し、期末に発生主義へ整理
  • ただし給与・EC 売上・カード利用・卸売上・仕入は月次で発生計上し、入金・支払で消し込み
  • 判定に迷う取引だけ人間に確認が来る

判定ルールは Notion の手順書ページに蓄積しています。ルールが増えるほど確認が減る、という育ち方を期待しています。

注意点

  • 電子帳簿保存法: 帳簿を電子で保存する場合、システムの概要書の備付けと、画面・書面に出力できる状態が最低限必要です。Notion の DB と手順書ページをそのまま概要書として整えておくと楽です
  • 記帳の知識は要る: 会計ソフトが裏でやっている整合チェック・残高管理・期首処理を、自分（と Claude）でやることになります。仕訳の意味が分からない状態で始めると、誤りに気づけません
  • 戻れる道は残す: 弥生形式の CSV で書き出せるようにしておけば、税理士に依頼する・会計ソフトに戻す、といった選択肢を失いません

まとめ

  • 決算・申告まで自前でできるなら、会計ソフトは「仕訳の置き場」にすぎない
  • Notion なら他の業務データと同じ場所に置け、Claude が横断して扱える
  • 設計のポイントは「1期1DB・ロックで締める」「貸方マイナスで合計0」「弥生形式で書き出せる」
  • 移行時は税抜/税込、未実現仕訳、日付形式、期首処理の4点に注意

経理の仕組みを見直したい方へ

BackOps では、Claude を使った経理業務の自動化・内製化を支援しています。

  • 会計ソフトと Claude を連携した記帳の自動化
  • 会計ソフトや有料 SaaS からの移行・脱 SaaS
  • 月次の定型業務を手順書化して Claude に任せる仕組みづくり

「全部やめるのは不安だが、手作業は減らしたい」という段階からでも相談を受け付けています。お問い合わせ からどうぞ。

#事例 #経理 #Notion #MoneyForward #Claude Code #脱SaaS