The consented comparison: target vs your network vs the market

What this table is

Inside an open diligence engagement, once the target has granted at least one data category, a table appears with three columns: the target company's own number, your own network's number, and the market's number, side by side, metric by metric. This is the consented comparison, the core deliverable of the entire Diligence workflow. Everything else in the engagement (the invite, the category checklist, the deal profile) exists to produce this table.

This article is about how that table works: what each column actually measures, where the numbers come from, why the target's raw books never touch your workspace, and what every dash means. For the wider workflow (inviting a target, categories, resolving an engagement), see Diligence: the acquisition data room, explained.

Where to find it

Open Diligence from the HQ sidebar, then open any engagement tile to reach its detail workspace at /franchise/diligence/[id]. The comparison sits below Data access and Questions to resolve before close (when either has anything to show), one section per granted category, in this fixed order: Financials, Jobs & Claims, AP & Procurement, Team & Compensation. That order is always the same regardless of which order you originally requested the categories in.

Reading a category section

Each granted category gets its own section, headed by the category name, with a small grid underneath:

• The header row reads Target, Your network, and Market, right-aligned above the numbers.
• Each row below is one metric: its name on the left, then the target's value (bold), your network's value, and the market's value, in that order, separated by a hairline under each row.

A category section appears in full as soon as it's granted, even if every cell in it is still a dash because the underlying data hasn't caught up yet. Granting access and having a computable number are two different things, and the table is honest about the gap between them.

The metrics per category

• Financials: Net Margin, Gross Margin %, Opex Ratio Pct.
• AP & Procurement: Materials Ratio.
• Jobs & Claims: Cycle Time, Days to Pay.
• Team & Compensation: Labor Ratio, Revenue / Employee (only reachable once the antitrust review clears, see Diligence overview).

Every metric is formatted for what it is: ratios as a percentage to one decimal place (e.g. "36.4%"), day counts as a rounded whole number (e.g. "38 days"), and Revenue / Employee as a dollar figure, abbreviated to thousands once it clears $1,000 (e.g. "$180k").

What each column actually measures

Target

The target company's own value for that metric. This is a real, single number, not an estimate or a range, computed the same way any operator's own metric is computed on their own margin and benchmark pages: normalized from whatever financial statements, jobs, and books the target has connected, then read as either their latest reported period (for ratio metrics like margin, opex, materials, and labor) or the median across their own job records (for cycle time and days to pay, which vary job to job rather than existing as one number per period).

Your network

The median across your own network's locations for that same metric, right now, computed the identical way your HQ Benchmarks tab computes any per-office metric: each of your named offices contributes its own representative value, and this column is the middle of that distribution. This is entirely your own data. It carries no privacy gate and no minimum-office requirement beyond simply having offices reporting the metric, because there is no third party's information to protect here, it's yours.

Market

The median of operators outside your network on the same metric, a single reference line, not a rival's number. This is the same anonymized peer layer every benchmark on the platform draws from (see how benchmarks work), and it carries the platform's standard privacy protections: a market figure only appears once enough distinct peer operators contribute to it, with a higher bar for the more sensitive categories (financials and labor costs) than for operational ones (jobs and procurement). Below that bar, the cell reads as a dash rather than publishing a number built from too few businesses to protect anyone's identity. The market column also never mixes a real buyer's view with demo-seeded numbers, or the reverse; if your workspace and the peer data behind this column aren't in the same real-or-demo universe, the cell reads as a dash rather than showing a mismatched figure.

The privacy mechanism: read by hash, never by name

This is the detail that makes the whole workflow trustworthy, and it's worth being precise about, because "we don't query your PII" is a claim that only means something if it's structurally true, not just a policy on paper.

Every operator on Verinode, including the target company in a diligence engagement, has a canonical operator hash: a one-way keyed cryptographic hash of their internal operator ID, generated under a deployment secret that never leaves the server. You cannot reverse this hash back to an identity without that secret. The target's actual business documents, their P&L, their job files, their invoices, live in Verinode's operator database, addressed by their real operator ID. The Diligence buyer-side compute layer never talks to that database. It structurally cannot: it reads only from the same de-identified, normalized facts layer that powers every benchmark on the platform, and it fetches exactly one row from that layer: the row whose hash matches the hash of the target's operator ID.

In practice, this means the buyer's workspace never sees, and never asks for, the target's operator ID, their raw statements, or any row keyed by their identity. It asks the anonymized facts layer, "what is the value on the row matching this hash," the same question every peer benchmark answers, just resolved to a specific target instead of a percentile. The Your network and Market columns are read the same way (network by your own group's hashes, market by the eligible peer hashes), so all three columns in this table are produced by the identical mechanism, just scoped to different sets of hashes.

The consent grant is what makes this compute happen at all, not what hides it afterward. A category's comparison is only ever computed for categories currently granted and unexpired. Revoke a category, or let its 90-day window lapse, and the very next time anyone loads this page, that category's entire section is gone, not because a cached number was cleared, but because the compute path for it was never invoked. There's no snapshot lingering anywhere for a category the target has taken back.

Dashes and what they mean

A dash in any cell means the same thing everywhere: Verinode doesn't have enough of the right data to compute that specific number yet. What "enough" means differs by column:

• Target is a dash when the target hasn't connected enough of their own data for that metric, most commonly because that specific financial period or job history hasn't flowed in yet.
• Your network is a dash when none of your own offices have a value for that metric yet.
• Market is a dash when the peer cohort behind it hasn't cleared the platform's minimum-contributor bar for that category, or when the eligible peer data isn't available for your workspace's world.

A dash is never a hidden or suppressed real number. It means the number doesn't exist yet, either because the underlying business hasn't produced the data or because publishing it would risk identifying someone.

How this feeds the verification questions

Directly above the comparison, a Questions to resolve before close section (when present) is built from this exact same data. When a granted metric sits meaningfully off the market median, on the side that would matter to a buyer (a materials ratio running high, a margin running low, a cycle time running long), Verinode writes it up as a question to check before you rely on it, for example: "Materials ratio is 22% above the market median. Verify purchasing controls, inventory shrinkage, and any owner add-backs before close." A target that reads close to market on every shared metric produces no questions at all. These are prompts to verify, never a verdict on the deal; Verinode surfaces where the numbers diverge, you decide what it means.

The completeness note

Both the Data access section and the request form above it carry the same line, unconditionally: "Computed from the documents provided; Verinode does not verify completeness or audit the underlying data." It applies to this table too. A normalized number is only as trustworthy as what was fed into it. Verinode does not audit the target's underlying documents or attest to their completeness, and it never claims to. Treat every figure in this table as a strong starting point for your own diligence, not a substitute for it.

Related reading

• Diligence: the acquisition data room, explained
• Understanding your margin
• How benchmarks work
• Reading a benchmark
• Benchmarks overview
• Connecting your data