Cash runway distribution: under 30 / 30–60 / 60+ day buckets

The runway distribution is the network-wide answer to one question: how many of your members are close to running out of cash. It is three counts, under 30 days of runway, 30 to 60 days, and 60 or…

10 min read·Updated July 14, 2026
On this page

What this shows

The runway distribution is the network-wide answer to one question: how many of your members are close to running out of cash. It is three counts, under 30 days of runway, 30 to 60 days, and 60 or more, sitting in the hero row at the top of the Margin & Cash page. It is deliberately a headcount, not a dollar figure. HQ never reads what any member's cash balance actually is, on this page or anywhere else. What the aggregator hands up is a classification: this many members are tight on cash, this many are healthy, this many are strong, and the rest have not reported enough to classify yet. This article covers exactly how those three (really four, counting "not yet on file") numbers are built, what the empty and partial states mean, and why a bucket count is what HQ sees instead of a balance.

Tip

This article covers one row on the Margin & Cash page: the runway buckets in the hero. For the margin percentile, the industry comparison, the Below Margin and Top Margin rows, and the Cost Ratios row that share the same page, those are documented separately and referenced at the end of this article.

Where to find it

Open Margin & Cash from the HQ sidebar, under the Intelligence group (alongside Benchmarks, Forecasting, and Impact), or go directly to hq.verinode.ai/margin-cash. The three runway buckets sit as the second, third, and fourth numbers on the page, to the right of the network's median margin headline, in the hero panel's secondary metrics column. A Download board slide button in the top-right corner exports the whole page, including this row, as a PDF for a board or ownership deck.

The hero row: margin headline plus three runway counts

The hero panel leads with Network Median Margin, the group's median gross margin percentage across reporting members, with a percentile or member-count pill beside it and, when at least two months of history exist, a 12-month trend line underneath. To the right of that headline sit three secondary tiles:

| Label | What it shows | |---|---| | Under 30 Days | Count of members the aggregator currently classifies as having fewer than 30 days of cash runway. Sub-line reads "N% Of Network" (share of total members), or a dash if the network has no members on record at all. | | 30–60 Days | Count of members classified as healthy, 30 to 59 days of runway. Sub-line reads a bare "N%" of the network. | | 60+ Days | Count of members classified as strong, 60 or more days of runway. Sub-line reads a bare "N%" of the network. |

Each tile animates its count up on load. The Under 30 Days tile is tinted the same warning color HQ uses for a signal that needs attention whenever its count is above zero, and turns neutral green only when nobody is in that bucket. The 60+ Days tile works the other way: it turns the healthy green when its count is above zero, and reads neutral when it is zero. The 30–60 Days tile in the middle never changes color, it is the "normal" band and is not itself a signal either way.

Underneath the margin headline, when the network has a median margin on file, the panel's subtext folds the same three counts into one sentence: "Industry median [X]% · [N] under 30 days, [N] healthy, [N] strong cash position." If any members have no runway classification at all yet, that sentence gets one more clause appended: "[N] of [N] have a cash balance on file."

Note

The runway sentence only appears when the network has a median margin computed. If margin has not computed yet, the subtext instead reads "Network margins will appear as members share their financial data.", and the runway sentence does not show there. The three runway tiles themselves are not gated by margin, though: they show their real counts (including zero) regardless of whether the margin headline has resolved.

How the buckets are computed

The three buckets mirror the same three bands each individual member already sees on their own IQ account: a member's own Cash Flow view classifies their runway as Exposed (under 30 days), Watching (30 to 59 days), or Thriving (60 or more), the same math documented in Cash flow and cash runway. HQ's runway distribution is the network-level headcount version of that same classification, how many members currently sit in each band, computed and refreshed by a nightly aggregator cron that runs against each member's own account.

Concretely, the cron writes three counts, under_30, between_30_60, and over_60, into a shared evidence record for your group (the network data), alongside a total_members figure for that same snapshot. The Margin & Cash page reads the single most recent one of these snapshots (ordered by date, one row per group) and derives:

  • Under 30 Days = the snapshot's under_30 count.
  • 30–60 Days = the snapshot's between_30_60 count.
  • 60+ Days = the snapshot's over_60 count.
  • Not yet on file (the "unknown" count folded into the subtext sentence, described below) = total_members minus the sum of the three counts above, floored at zero so a stale or partial snapshot can never show a negative count.

That evidence record is stored encrypted under your group's own key and decrypted on read; if a decrypt ever fails, the page falls back to a plaintext copy of the same values kept during the platform's rollout window, so what you see does not change either way. Percentage sub-lines on each tile ("N% Of Network") divide the bucket's count by the same snapshot's total_members, not by a live recount of your roster at the moment you load the page. If your roster has changed since the cron last ran, the percentages reflect the roster as of that snapshot, not this second.

What "unknown / on file" means

A member lands in exactly one of four states at any given moment: under 30 days, 30 to 60 days, 60 or more days, or not yet classified at all. That fourth state, "not yet on file," is not one of the three visible tiles. It only surfaces as the trailing clause in the hero's subtext sentence, "[N] of [N] have a cash balance on file," and only when at least one member is in it.

A member ends up "not yet on file" for one of two reasons:

  • The member has not given Verinode a current cash figure. Runway math needs a starting cash balance on the member's own Cash Flow view (told to IQ directly, uploaded from a bank statement or balance sheet, or pulled in through QuickBooks or Xero ingest). Until that member has one, and a recent enough one, their own account has no runway number to contribute, so the network-level cron cannot place them in a bucket.
  • The aggregator has not run a snapshot with runway data yet for your group. Until the aggregator's cash-runway extension has populated a snapshot for your group at all, every one of the three counts reads zero and every member in your network falls into "not yet on file." In that state you will see all three tiles reading 0 with "0% Of Network" (or a dash, if your group also has no roster yet), and, if your roster is non-empty, the subtext will read "0 of [N] have a cash balance on file."

Either way, "not yet on file" is not an error state and not something to chase down member by member from this page. It resolves itself as members connect a cash balance and the aggregator's next nightly run picks it up; nothing here requires you to take an action to unlock it.

Why HQ sees counts per bucket, not a member's actual cash balance

The cash balance behind a member's runway figure, the dollar amount actually sitting in that business's bank account, lives entirely inside that member's own IQ account, on the PII side of the platform. HQ's application server has no path to that data at all: its database role is hard-revoked from the PII schema, the same technical wall documented in What HQ sees: the network privacy boundary. The only process that ever touches a member's raw cash figure is the aggregator cron itself, which runs with the access it needs to compute derived, network-facing numbers, and it never writes the balance itself anywhere HQ's server can read.

What the cron writes back is already twice removed from the balance. First, it turns the raw dollar figure into a runway-days number for that one member, itself a derived read, not the balance. That per-member day count is what you see when you drill into a specific franchisee's tile elsewhere on this page, for example on the Cash Runway Alerts row below the hero, where a member showing up under 30 days reads something like "18d Runway" next to their name. That is still a fact about your own network, which is why it can be named the way the privacy boundary article describes for your own roster (or shown under an anonymized label, if your network runs independent-operators anonymization).

Second, for the network-wide hero row specifically, the cron reduces even that day count down one more step, to bucket membership. The hero does not tell you "the network's average runway is 47 days," which would blend a struggling member's number in with a strong one's and hide exactly who needs attention. It tells you how many members are in each band. That is a deliberately blunter, more honest number for a board-level read: it says how many, never how much, and it cannot be worked backward into any one member's actual balance, because the aggregation step that produces it never carried the balance through in the first place.

Reading it alongside the rest of the page

The runway buckets are a triage count, not the whole picture. To act on a specific member showing up in the under-30 bucket, look at the Cash Runway Alerts row further down the Margin & Cash page: it lists, by name, every member with a known runway figure under 30 days (up to six at a time), each tile showing that member's margin position, its own runway day count, and an At Risk pill if an intervention is already open for them. Clicking a tile opens that member's own detail card on the Franchisees page, from where an HQ admin can flag them for follow-up, the workflow covered in The interventions queue for at-risk locations.

Two honesty notes on that row worth knowing:

  • It only includes members with a known runway figure under 30, not members who are simply unclassified. A member in "not yet on file" does not appear in Cash Runway Alerts, and is not counted as healthy either, they are just absent from that row until their own account has a runway number.
  • When no member currently has a runway figure under 30, the row reads "All members in healthy cash position." That is a real "nobody qualifies" state, not the same thing as "everybody has reported and everybody is fine." A network sitting entirely in "not yet on file" would also show this same empty-state sentence, since nobody has a runway figure under 30 to list, so read it alongside the hero's own "not yet on file" count rather than on its own.

Best-practice example

Say the Margin & Cash hero reads a network median margin of 32.4%, with the runway tiles showing Under 30 Days: 3 (21% of network), 30–60 Days: 6 (43%), and 60+ Days: 4 (29%), and the subtext adds "13 of 14 have a cash balance on file." That tells you at a glance: one member out of fourteen has not connected a cash balance yet, and three are running tight. Scroll to the Cash Runway Alerts row to see those three by name (or by their anonymized label, depending on your network's entity model), each with its own day count, for example "18d Runway" and "9d Runway." Click the tightest one to open its detail card, and flag it for follow-up if nobody has already, using the reason "Margin trending below network" or "Engagement dropped, no recent data," whichever fits what you see on the card.

Data sources

  1. 1.Your network's own aggregator snapshots (the network data). Your franchise network.
  2. 2.Each member's own Cash Flow / Cash Runway data. Your franchise network's members.
Was this helpful?