売掛回収・現金耐性・日本の事業形態判断

Executive Summary

• 請求、provider 残高、入金予定を銀行現金と呼ばない。 契約、履行、受入、請求、期限、回収、provider settlement、payout、銀行着金を別 event にする。13 週判断は gross の authoritative bank cash を起点に、重複のない commitment と active reserve を控除する。
• 回収は強く迫る作業ではなく、事実と摩擦を解く運用である。 穏当な reminder、正しい支払窓口、紛争分岐、頻度上限を持ち、service hold、外部回収、債権放棄は人が契約・法令・顧客影響を確認して承認する。
• 現金耐性は期末残高でなく、13 週間で最も低くなる余裕で測る。 税・社会保険、返金・dispute、年額前受の未履行、事業継続 reserve を先に控除し、売掛、promise-to-pay、pending payout、未実行融資枠、保険限度額は加えない。
• 個人事業、合同会社、株式会社を単一の利益額で選ばない。 同じ 36 か月 scenario で事業 cash、家計 cash、社会保険、税、事務、設立・終了・移行、保証・責任、調達適合を比較し、税率や普遍的な「法人化ライン」をモデルへ固定しない。

基準日: 2026-08-02
対象: 日本で Web app、SaaS、AI service を一人または小規模に運営する technical founder
判断主体: founder。個別の法律、税務、会計、社会保険、債権回収、融資、保険、factoring、法人設立は該当専門家と確認する。

この章は一般教材であり、個別の法律・税務・会計・社会保険・金融・投資助言ではない。法令の適用は、当事者、従業員、資本金、委託内容、契約期間、履行事実、地域、課税状態等で変わる。live action の前に、実行日時点の一次資料と弁護士、税理士、社会保険労務士その他の適切な専門家へ確認する。

本文、付属 pack、SQLite companion の fixture に登場する ID、顧客、契約、金額、日数、税・社会保険、回収率、残高、判断結果は fully synthetic である。ただし、一次資料へ直結した「Current facts snapshot」の法定・行政上の金額と期限は、明示した確認日時点の実在する reference fact であり、fixture ではない。それらも外部 benchmark、将来予測、推奨値、個別の法人化推奨ではなく、実行時に再確認する。公開物へ氏名、住所、連絡先、口座、カード、credential、納税者番号、個人番号、実 customer document を入れない。

この章は請求後から銀行現金までを受け持つ

本章は会計や契約の基礎を繰り返すのではなく、既存章の出力を一つの cash decision へ接続する。

正本	受け持つ問い	本章へ渡すもの
02 章	P&L、貸借、cash flow、価格、unit economics	売上・費用・前受・売掛を混ぜない基礎
06 章	日本の security、privacy、契約、税務の共通入口	適用法、電子記録、税務・法務の確認先
09 章	founder household、時間、13 週資金繰りの基礎	家計 cash、最低残高、予定入出金
11 章	B2B 契約、invoice、credit note、入金、更新	contract・invoice・payment event
15 章	portfolio cash waterfall、continuity reserve、sunset liability	製品別義務と終了 cash
18 章	reseller / partner / contractor の責任と採算	seller、invoice、bad-debt、commission owner
20 章	machine payment の settlement、delivery、reversal	provider・wallet・delivery の検証済み event
21 章	請求後の回収証拠、provider-to-bank、cash stress、貸倒境界、事業形態	13 週判断と 36 か月 entity decision

付属物は次の二つである。

• cash resilience and entity choice pack: 与信・契約、売掛 event、aging、ethical dunning、provider-to-bank、reserve、13 週 stress、事業形態、移行、Codex handoff を複製する 14 書式。
• SQLite companion: 売掛や pending payout の現金昇格、貸倒状態の混同、reserve 欠落、TEST / REAL 混在、stale な entity assumption を fail closed にする完全架空の参考実装。

章、pack、SQL の一件を cash_resilience_contract_id / contract_version で結ぶ。この ID は権限、現金、契約成立、法的効力を証明しない。各 event は authoritative object、version、occurred / recorded / effective time、source、review を別に持つ。

証拠は便宜上、E0_INFERENCE から E5_BANK_TAX_LEGAL_AUTHORITATIVE までに分ける。予測・会議メモを scenario には使えても、銀行現金、法的債権放棄、税務上の貸倒へ昇格させない。provider dashboard は provider 内状態の正本になり得るが、銀行 cash の正本ではない。

利益、請求、provider 残高、銀行現金を分ける

現金不足の多くは、金額の計算より ontology の混同から始まる。 次の行を同じ balance 列へ押し込まない。

状態	authoritative evidence	言えること	まだ言えないこと
利益	会計方針に沿う帳簿・決算	期間損益	今日支払える現金
booking / 契約額	有効な契約・注文	約束された対価	履行、請求、回収
invoice	送達済み請求書と契約	請求した額・期日	受入、支払、銀行着金
receivable	履行・受入・invoice・credit の event	未回収債権の管理残高	全額回収可能、用途制約なし cash
provider pending balance	provider の検証済み event	provider 内で保留中の残高	available、payout、銀行着金
provider available balance	provider ledger	provider 規約上、出金等へ使える可能性	返金・dispute・reserve・fee 後の銀行 cash
payout initiated / paid	provider payout object	provider 側の出金段階	自行への着金
bank receipt	銀行明細と一意な movement	銀行に観測された入金	売掛への正しい消込、将来義務なし
prepaid credit	provider の credit ledger・条件	特定 provider で将来利用できる残高	返金可能な銀行 cash
credit / insurance / factoring limit	有効な契約・見積	条件付きの資金候補	実行済み financing cash

13 週の authoritative opening cash は、原則として対象口座の internal reserve 控除前の gross 銀行残高 から作る。active reserve は後段で一度だけ控除する。provider available balance は near-cash driver として別表示できるが、opening bank cash へ加えない。opening balance に既に含まれる銀行 movement を期間入金として再加算しない。

UNKNOWN、N/A、FAILED、NOT_DUE と、実測した 0 は別である。確認できない reserve をゼロにしない。credit note は receivable の減額であって cash receipt ではなく、借入実行額は cash inflow でも revenue ではない。

未回収でも、権利が確定した掛売上が売上・所得へ先に入る場合がある。国税庁の 令和7年分 収支内訳書（一般用）の書き方も、年末時点の未回収掛売上をその年の売上へ含める例を示す。会計利益、所得税・消費税の cash timing、銀行着金を分け、課税関係は採用する会計・申告方法と事実を税理士へ確認する。

年額前受は銀行へ着金していても全額を unrestricted としない。残存提供、返金、移行、終了、障害対応等の current obligation に対応する reserve を別に置く。02 章の会計区分と、15 章の portfolio waterfall を壊さず、本章では「今後 13 週に使ってよいか」を追加判定する。

売掛は event chain と aging で追う

一つの上書き status では、後から dispute や backdated acceptance が入り、過去判断まで静かに変わる。append-only event から snapshot_as_of 時点の状態を導出する。

CONTRACTED
  → PERFORMANCE_RECORDED
  → ACCEPTANCE_RECORDED | ACCEPTANCE_DISPUTED | ACCEPTANCE_NA_WITH_BASIS
  → INVOICED
  → NOT_DUE
  → DUE
  → OVERDUE
  → PROMISED | DISPUTED | COLLECTION_ACTIVE | SERVICE_HOLD_REVIEW
  → PARTIALLY_PAID | PAID | CREDITED | OPERATIONALLY_FROZEN
  → ACCOUNTING_WRITE_OFF_RECORDED
  → TAX_BAD_DEBT_QUALIFIED | TAX_BAD_DEBT_NOT_QUALIFIED | TAX_BAD_DEBT_UNKNOWN
  → RECOVERED_AFTER_WRITE_OFF

最低限、次の時計を分ける。

clock	用途
occurred_at	履行、受領、入金等が実際に起きた時刻
recorded_at	自社台帳へ記録した時刻
effective_at	credit、契約変更、法的処理等の効力時点
due_at	契約・適用法から導いた支払期日
snapshot_as_of	その判断に使えた情報の cutoff
maturity_at	返金・dispute・回収 outcome 等を評価する時点

aging は単に 30 / 60 / 90 の列を作るだけでは足りない。NOT_DUE / DUE / OVERDUE、期限経過日数、元本、currency、dispute、promise、credit、回収 action、最終接触、最大顧客集中を同じ snapshot で見る。aging bucket の閾値は自社契約と review cadence に合わせ、法定期限や税務資格を bucket 名から推定しない。

cash allocation は銀行 receipt を超えず、invoice 未消込残高を超えず、一つの bank object を一度だけ使う。部分入金、複数 invoice の一括入金、fee 差引、外貨、返金、chargeback は allocation event を分ける。write-off 後の回収は過去 event を消さず、RECOVERED_AFTER_WRITE_OFF として税務・会計の再調整へ渡す。

driver は次のように定義する。

• overdue_at_risk_exposure: 有効な期日を過ぎ、銀行入金で未消込の元本。dispute、credit、write-off を内訳化する。
• receivable_collection_lag_days: cohort と censoring を明示し、agreed due clock と bank cash clock を混ぜない。
• matured_collection_yield: outcome を見る前に eligible_receivable_cohort_id / eligibility_as_of / maturity_rule_version を固定する。分母は cutoff までに maturity を迎えた eligible invoice の gross principal から、その時点までに authoritative に発効した credit だけを控除した額、分子は cutoff までに bank receipt が元本へ applied された額とする。dispute、operational freeze、accounting / tax write-off は分母へ残し、breakdown として表示する。
• largest_customer_overdue_share: overdue exposure に占める最大顧客の比率。売上集中とは別に見る。

未成熟案件だけを除いて高い回収率を見せたり、回収後に collectible を再定義して dispute・freeze・write-off 案件を分母から外したりしない。少数顧客では比率と同時に 銀行消込済み元本 / maturity 済み eligible 元本 を表示する。

契約前の制御と日本の支払ルールを先に固定する

回収力は督促文面より契約前に決まる。payer、bill-to、発注権限、PO、業務範囲、履行日、受領・受入、変更、invoice trigger、具体的支払日、tax、振込費用、dispute route、service terms、知財、終了時精算を一枚の credit / contract card にする。

2026-08-02 の制度状態

状態	制度	本章へ入れる境界
現行	フリーランス法・公取委 Q&A	2024-11-01 施行。従業員を使用しない個人や、代表者一人・他の役員と従業員なしの法人も対象になり得る。全発注事業者の取引条件明示と、発注者の体制に応じた受領等から 60 日以内かつできる限り短い支払等を transaction ごとに確認する。
現行	取適法・施行時の留意事項	2026-01-01 以後の対象発注に適用。委託類型、資本金、資本金基準で捕捉されない場合の従業員基準を確認し、発注明示、記録、60 日以内支払、手形禁止、価格協議、振込手数料等を反映する。Web app でも「プログラム作成委託」等の実態で判定する。
現行の執行例	広告業における集中調査、2026-06-29	invoice の提出遅れを法定支払遅延の一般的な正当化にしない。納品・役務、変更・取消、知財、無償保管、振込費用を別事実にする。
現行	知的財産権・ノウハウ・データの適切な取引のための指針・契約書ひな形、2026-06-24	意見募集後に一部変更して確定公表された全業種向け指針。既存技術、成果、対価、知財帰属等を確認する入口であり、個別契約と事実認定を置換しない。
未施行	製造委託等の代金支払に関する特定の不公正な取引方法・運用基準	2026-06-18 告示、2027-04-01 施行。取適法の規模要件外でも、取引上の地位が劣る受注者への一定の 60 日超支払を独禁法上扱う将来ルール。2026 年の現行義務として扱わない。
案・未確定	取適法運用基準・フリーランス法の考え方の改正案、2026-06-24	上記の確定した知財取引指針を踏まえ、両法の解釈・考え方を明確化する別の改正案。執筆基準日時点では意見募集後の確定版を確認できないため、現行義務へ先取りしない。

フリーランス法と取適法は同じではない。たとえば、フリーランス法だけに取適法の一律の手形禁止をそのまま移植しない。一方、両方が適用される取引では、各法の義務を別々に満たす。標準 SaaS の一般販売が直ちに業務委託になるとも限らないため、顧客仕様の開発、専用連携、移行、継続役務と off-the-shelf subscription を分ける。

契約上の期日を invoice 到着だけへ依存させず、受領・役務提供・検査・invoice・具体的支払日を別 field にする。公取委 Q&A は、プログラムをメール等で納品した場合、発注者側の computer に記録された時点を受領時点として説明する。月締めの「2か月」運用など具体的な数え方もあるため、自作の単純な 60 * 24h timer で法的結論を出さない。

通常の金銭債権については、契約上の遅延損害金、特別法、民法を区別する。法務省は 2026-04-01 から 2029-03-31 の法定利率を年 3% と公表しているが、取適法の遅延利息などを置換する数字ではない。モデルへ一律 rate を埋め込まず、債権ごとに current basis と専門家確認を保存する。

Ethical dunning は dispute と service hold を人へ分岐する

行動科学は羞恥や圧力を高めるためでなく、忘却、担当違い、カード更新、情報不足、社内承認待ちという friction を減らすために使う。

1. 契約前: payer、請求経路、支払方法、dispute route、支払条件、法令適用を確認する。
2. 履行中: milestone、acceptance、変更要求、顧客側 delay の証拠を残す。
3. 請求時: invoice ID、契約・PO、期間、金額、tax state、due date、送達 receipt を照合する。
4. 期限前: 必要な場合だけ、正確で穏当な reminder を一度送る。金額、期限、invoice、支払または相談という一つの次行動を示す。
5. 期限後: delivery、支払済み、credit、duplicate、連絡先を再確認し、経理、buyer、sponsor の正しい route へ段階的に連絡する。
6. genuine dispute / hardship: 自動 cadence から除外し、争点、非争点金額、修正、支払計画、暫定 service を人が判断する。
7. service hold review: 契約根拠、適用法、notice、顧客の安全・業務継続、data export、解除条件、承認者を確認する。自動停止しない。
8. external collection / legal: 相手、金額、証拠、時効、費用、関係影響を専門家へ渡す。公開 model は強制執行を実装しない。
9. freeze / write-off: operational、accounting、tax、legal をそれぞれの owner と evidence で処理する。

通知は平易な言葉、一つの行動、accessible な支払・相談経路、頻度上限、quiet hours、suppression、delivery log を持つ。偽の緊急性、法的権限がない脅し、公開羞恥、紛争中の反復送信、支払済み顧客への再送を禁止する。自動生成文面は draft に留め、送信者、宛先、根拠、tone、金額、期限を人が確認する。

四つの write-off を分離する

状態	意味	owner / evidence	cash・債権への効果
OPERATIONALLY_FROZEN	通常回収 cadence や新規与信を止める内部状態	commercial owner、action log	債権を消さない
ACCOUNTING_WRITE_OFF_RECORDED	会計方針に沿う仕訳	accountant、ledger、承認	法的放棄・税務資格を自動証明しない
TAX_BAD_DEBT_QUALIFIED	税法上の要件を満たすと確認した状態	tax owner、一次資料、専門家 review	対象年度・税目の処理。債権の法的存否とは別
LEGAL_RELEASE_EXECUTED	有効な債権放棄、和解、法的切捨て等	legal owner、署名済み文書	不可逆になり得る。Codex や自動 rule に実行させない

国税庁の 所得税基本通達 51-10〜51-13 と 法人の貸倒損失 No.5320 は、法律上の切捨て、全額回収不能の事実、一定の取引停止後等を区別する。OVERDUE、provider の uncollectible、社内の回収断念だけで税務上の貸倒れとしない。継続取引の売掛に使える条件を、貸付金や単発債権へ広げない。

課税売上債権の貸倒れに伴う消費税調整には、対象債権、貸倒時期、証拠保存、後日回収時の戻しがある。国税庁 No.6367を基準に、所得・法人税の write-off ledger と消費税 adjustment ledger を分ける。個別の税額や率は SQL で決めない。

青色申告者には一定の事業上の売掛金等に対する貸倒引当金制度もある。国税庁 No.2070を確認し、引当金を actual cash loss、法的債権消滅、個別債権の税務上の貸倒れと呼ばない。

PSP、subscription、refund、dispute、payout を銀行へ橋渡しする

card subscription でも、customer payment success から銀行現金までに複数の時計がある。

payment attempt
  → authorization
  → provider settlement
  → pending balance
  → available balance
  → reserve / refund / dispute / fee / negative balance
  → payout initiated
  → payout paid
  → bank receipt observed
  → receivable allocation / reconciliation

Stripe balances は pending と available を分け、balance report は取引、fee、payout の照合材料を提供する。どちらも自行の bank statement を置換しない。account、country、payment method、risk review、holiday により settlement / payout timing は変わるため、公開の標準日数を自社の保証日として forecast に固定しない。

Stripe refunds では available balance が refund 原資となり、pending balance は直接使えない。dispute lifecycle では申立額と fee が balance から debit され、card network 等による申立窓と解決期間がある。文書にある代表的期間を全取引の maturity とせず、payment method、jurisdiction、case の current deadline を provider object から取る。

subscription の retry や recovery automation は、支払摩擦を減らす道具であって法的貸倒判定ではない。Stripe automatic collection と revenue recovery の状態を自社 receivable event へ写し、provider uncollectible を TAX_BAD_DEBT_QUALIFIED に変換しない。

marketplace / app store も販売額と銀行着金を分ける。Apple は fiscal month 終了後 45 日以内という支払説明を、Google Play は 翌月 15 日前後という支払説明を公開しているが、threshold、口座・税情報、休日、adjustment 等の条件があり、銀行 receipt の保証ではない。

provider の将来変更を current cash rule へ先取りしない。調査基準日時点で、Google Play の 新しい refund / chargeback responsibility は 2026-08-03 より後に発注された注文向け、日本の新サービス料体系 は 2026-09-30 予定と説明されている。いずれも 2026-08-02 の realized cash へ遡及させず、発効後の order cohort と statement で確認する。

毎 payout について、provider account、currency、settlement objects、fee、refund、dispute、reserve、payout ID、expected arrival、bank movement、allocation、difference reason を一件に結ぶ。exact object がない集約額は reconciliation difference として残し、都合のよい invoice へ配賦しない。

AI・cloud の alert と年額前受 reserve を hard control と呼ばない

売上 cash は週・月単位で遅れる一方、AI・cloud・外部 API は request ごとに費用を増やせる。通知を制御と誤認すると、売掛遅延と usage spike が同時に cash を壊す。

control	証明できること	追加で必要な制御
budget alert	閾値判定時に通知する設計	enforcement の有無、集計遅延、通知失敗、owner
provider hard limit	特定 product / scope / period の停止または拒否	fail-open path、別 project・key、retry、既発生 usage
prepaid billing	provider credit を先に購入した	cutoff 遅延、negative balance、expiry、refund 条件、manual top-up
app-side quota	tenant / feature / request の自社制御	bypass、admin override、concurrency、reconciliation
kill switch	新規高費用処理を止める	customer-safe degradation、既実行 job、再開承認

OpenAI の project 管理には、超過後も request が継続する project の soft threshold と、monitor-only または強制を設定できる organization / project spend controls の双方が記載される。developer docs の Spend limits は hard limit の挙動と、enforcement が瞬時ではないことを説明する。したがって「OpenAI budget はすべて soft」または「limit と表示されれば超過 usage は一件も起きない」と一般化しない。exact control type、scope、enforcement mode、source version を保存し、実 account と app-side quota / kill switch で確認する。

OpenAI prepaid billing は cutoff 遅延による negative balance の可能性や、manual purchase が auto-recharge limit の外にあることを説明する。prepaid credit を unrestricted bank cash や完全な cost cap としない。

Cloudflare の Budget Alerts は通知であり、利用処理・通知に遅れ得る。billing changelogで product 固有の新 control を確認し、generic alert と enforcement を分ける。AWS も Budgets の情報更新には通常 8〜12 時間程度かかり得ると説明する。既に発生した usage を alert が取り消すことはない。

制御は provider alert → provider enforcement → app quota → concurrency / job budget → graceful degradation → kill switch → bank/card reconciliation の層で持つ。AI feature ごとの unit cost は 12 章、portfolio の共通 provider failure は 15 章を正本とする。

年額前受や prepaid customer credit は、残存提供期間、解約・返金、data export、終了、support、AI/cloud の将来原価を reserve schedule にする。銀行へ入ったという理由だけで growth spend へ全額移さない。

13週で最も低い unrestricted cash headroom を primary にする

月末や 13 週後の残高が正でも、途中で給与、税、社会保険、cloud invoice、refund を払えなければ成立しない。primary KPI は期間中の最小点である。

week_end_unrestricted_cash
  = gross_authoritative_opening_bank_cash_before_internal_reserves
  + authoritative_bank_inflows_since_open_exactly_once
  - authoritative_bank_outflows_since_open_exactly_once
  - unpaid_committed_cash_obligations_due_through_week_end
  - uncovered_active_required_reserves_as_of_week_end

minimum_13_week_unrestricted_cash_headroom
  = min(week_01 ... week_13 week_end_unrestricted_cash)

実装では、opening date、bank account scope、movement の一意性、commitment / reserve の effective date を固定する。revenue、financing、owner transfer は一つの authoritative bank inflow に付ける相互排他的な分類または memo であり、financing を二つ目の加算項にしない。

commitment と reserve は共通の cash_obligation_id を持ち、同じ obligation に対する金額 overlap を 0 にする。ここで uncovered_active_required_reserves は「現金が不足する reserve」ではなく、同じ obligation の realized outflow または unpaid commitment として式内でまだ控除していない active 部分を指す。reserve が具体的な支払 commitment へ移った場合は coverage を組み替え、両方を控除しない。一方、支払予定を入力しただけで reserve を早期解除せず、銀行支払による消滅または根拠・承認付き release まで active に保つ。

13 週ごとの表には、少なくとも次を持つ。

field	内容
authoritative opening	bank source、balance time、reconciliation state
realized receipts	bank receipt。revenue / financing / owner transfer を区分
expected receipts	receivable、provider payout 等の scenario。primary へ未加算
committed outflows	契約済み、税・社会保険、payroll、cloud、refund、owner draw 等
optional outflows	取消・延期可能性と承認 owner
required reserves	tax、social、refund、dispute、future delivery、continuity
week-end unrestricted cash	実現 cash と commitment / reserve から導出
evidence state	OBSERVED / UNKNOWN / STALE / FAILED / N/A

primary へ加算しないものは、未入金 invoice、promise-to-pay、provider pending / available balance、payout initiated、pipeline、quote、未実行 loan / line、factoring 見積、insurance limit、補助金申請である。実行済み借入は銀行へ着金した一つの inflow として一度だけ算入し、financing 分類を付けて revenue contribution と別表示する。

stress は確率を一つに潰さず、次の driver を独立に動かす。

• 最大顧客または複数顧客の入金遅延・dispute。
• provider payout 遅延、reserve 増加、account review。
• refund / chargeback の集中。
• AI / cloud usage 増加、price・FX・fee 変更。
• 税・社会保険・専門家費・年払いの timing。
• 年額前受の残存履行と service incident。
• founder の稼働低下、主要 vendor / partner の停止。
• entity migration の二重運用と再審査遅延。

外部 benchmark の「安全な月数」を入れず、自社の契約、家計、顧客集中、取消可能性、障害時支出から loss case を作る。driver ごとに base / downside / severe-but-plausible の根拠、checked_at、owner、recheck trigger を持つ。

driver KPI は overdue_at_risk_exposure、matured_collection_yield、provider_to_bank_lag_days、cash_reserve_coverage、largest_customer_overdue_share とする。cash_reserve_coverage は gross authoritative bank cash と active required reserve の関係を見る診断であり、未払 commitment 控除後の支払能力を表さない。未確認 reserve の coverage は UNKNOWN、実測 0 reserve は N/A とし、この driver で primary の minimum_13_week_unrestricted_cash_headroom を上書きしない。

decision priority は次である。

STOP > PAUSE > UNKNOWN > CHANGE > MAINTAIN > BOUNDED_EXPAND

法務・安全・security・契約 veto、現実的な支払不能、無承認の外部作用は upside より先に止める。BOUNDED_EXPAND は顧客、期間、cost、credit、feature のうち evidence が支える範囲だけを広げる。

Risk financing は business mechanics の後で比較する

損失を第三者へ移す前に、回収期間と費用発生の構造を直す。比較順は次である。

1. upfront、deposit、milestone、短い条件、同意済み autopay、credit cap。
2. customer concentration と annual-prepay fulfillment reserve の上限。
3. AI / cloud variable spend の enforceable limit、kill switch、graceful degradation。
4. committed / optional expense と支払 timing の分離。
5. reserve policy と founder household runway。
6. overdraft、line、loan の事前相談。実行 cash と未実行枠を分ける。
7. factoring、credit insurance、共済等の比較。
8. equity / partner capital。revenue でなく financing decision とする。

option	比較する cash 項目	重要な非 cash 項目	primary KPI への扱い
loan / line	実行額、fee、利息、返済、covenant、保証	審査、更新、期限の利益、個人保証	銀行着金後、一つの bank inflow に financing 分類
factoring	advance、fee、reserve、recourse、買戻し	通知、債権適格性、顧客体験、accounting / tax	見積・限度額は除外。実着金と残存債務を別記
credit insurance	premium、deductible、支払時期、対象損失	適格債権、免責、申告、回収協力	保険金の銀行着金前は除外
経営セーフティ共済	掛金、貸付実行、返済	加入・取引先倒産等の要件、対象外事由	grant や一般売掛保険と呼ばない
equity / partner capital	入金、legal / admin cost、将来 distribution	control、dilution、情報権、exit	実着金後、一つの bank inflow に financing 分類

中小機構の 経営セーフティ共済 は取引先倒産等に備える要件付き制度であり、通常の reserve や無条件給付を置換しない。日本政策金融公庫の 創業の手引等を入口にしても、借入可能額を cash forecast に先取りしない。

比較 card には recourse、personal guarantee、notification、customer consent、fee の cash timing、eligible receivable、failed claim / failed funding case、accounting / tax review、data sharing、苦情 route を置く。資金調達が可能でも、恒常的な負の unit economics や不適切な与信を正当化しない。

36か月で個人事業・合同会社・株式会社を比較する

法人化の判断単位は当年税額でなく、同じ business assumptions を使う 36 か月の事業・家計 cash と、責任・調達・移行の scorecard である。

比較 option は CURRENT_FORM / SOLE_PROPRIETOR / GODO_KAISHA / KABUSHIKI_KAISHA とし、current form と重複する option は二重計上しない。各 option × month へ、amount、state、source class、evidence ID、checked_at、valid_until、owner、sensitivity を持たせる。

Current facts snapshot — 2026-08-02 確認

次の数字は現行制度の確認用であり、36 か月モデルの定数ではない。実行時に再取得する。

項目	2026-08-02 の公式情報	モデル上の扱い
株式会社の登録免許税	資本金額 × 7/1,000、最低 150,000 円。法務省「株式会社の設立手続」	current quote / evidence として入力。将来月へ hard-code しない
合同会社の登録免許税	資本金額 × 7/1,000、最低 60,000 円。定款の公証人認証は不要。法務省「合同会社の設立手続」	同上。株式会社との手続差を別 field にする
紙の会社設立定款	原本は印紙税 40,000 円の区分。国税庁 No.7141	紙 / 電子の実際の方式を確認し、自動加算しない
法人の社会保険適用	法人事業所は事業主のみを含め原則強制適用。日本年金機構	報酬・資格・会社負担・本人負担を専門家見積へ分離
法人住民税均等割	赤字でも原則発生。東京都の資本金 1,000 万円以下・従業者 50 人以下の 12 か月例は 70,000 円だが、全国一律ではない。東京都主税局 Q&A	所在自治体、資本金、従業者、月数、複数事務所で current 見積

株式会社の定款認証手数料、司法書士等の報酬、証明書、印鑑、銀行、会計、給与、保険等は、設立方法・条件・provider により変わる。法定の最低登録免許税だけを「総設立費用」と呼ばず、current official fee と実見積を別に集める。

法人事業所と代表者個人の被保険者資格も分ける。日本年金機構は 役員報酬を受ける一人法人代表者の加入を案内する一方、厚労省は 2026-03-18 に 実態のある継続的な経営労務と対価としての継続報酬を確認する取扱いを公表した。名目的な役員資格を社会保険節約策として model にしない。

社会保険は年次税額だけでなく毎月の cash cadence へ入れる。日本年金機構の 厚生年金保険料等の納付は、事業主が本人負担分を控除し、事業主負担分と合わせて原則翌月末までに納付する流れを示す。将来の保険料額・資格は固定せず、報酬、年齢、地域、保険者等を current estimate へ反映する。

個人事業の手続も期限を分ける。2026-01-01 以後の開業届は 開業した年分の所得税確定申告期限までだが、青色申告承認申請は 原則 3 月 15 日、1 月 16 日以後の開業は開始日から 2 か月以内である。古い「開業後 1 か月」と、青色申告の期限を混ぜない。

インボイス登録者は売上規模だけで免税にならない。国税庁 No.6498を基準に、受注効果、価格転嫁、納税、事務、公開情報を比較する。2 割特例は 2026-09-30 までの日を含む対象課税期間という時限措置で、2026 年度改正の一定の個人向け 3 割措置は 2027・2028 年分である。国税庁の制度見直し案内を実行時に再確認し、法人や全期間へ一般化しない。

36か月の required inputs

• sales、collected cash、bad debt、refund、chargeback。
• operating cost、AI / cloud、PSP、insurance、professional fee。
• owner compensation / draw、household inflow・outflow、最低家計 cash。
• 社会保険の事業主・本人 cash。報酬と資格を含む。
• 所得・法人・地方・消費税等の cash timing。税名・税額は専門家 input。
• setup、notary / registration、accounting / payroll、annual filing、renewal、closure。
• bank、PSP、cloud、store、domain、IP、customer contract / data の migration と二重運用。
• liability insurance、personal guarantee、director / contract / tort / privacy / security / tax / social exposure。
• procurement fit、invoice / contract requirement、funding / equity、continuity、将来の共同所有・雇用。
• founder admin minutes と、移行中に失う product / sales capacity。

税率、保険料率、控除、自治体均等割、専門家費用を SQL へ固定しない。各 input に OBSERVED / ESTIMATED / UNKNOWN / N/A、official source または専門家見積、確認日、失効日、assumption owner を要求する。

出力は ending cash だけでなく、minimum_monthly_household_cash、minimum_business_unrestricted_headroom、setup / closure cash、founder admin minutes、personal guarantee、liability veto、procurement fit、migration completeness を並べる。最大 ending cash の option を自動推奨しない。

decision は KEEP_CURRENT / GET_CURRENT_QUOTES / PREPARE_MIGRATION / FORM_ENTITY の候補に留める。少なくとも current option と一 alternative の complete 36 か月 scenario、downside、非金銭 scorecard、専門家確認、移行 owner が揃わなければ GET_CURRENT_QUOTES または UNKNOWN で止める。「利益が特定額を超えたら法人」という普遍ルールを置かない。

法人成りは別主体への移行として責任を閉じる

個人と設立後の法人は別主体であり、契約、売掛、IP、account が自動で移らない。国税庁も 個人から法人への変更では支払者等の法的主体が変わることを前提に扱っている。

domain	accountable owner が確認すること	completion evidence
customer contract	譲渡可否、novation、相手同意、seller、SLA、返金・service hold	署名済み変更、effective date、customer receipt
receivable / payable	旧主体の債権債務、回収口座、invoice / credit、税区分	closing ledger、allocation、counterparty confirmation
IP / OSS / brand	code、著作権、商標、license、第三者素材	assignment / license、repository・asset register
domain / DNS / certificate	registrant、billing、MFA、recovery、renewal	provider receipt、access test、rollback
PSP / marketplace / store	KYC、merchant / seller、payout、refund、reserve、review	provider approval、test settlement、bank reconciliation
cloud / API / AI	contract owner、billing、credit、quota、data、keys	new account / agreement、cost cap、rotation evidence
bank / card / accounting	口座、権限、opening、旧口座 close 条件	opening statement、dual control、reconciliation
personal / customer data	利用目的、委託・第三者提供、通知・同意、保存・削除	legal review、record、migration / deletion receipt
invoice / tax / social	登録番号、届出、payroll、源泉、社会保険、地方税	official receipt、専門家 review、calendar
vendor / partner / insurance	契約主体、再審査、additional insured、保証、tail	countersigned terms、coverage / status evidence
support / incident / continuity	問合せ先、status、on-call、data export、旧主体の tail	rehearsal、customer notice、acceptance

migration state は PLANNED → CONSENT_REQUIRED → APPROVED → TRANSFERRED → ACCEPTED → RECONCILED とし、TRANSFERRED だけで閉じない。再審査が失敗した場合の旧主体継続、refund、customer notice、data export、rollback owner を先に決める。

旧主体の売掛を新主体の cash receipt として二重に売上計上しない。誰が回収し、どの銀行へ着金し、どの主体の帳簿・税務へ帰属するかを invoice 単位で確認する。設立日以前の契約を法人名へ書き換えるだけの backdating をしない。

有限責任は無責任を意味しない。個人保証、役員自身の不法行為・義務違反、税・社会保険、security / privacy、契約上の表明、顧客 data 事故等は別に評価する。

14日で一件だけ pilot する

pilot の目的は回収率や法人化効果を 14 日で証明することではなく、cash fact、missing evidence、最小の safe action を一件で通すことである。

Day 1 — decision contract

cash_resilience_contract_id / contract_version、対象口座、対象 receivable cohort、cutoff、最大損失、禁止する外部作用、owner、reviewer を固定する。実 customer data を public fixture へコピーしない。

Day 2–3 — authoritative cash

銀行 opening balance、期間 movement、会計・provider の差を照合する。provider pending / available、payout initiated、expected invoice を opening cash から除外する。

Day 4–5 — receivable chain

一つの顧客または同条件 cohort について、contract、performance、acceptance、invoice、due、credit、bank allocation を event 化する。missing fact をゼロで補わない。

Day 6 — contract and law card

当事者、従業員・資本金、委託内容、発注日、契約期間を記録し、フリーランス法・取適法・通常契約の applicability を人が確認する。Codex の分類は候補に留める。

Day 7 — provider bridge

provider settlement、fee、refund、dispute、reserve、payout、bank receipt を exact ID で一件照合する。差額は unresolved のまま残す。

Day 8 — commitments and reserves

税、社会保険、refund / dispute、annual prepay delivery、continuity、家計、既契約支出を week へ配置する。stale / missing estimate は UNKNOWN。

Day 9 — 13-week stress

base と二つ以上の downside driver を別々に動かし、minimum headroom と最初に不足する週を出す。pipeline と未実行 financing を加えない。

Day 10 — ethical collection review

一件の reminder draft、suppression、dispute route、promise evidence、次の人手 action を review する。自動送信、service hold、外部回収は実行しない。

Day 11 — risk-financing card

terms / cost / reserve 改善を先に検討し、必要な場合だけ financing option の current quote と失敗時 cash を集める。申し込みや契約は別承認とする。

Day 12 — entity evidence gap

current form と一 alternative について、36 か月 required categories の OBSERVED / UNKNOWN / N/A を埋める。税額を推測せず、税理士・社労士等へ渡す質問を作る。

Day 13 — independent review

別の人が double count、due basis、write-off state、reserve、TEST / REAL、stale source、外部作用を確認する。重大不一致は修正せず PAUSE / UNKNOWN として記録する。

Day 14 — bounded decision

STOP / PAUSE / UNKNOWN / CHANGE / MAINTAIN / BOUNDED_EXPAND の一つ、対象範囲、根拠、owner、due、recheck trigger を決める。14 日の未成熟な回収結果から普遍的な dunning cadence、credit policy、法人化推奨を作らない。

pilot の合格条件は、銀行 cash の二重計上なし、少なくとも一つの end-to-end reconciliation、reserve の unknown 明示、無承認 external action なし、次の cheapest evidence が特定済みであることとする。

Codex は照合と下書きを担い、外部作用を決めない

任せやすい

• redacted contract、invoice、provider export、bank export の schema mapping 候補。
• append-only event、aging、allocation、provider-to-bank reconciliation query。
• 13 週 scenario、DQ assertion、double-count / stale / missing evidence 検査。
• dunning draft、dispute summary、専門家への質問、entity comparison table の下書き。
• source URL、checked_at、valid_until、変更差分の整理。
• synthetic fixture、negative probe、週次 review、handoff pack の生成。

人が承認・実行する

• 顧客への reminder、promise acceptance、外部 collection、法的通知。
• service hold、account disable、data access 制限、再開。
• credit、refund、値引、和解、債権放棄、accounting / tax write-off。
• 法令適用、税額、社会保険資格、会計方針、契約解釈。
• loan、line、factoring、insurance、共済、equity の申込・契約。
• 法人設立、登記、税・社会保険届出、PSP / bank / cloud の live migration。
• loss cap、家計最低 cash、顧客安全、最終 entity decision。

Codex handoff には、allowed / forbidden files、SYNTHETIC / REDACTED_REAL、TEST / REAL、source watermarks、maximum external effects、required approvals、rollback、redaction を入れる。raw bank credential、card、private key、full customer document、個人番号、password、live signing authority を渡さない。

生成された SQL の PASS は、銀行残高、法的結論、税務資格、回収可能性、法人化利益を証明しない。形式検証の合格を business approval へ昇格させない。

よくある失敗は状態の短絡から起きる

• 利益を cash とする: 帳簿上の売上・利益と銀行 movement を分ける。
• invoice を cash とする: due、collection、bank allocation を通す。
• provider available を bank cash とする: payout と bank receipt を待ち、near-cash として別表示する。
• payout initiated を着金とする: bank statement で観測するまで opening cash へ入れない。
• opening balance と receipt を二重計上する: opening cutoff 以前・以後の movement を一意に分ける。
• 融資着金を bank inflow と financing addend の両方へ足す: 一つの bank movement に financing 分類を付け、一度だけ算入する。
• gross opening から reserve 済み残高を使い、同じ reserve を再控除する: opening は internal reserve 控除前へ揃え、cash_obligation_id で coverage を照合する。
• commitment 入力時に reserve を早期解除する、または両方控除する: obligation の overlap を 0 にし、支払または承認済み release まで active coverage を維持する。
• promise、pipeline、融資枠を headroom へ加える: scenario driver に留め、実着金後だけ cash にする。
• invoice 未提出で法定時計をずらす: performance / receipt / service、invoice、due basis を別にする。
• 強い文面ほど回収できると考える: friction removal、正しい route、頻度上限、dispute suppression を優先する。
• 紛争中も自動督促する: automation から外し、非争点額と解決 owner を人が決める。
• 延滞で即 service を止める: 契約、法令、安全、data export、notice、解除条件を human review する。
• OVERDUE を税務貸倒にする: operational、accounting、tax、legal state と証拠を分ける。
• write-off 後の回収で過去を消す: recovery event と税・会計 adjustment を追加する。
• 回収後に collectible を再定義して yield を上げる: eligibility と maturity を outcome 前に固定し、dispute・freeze・write-off を分母内の breakdown に残す。
• 年額前受を全額使う: future-delivery / refund / continuity reserve を控除する。
• alert を hard cap と呼ぶ: control type、enforcement、scope、遅延、bypass を test する。
• 固定税率で 36 か月を出す: current source・専門家 input・expiry と sensitivity を要求する。
• 「利益○円」で法人化する: 家計、社会保険、均等割、admin、移行、責任、調達を同じ horizon で比較する。
• 設立で契約・IP・PSP が移るとみなす: domain ごとの consent、acceptance、reconciliation を閉じる。
• 有限責任を責任なしと呼ぶ: guarantee、officer、tort、tax / social、privacy / security を別評価する。
• synthetic test を real KPI へ入れる: environment を event ごとに固定し、TEST receipt を REAL view から除外する。
• stale な行政・provider page を現行とする: checked_at、valid_until、発効日、recheck trigger を残す。

週次 review と最終 checklist

週次 review は dashboard を眺める時間でなく、一つの current decision と action owner を閉じる時間である。

cash_resilience_contract_id / contract_version:
decision_snapshot_id / snapshot_as_of:
bank source watermarks / reconciliation difference:

authoritative opening bank cash:
authoritative bank inflow breakdown — revenue / financing / owner transfer:
committed outflows / optional outflows:
tax / social / refund / dispute / delivery / continuity reserves:
week 01–13 minimum unrestricted cash / first shortfall week:

not due / due / overdue / disputed / promised / frozen principal:
largest customer overdue share:
matured collection yield / provider-to-bank lag:
dunning sent / suppressed / human escalation:

provider pending / available / reserve / negative balance:
payout initiated / paid / bank received / unreconciled:
AI-cloud alert / enforced cap / app limit / override:

operational / accounting / tax / legal write-off state:
financing quote / approved / executed / bank received:
entity evidence expiring / migration domains open:

DQ: duplicate / missing / stale / backdated / TEST-in-REAL:
decision: STOP | PAUSE | UNKNOWN | CHANGE | MAINTAIN | BOUNDED_EXPAND
scope / evidence / owner / due / recheck trigger:

Cash and evidence

• opening bank cash の account、currency、cutoff、statement がある。
• opening bank cash は internal reserve 控除前の gross であり、active reserve は後段で一度だけ控除した。
• opening balance と後続 movement を二重計上していない。
• revenue、financing、owner transfer は同じ bank inflow の分類であり、別 addend として重ねていない。
• invoice、provider balance、payout、promise、pipeline を bank cash にしていない。
• UNKNOWN / N/A / FAILED / NOT_DUE / 0 を分けた。
• late / backdated event が過去 snapshot を静かに変更していない。

Receivable and collection

• contract、performance、acceptance、invoice、due、credit、receipt、allocation を結んだ。
• collection yield の eligibility と maturity を outcome 前に固定し、authoritative credit 以外を分母から除いていない。
• フリーランス法・取適法・契約の applicability と source date を確認した。
• reminder は正確、穏当、一 action、頻度上限、suppression、delivery evidence を持つ。
• dispute、hardship、service hold、external collection は human owner へ分岐した。
• operational、accounting、tax、legal write-off を置換していない。

Provider, cost, and reserve

• settlement、pending、available、refund、dispute、payout、bank receipt を分けた。
• provider object と bank movement の差額理由を記録した。
• AI / cloud alert と enforced cap を分け、app-side limit と kill switch を test した。
• annual prepay の future-delivery、refund、continuity reserve がある。
• 未確認 reserve をゼロとして coverage を作っていない。

Cash stress and financing

• 13 週すべての committed outflow と最小点を見た。
• commitment と reserve が共通の cash_obligation_id を持ち、重複控除が 0 である。
• reserve を予定入力だけで解除せず、支払または根拠・承認付き release まで維持した。
• expected cash と realized cash、revenue と financing を分けた。
• customer delay、payout、refund / dispute、cloud、tax / social の downside を分けた。
• financing の limit / quote と executed bank cash を分けた。
• recourse、guarantee、claim failure、返済を含めた。

Entity and migration

• current と一 alternative の 36 か月 required categories が揃う。
• tax、social、local、setup、admin、migration、closure、household に current source / expert estimate がある。
• ending cash だけでなく minimum household / business cash、admin、liability、procurement を見た。
• contract、receivable、IP、domain、PSP、cloud、store、data、invoice、bank の移行 owner がいる。
• current / time-limited / future rule を混ぜていない。

Authority

• Codex の allowed work と禁止する external effect が明示されている。
• reminder、service hold、write-off、financing、法人設立に human approval がある。
• public fixture は fully synthetic で、PII、口座、credential、customer document を含まない。
• 最終 decision に scope、owner、due、rollback / recheck trigger がある。

Findings

最も価値の高い制御は、入金見込みを精緻に予測することではなく、現金へ昇格できない状態を明示することである。 invoice、promise、provider balance、financing limit を除外すると、一人事業が実際に負える顧客与信、年額販売、AI usage、owner draw の範囲が見える。

回収と法人化は別テーマではない。 回収遅延、税・社会保険の支払 timing、provider reserve、家計、設立・移行費が同じ 13 週・36 か月 cash に衝突する。事業形態の比較は、この衝突を同一 assumption で見るために行う。

自動化すべきなのは証拠と照合であり、不可逆な対外判断ではない。 ethical dunning、service hold、tax write-off、legal release、financing、entity migration は human authority を残した方が、誤停止、過剰回収、法令誤認、顧客毀損を抑えられる。

Recommendations

• まず14日間の bounded pilot で、契約、履行、請求、売掛、provider event、銀行入出金を同じ cash_resilience_contract_id に結び、銀行で確認できない見込みを primary cash へ加えない。
• 週次では13週の最小 unrestricted cash headroom を最優先し、customer delay、provider payout、refund / dispute、AI / cloud、税・社会保険を別 driver で stress する。
• 回収強化の前に payment terms、acceptance、credit limit、dispute path、service-hold 条件を契約へ戻し、対外 reminder、停止、法的回収、貸倒、資金調達は human approval を残す。
• 年額前受、provider reserve、AI / cloud spend、executed financing を売上と混ぜず、future-delivery reserve、account 固有の制御、返済・recourse を同じ cash schedule へ入れる。
• 事業形態は単一の利益 threshold で選ばず、個人事業、合同会社、株式会社について current source と専門家見積を36か月で比較し、契約・債権・IP・account・data の移行 owner と acceptance を先に置く。

Further Questions

• 実際の売上は B2B invoice、card subscription、marketplace、app store のどの比率か。
• 最大顧客の売上、売掛、support、roadmap concentration はどの程度か。
• annual prepay に残る未履行月、返金、終了、data export 義務は何か。
• provider balance と銀行明細を exact object で照合できるか。
• 税、社会保険、自治体税、家計 cash の専門家見積はいつ失効するか。
• 法人化の主因は税 cash、責任分離、procurement、採用、共同所有、資金調達のどれか。
• 現契約、債権、IP、domain、PSP / cloud / store、customer data の移行に相手同意や再審査が必要か。
• service hold が顧客の安全、法令、data portability、business continuity を損なわないか。
• 未施行の 2027 年支払告示と、取適法運用基準・フリーランス法の考え方の改正確定版が current contract に何を変えるか。

Caveats

• この operating model の state、KPI、decision priority は実務上の設計であり、法定用語、会計基準、税務要件、外部 benchmark ではない。
• 行政 Q&A、基本通達、provider docs は法令本文、契約、account 固有条件、専門家による事実認定を置換しない。
• 2026-08-02 の現行事項、インボイス等の時限措置、2027 年以降の未施行事項を分けた。公開後も法令、自治体、provider、fee、API、account eligibility は変わり得る。
• cash stress は scenario であり、回収、refund、tax、cloud usage、融資実行の不確実性を消さない。expected と realized を常に分ける。
• 36 か月比較は入力の質に依存する。税率・社会保険・地方税・専門家費・設立費を固定せず、current official source と専門家見積を version 管理する。
• limited liability は個人保証、役員責任、不法行為、税・社会保険、security / privacy、契約責任を消さない。
• pack と SQL の fixture、数値、判断は fully synthetic であり、利用者の回収率、必要 reserve、利益、税額、法人化時期、事業形態を推奨しない。