会計事務所の基幹システムとは？顧問先管理・申告進捗・報酬請求を統合する選び方【2026年】

顧問先が百件を超えたあたりから、どの関与先がいまどの工程にいるのかが表計算ソフトと担当者の記憶でしか追えなくなります。決算期はばらばら、申告期限も顧問先ごとに違い、資料が届いていない先の督促は担当者の判断任せ。会計事務所と税理士事務所が自分たちのために導入する基幹システムは、事業会社が使うERPとは要件がはっきり違います。この記事では、事務所内基幹システムの中核となる四領域、一般企業向けERPや基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説で扱う汎用の構成領域との要件差、会計事務所向けパッケージで足りる範囲と受託開発へ切り替える分岐点までを整理します。

まとめ：会計事務所の基幹システムを顧問先マスタと申告期限の自動判定で選ぶ判断軸

先に結論を置きます。会計事務所の基幹システムは、機能一覧の多さではなく次の四点で足切りしてください。第一に、顧問先マスタが決算期と申告区分と契約区分をキーとして持ち、そこから法人税・消費税・所得税・償却資産の各申告期限を自動生成できること。第二に、進捗ステータスが「資料未着」「記帳中」「試算表提示済」「申告書レビュー中」「電子申告済」のように事務所の実際の工程語で持てること。第三に、顧問料と決算料とスポット報酬を別建てで請求でき、担当者の工数と突き合わせて顧問先別の原価率が出せること。第四に、担当者ごとに閲覧できる顧問先を絞り、誰がいつどのデータを見たかを記録できること。

この四点が揃わない製品では、期限管理が表計算ソフトへ逆戻りします。職員十名以下で顧問先が二百件程度までなら会計事務所向けパッケージの標準機能でおおむね足り、受託開発は回収しにくい。逆に、非標準業務が売上の三割を超える事務所や、複数拠点で就業と承認の運用が分かれる事務所では、パッケージを残したまま周辺だけを個別開発する差分開発が現実解になります。分岐点は後半で条件付きに書き切りました。

会計事務所の基幹システムが一般企業のERPと違う二層構造｜自事務所と顧問先の帳簿

事業会社の基幹システムは、自社一社分の会計・販売・購買・在庫を一本のデータベースへ通す構造です。会計事務所ではここが根本から違います。

事務所自身の帳簿と顧問先数百社分の会計データが並ぶ二層構造の意味

会計事務所が扱うデータは二層に分かれます。上層は事務所自身の経営データ、つまり顧問料の売上、職員の工数、事務所の経費と決算。下層は顧問先ごとに独立した会計帳簿で、二百件の関与先があれば二百個の別法人の元帳が並びます。層が違えば会計期間も勘定科目体系も別です。

この構造が設計へ効いてきます。下層のデータは顧問先ごとに完全に分離されていなければならない一方で、上層からは「A社の月次はどこまで進んだか」「B社の決算料はいつ請求できる状態か」を横断して見たい。分離と横断を同時に満たすため、事務所内基幹システムは下層の会計データそのものを持たず、顧問先ごとの進捗と契約と請求だけを上層で管理し、会計データは会計ソフト側に置くという役割分担を取るのが一般的な設計です。両方を一つのデータベースへ押し込もうとすると、顧問先の会計ソフトを移行するたびに基幹側まで作り直す羽目になります。

汎用ERPの在庫・生産・購買モジュールが事務所業務で空欄になる要件差

会計事務所向けの検討で汎用ERPが候補に挙がることがありますが、モジュール構成が噛み合いません。ERPとは？基幹システム・CRMとの違いと主な機能・導入の進め方を解説で整理した通り、ERPの中核は会計・販売・購買・在庫・生産・人事の統合にあります。会計事務所には在庫も生産も無く、購買は消耗品程度。実質的に使うのは会計と人事、それに販売モジュールを顧問料請求へ流用する部分だけです。

ライセンス費用は使わないモジュールを含めた構成で発生しますから、費用対効果が合わない。加えて、汎用ERPの販売管理は「商品を単価×数量で売る」前提で組まれており、月額顧問料と年一回の決算料とスポットの相続税申告報酬という異なる収益認識の型を同時に扱うのが不得手です。会計事務所で汎用ERPを検討する意味があるのは、税理士法人が数十拠点規模になり人事と経費精算の統制を優先する段階からと考えてください。

会計ソフト・業務システム・基幹システムの呼び名が混在する守備範囲の整理

この領域は呼び名が入り乱れます。「会計事務所向けシステム」で検索したときに出てくるものは、実際には三種類に分かれています。

本記事が扱うのは真ん中の事務所内基幹システムです。会計ソフトの選定は関与先の環境に引きずられる別問題で、周辺システムとの線引きは業務システムとは？種類・基幹システムとの違いと開発・導入形態の選び方の考え方がそのまま当てはまります。検討時にベンダーへ問い合わせるときは、この三区分のどれを指しているかを最初に確認すると話が早い。

事務所内基幹システムの中核四領域｜顧問先管理・申告進捗・資料回収・報酬請求の要件

事務所内基幹システムに求める機能は、突き詰めると四つの領域に収まります。順に、外せない要件を具体化します。

顧問先マスタの設計｜決算期・申告区分・契約区分をキーに持たせる項目

顧問先マスタは単なる住所録ではありません。ここに何を持たせるかで、後段の期限管理と請求が自動化できるかが決まります。持たせる項目は次の通り。

• 決算期（月）と設立年月日、事業年度の変更履歴
• 申告区分（法人税・所得税・消費税の課税事業者か免税か・簡易課税の選択有無）
• 契約区分（月次関与・年一関与・記帳代行の有無・訪問頻度）
• 担当者と補助担当、レビュー担当の三層のアサイン
• インボイス登録番号と電子帳簿保存法への対応状況

特に効くのが消費税の課税区分です。免税事業者からの課税仕入れに係る経過措置は、国税庁の令和8年度税制改正特集によると控除割合が令和8年10月から70パーセント、令和10年10月から50パーセント、令和12年10月から30パーセントへ段階的に縮小し、令和13年10月以降は控除できなくなります。対象となる課税仕入れの金額基準も、同一の非登録事業者からの合計額で10億円超から1億円超へ引き下げ。顧問先ごとの登録状況をマスタで持っておかないと、切替時期に個別確認をやり直すことになります。

決算期から逆算する申告期限の自動判定と進捗ステータスの持たせ方

会計事務所の期限管理は、顧問先ごとの決算期から機械的に逆算できる部分と、できない部分に分かれます。法人税の確定申告は原則として事業年度終了日の翌日から二か月以内で、この計算は決算期さえマスタにあれば自動生成できる。個人の所得税は三月十五日、個人事業者の消費税は三月三十一日と固定です。ここまでは自動化の対象。

手が止まるのは延長特例です。法人税の申告期限延長の特例を受けている法人は一か月延長され、届出をすれば消費税の申告期限も一か月延長できる取扱いがあります。この適用有無は顧問先ごとに違うため、マスタのフラグとして持たせ、期限の自動生成側で分岐させる必要があります。フラグを持たない製品だと、延長組の期限を担当者が頭の中で足し込む運用になり、そこが抜ける。

進捗ステータスは製品の初期値をそのまま使わず、事務所の実際の工程語へ置き換えてください。「進行中」のような粒度では、資料が来ていないのか記帳が終わっていないのかレビュー待ちなのかが判別できず、所長が見ても打ち手が決まりません。

記帳資料と証憑の回収管理｜電子取引データの保存要件と督促の可視化

月次の遅延理由の大半は、顧問先から資料が届かないことに起因します。回収管理で持つべきは、資料の種類別の到着状況、依頼日、督促の履歴、そして到着した資料の保存場所の四つ。ここを担当者のメール受信箱に依存させると、担当者が休んだ日に誰も状況を把握できなくなります。

保存要件も設計に影響します。国税庁の電子帳簿保存法一問一答（電子取引関係）によれば、電子取引データの電子保存は令和6年1月以後の取引から必要で、猶予措置は所轄税務署長が保存要件に従えなかった相当の理由があると認め、かつ税務調査等でデータのダウンロードの求めと出力書面の提示・提出に応じられる場合に限って適用されます。猶予措置は要件を免除するもので、データそのものの保存義務が消えるわけではない点に注意してください。顧問先から受け取った電子データを事務所側でどこまで預かるのかは、契約書と回収フローの両方で決めておく必要があります。

顧問料・決算料・スポット報酬の三区分と工数を突き合わせる原価管理

会計事務所の収益構造は、毎月定額の顧問料、年一回の決算料と申告報酬、相続や事業承継などのスポット報酬に分かれます。基幹システム側でこの三区分を別建てに持たないと、月次の請求は自動化できても決算料の請求漏れが起きる。決算料は「決算月の翌々月に請求」のように、顧問先マスタの決算期から自動で請求予定を立てられる形が望ましい設計です。

原価側は工数の記録です。顧問先別の投入時間が取れると、顧問料一万円の関与先に月八時間かけているといった逆ざやが見えます。工数入力を職員へ求めると必ず抵抗が出るため、案件単位ではなく顧問先単位で三十分刻み程度に粗く取るところから始めるのが続きます。細かく取ろうとした事務所ほど、半年で入力が形骸化する。

会計事務所向けパッケージの守備範囲｜標準機能で足りる範囲と外側に残る三つの穴

会計事務所向けには専用パッケージが複数あります。どこまでを標準で賄えて、どこから作り込みが要るのかを分けます。

会計事務所向けパッケージが標準で持つ機能とベンダー内完結という前提

ミロク情報サービスのACELINK NX-Proは、事務所管理・会計業務・顧問先連動といったシリーズで構成され、事務所の顧客管理と会計税務業務を同一系列で扱う製品です。TKC、JDL、NTTデータの達人シリーズなども同様に、会計事務所の業務全体を自社製品群でカバーする設計を取っています。この系列を丸ごと採用すれば、顧問先マスタから会計データ、申告書作成、事務所の請求までが同じベンダー内で繋がる。

ただし前提があります。連携が滑らかなのは同一ベンダーの製品どうしに限られる、という点です。顧問先がクラウド会計へ移行して事務所側だけ従来のパッケージに残ると、その顧問先のデータは連携の外側に落ちます。関与先の会計ソフトが三系統以上に分かれている事務所では、パッケージ単体で全件を一元管理する前提が最初から崩れていると考えてください。

パッケージの外側に残る三つの穴｜顧問先ポータル・独自報酬・収益分析

標準機能で埋まらずに残りやすい領域は三つあります。順に、顧問先との資料授受を担うポータル、事務所独自の報酬体系、そして経営判断のための収益分析です。

顧問先ポータルは、資料のアップロードと進捗の共有を関与先側の画面で行う仕組み。パッケージにも同種の機能はあるものの、顧問先側にそのベンダーの環境を求めるものが多く、既に別のファイル共有サービスを使っている関与先には押し付けられません。報酬体系は、従業員数や仕訳数に連動する独自の料金表を組んでいる事務所ほど標準の請求機能から外れます。収益分析は、顧問先別の粗利や担当者別の生産性を見たい段階で、パッケージの標準帳票では粒度が足りなくなる。

この三つのうち二つ以上が業務の中心にある事務所は、パッケージ単体での完結を諦めて、周辺を作る前提で検討したほうが結果的に安く済みます。

e-Tax・eLTAXとの連携範囲と代理送信の署名省略が効く場面の見極め

電子申告まわりは、事務所内基幹システムが直接担う領域ではありません。申告データの送信は申告ソフトからe-TaxおよびeLTAXへ行くのが通常の経路で、基幹側は「電子申告が完了したか」というステータスを受け取れれば足ります。

実務で効くのが代理送信の扱いです。e-Taxの案内によると、税理士等が関与先の申告等データを代理送信する場合、納税者本人の電子署名を省略し、税理士の電子署名と納税者の利用者識別番号で送信できます。つまり顧問先ごとに電子証明書を取得してもらう手間は原則として不要で、基幹システム側で管理すべきは顧問先の利用者識別番号と、その顧問先について代理送信の同意を得ているかどうかの記録になります。ここを取り違えて「顧問先の電子証明書の有効期限管理」を要件に入れてしまう設計を時々見かけますが、大半の顧問先では不要な項目です。

パッケージ導入と受託開発の分岐点｜職員数・顧問先数・非標準業務の比率で決める判断

ここが本記事の結論部分です。曖昧に両論併記せず、条件を付けて言い切ります。

受託開発を選ばない条件｜職員十名以下・顧問先二百件以下・標準業務中心

次の三つがすべて当てはまる事務所は、個別開発を選ばないでください。職員が十名以下、顧問先が二百件以下、そして売上の大半が月次顧問と決算申告という標準業務であること。この規模では、会計事務所向けパッケージまたはクラウド型の事務所管理サービスの標準機能で管理対象を賄えます。

個別開発を避ける理由は初期費用よりも保守にあります。税制は毎年変わり、電子帳簿保存法もインボイス経過措置も期限付きで動く。自前のシステムはその都度改修の発注が必要になり、年間の保守費が職員一名分の人件費に迫ることも珍しくありません。パッケージなら制度改正への追随はベンダーの保守範囲に含まれます。標準に合わない業務が一つ二つあるなら、システムを作るのではなく業務手順のほうを標準へ寄せるほうが安い。システム選定より前に業務そのものをどの順で変えるかは、会計事務所のDXとは？記帳代行の自動化と顧問先連携を優先順位で決める進め方で優先順位を整理しています。

個別開発が回収できる条件｜非標準業務の売上比率・複数拠点・事務所統合

逆に、次のいずれかに当てはまるなら個別開発が回収圏に入ります。第一に、事業承継支援や医療機関特化のコンサルティングなど、標準の顧問業務に当てはまらない収益が売上の三割を超える場合。第二に、三拠点以上で承認フローと料金体系が分かれている場合。第三に、他事務所の統合や買収で、異なるパッケージを使う組織を短期間で束ねる必要がある場合です。

いずれも共通するのは、業務のほうを標準へ寄せると事務所の競争力そのものが失われる、という構図。医療機関特化の事務所が診療報酬改定の周期に合わせた独自の進捗管理を持っているとして、それをパッケージの標準ステータスへ潰すのは本末転倒です。判断の順序は、まず業務を標準へ寄せられるかを検討し、寄せると価値が落ちる部分だけを開発対象として残す。この順序を逆にした事務所は、現行業務をそのまま写した高額なシステムを作って使いこなせずに終わります。

全部を作り直さない現実解｜パッケージを残して周辺だけ作る差分開発の費用

実際に多いのは、会計税務の中核をパッケージに残し、その外側だけを個別開発する差分開発です。顧問先ポータル、独自報酬体系の請求計算、収益分析のダッシュボードといった前節の三つの穴を、パッケージのデータをCSVやAPIで受け取って埋める形。中核の制度改正追随はベンダーに任せたまま、事務所固有の部分だけを自分たちの資産にできます。

設計の要は連携インターフェースです。パッケージ側が提供するデータの粒度と更新頻度を先に確認し、日次バッチで足りるのか即時連携が要るのかを決めてから機能を設計してください。順序を逆にすると、実現できない即時性を前提にした画面を作ってしまいます。差分開発の範囲設定や、既存パッケージとの連携可否の切り分けについては、基幹システム開発の相談時に現行の製品名と顧問先数を伝えると、開発範囲の見積もりが具体化します。なお、開発したものをクラウドに置くかオンプレミスに置くかという導入形態の一般的な比較はオンプレミス型とクラウド型の基幹システム導入形態の違いと選定ポイントを参照してください。

基幹システム刷新でつまずく実務｜稼働時期・顧問先マスタの移行・権限設計の落とし穴

製品が決まってからの失敗は、機能ではなく段取りで起きます。会計事務所に固有の二点を挙げます。

三月と五月を外す稼働時期の決め方と並行運用を二か月に収める段取り

会計事務所の繁忙は暦で決まっています。所得税の確定申告が集中する一月から三月中旬、三月決算法人の申告が重なる五月、年末調整と法定調書の十二月から一月。新システムの稼働をこの時期に当てると、教育の時間が取れないまま実務が始まって定着しません。

現実的な稼働時期は六月から八月、次点で十月です。並行運用は二か月を上限に設計してください。二重入力の期間が長引くほど職員の入力が片方だけになり、どちらのデータが正なのか分からなくなる。並行期間中は「新システムが正、旧システムは参照のみ」と最初に宣言し、旧システムへの入力を止める日を先に決めておくのが定着の分かれ目です。

顧問先マスタ移行の名寄せ問題と担当者単位の権限設計・操作ログの要否

データ移行で必ず揉めるのが顧問先マスタの名寄せです。会計ソフト側の得意先名、事務所の請求システムの請求先名、担当者が個人で持っている連絡先リストで、同じ関与先が別表記になっている。法人番号を持っている先は法人番号で寄せられますが、個人事業主と設立前の法人は寄せる鍵がありません。移行前に、代表者名と所在地でリストを突き合わせる作業を一度は人手で通す必要があります。決算期の欠損もよく出る項目で、旧システムに入っていない先は登記情報や過去の申告書から埋め直すことになります。

権限設計は担当者単位で顧問先を絞るのが基本です。会計事務所は顧問先の財務情報とマイナンバーを預かる立場にあり、番号法に基づく安全管理措置として取扱担当者の限定と区域管理が要る領域。全職員が全顧問先を閲覧できる初期設定のまま運用を始めると、後から絞ろうとしたときに「見えていたものが見えなくなる」抵抗が出ます。操作ログは、誰がどの顧問先のどのデータを参照したかを記録できる製品を選んでおくと、退職者が出たときの確認ができます。

会計事務所の基幹システムの選定と導入に関するよくある質問への回答

検討段階で寄せられることの多い質問を、判断に直結する形で整理しました。

会計事務所の基幹システムと会計ソフトは何が違うのですか？

会計ソフトは顧問先の帳簿を作るための道具で、事務所内基幹システムは事務所の運営そのものを管理する仕組みです。前者が扱うのは顧問先ごとの仕訳と試算表と申告書、後者が扱うのは顧問先マスタ、申告期限、進捗ステータス、報酬請求、職員の工数。両者はデータ連携で繋ぎますが、役割は別です。「会計ソフトを入れているのに期限管理が表計算ソフトのまま」という状態が、後者の不在を示す典型的な兆候になります。

顧問先が何件くらいから基幹システムの導入を検討すべきですか？

件数だけで線を引くなら、顧問先が百件を超えたあたりが目安です。ただし件数より効くのは職員数で、担当者が三名を超えて「誰が何を持っているか」が所長の頭の中だけで管理できなくなった時点が実質的な導入時期。逆に顧問先が二百件あっても所長一人で回している事務所なら、期限管理の表計算ソフトを整えるほうが費用対効果は上です。判断は件数ではなく、情報が個人に閉じているかどうかで決めてください。

会計事務所向けパッケージと汎用のERPはどちらを選ぶべきですか？

会計事務所の業務を管理する目的なら、会計事務所向けパッケージです。汎用ERPは在庫・生産・購買のモジュールを含む構成でライセンス費用が発生する一方、会計事務所ではこれらがほぼ空欄になります。加えて汎用ERPの販売管理は商品を単価と数量で売る前提のため、月額顧問料と年一回の決算料とスポット報酬という異なる型を同時に扱うのが不得手。汎用ERPが候補になるのは、税理士法人が多拠点化して人事と経費精算の統制を優先する段階からになります。

既存のパッケージを残したまま一部だけシステムを作ることはできますか？

できます。会計税務の中核をパッケージに残し、顧問先ポータルや独自の報酬計算、収益分析のダッシュボードなど標準機能から外れる部分だけを個別開発する差分開発が現実的な選択肢です。前提となるのは、パッケージ側がデータをCSVやAPIで外部へ出せること。連携方法と更新頻度を先に確認してから機能を設計する順序を守れば、制度改正への追随はベンダーの保守範囲に残したまま、事務所固有の部分だけを作れます。

システムの入れ替えはいつ着手するのが安全ですか？

稼働は六月から八月、次点で十月に置いてください。一月から三月中旬の確定申告期、五月の三月決算法人の申告期、十二月から一月の年末調整期は教育の時間が確保できません。逆算すると、要件定義と製品選定は前年の秋から冬に始めるのが無理のない進め方。並行運用は二か月を上限とし、旧システムへの入力を止める日を着手時点で決めておくと、二重入力の常態化を避けられます。

関連記事

• 基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説：事業会社向けの基幹システムの構成領域と刷新手順の全体像に。
• 業務システムとは？種類・基幹システムとの違いと開発・導入形態の選び方：周辺の業務システムとの守備範囲の切り分けに。
• ERPとは？基幹システム・CRMとの違いと主な機能・導入の進め方を解説：汎用ERPのモジュール構成と機能範囲の確認に。
• オンプレミス型とクラウド型の基幹システム導入形態の違いと選定ポイント：導入形態を比較して決める段階に。