How network margin benchmarks are computed and protected

What this article is for

Margin & Cash (hq.verinode.ai/margin-cash) shows you a handful of numbers that look simple on screen: a headline margin percentage, five cost-ratio tiles, a percentile pill, a dollar gap against the industry. Underneath every one of those, the same calculation engine is doing real work: joining your network's data against everyone else's without ever seeing a name, reducing thousands of raw rows down to one honest value per business, checking that the comparison isn't built from a peer pool thin enough to reverse-engineer, and labeling its own confidence rather than pretending every number is equally solid.

This article is the plumbing underneath the Margin & Cash page specifically: gross margin and the five cost ratios (cost of goods sold, labor, materials, equipment, operating expense). It does not cover the office-vs-office engine that powers the Benchmarks tab and the Leaderboard, that is a different calculation, and it does not re-walk the page's rows, tiles, and empty-state copy, that is already covered end to end. Read this one when you want to know exactly how a "Network Median Margin" or a "Labor 38% · Industry 34%" figure came to exist, and what has to be true before Verinode will show it to you at all.

Where this engine actually shows up on the page, and where it doesn't

Not everything on Margin & Cash comes from the same calculation. It's worth separating the two before going further, because they behave differently and fail differently.

Powered by the engine this article describes (a live group-vs-rest comparison, computed fresh from anonymized peer facts):

• The Network Median Margin headline and its percentile pill in the hero.
• The Industry median figure quoted in the hero's subtext.
• All five Cost Ratios vs Industry tiles (cost of goods sold, labor, materials, equipment, operating expense).
• The industry reference figure used to compute the dollar gap shown on individual membership tiles (see Margin gap in dollars for the full formula). This engine supplies one input to that formula, the industry median margin, not the membership's own figures.

Not this engine (a separate nightly rollup, cached per network):

• Each membership's own margin percentage, cash-runway day count, days-to-pay, and quartile position (Bottom Quarter / Middle Half / Top Quarter) shown on the Below Margin, Cash Runway Alerts, and Top Margin tiles. Those come from a snapshot the network aggregator writes once per run into your network's own aggregate store, not from a live per-request query against the intelligence layer.
• The Under 30 Days / 30-60 Days / 60+ Days cash-runway counters beside the hero headline. Those are bucket counts from the same aggregator snapshot.

The distinction matters because the two pipelines have different refresh cadences and different failure modes. A membership's own figures update on the aggregator's own schedule; the industry comparison this article describes is computed live, on every page load, from whatever the intelligence layer currently holds.

Step 1: hashed operator joins, how "your network" and "the rest" get assembled

Every comparison starts by resolving two sets of businesses: your own network, and everyone eligible to stand in for "the rest of the industry."

Your network's roster comes from your own group membership table, a plain list of operator records. Verinode never joins that roster directly against the cross-network intelligence tables using those raw identities. Instead, every operator identity is run through a one-way cryptographic hash before it ever touches the intelligence schema, and the hashed form is what actually gets matched against the peer facts (the benchmark data, the table margin and every cost ratio on this page reads from). The hash only ever travels one direction: given an operator's identity you can compute their hash, but the intelligence tables carry no reverse path back to a name, a login, or a business record. HQ's server never issues a query against the intelligence layer using anything but a hash.

Once your roster is hashed, the engine reads every row in the relevant peer-facts table and splits it two ways:

• Your network's own rows (hash matches a member of your roster). These are always counted. There's no eligibility gate on this side, because it's your own network's data, not a peer's, being read back to you.
• Everyone else's rows (hash does not match your roster). These only count if the hash also clears the eligibility allow-set described in Step 3. A peer's data that doesn't clear that gate is dropped from the comparison entirely, not shown with a caveat.

This is also the mechanism behind the network's own estimated-revenue figure that feeds the gap-in-dollars column: the same hashed lookup pulls headcount and revenue-per-employee from the peer-facts table for your own network's operators, to estimate an annualized revenue per membership without ever reading an invoice or bank balance.

Step 2: per-operator-first, before any percentile gets computed

The peer-facts tables are not one row per business. Some metrics (margin, each cost ratio) are snapshot metrics, one row per operator per reporting period, and the engine takes the most recent one. Other metrics elsewhere on the platform are job-grain, one row per completed job, which means a single high-volume business can contribute hundreds of rows while a smaller one contributes a handful.

Before computing any P25, median, or P75, the engine collapses every business down to exactly one value: the latest snapshot for a metric like margin or a cost ratio, or the business's own median across its rows for a job-grain metric. Only after that reduction does it sort the resulting one-value-per-business list and compute percentiles. The distinction is deliberate: if the raw rows were pooled straight into a percentile calculation, a single high-volume business would quietly dominate a figure that's supposed to represent "the typical business," one business, one vote, regardless of how much data any single business has contributed.

This applies identically to both sides of the comparison, your network's own rows and the eligible rest-of-industry rows.

Step 3: the eligibility allow-set, the demo and real chokepoint

Verinode maintains a separate showcase world for onboarding and product demos, entirely apart from the live network of real, contributing businesses. Every peer-facts row that could be counted on the "rest of the industry" side has to pass through a single allow-set check before it's eligible at all: it has to have matured into benchmark eligibility, and it has to belong to the same world (demo or real) as the network asking the question.

Your own network's world is fixed by how your account was set up. A real franchise network's rest-of-industry comparison is only ever built from other real, matured operators, never from showcase data, even if the real peer pool is still thin. A demo or evaluation network sees the reverse: only demo peers, so a sales walkthrough never accidentally surfaces a real operator's business figures.

This check is a single chokepoint, not a per-metric setting, and it fails loud rather than fails open. If the allow-set itself can't be read for any reason, the engine treats the rest-of-industry side as empty for that request rather than falling back to an unfiltered pull of every business in the peer-facts table. Concretely, that means a real network never sees a comparison quietly built from demo data, even in a degraded state: the honest failure is an empty or "still warming up" comparison, never a wrong one dressed up as real.

Step 4: the privacy floor, checked on both sides

Once the engine has one clean per-business value for your network and for the eligible rest of the industry, it checks a hard floor before it will publish anything: both sides have to be built from at least a minimum number of distinct contributing businesses, counted by business, never by row, or the entire comparison for that metric is withheld.

Two things about this floor are worth knowing precisely, because they explain behavior that can otherwise look like a bug:

• The floor is not the same for every metric family. Verinode holds financial and cost-structure figures, which is everything on Margin & Cash, to a materially higher bar than operational metrics elsewhere on the platform, because a margin or cost-ratio figure is more re-identifying than a process-timing number. Every metric this page shows sits behind that higher tier, without exception, because gross margin and all five cost ratios are read from the same financial-period peer-facts table.
• The floor checks BOTH sides, including your own network's. This is easy to miss: the check isn't only "is there enough of the outside industry to compare against." If your own network doesn't yet have enough distinct reporting memberships to clear the same bar, the engine withholds your network's own median too, not just the industry comparison. A very small or very new network can see the hero read as if there's no margin data at all, even when a handful of memberships have genuinely reported a figure, because publishing that network's own median from too few contributing memberships would itself be identifying.

When either side fails the floor, every figure that depends on it, your network's own P25/median/P75, the industry's P25/median/P75, and the percentile placement between them, comes back null for that metric. The page never shows a partial number with a small-sample caveat; it shows nothing, and the row or tile falls back to its plain-language empty state instead.

Step 5: the coverage ladder, a confidence signal on top of the floor

Once a metric clears the privacy floor and is actually publishing a number, Verinode layers a second, separate signal on top: a confidence label describing how much data currently backs the comparison. You'll see it as the small pill at the top of every Cost Ratios tile, reading one of:

• Awaiting Data: no comparison is publishing yet, either because there's genuinely no data or because the privacy floor hasn't cleared. From the tile alone you cannot tell which.
• Early Signal: the comparison has just started publishing. Treat the number as a first read, not a settled one.
• Trending: more contributors are behind it now, a real direction is visible.
• Observed: a solid base of contributors on both sides. Dependable enough to plan around.
• Verified: the strongest read the engine produces, built from a broad base of contributing businesses on both sides.

This ladder is a confidence signal, never a second privacy gate. It only ever appears once a metric has already cleared the hard floor in Step 4; a metric that hasn't cleared the floor doesn't get a "low confidence" label, it gets withheld entirely and reads as Awaiting Data by default. As more memberships in your own network and more eligible operators outside it report the underlying figures, a tile's label climbs on its own, group and industry sides both, with nothing for anyone to configure or unlock.

One more detail worth knowing: when a Cost Ratios tile has a group and industry figure but the two sides haven't diverged enough to compute a meaningful delta yet, the tile's meta line falls back to a plain headcount readout instead of a percentage difference, a quick "how many businesses is this built from" instead of "how far apart are we."

Putting it together: reading a tile correctly

1. 1Read the headline and "Industry" figures at face value only if the tile shows a coverage label above Awaiting Data. Below that, there's nothing to read yet, the comparison hasn't cleared the floor.
2. 2If the pill reads Early Signal or Trending, treat the number as directional, useful for spotting a pattern worth watching, not for a board-level dollar decision on its own.
3. 3Once a tile reaches Observed or Verified, the comparison is built from enough contributing businesses on both sides to plan against with confidence.
4. 4If a number you expected to see is simply gone, check whether your own network has grown recently (more memberships reporting financial data moves the group side of the floor) rather than assuming something broke. The comparison appears on its own once both sides clear the bar, there's no setting to force it.

Best-practice example

Say the Cost Ratios row shows Labor at "38% · Industry 34%" with a Trending pill and "+4.0% vs Industry." That number means: enough of your own network's memberships have reported a labor ratio, and enough eligible operators outside your network have reported theirs, that Verinode is willing to publish the comparison, but the pool behind it is still growing on at least one side. Read it as a real signal worth raising at the next ops call, and expect the same tile to firm up to Observed or Verified as more of your network and more of the eligible peer pool report in, with no action required from you to make that happen.

Contrast that with a network still adding its first few memberships. The hero may read "Network margins will appear as members share their financial data" even though two or three memberships already have a margin figure on file, because the group side of the floor hasn't cleared yet. That's not a stalled page, it's the same floor working exactly as designed on your own network's side of the comparison, not just the industry's.

Related articles

• Margin & Cash: how HQ reads network profitability
• Margin gap in dollars: turning percentiles into board dollars
• Benchmark methodology and the privacy boundary
• Coverage labels and the anonymity floor
• What HQ sees: the network privacy boundary
• Network benchmarks: how the section works
• HQ overview
• Network health
• HQ report library