システム開発会社の資金繰り改善｜検収遅れ・外注費・人件費の対策

本ページにはプロモーションが含まれています。契約類型、検収、取適法の適用、会計・税務、雇用・外注、融資条件は取引と事業形態で異なります。重要な判断は契約書と公的な現行資料を確認し、必要に応じて弁護士、税理士、社会保険労務士等へ相談してください。

システム開発会社では、エンジニアの給与や外注費を毎月支払う一方、売上の入金は納品・検収後になることがあります。大型案件を受注して売上が増えても、開発期間が長く、仕様変更や検収遅れが重なると手元資金は減ります。

最初に行うのは、全社の月次売上だけを見ることではありません。案件ごとに契約額、請求条件、検収予定日、入金予定日、社内工数、外注費、クラウド費を並べ、13週間の最低残高を確認します。

この記事では、受託開発会社の資金繰りが苦しくなる原因、案件別管理、請負・準委任の整理、検収と仕様変更、外注費、取適法、契約条件の改善、支払いが迫る時の対応を解説します。

受注額が増えていても、入金前に給与・外注費を立て替える期間が長ければ資金繰りは悪化します。

システム開発会社の資金繰りが苦しくなる理由

人件費が毎月先に出る

システム開発は、売上原価に占める人件費の影響が大きい事業です。社員の給与、社会保険料、賞与、採用費、教育費は、顧客からの入金が遅れても支払いが続きます。

日本政策金融公庫のソフトウェア開発業の創業ポイントも、資金計画と収支計画、人材の確保・育成、運転資金の準備を挙げています。

案件開始から入金まで6か月かかる場合、その間の人件費を自社で立て替えることになります。売上総利益が出る案件でも、立替期間の現金がなければ継続できません。

外注費の支払いが元請け入金より早い

協力会社やフリーランスへの支払いが翌月末で、顧客からの入金が検収後翌々月末なら、外注費を1か月以上先に支払います。

二次請け、三次請けの商流では、発注元の検収状況が自社の請求時期へ影響する場合があります。一方、自社から外注先への支払期日は別契約です。上流の入金が遅れたことだけを理由に、外注先への支払いを当然に遅らせることはできません。

検収と修正で請求が後ろ倒しになる

納品後に顧客の受入テストが始まり、指摘対応が長引くと検収日が遅れます。契約が「検収後に請求」となっていれば、請求書の発行と入金も後ろへずれます。

検収条件が曖昧なまま開発すると、障害修正、仕様変更、追加要望の境界が分からなくなります。無償対応が増えるだけでなく、請求可能な状態へ到達しにくくなります。

クラウド費とライセンス費が増える

開発・検証・本番環境のクラウド費、SaaS、開発ツール、セキュリティ製品、端末、回線等は、プロジェクトの進行中に発生します。

顧客へ実費請求できるもの、自社負担するもの、共通費として配賦するものを分けないと、案件別の利益が実態より良く見えます。

大型案件への依存が高い

1社・1案件の売上比率が高いと、検収延期、仕様凍結、予算変更、契約終了が全社の資金繰りへ直結します。案件単体の採算だけでなく、入金集中度と継続受注の確度も確認します。

利益が出る予定の大型案件でも、入金前の立替額が手元資金を超えるなら受注条件の見直しが必要です。

全社黒字でも、複数案件の人件費と外注費が同時に先行すれば現金は不足します。

案件別の資金繰り表を作る

契約・請求・原価を1行でつなぐ

案件管理表には、営業情報だけでなく入出金情報を入れます。

項目	確認する内容
契約	契約額、契約類型、期間、成果物
請求	着手金、中間金、月次、検収後
入金	請求予定日、支払サイト、入金予定日
社内原価	担当者、予定工数、実績工数、人件費
外注原価	発注額、支払条件、支払予定日
その他原価	クラウド、ライセンス、旅費、機器
変更	追加要望、見積、承認、追加請求
採算	予定粗利、見込粗利、完成時粗利

案件番号を請求書、外注発注、工数、経費へ共通で付けると、集計しやすくなります。

予定と実績を分ける

受注時の予定工数だけでは判断できません。毎週、消化工数、残工数、追加要望、完了見込みを更新します。

予定1,000時間の案件が、途中で1,300時間の見込みになった場合、契約額が同じなら粗利は下がります。追加300時間について、障害対応なのか、当初仕様なのか、仕様変更なのかを整理します。

13週間の入出金へ落とす

案件管理表から、実際の入金予定と支払予定を13週間の資金繰り表へ転記します。売上計上日ではなく、銀行口座へ入る予定日を使います。

週	主な入金	主な支出	週末残高
第1週	保守月額、前月請求	給与、外注費	計算
第2週	中間金	クラウド、税金	計算
第3週	SES月次請求	採用費、家賃	計算
第4週	検収案件	社会保険料、返済	計算

「予定どおり検収」「検収が2週間遅れる」「追加修正で1か月遅れる」の3パターンを作ると、不足日を早めに把握できます。

未請求と請求漏れを確認する

月次作業報告、検収書、納品書、請求書のどこで止まっているかを一覧にします。担当者だけが顧客の承認状況を把握している状態を避けてください。

請求予定日を過ぎた案件は、営業、プロジェクト責任者、経理が同じ画面で確認します。支払サイトの計算方法も使い、締日と支払日を正しく資金繰り表へ入れます。

案件別採算表と13週間資金繰り表をつなぎ、検収が遅れた場合の最低残高まで確認します。

請負・準委任・保守の入金条件を分ける

契約名だけで判断しない

システム開発では、請負、準委任、保守・運用、ライセンス、クラウド利用等が組み合わさることがあります。

一般に、成果物の完成を目的とする契約と、一定の業務遂行を目的とする契約では、完了確認や請求条件が異なります。ただし、契約書の名称だけで法的性質が決まるとは限りません。実際の業務、成果物、指揮命令、責任分担を契約ごとに確認します。

請負は工程ごとの支払いを検討する

要件定義、基本設計、詳細設計、開発、テスト、移行を一括で最終検収後払いにすると、長期間の立替が発生します。

工程ごとに契約や検収を分ける、着手金を設ける、中間成果物で請求する方法を交渉します。分割する場合は、各工程の成果物、完了条件、金額、検査期間、支払日を明確にします。

準委任は月次の作業確認を早める

月次精算の契約では、作業報告書の提出と承認が遅れると請求も遅れます。月末に初めて確認するのではなく、週次で稼働、課題、承認者を共有します。

精算幅、超過・控除、休暇、待機、再作業の扱いも事前に決めます。稼働時間だけでなく、請求単価と人件費・外注単価の差を確認してください。

保守・運用は定額と追加作業を分ける

月額保守に含む作業範囲が曖昧だと、小規模改修や問い合わせ対応が無制限に増えます。

定額範囲、受付時間、対応回数、SLA、追加作業の見積条件を分けます。保守売上が安定していても、担当工数が増え続ければ利益と人員余力が減ります。

契約類型ごとに、何をもって請求できるか、誰がいつ承認するかを契約前に決めます。

検収遅れと仕様変更を防ぐ

IPAの情報システム・モデル取引・契約書は、ユーザ企業とITベンダの取引構造を透明化し、各開発段階の責務を整理するための解説と契約書ひな型を提供しています。

ひな型をそのまま使えば全案件に適合するわけではありませんが、役割、成果物、変更、検査、責任を話し合う材料になります。

検収条件と期間を契約へ入れる

検収対象、テスト環境、受入基準、検査期間、指摘方法、再検査、みなし検収の扱いを確認します。

顧客側の検査担当者と決裁者も明確にします。納品後に「確認する人が決まっていない」「本番データを用意できない」と判明すると、検収が止まります。

仕様変更は変更管理票へ残す

追加要望を口頭やチャットだけで受けず、次の項目を残します。

• 変更内容と理由
• 当初仕様との違い
• 追加工数と金額
• 納期への影響
• 検収条件への影響
• 承認者と承認日

軽微な変更であっても、積み重なると工数超過になります。無償範囲と追加見積の基準をプロジェクト開始時に共有します。

障害と仕様変更を切り分ける

契約不適合や障害として対応すべきものと、当初合意にない機能追加を混同しないでください。開発会社が一方的に決めるのではなく、要件定義書、議事録、テスト仕様、承認記録をもとに顧客と確認します。

請求準備を納品前に始める

検収書の様式、請求書の送付先、購買番号、締日、電子請求システム、担当者を納品前に確認します。顧客の経理手続を納品後に知ると、請求が1締め遅れることがあります。

検収遅れは開発部門だけの問題にせず、営業・経理を含めて請求予定日まで管理します。

追加要望は工数だけでなく、検収日と入金日への影響まで合意してから着手します。

エンジニア人件費・外注費・クラウド費を管理する

人月単価だけで粗利を見ない

売上単価から給与だけを引くと、採用費、社会保険料、賞与、待機、教育、PC、オフィス、管理者工数が漏れます。

社内原価率は会社の会計方針に合わせて設定し、案件比較用の基準を統一します。細かすぎて更新されない表より、毎月更新できる原価基準を優先します。

稼働率と案件間の空白を確認する

100%稼働を前提にすると、案件間の待機、有給休暇、研修、営業支援、社内業務を吸収できません。

今月の稼働だけでなく、3か月後のアサイン予定を確認します。大型案件の終了直後に複数人が待機すると、人件費負担が一気に増えます。

外注先への発注条件を明確にする

外注する範囲、成果物、期間、単価、精算、検査、再委託、知的財産、セキュリティ、支払期日を記録します。

顧客との契約条件をそのまま外注先へ押し付けられるとは限りません。自社が負うリスクと外注先が負うリスクを整理し、上流入金に依存しない支払計画を作ります。

クラウド費を案件タグで集計する

クラウドアカウント、プロジェクト、環境、タグを案件に紐付けます。開発終了後もテスト環境やログ保管が残ると、請求終了後に費用だけが続きます。

停止・縮小の判断日、データ保管期間、顧客負担分、為替変動を確認します。顧客の承認なく利用料を追加請求できるとは限らないため、契約時に扱いを決めます。

案件粗利には給与・外注費だけでなく、待機、管理者工数、クラウド、ライセンスを反映します。

売上単価が高い案件より、入金までの立替と完成時粗利を含めて現金を残せる案件を評価します。

多重委託と取適法の注意点

2026年1月に、従来の下請法は中小受託取引適正化法、通称「取適法」へ改められました。

公正取引委員会の取適法の概要によると、対象取引は事業者の資本金規模または従業員基準と取引内容で定義され、情報成果物作成委託や役務提供委託も含まれます。

すべてのシステム開発契約へ一律に適用されるわけではありません。発注側・受注側の規模と委託内容を確認してください。

発注条件を書面・電磁的記録で残す

公正取引委員会の委託事業者の義務は、対象取引について、給付内容、受領期日、検査完了期日、代金、支払期日等の具体的事項を示しています。

自社が受注側の時だけでなく、協力会社へ委託する時は自社が発注側になります。元請けから発注書が届かないことと、自社が外注先へ必要事項を示す義務は別に考えます。

検収日を恣意的に延ばさない

対象取引では、検査の有無や検査期間を理由に、法令上の支払ルールを外れる扱いはできません。受領日や役務提供期間、支払期日の考え方は委託内容によって確認します。

「顧客が検収していないから外注先にも払わない」という連動条件だけで処理せず、各契約と取適法の適用を確認してください。

価格変更は協議と根拠を残す

人件費、クラウド費、セキュリティ対応等が上がった場合、価格改定の根拠を用意して協議します。発注側としても、受注側から協議の申出があった時の窓口と記録を整えます。

中小企業庁の取引適正化ガイドラインには、情報サービス・ソフトウェア産業の現行ガイドラインが掲載されています。

取適法の適用は会社規模だけで決めず、取引内容と発注・受注の立場を案件ごとに確認します。

着手金・中間金・月次請求へ条件を変える

着手金で開始時の立替を減らす

要件定義前の調査、環境構築、採用、外注手配等が必要なら、着手金を交渉します。着手金の対象作業、返金条件、契約解除時の精算も決めます。

受注を取りたいからといって、すべて最終検収後払いにすると、自社が顧客の開発資金を負担する形になります。

工程別の中間金を設定する

要件定義完了、基本設計完了、開発完了、受入テスト完了など、確認可能な節目で請求します。

節目を細かくしすぎると事務負担が増えるため、金額と期間に応じて設定します。中間金を設定しても、成果物・完了条件が曖昧なら請求時に争いになります。

長期開発は月次精算も検討する

仕様が変化しやすい開発では、固定額の一括請負だけでなく、準委任や月次精算が適する場合があります。

契約類型の選択は、責任を避けるためではなく、開発の不確実性、役割分担、成果物、予算管理に合わせます。法的な評価は専門家へ確認してください。

支払サイト短縮を価格と一緒に交渉する

単価だけでなく、締日、請求日、支払日を交渉します。単価が同じでも、入金が30日早まれば立替資金は減ります。

顧客の経理ルールで変更できない場合は、着手金や中間金、工程分割、外注先との支払条件等を組み合わせます。

支払いが迫る時の対応

直近7日と13週間を確定する

現預金、確定入金、給与、社会保険料、外注費、クラウド費、税金、家賃、返済を日付順に並べます。

「月末に足りない」ではなく、何日にいくら不足するかを出します。運転資金が足りない時の対策も使い、短期対応と収益改善を分けます。

検収・請求の停滞を解消する

未請求案件を、納品前、顧客確認中、修正中、検収待ち、請求手続中に分けます。担当者、次の行動、期限を付けます。

契約や法令を無視して一方的に請求するのではなく、顧客と合意した手続を進め、必要な成果物・証跡をそろえます。

支払先へ期限前に相談する

給与や外注代金を無断で遅らせないでください。支払いが難しい場合は、法令と契約を確認し、期限前に金融機関、税理士、弁護士、社労士等へ相談します。

短期の資金不足に対応しても、赤字案件を継続すれば再発します。追加開発の見積、要員変更、不採算案件の終了を同時に検討します。

融資は不足理由と回収計画を説明する

金融機関へ、受注残、案件別粗利、請求予定、入金予定、外注費、資金繰り表を示します。

運転資金の使途を「事業資金」とだけ説明せず、どの案件で、いつまでに、いくら立て替え、いつ回収するかを整理します。

確定売掛金があれば資金化を比較する

提供済み・請求済み等の確定したBtoB売掛金があり、入金前の給与や外注費が不足する場合、ファクタリングを比較できる可能性があります。

ファクタリングの仕組みを確認し、売掛先、債権額、支払期日、譲渡禁止特約、二重譲渡の有無等を整理します。将来完成する予定だけの案件を、確定した請求書と同じに扱わないでください。

ファクタリング手数料の計算方法で手取りを確認し、手数料を払っても案件の利益と翌月資金が残るかを見ます。資金化した売掛金の入金月には、同じ売上を再び使えない点も資金繰り表へ反映します。

資金調達だけで終わらせず、検収・請求・赤字案件の原因を同じ週に修正します。

よくある質問

Q: システム開発会社はなぜ黒字でも資金不足になりますか？

A: 給与・外注費・クラウド費を先に支払い、売上は納品・検収後に入るためです。案件別の利益が出ていても、立替期間が長ければ現金が不足します。

Q: 検収が遅れたら支払いも無期限に遅れますか？

A: 契約と適用法令を確認する必要があります。検収条件・期間・支払期日を事前に定め、停滞時は証跡をそろえて顧客と確認してください。取適法対象取引では同法の支払ルールも確認します。

Q: 請負と準委任はどちらが資金繰りに有利ですか？

A: 一律には決まりません。請負でも着手金・中間金を設定でき、準委任でも報告承認が遅れれば請求が遅れます。業務の実態と請求条件を合わせて比較します。

Q: 追加仕様を無償で対応すべきですか？

A: 当初仕様、障害対応、契約上の責任、追加要望を資料で整理してください。追加要望なら、工数・金額・納期・検収への影響を見積もり、承認後に着手する運用が重要です。

Q: 取適法はすべてのシステム開発取引に適用されますか？

A: すべてではありません。発注側・受注側の資本金または従業員基準と、情報成果物作成委託・役務提供委託等の取引内容で判定します。

Q: システム開発の売掛金はファクタリングできますか？

A: 提供済み・請求済み等の確定したBtoB売掛金なら相談できる可能性があります。未完成案件や将来の受注見込みを、確定債権と同じに扱わないでください。

まとめ

システム開発会社の資金繰りは、受注額や月次売上だけでは判断できません。案件ごとに入金日、社内工数、外注費、クラウド費、検収状況を管理します。

請負、準委任、保守では請求条件が異なります。検収基準、変更管理、着手金、中間金、月次請求を契約前に整え、無償の仕様追加と請求遅れを防いでください。

取適法は、会社規模と取引内容で適用を確認します。自社が受注側の時だけでなく、協力会社へ発注する時の条件と支払いも整えます。

資金繰り改善の中心は、案件別採算と入金日を結び、検収遅れが起きても給与と外注費を支払える状態を作ることです。