Liquidity Stress Test
When to use
Use whenever cash position needs to be tested against a genuine downside, not just tracked under the current plan — before a board or lender conversation that will ask "what happens if revenue drops," or as a standing discipline for any business carrying real liquidity risk. Especially use to replace a stress test that stops at identifying the risk without sizing what specific actions would actually close the gap.
What it does
Applies a stated revenue-drop shock to the monthly net burn via a bundled calculator, projects the cash balance across the stress horizon, finds the trough month and the shortfall if cash would go negative, and ranks a list of candidate mitigations by exactly how much cash or runway each one restores — turning "we should probably cut costs" into a ranked, sized list of specific actions.
Method
- State the base monthly net burn under the current plan, before any shock is applied.
- Define the shock explicitly: a specific revenue drop percentage, not a vague "if things get worse." A defensible shock size usually comes from a real historical precedent or a specific plausible risk (a major customer churning, a macro downturn comparable to a past cycle).
- Account for collection delay as part of the shock, not just the revenue drop itself — a revenue shortfall often arrives with a lag in when cash actually stops coming in, and modeling only the revenue drop without the collection timing understates the near-term cash impact.
- Run the bundled calculator (
scripts/stress_test.py) to get the month-by-month stressed cash balance, the trough month, and the shortfall amount if the balance would go negative.
- Build the mitigation list before the stress test, not after seeing a scary result. Real candidate actions: a credit line that could be drawn, specific opex cuts with their monthly savings, planned hires that could be delayed — each with an honest estimate of its cash or monthly-savings impact.
- Read the ranked mitigation output as the actual output of the exercise, not the trough number alone. The trough tells you there's a problem; the ranked list tells you what to actually do about it and how much each option is worth.
- Pre-commit to which mitigations trigger at which point, rather than deciding under pressure once the stress scenario starts to look real — name the specific cash level or month that would trigger drawing the credit line versus cutting discretionary spend.
Inputs
- Current cash and base monthly net burn
- The stress shock: revenue drop percentage and collection delay
- Stress horizon in months
- Candidate mitigations with their cash impact (one-time) or monthly savings (ongoing)
- Config saved as JSON matching the format documented at the top of
scripts/stress_test.py
Output format
Month-by-month stressed cash balance; trough cash and month; explicit shortfall flag if the balance goes negative; ranked mitigation list showing exactly how much cash or runway each option restores.
Example
A 30% revenue-drop shock, with a one-month collection delay factored in, shows the business would run out of cash by month 12, a $105,000 shortfall at the trough. Rather than stopping there, the ranked mitigation list shows drawing an available credit line restores $1M, dwarfing what an opex cut alone would provide in the same window — the specific, sized comparison the trough number alone never would have surfaced.
Common pitfalls
- Running a stress test that only identifies risk without ranking what mitigations would actually close the resulting gap.
- Applying the revenue shock without accounting for the collection delay that typically comes with it, understating the near-term impact.
- Deciding on mitigations only after the crisis starts, instead of pre-committing to specific triggers ahead of time.
1---2name: liquidity-stress-test3description: Applies a revenue-drop shock to the cash position via a bundled calculator, finds the trough month and shortfall if any, and ranks available mitigations by how much cash or runway each actually restores, instead of a stress test that ends at "here's what could go wrong" with no sized response. Use whenever the user needs to stress-test liquidity against a downside scenario, is preparing a contingency plan, or has a stress test that identifies risk but never sizes or ranks what to actually do about it.4---56# Liquidity Stress Test78## When to use9Use whenever cash position needs to be tested against a genuine downside, not just tracked under the current plan — before a board or lender conversation that will ask "what happens if revenue drops," or as a standing discipline for any business carrying real liquidity risk. Especially use to replace a stress test that stops at identifying the risk without sizing what specific actions would actually close the gap.1011## What it does12Applies a stated revenue-drop shock to the monthly net burn via a bundled calculator, projects the cash balance across the stress horizon, finds the trough month and the shortfall if cash would go negative, and ranks a list of candidate mitigations by exactly how much cash or runway each one restores — turning "we should probably cut costs" into a ranked, sized list of specific actions.1314## Method151. **State the base monthly net burn** under the current plan, before any shock is applied.162. **Define the shock explicitly**: a specific revenue drop percentage, not a vague "if things get worse." A defensible shock size usually comes from a real historical precedent or a specific plausible risk (a major customer churning, a macro downturn comparable to a past cycle).173. **Account for collection delay as part of the shock**, not just the revenue drop itself — a revenue shortfall often arrives with a lag in when cash actually stops coming in, and modeling only the revenue drop without the collection timing understates the near-term cash impact.184. **Run the bundled calculator** (`scripts/stress_test.py`) to get the month-by-month stressed cash balance, the trough month, and the shortfall amount if the balance would go negative.195. **Build the mitigation list before the stress test, not after seeing a scary result.** Real candidate actions: a credit line that could be drawn, specific opex cuts with their monthly savings, planned hires that could be delayed — each with an honest estimate of its cash or monthly-savings impact.206. **Read the ranked mitigation output as the actual output of the exercise**, not the trough number alone. The trough tells you there's a problem; the ranked list tells you what to actually do about it and how much each option is worth.217. **Pre-commit to which mitigations trigger at which point**, rather than deciding under pressure once the stress scenario starts to look real — name the specific cash level or month that would trigger drawing the credit line versus cutting discretionary spend.2223## Inputs24- Current cash and base monthly net burn25- The stress shock: revenue drop percentage and collection delay26- Stress horizon in months27- Candidate mitigations with their cash impact (one-time) or monthly savings (ongoing)28- Config saved as JSON matching the format documented at the top of `scripts/stress_test.py`2930## Output format31Month-by-month stressed cash balance; trough cash and month; explicit shortfall flag if the balance goes negative; ranked mitigation list showing exactly how much cash or runway each option restores.3233## Example34A 30% revenue-drop shock, with a one-month collection delay factored in, shows the business would run out of cash by month 12, a $105,000 shortfall at the trough. Rather than stopping there, the ranked mitigation list shows drawing an available credit line restores $1M, dwarfing what an opex cut alone would provide in the same window — the specific, sized comparison the trough number alone never would have surfaced.3536## Common pitfalls37- Running a stress test that only identifies risk without ranking what mitigations would actually close the resulting gap.38- Applying the revenue shock without accounting for the collection delay that typically comes with it, understating the near-term impact.39- Deciding on mitigations only after the crisis starts, instead of pre-committing to specific triggers ahead of time.
Natan-Mohart