IT受託会社の資金戦略｜受託開発の分割請求は資金繰りを本当に改善するのか

IT受託会社専門｜資金戦略を設計する行政書士・外部CFO型パートナー

「着手金を入れたので、この案件は資金繰りが楽になるはずだ」。
受託開発の現場では、そう考えて判断を進めてしまう場面が少なくありません。

ですが、実際には、分割請求を入れたから安全になるとは限りません。

着手金が入っても、その後の人件費が先に出続ければ、月次では現金が減ります。

中間請求を置いても、検収条件が曖昧なら、予定した入金はズレることがあります。

粗利が見えていても、営業キャッシュフローが弱ければ、資金余力は思ったより早く細ります。
この論点で見たいのは、請求回数ではありません。

自社の固定費構造と案件ごとの入出金の並びを前提に、分割請求がどこを改善し、どこを改善しないのか。

その切り分けです。

分割請求は資金繰りを楽にする、とは言い切れない

受託開発の請求条件は、概ね「着手金」「中間請求」「検収請求」に分かれます。

着手時に一部を受け取る形は初期の資金流出を和らげやすく、中間請求は開発期間中の資金偏在を平準化しやすい。

一方、検収請求中心の契約は、売上は見えていても現金化が後ろに寄りやすい構造です。

もっとも、ここで注意したいのは、請求条件と資金安全性は一致しないという点です。

情報サービス・ソフトウェア産業では、多重かつ不透明な請負関係が一般化していることが中小企業庁のガイドラインでも指摘されており、検収基準や支払条件の曖昧さが下流の資金繰りに影響しやすい構造があります。

会計上の売上計上と入金は別です。

J-Net21が示すとおり、営業活動によるキャッシュフローは、当期純利益だけでなく、売上債権や債務の増減で動きます。

つまり、請求書を出したこと自体ではなく、いつ現金になるかで資金余力は変わります。

利益が出ていても現金が足りない、いわゆる「勘定合って銭足らず」は珍しい話ではありません。

IT受託会社でこのズレが重くなるのは、入金サイト60日問題があるからです。

仮に中間請求を入れても、月末締め翌々月払いであれば、現金化まで時間が空きます。分割請求は入金タイミングを前倒しする効果はありますが、入金サイトそのものを消すわけではありません。

受託開発のキャッシュフローは、請求条件だけでは決まらない

受託開発の資金繰りを難しくするのは、開発の途中で現金が出続ける点です。

エンジニア人件費は毎月発生し、外注費は先払いまたは先行負担になりやすい。採用広告や営業広告、教育費も案件の入金を待ってくれません。

J-Net21が示すように、営業キャッシュフローは売上債権の増減で大きく動くため、損益上の粗利だけでは安全性を測れません。

ここで見落としやすいのが、プロジェクトキャッシュフローです。

案件粗利率が高くても、前半に外注費と社内人件費が集中し、入金は後半に偏ることがあります。この場合、案件単体では黒字でも、会社全体の月次資金は圧迫されます。

人月モデルの会社ほど、稼働率が少し落ちただけで固定費吸収力が下がり、分割請求で得た前受け感覚が簡単に消えます。
分割請求が改善するのは、主に「初期の資金流出の緩和」と「一部のサイト短縮」です。

改善しないのは、「固定費総額」「稼働率低下による粗利の毀損」「検収遅延リスク」「案件横断での資金偏在」です。

この切り分けを誤ると、請求条件の見直しだけで安全性が上がったように見えてしまいます。

分割請求を設計するときに確認したい資金構造

確認したいのは、まず固定費構造です。

とくにエンジニア人件費比率が高い会社は、売上変動に対して固定費が重く、資金余力の目減りが速くなります。次に営業キャッシュフロー（以下、「営業CF」といいます）です。

営業CFが継続的にマイナスなら、粗利のある案件を積んでも現金が残りにくい状態です。

J-Net21でも、営業活動によるCFは売上債権の増加で減少しうることが整理されています。

そのうえで、固定費カバー月数を見ます。手元資金から、毎月の固定費相当額を何か月賄えるか。ここでいう固定費には、役員報酬、給与、外注のうち実質固定化している部分、地代家賃、採用費の継続負担、借入返済元金のうち実質的に月次を圧迫する部分まで含めて考えるほうが実務的です。
さらに、短期資金と長期資金を分けて考える必要があります。

日本政策金融公庫でも、運転資金と設備資金で返済期間の考え方を分けています。

請求の谷を埋める資金なのか、固定費構造そのものの再設計に使う資金なのかで、借り方は変わります。

運転資金を長期で抱えるか、長期課題を短期資金で回すかは、後から重く効きます。

判断基準は「何回請求できるか」ではなく「何か月持つか」

実務上の目安として、資金余力が3か月未満なら、分割請求を増やす議論だけで済ませないほうがよい場面が多いと考えます。

請求条件の見直しは必要でも、それだけで安全域に戻るとは限らないからです。
また、営業CFが数期または複数四半期で弱い、もしくは売上成長に対して売上債権の増加が先行している場合、分割請求は「見た目の平準化」には効いても、構造改善にはなっていない可能性があります。
DSCRは、簡潔にいえば元利返済をどれだけ事業キャッシュで賄えるかを見る指標です。

1.0倍を下回れば、返済を事業内で吸収できていない状態ですし、1.2倍前後でも案件ブレの大きい会社では余裕が薄いことがあります。

加えて、日本政策金融公庫の経営改善計画では、一般に債務償還年数は20年以内、できれば10年程度を意識する考え方が示されています。

返済余力を見るときは、単月利益ではなく、年間を通したキャッシュ創出力で確認したいところです。

金融機関は分割請求そのものより、資金管理の一貫性を見る

金融機関が見ているのは、「着手金があるから安心」という単純な話ではありません。

案件ごとに請求条件が違うなら、その違いが月次資金繰りにどう出るのか説明できるか。

借入金の使途が、請求サイトの谷を埋める短期運転資金なのか、固定費構造を支える長期運転資金なのか整理できているか。

そこに一貫性があるかを見ます。
日本政策金融公庫の資料でも、目標は数値で示し、月次試算表などでモニタリングし、金融機関へ定期的に報告することの重要性が示されています。

金融機関評価は、請求条件の巧拙よりも、数字管理の継続性で変わることが多いものです。

SESと受託開発では、分割請求の意味が異なる

SESは月次請求が前提になりやすく、人月売上と請求の連動が比較的見えやすいモデルです。

もちろん入金サイトの長さや稼働率低下の影響はありますが、請求の分割そのものが論点になる場面は相対的に少ない。
一方、受託開発は、着手金の有無、中間請求の置き方、検収条件、変更契約の扱いで資金構造が揺れやすい。

しかも、同じ年商でも、前受けが厚い会社と検収一括中心の会社では、必要な運転資金量が変わります。

ここを一緒に扱うと判断を誤ります。

分割請求は、受託開発においては請求実務ではなく、資金構造設計の一部として見るほうが実態に近いはずです。

まとめ

受託開発の分割請求は、たしかに資金繰りの一部を改善します。

ですが、それは主として入金タイミングの前倒しや偏りの緩和であって、固定費の重さ、稼働率低下、検収遅延、案件横断の資金偏在まで解消するわけではありません。
問うべきなのは、「何回請求できるか」ではなく、「その設計で自社の資金余力は何か月確保できるのか」です。

請求条件の改善を入口にしつつも、最終的には固定費構造、営業CF、返済余力、借入の期間設計まで通して見ないと、判断は浅くなります。

資金戦略は、一般論で決められるものではありません。
同じIT受託会社でも、入金サイトや固定費構造によって最適解は変わります。
重要なのは、「借りられるか」ではなく「今、借りるべきか」を判断できる状態をつくることです。
まずは自社の数字を整理することから始めてみてください。

参考にした公的情報

• 「情報サービス・ソフトウェア産業における 中小受託適正取引等の推進のためのガイドライン」／中小企業庁
• 「ソフトウェア業の下請取引等に関する実態調査報告書」／公正取引委員会
• 「経営基盤を強化するキャッシュフロー経営とは？」／J-Net21（独立行政法人中小企業基盤整備機構）
• 「キャッシュフロー計算書の見方と活用方法について教えてください。」／J-Net21（独立行政法人中小企業基盤整備機構）
• 「経営環境変化対応資金（セーフティネット貸付）」／日本政策金融公庫
• 「経営目標を達成するための経営改善計画」／日本政策金融公庫