この記事では、会計連携前に確認したい企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- 連携対象
- 勘定科目
- 部門・税区分
- 締め処理
- CSV/API
- 仕訳確認
- 責任範囲
まず結論
基幹システムと会計ソフトを連携する際に、最初に決めるべきなのは接続方法ではありません。どの業務データを、いつ、どの単位で、どの勘定科目・部門・税区分へ変換するかを整理することが先です。
売上データだけを連携する場合でも、計上時期、請求との関係、返品や値引き、消費税、売掛金、入金との対応を確認する必要があります。基幹システムの数値が正しくても、会計上の計上基準と合わなければ、適切な仕訳にはなりません。
また、すべての取引を自動連携することが最適とは限りません。定型処理は自動化し、発生頻度が低い例外取引は担当者が確認して処理する方が、開発費や保守負担を抑えられる場合があります。
現在の仕訳作成方法、Excel加工、確認作業、修正内容を棚卸しし、自動連携するデータ、会計側で入力するデータ、担当者が確認するデータを切り分けます。そのうえで、CSV、API、連携ツールなどの方式を比較してください。
よくある背景・失敗しやすい理由
基幹システムと会計ソフトの間を、担当者の手作業でつないでいる企業は少なくありません。基幹システムからCSVを出力し、経理担当者がExcelで勘定科目や部門を付け、会計ソフトへ取り込む運用です。
この方法は柔軟ですが、列の削除、並べ替え、コピー漏れ、二重取込などのリスクがあります。加工方法や判断基準を知る担当者が退職すると、月次決算が止まる可能性もあります。
また、会計ソフトへ取り込める形式のCSVを作れば連携できると考えるのも危険です。売上や仕入をいつ計上するか、どの科目を使うか、税区分や部門をどう付けるかを決めなければ、仕訳を正しく作成できません。
基幹システムと会計ソフトを異なる会社が保守している場合は、障害時の責任範囲が曖昧になりがちです。データが出力されない、取込エラーになる、金額が合わないといった問題について、誰が調査するかを事前に決める必要があります。
確認すべきポイント
1. 連携対象
最初に、どの取引を会計ソフトへ連携するかを明確にします。売上、仕入、入金、支払、在庫、経費、原価、固定資産など、対象によって必要な項目や仕訳の作り方が異なります。
売上データを連携する場合でも、明細を一件ずつ送るのか、取引先別・日別・月別に集計するのかで仕訳件数が変わります。詳細なデータは確認しやすい一方、件数が多過ぎると会計ソフトの処理や検索へ影響します。
返品、値引き、取消、相殺、前受金、仮受金などの例外取引も対象に含めるかを確認してください。通常取引だけを連携すると、月末に手作業で補正する運用が残ります。
マクティズムでは、会計側で必要な情報、監査時の確認方法、処理件数を踏まえ、自動連携する範囲と手動処理する範囲を整理します。
2. 勘定科目
基幹システムの取引区分と、会計ソフトの勘定科目を対応付けます。商品売上、役務売上、送料、値引き、返品などを、どの科目へ計上するかを明確にしてください。
取引内容によって科目が変わる場合は、商品分類、取引先区分、取引種別などを基に変換ルールを作ります。担当者が都度判断している場合、その基準を明文化しなければ自動化できません。
補助科目を使用する場合は、取引先コードや商品分類との対応も必要です。新旧でコード体系が異なるときは対応表を作成し、追加・変更時の管理者を決めます。
勘定科目や補助科目を変更した場合の適用日と履歴を残しておくと、過去仕訳との比較や障害調査がしやすくなります。
3. 部門・税区分
部門別損益を管理する場合は、基幹システムの部署、店舗、拠点、事業区分を会計ソフトの部門コードへ対応させます。組織変更時に修正できる仕組みも必要です。
売上部門と担当部門が異なる、複数部門へ配賦する、共通費として処理するといったルールがある場合は、部門を決める基準を整理してください。
税区分は、課税、非課税、不課税、免税、対象外の違いに加え、税率や仕入税額控除の扱いも確認します。両システムで税区分コードが異なる場合は変換表が必要です。
税区分を一律設定すると誤仕訳につながるため、商品、取引先、取引種別ごとの判定条件と、例外時の修正方法を決めます。
4. 締め処理
データをいつ会計ソフトへ連携するかは、月次決算や請求締めに影響します。売上登録時、出荷時、請求確定時、月末締め後など、仕訳を作成する時点を決めてください。
基幹システムの締め後にデータを修正できる場合、その変更を会計ソフトへどう反映するかも重要です。既存仕訳を上書きするのか、取消仕訳と修正仕訳を作成するのかを整理します。
月末締め後に返品や追加請求が発生した場合、当月へ反映するのか、翌月へ計上するのかで処理が変わります。業務上の締めと会計上の締めが一致しているかを確認してください。
連携済みデータの再送による二重計上を防ぐため、送信済みフラグや連携番号による管理が必要です。
5. CSV/API
CSV連携は比較的導入しやすい一方、ファイル出力、加工、取込の作業が残りやすく、誤操作のリスクがあります。項目順、文字コード、日付形式、金額の符号、空欄の扱いまで定義します。
API連携は自動化しやすい反面、認証、通信エラー、仕様変更、利用回数制限などへの対応が必要です。リアルタイム性が不要であれば、日次や月次の一括連携で十分な場合もあります。
どちらの方式でも、二重送信を防ぐ仕組み、エラーとなったデータだけを再送する仕組み、結果を確認できるログが必要です。
方式は利便性だけでなく、件数、頻度、運用負担、障害時の復旧方法、将来の会計ソフト変更まで含めて比較してください。
6. 仕訳確認
連携処理が正常終了しても、仕訳内容が正しいとは限りません。連携前後の件数、借方・貸方金額、取引先別・部門別・税区分別の合計を確認します。
通常取引だけでなく、返品、値引き、取消、マイナス金額、端数差額、複数税率など、誤りが起きやすい取引を使ってテストしてください。
基幹システムの売上合計と会計ソフトの売上仕訳が一致するか、売掛金残高や入金データと整合するかも確認します。差額が出た場合に、どのデータから原因を追えるかが重要です。
確認者、確認項目、合格基準を決め、月次締め時の照合作業として手順化します。稼働直後は自動連携後も人による確認を継続します。
7. 責任範囲
基幹システム、連携プログラム、会計ソフトを異なる会社が担当する場合は、データ作成、送信、受信、取込、仕訳変換の担当範囲を明確にします。
エラー発生時に、どの会社が一次調査を行い、ログを確認し、利用部門へ連絡するかを決めてください。責任分界が曖昧だと、各社が自社側は正常と主張し、復旧が遅れます。
保守契約では、対応時間、問い合わせ窓口、夜間・休日対応、追加費用の条件も確認します。月末や決算期に止められない処理であれば、緊急連絡体制が必要です。
システム構成図、データの流れ、責任分界点、ログの保存場所を資料として残しておくと、担当者交代後も対応しやすくなります。
自社で整理できること・外部に相談すべきこと
社内では、どの取引を会計ソフトへ入力しているか、誰がCSVを作成・加工・取込しているか、どのような修正が発生しているかを整理します。月次締めで使用する帳票やExcelも確認対象です。
勘定科目、補助科目、部門、税区分、摘要、取引先コードについて、基幹システムと会計ソフトの対応を一覧化します。返品、値引き、相殺、前受金などの例外取引も確認してください。
データ量が多い、複数システムから仕訳を作成する、会計判断が複雑、API開発が必要といった場合は、開発会社と経理担当者を交えて整理する方が安全です。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| CSV加工が少なく件数も少ない | 現行運用の標準化 | 手順書とチェック方法を整備する |
| Excel加工や手修正が多い | 連携プログラム・変換ツール | 加工理由と仕訳ルールを確認する |
| 勘定科目や部門の誤りが多い | 変換ルールの見直し | コード対応表の管理者を決める |
| 大量データを定期連携する | API・自動連携 | 処理時間と再送方法を確認する |
| 例外取引が多い | 自動連携と手動確認の併用 | すべてを無理に自動化しない |
| 複数会社がシステムを担当する | 責任分界と保守体制の整理 | 障害時の一次窓口を明確にする |
| 判断が難しい | 現行調査・連携設計 | 業務ルールと技術仕様を資料化する |
判断表は一般的な目安です。取引件数、仕訳数、締め時期、部門数、税区分、会計ソフトの仕様によって適切な方法は変わります。自動化の範囲、運用負担、保守性、障害対応を比較してください。
相談前に準備しておく情報
- 基幹システムと会計ソフトの概要
- 連携対象となる取引データ
- 現在のCSVや仕訳データのサンプル
- 勘定科目・補助科目の一覧
- 部門・税区分の一覧
- 仕訳作成と確認の手順
- 月間の取引件数・仕訳件数
- 締め処理と連携の実行時期
- 返品、値引き、相殺などの例外処理
- 現在発生しているエラーや手修正
- 各システムの保守会社
- 想定予算と導入時期
正常な仕訳だけでなく、返品、取消、複数税率、部門振替などのサンプルも準備してください。経理、販売管理、情報システムの担当者を決め、仕訳ルールとシステム仕様を一緒に確認できる体制を整えます。
マクティズムの見解
マクティズムでは、基幹システムと会計ソフトの連携は、単にCSVを出力したりAPIで接続したりする作業ではないと考えています。業務データを正しい会計仕訳へ変換するルールの整理が重要です。
勘定科目、補助科目、部門、税区分、計上時期が曖昧なまま自動化すると、誤った仕訳が大量に登録される可能性があります。経理担当者が手作業で行っている判断を確認し、ルールとして明文化する必要があります。
マクティズムでは、連携対象、データ粒度、変換ルール、締め処理、エラー時の再送、仕訳確認まで一連の流れとして整理します。定型処理は自動化し、例外取引は確認後に処理するなど、無理のない方法を検討します。
また、複数会社が関わる場合は、障害時の責任分界と問い合わせ窓口を明確にします。連携機能だけでなく、運用開始後に誰が保守するかまで考えることが重要です。
会計連携の目的は入力作業を減らすことだけではありません。基幹システムの取引データと会計上の数値を一致させ、月次決算を正確かつ迅速に行える状態を作ることが重要です。
よくある質問
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
