Finance & FP&A

How to forecast runway and months of cash as CPG Founders

Finance & FP&AFor CPG Founders2 apps12 steps~24 min to set up

Your runway number lives in a spreadsheet that's already wrong. You've got Stripe capturing DTC revenue, a separate Shopify payout hitting your bank account on a delay, co-packer invoices coming in net-30 that your bookkeeper hasn't touched yet, and a Plaid transaction labeled 'ACH DEBIT' that could be your 3PL or your label printer lease. Every month you spend 2-3 hours reconciling this into a Google Sheet before you can answer the one question your investors and your gut both need: how many months of cash do I actually have? And that number is stale the moment you close the laptop.

Build this on Starch → See the apps used

Finance & FP&AFor CPG Founders2 apps12 steps~24 min to set up

Outcome

What you'll set up

A live burn rate and runway dashboard that pulls your actual Stripe revenue and Plaid bank transactions daily — so your cash position is always current, not last-month's-close current

Side-by-side scenario models comparing what happens to your runway if your co-packer raises minimums, your Amazon velocity dips 20%, or you delay hiring your ops coordinator until Q3

Expense breakdowns by category so you can see exactly how much of your burn is COGS-adjacent (co-packer, freight, 3PL storage fees) versus true SG&A — the split that actually matters when you're deciding whether to raise or cut

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Runway Analysis Scenario Analysis

Data sources & config

Starch syncs your Stripe data and your Plaid bank transactions on a schedule — charges, payouts, and categorized expense data flow in daily without manual uploads. The Runway Analysis and Scenario Analysis apps read from that synced data directly, so your dashboard reflects actual cash movement rather than a snapshot you pulled last Tuesday.

Prompts to copy

Connect my Plaid bank feeds and Stripe account. Build me a runway dashboard that shows net burn by month for the last 6 months, projects forward 24 months at current pace, and breaks expenses into categories — separate out anything tagged as co-packer, freight, or 3PL from general overhead.

Pull my actual Stripe and Plaid baseline into a scenario model. I want three scenarios: (1) current trajectory, (2) what happens if I add a $40k/month co-packer retainer starting in August and revenue stays flat, (3) what happens if DTC revenue grows 15% month-over-month but I also hire one full-time ops hire at $85k salary. Show runway and break-even for each.

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Stripe from the Starch setup screen — Starch syncs your charges, payouts, and subscription data on a schedule. If you run any wholesale billing through Stripe invoices, those pull in too.

2 Connect your business bank account via Plaid — Starch syncs categorized transactions and balances on a schedule. If you have multiple accounts (operating, payroll, tax reserve), connect all of them so burn math uses the full picture.

3 Install the Runway Analysis app from the Starch App Store and open it — the baseline dashboard populates automatically from your synced Stripe and Plaid data with no manual entry.

4 Review the auto-categorized expense breakdown. Flag any transactions that Plaid categorized incorrectly — co-packer ACH transfers often land in 'Business Services' rather than COGS; rename the category so your burn split is accurate.

5 Tell Starch how to treat your Shopify payouts if they're hitting Plaid as a bank deposit rather than Stripe revenue — for example, 'Treat any ACH deposit from Shopify Payments as revenue, not a transfer, so it offsets burn in the model.'

6 Read your real net burn from the 6-month historical trend line — this is more accurate than any single month because CPG spend is lumpy (quarterly co-packer true-ups, seasonal inventory builds, annual insurance).

7 Open Scenario Analysis and set your current Runway Analysis baseline as Scenario 1. This is your 'do nothing' case.

8 Build Scenario 2: adjust for the operational change you're actually weighing — a new co-packer minimum, an FBA prep service contract, adding a part-time bookkeeper. Put a real dollar amount and a real start month on it.

9 Build Scenario 3: model the upside — what your runway looks like if your next retailer launch drives a meaningful lift in reorder velocity. Use a conservative number, not your pitch deck number.

10 Read the scenario comparison: which assumptions move your runway by more than 3 months? Those are the decisions worth a full founder meeting. The ones that move it by 2 weeks are noise.

11 Screenshot or export the scenario comparison for your next board update or investor check-in — this is the 'when do we need to raise?' slide, built from actual data rather than a manually-maintained model.

12 Leave both apps running — because Starch syncs Stripe and Plaid on a schedule, your runway number updates daily without you touching anything. Check it Monday morning instead of rebuilding it every month.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

August 2026 runway review — 8-SKU snack brand, $1.8M ARR

Sample numbers from a real run

DTC Stripe revenue (last 30 days)	62,000
Shopify payout to bank (Plaid)	18,000
Wholesale invoice receipts (Plaid)	41,000
Co-packer production run (Plaid outflow)	-74,000
3PL storage + pick-and-pack fees (Plaid outflow)	-18,500
Inbound freight / drayage (Plaid outflow)	-9,200
Payroll + contractor labor (Plaid outflow)	-38,000
Broker commissions and trade spend (Plaid outflow)	-12,400
SG&A (software, office, misc) (Plaid outflow)	-7,100

The founder opened Runway Analysis on a Tuesday morning without doing any prep. Stripe showed $62k in DTC charges for the trailing 30 days; Plaid showed $18k from a Shopify payout and $41k in wholesale receipts hitting the operating account. Gross cash in: $121k. Gross cash out: $159.2k, for a net burn of $38.2k — but that included a $74k co-packer run that only happens every 6-8 weeks. The 6-month historical trend smoothed this out to an average net burn of $28k/month, which Starch surfaced automatically without the founder needing to build the rolling-average formula herself. At $287k in the bank, true runway was 10.3 months. She then ran two scenarios in Scenario Analysis: Scenario A added a $22k/month dedicated brokerage retainer starting in September to expand into a new region; Scenario B assumed the retainer plus a 12% lift in reorder velocity by month 4. Scenario A cut runway to 7.1 months. Scenario B brought it back to 9.4. The break-even analysis showed she needed the velocity lift within 90 days of the retainer starting or she'd be fundraising from a worse position than today. That was the actual meeting agenda for the following week — not a number she'd spent two hours computing.

Measurement

How you'll know it's working

Net burn rate (smoothed over 6 months, not single-month snapshot) — critical because co-packer production runs create lumpy outflows that distort any single month

COGS-adjacent spend as a percentage of total burn — separating co-packer, freight, and 3PL fees from true SG&A tells you whether you have a scaling problem or a spending problem

Months of runway at current vs. growth-plan burn — most CPG founders need to see both because the fundraising timeline is set by the growth-plan case, not the coast-along case

Revenue concentration by channel (DTC vs. wholesale vs. Amazon) — because a runway model that treats all revenue as equally reliable is wrong if 60% of it is one retailer's reorder

Cash-to-next-production-run ratio — you need enough in the bank to fund the next co-packer invoice before the wholesale payment that covers it actually clears

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Google Sheets + manual bank export

Free and flexible, but you're rebuilding the model every month from a CSV you downloaded by hand — the number is always 2-3 weeks stale and the formula breaks when someone edits a cell

QuickBooks + accountant-prepared reports

Accurate once the books are closed, but your bookkeeper closes the month on the 20th of next month, so your runway number is always based on data that's 6 weeks old when you need it for a conversation happening today

Mosaic or Jirav

Purpose-built FP&A tools with strong scenario modeling, but they're priced for companies with a finance hire to set them up and maintain the model — meaningful monthly cost and real implementation time for a 3-person team

Runway (runway.com)

Clean interface and good scenario features, but another standalone tool that doesn't connect to the rest of your ops stack — your demand forecast and inventory position still live somewhere else

On Starch RECOMMENDED

One platform — runway analysis, scenario planning all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

My co-packer invoices aren't in Stripe — they're ACH debits straight from my bank. Will those show up in the burn calculation?

Yes. Plaid syncs your categorized bank transactions on a schedule, so ACH debits hit the model just like any other outflow. The main thing to check is how Plaid categorizes them — large ACH debits to a food manufacturer sometimes land in 'Business Services' rather than a COGS-adjacent bucket. You can tell Starch how to recategorize them so your expense breakdown splits correctly.

I have Shopify payouts going to the bank and Stripe for DTC. Do I end up double-counting revenue?

Not if you set it up correctly. Stripe syncs charges and payouts separately. If your DTC runs through Shopify Payments rather than Stripe directly, that payout shows up in Plaid as a bank deposit. Tell Starch which Plaid deposits to treat as revenue versus transfers, and the model keeps them straight. The setup prompt to use: 'Treat ACH deposits from Shopify Payments as revenue offsets, not expense-side transfers.'

Is this the same as what my accountant produces at month-end?

No, and that's the point. Your accountant produces accrual-basis financials after the books are closed — accurate, but 4-6 weeks behind. Runway Analysis is a cash-basis daily view built for the question 'do I have enough runway to make this decision today.' They serve different purposes. Use both.

Is Starch SOC 2 Type II certified? I'm connecting my bank account.

Not yet. Starch is not SOC 2 Type II certified today. Plaid is, and handles the bank connection itself — Starch receives the transaction and balance data Plaid surfaces, not your bank credentials directly. If SOC 2 Type II is a hard requirement for your company's vendor policy, that's worth knowing upfront.

My revenue is lumpy — big wholesale POs every quarter, not smooth monthly DTC. Will the runway model handle that?

The 6-month historical trend that Runway Analysis surfaces is specifically designed to smooth lumpy revenue and lumpy spend — a single $90k wholesale receipt in March shouldn't make your runway look like 18 months when it's actually 9. That said, if you want to model a specific PO timing assumption into a forward projection, you can do that in Scenario Analysis: 'Assume a $120k wholesale PO hits in October and again in January; show me runway under that assumption versus no PO.'

Can I connect QuickBooks instead of Plaid if my bookkeeper is already maintaining the books there?

Yes — Starch connects directly to QuickBooks and syncs entities like invoices, bills, payments, and vendors on a schedule. One thing to know: QuickBooks report views like the P&L summary are temporarily unavailable due to a connector issue being fixed upstream. Entity-level data syncs normally, so you can build expense breakdowns from the underlying transactions. If your bookkeeper keeps QuickBooks current, connecting it alongside Plaid gives you the most complete picture.