2026.09.20 業務システム

社会福祉法人の会計ソフト選定｜区分設計と請求・給与連携から決める判断軸

社会福祉法人向けの会計ソフトを比べ始めると、製品一覧と機能表が並びます。ところが機能表を突き合わせても、自法人にどれが合うかは決まりません。分かれ目になるのは機能の数ではなく、社会福祉法人会計基準が求める区分と帳票をどこまで機械で出し切れるか、そして請求システムや給与システムから来るデータをどの粒度で受けるかの二点です。この記事では製品名を挙げずに、省令の条文と厚生労働省の公表資料を手がかりに、選定で先に決めるべき項目と、パッケージで足りる範囲の線引きを業務システムの受託開発会社の目線で整理します。

まとめ：社会福祉法人の会計ソフト選定で先に決める区分設計と連携範囲

会計ソフトの必須要件は機能表ではなく省令で決まる。事業区分・拠点区分・サービス区分の3階層（社会福祉法人会計基準第十条）と、計算書類12種類（第七条の二）を出せることが出発点になる
差が出るのは附属明細書の側。19本のうち7本は法人全体、12本は拠点区分ごとに作る。拠点が増えるほど作成本数が増える構造を、ソフトが自動で吸収するかを見る
共通費の配賦は製品ごとに設定の自由度が大きく違う。基準を期中に変えられるか、按分結果を配賦前の数字まで遡って検証できるかを、デモの段階で自法人の科目で試す
請求システムと給与システムの接続は、月次の処理件数で決める。おおむね数百件までならCSV取込で回り、それを超えるか締め日が詰まる法人でAPI連携の投資が回収できる
拠点1か所・単一サービス区分・就労支援事業なしの法人なら、パッケージ単独で完結する。個別開発を挟む価値があるのは会計本体ではなく、請求・給与と会計をつなぐ変換部分に限られる

社会福祉法人会計基準が会計ソフトに課す三つの区分と計算書類の法定要件

一般企業向けの会計ソフトが社会福祉法人で使いにくい理由は、機能不足ではありません。作るべき帳票の単位そのものが違うためです。根拠は社会福祉法人会計基準（平成二十八年厚生労働省令第七十九号）にあり、ここを読むと選定時に確認すべき項目がそのまま出てきます。

事業区分・拠点区分・サービス区分を定める会計基準第十条の規定内容

第十条は「社会福祉法人は、計算書類の作成に関して、事業区分及び拠点区分を設けなければならない」と定め、第2項で「拠点区分には、サービス区分（社会福祉法人がその行う事業の内容に応じて設ける区分をいう）を設けなければならない」と続けます。条文はこの2項だけで、3階層が義務であることを短く言い切っています。

会計ソフト側でこれに対応するには、勘定科目の下に区分軸を持つのでは足りません。区分ごとに独立した計算書類を組み立てる構造が要ります。加えて第十一条が内部取引の相殺消去を求めるため、拠点間の繰入金や貸付金がある法人では、相殺前後の両方の数字を保持できるかが実務上の判断を分ける条件です。区分間の資金移動が年に数回でも発生するなら、この機能の有無は導入後の手作業量を直接左右します。

法人単位から拠点区分まで十二種類に及ぶ計算書類の作成範囲と省略規定

第七条の二は、各会計年度に作成する計算書類を具体的に列挙しています。貸借対照表が法人単位・内訳表・事業区分内訳表・拠点区分の4種、資金収支計算書が同じく4種、事業活動計算書が4種で、合計12種類です。様式も省令が指定しており、資金収支計算書は第一号第一様式から第四様式まで（第十七条）、事業活動計算書は第二号第一様式から第四様式まで（第二十三条）と決まっています。

ただし全法人が12種類すべてを作るわけではありません。第七条の二第2項が省略できる場合を3つ定めています。

法人の状態	省略できる書類
事業区分が社会福祉事業のみ	内訳表（貸借対照表・資金収支・事業活動）
拠点区分の数が1つ	内訳表と事業区分内訳表
事業区分内の拠点が1つ	事業区分内訳表

単一拠点の法人が作る書類は、法人単位と拠点区分の6種類まで減ります。ここを確認せずに「12種類すべてに対応」という機能表だけで比べると、自法人には要らない部分に費用を払う結果になるわけです。逆に将来の拠点増設が決まっているなら、増設時に内訳表が自動で立ち上がるかを契約前に確かめておく価値があります。金額表示は第二条の三により一円単位です。千円単位の表示しか持たない汎用ソフトは、この時点で候補から外れます。

附属明細書十九本と省略規定から逆算する会計ソフトの出力機能の必要水準

製品間で差が出るのは、計算書類より附属明細書のほうです。第三十条が19号まで列挙しており、しかも作成単位が途中で切り替わります。ここを手作業で埋めている法人は、決算期の負荷が拠点数に比例して増えていきます。

法人全体七本と拠点区分ごと十二本に分かれる附属明細書の作成単位

第三十条第1項は、第1号から第7号までを法人全体について、第8号から第19号までを拠点区分ごとに作成すると定めています。法人全体で作るのは借入金明細書、寄附金収益明細書、補助金事業等収益明細書、事業区分間及び拠点区分間繰入金明細書、同じく貸付金（借入金）残高明細書、基本金明細書、国庫補助金等特別積立金明細書の7本です。

残る12本は拠点ごとに作ります。基本財産及びその他の固定資産の明細書、引当金明細書、拠点区分資金収支明細書、拠点区分事業活動明細書、積立金・積立資産明細書、サービス区分間繰入金明細書、同じく貸付金（借入金）残高明細書などが該当する書類です。拠点が5か所ある法人なら、拠点側だけで単純計算60本の帳票を毎年作る計算になります。この数をソフトが自動生成できるかどうかが、決算作業の実所要時間を決めます。第3項により社会・援護局長の定めるところで省略が認められ、様式も第4項で局長が定めるため、省令本文だけでなく通知側の改正にソフトが追随する体制も確認対象です。

就労支援事業の明細書四本が必要になる事業所と不要な事業所の分岐

第十五号から第十八号は就労支援事業関係で固まっています。就労支援事業別事業活動明細書、就労支援事業製造原価明細書、就労支援事業販管費明細書、就労支援事業明細書の4本です。第十九号には授産事業費用明細書が続きます。就労継続支援A型・B型を運営していれば、この製造原価の系統が必要になります。

裏を返せば、保育所や特別養護老人ホームだけを運営する法人には、この4本は無縁です。就労支援向けの原価計算機能を売りにした製品は、そうした法人では費用対効果が合いません。自法人の事業が第十五号から第十九号に触れるかどうかを先に判定すると、候補は目に見えて絞れます。工賃計算や利用者ごとの作業実績の管理までソフトに求めるなら、会計ソフト単体ではなく就労支援の業務システム側との役割分担を決めておく必要があります。

拠点区分とサービス区分への共通費配賦で分かれる会計ソフトの実装差

区分が3階層あるということは、区分をまたぐ費用を必ず割り振るということでもあります。法人本部の人件費、複数事業が入る建物の水道光熱費、共用車両の燃料費。この配賦処理の作り込みが、製品ごとに最も差が出る部分です。

人件費と水道光熱費の配賦基準をソフト側にどこまで持たせるかの確認点

確認するのは3点に絞れます。配賦基準を科目ごとに別々に設定できるか、1つの費用を複数の基準の組み合わせで割れるか、基準となる数値（職員数・利用者数・面積・従事割合）を外部から取り込めるか。人件費は従事割合、光熱水費は面積か利用者数というように、基準は費用の性質ごとに変わります。すべての共通費を単一の比率で割る設計の製品は、監査での説明が苦しくなります。

従事割合の元データは勤怠システムや常勤換算の集計表にあります。ここを毎月手で入力し直す運用になっていないかを、デモの段階で実際の職員数を入れて試すと差が見えます。配賦率の登録件数に上限がある製品もあるため、サービス区分の数が多い法人では上限値も確認対象です。

期中の配賦基準変更と按分結果の検証で表面化する設定自由度の差

年度途中で新しいサービスを始めれば、配賦基準は動きます。ここで問われるのが、期首に遡らず当月以降だけ新基準を適用できるか、過去月を再計算したときに確定済みの月次資料と突き合わせられるかです。基準変更が全期間の再計算しか選べない製品では、変更のたびに月次報告の数字が動き、理事会資料との整合を取り直す作業が発生します。

検証面では、配賦後の金額から配賦前の元データと基準値まで画面上で辿れるかを見ます。監事監査や会計監査人から配賦の根拠を問われた際、その場で内訳を示せるかどうかで対応時間が変わります。集計結果しか保持せず、根拠をCSVの再出力でしか確認できない設計は、監査対応の工数が読めません。

障害福祉と介護の請求データを会計へ突き合わせる月次工程の組み立て

会計ソフトの導入で効果が出るかどうかは、会計ソフトの外側で決まることが多い領域です。社会福祉法人の収益の大半は介護給付費・訓練等給付費・委託費で、その計算は請求システム側にあります。両者をどうつなぐかが月次締めの速度を決めます。

国保連請求と会計の締めがずれる期間に生じる未収金計上の実務課題

障害福祉サービスも介護保険サービスも、国民健康保険団体連合会への請求は提供月の翌月に行い、入金はさらに翌月です。会計側では提供月に収益と未収金を立て、入金月に消し込みます。つまり月次決算を早く締めるほど、確定前の請求データを会計に取り込む必要が出てきます。

ここで効くのが取り込み単位です。利用者ごとの明細まで会計に入れると仕訳件数が膨らみ、サービス区分ごとの合計で入れると個別の消し込みができません。実務で落ち着きやすいのは、収益計上はサービス区分別の合計、未収金の管理は請求システム側という分業です。請求側の詳細な機能範囲や実績記録との接続は障害福祉ソフトの機能範囲と選定の判断軸で整理しているため、会計側の設計はその前提に合わせて決めると無駄がありません。

返戻や過誤調整が起きた月の仕訳修正を小さくする取り込み単位の設計

返戻や過誤申立が発生すると、確定額が当初の請求額からずれます。このとき明細単位で会計に取り込んでいると、修正仕訳も明細単位で起こす羽目になります。区分別の合計で取り込み、差額だけを調整仕訳で処理する方式にしておくと、返戻件数が増えた月でも会計側の作業量はほぼ変わりません。

取り込みの粒度は後から変えにくい設計判断です。導入時に「明細まで入れれば分析ができる」と考えて細かくし、数か月後に修正作業の多さで粗くし直す例は珍しくありません。決めるときの基準は単純で、その明細を会計側の画面で日常的に参照するかどうかです。参照しないなら会計に入れる理由はありません。

給与・勤怠の仕訳をCSV取込かAPI連携かで分ける費用と保守の判断基準

人件費は社会福祉法人の費用の中で最大の塊であり、しかも配賦基準の元データでもあります。給与システムと会計ソフトをどうつなぐかは、選定の中で最も費用差が出る判断です。どちらが優れているかではなく、どこで切り替わるかを数字で押さえます。

CSV取込で足りる条件と手作業が残る工程を分ける月次の処理件数

CSV取込は、給与システムから出力したファイルを会計ソフトの仕訳形式に整えて読み込む方式です。追加開発が不要で、多くのパッケージが標準で持っています。回るのは、月次の取り込みが給与・賞与・請求の数本で収まり、レイアウトが年に数回しか変わらない場合です。

手作業が残るのは変換の部分です。給与システムの支給項目コードと、会計側の勘定科目・拠点区分・サービス区分の対応づけは、たいてい表計算で維持されます。この対応表が数十行なら保守できますが、拠点が増えて数百行になると、改定のたびに誰が直すかという問題に変わります。目安として、月次で扱う変換行数が数百件を超える、または担当者が1人しか対応表を触れない状態になったら、方式の見直し時期です。

API連携を選ぶ判断とパッケージ標準機能では届かない範囲の見極め

API連携に切り替える価値があるのは、次の条件が重なったときです。月次の締めが数日しかなく手作業の待ち時間を削る必要がある、複数システムから同じマスタ（職員・拠点・サービス区分）を参照していて不一致が実害を出している、取り込み後の差額調整が毎月発生している。この3つのうち2つ以上に当てはまるなら、変換部分を作る投資は数年で回収できる範囲に入ります。

観点	CSV取込	API連携
初期費用	標準機能の範囲	変換部分の開発費
月次の手作業	出力と整形が残る	原則として無人
レイアウト変更	都度の手直し	改修で吸収
向く規模	1〜2拠点	3拠点以上

逆に、条件を満たさないのにAPI連携を選ぶのは過剰です。拠点1か所・職員数十名の法人で、給与の取り込みが月1回で済むなら、CSVのまま運用したほうが総費用は小さく収まります。判断を分けるのはシステムの新しさではなく、手作業の頻度と、その手作業が止まったときの影響範囲です。会計ソフトの標準機能では届かない変換部分だけを切り出して作る場合の設計は、API開発・システム連携の進め方と合わせて検討すると、投資範囲を会計本体まで広げずに済みます。

財務諸表等電子開示システムへの提出を見据えた出力とデータ整合の確認

作った計算書類は法人の中で完結しません。所轄庁への届出と、国民向けの公表という2つの出口があります。この出口の形が、勘定科目の設計にまで跳ね返ってきます。

電子開示システムで公表される書類と所轄庁へ出すだけの書類の違い

厚生労働省の財務諸表等電子開示システムの概要によると、このシステムは運営の透明性確保のための情報提供と、現況報告書・財務諸表等の様式作成を支援して届出を電子化し事務負担を軽減することを目的に、独立行政法人福祉医療機構が構築したものです。

同省が公表している届出書類と公表方法の一覧を見ると、経路が書類ごとに分かれていることが分かります。計算書類12種はいずれも届出・調査・公表の対象で、システムを通じて扱われます。一方で附属明細書は届出の対象ではあっても、公表事項からは外れる行が大半です。役員等名簿のように法人ホームページ等での公表となるものもあります。会計ソフトの出力が「システムに取り込める形」であることと、「所轄庁に出す紙の様式に合っていること」は別要件だと理解しておくと、導入時の検証項目を取り違えずに済みます。

勘定科目の独自追加が提出時の様式適合を崩す場面と運用での回避策

現場からは、管理のために科目を細かく分けたいという要望が必ず出ます。ここで省令の様式にない科目を上位階層に足すと、提出用の帳票を出す段階で様式に収まらなくなります。

回避策は単純で、様式に載る科目の階層は動かさず、その下に補助科目や部門コードとして持つことです。会計ソフトを選ぶ際は、様式用の集計階層と管理用の階層を分けて持てるか、補助科目の階層数と件数の上限がいくつかを確認します。上限が浅い製品では、管理要望を満たそうとして様式側の階層に手を入れることになり、決算期に集計し直す作業が生まれます。科目体系は一度動かすと過年度比較にも影響するため、導入前に管理側の要望を洗い出して階層設計に落としておくほうが安全です。

パッケージで足りる法人と個別開発を挟む法人を分ける規模と条件の線引き

ここまでの要件を並べると、すべてを作り込みたくなります。結論から言えば、会計本体を個別開発する理由はほとんどありません。法定要件が省令で固まっている領域は、パッケージの追随力に乗るほうが費用も改正対応も有利です。

拠点数と職員規模から見たパッケージ単独で運用できる法人の具体的条件

パッケージ単独で完結する条件は、次の3つが揃う場合です。拠点区分が1〜2か所でサービス区分が数個までであること、就労支援事業の原価計算が不要であること、給与と請求の取り込みが月数回で収まること。この範囲なら、社会福祉法人会計に対応した市販製品の標準機能と、表計算での変換表の維持で運用できます。

一方で、拠点が3か所を超えて配賦基準が科目ごとに分かれ、請求システムが障害福祉と介護で別々に動いている法人では、標準機能の外側に手作業が溜まります。この段階で検討するのは会計ソフトの乗り換えではなく、システム間をつなぐ部分の整備です。導入形態そのものの選び分けについては業務システムの導入形態と選び方に一般論をまとめてあります。

個別開発を挟むべきでない場面と連携部分だけを作る中間案の判断基準

個別開発を見送るべき場面ははっきりしています。第一に、会計基準の改正や様式変更に自前で追随する体制がない法人。省令本文だけでなく局長通知で様式が定まる構造上、改正のたびに改修費と検証工数が発生します。第二に、要望の中身が「画面が使いにくい」「帳票の見た目を変えたい」に留まる場合。これは製品の乗り換えか帳票ツールで解く範囲で、会計エンジンを作る理由になりません。

作る価値があるのは、会計と他システムの間に挟まる変換部分だけです。給与システムの支給項目を拠点区分・サービス区分つきの仕訳に変換する処理、請求システムの確定額と会計の未収金を突き合わせる処理、配賦基準の元データを各システムから集めて配賦表を作る処理。いずれも自法人の区分設計に固有で、パッケージが標準で持てない部分です。この範囲に限れば投資額は会計システム全体の刷新より小さく、会計ソフトを将来入れ替えるときも変換部分だけを作り直せば済みます。

社会福祉法人の会計ソフト選定でよくある質問と実務上の判断の目安

選定の現場で出やすい質問を、省令の規定と実務の運用に沿って整理します。

一般企業向けの会計ソフトを社会福祉法人で使うことはできますか？

計算書類の要件を満たせないため現実的ではありません。社会福祉法人会計基準第十条が事業区分・拠点区分・サービス区分の設定を求め、第七条の二が区分別の計算書類を定めています。一般企業向け製品は部門管理で近い形を作れても、拠点区分資金収支計算書のような様式指定のある帳票を出せません。金額表示も第二条の三で一円単位と決まっており、千円単位表示しか持たない製品は要件を外れます。

クラウド型とオンプレミス型はどちらを選ぶべきですか？

会計基準の改正対応を自法人で抱えないという観点では、クラウド型が有利です。省令の様式は局長通知で細部が定まり、改正時には帳票の更新が必要になります。クラウド型はこの更新が提供側で行われます。オンプレミス型を選ぶ理由が残るのは、施設のネットワーク要件で外部接続に制約がある場合や、既存の基幹システムと同一サーバで運用している場合です。いずれの形態でも、改正対応が保守契約に含まれるか別途費用かを契約書で確認しておきます。

拠点が1か所の法人でも附属明細書は全部作る必要がありますか？

作成本数は事業内容で変わります。第三十条は19号を列挙していますが、第1号から第7号は法人全体、第8号から第19号は拠点区分ごとの作成です。拠点が1か所なら後者は1セットで済みます。就労支援事業を行っていなければ第十五号から第十八号は不要です。加えて第3項で、社会・援護局長の定めるところにより省略できる旨が規定されています。該当する省略規定を先に確認してから、ソフトの出力機能と突き合わせます。

会計ソフトと請求システムは同じメーカーで揃えるべきですか？

揃えると取り込みは楽になりますが、選定順序としては請求システムを先に決めるほうが実務に合います。請求は報酬改定への追随が命綱で、制度領域ごとに得意な製品が分かれるためです。会計側は法定要件が共通なので、後から請求システムの出力形式に合わせて選べます。別メーカーの組み合わせでも、区分別合計での取り込みに設計しておけば月次の作業量は大きく変わりません。

導入時に必ず検証しておくべき項目は何ですか？

自法人の実データで3点を試します。前年度の決算数値を入れて計算書類12種（省略規定に該当するものを除く）が出るか、共通費を実際の配賦基準で割って按分結果から元データまで辿れるか、給与と請求のファイルを取り込んで手直しが何行残るか。機能一覧の確認ではなく、自法人の科目と拠点構成で動かすところまでを、契約前のトライアル期間に組み込んでおきます。