{ "version": "1.13.0", "releasedAt": "2026-06-25", "kpis": [ { "rogueId": "customers.acv_trend_pct", "slug": "acv_trend_pct", "domain": "customers", "defaultLabel": "ACV Trend", "description": "Period-over-period percent change in Average Contract Value (mean ARR per active customer logo). A rising ACV trend signals pricing power, successful tier upgrades, or a mix-shift toward larger customers; a falling ACV trend signals seat compression, discounting pressure, or a mix-shift toward smaller customers. The board reads this alongside `total_customers` and `customers.net_revenue_retention` to disambiguate which lever is moving — logo growth vs. expansion vs. price. Common pitfall: ACV mix-shifts (a wave of new SMB logos at low ACV) can drag the average down even when existing-customer ACV is rising — segment-cut ACV is more diagnostic than the blended number.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "acv_trend_pct = (ACV_current_period − ACV_prior_period) ÷ ACV_prior_period, where ACV = total ARR ÷ total active customer logos. The blended view is sensitive to logo-mix shifts; segment-cut ACV (by cohort, ACV band, or product tier) is more diagnostic.", "whyItMatters": "Separates \"more customers\" from \"bigger customers\" in growth narrative. Combined with logo count, isolates the pricing-power signal that NRR and ARR alone can blur.", "interpretationGuidance": "No citation-grade absolute benchmark exists — compare to the company's own trailing trend and to deliberate strategy (a downmarket push should show ACV declining). Pair with segment cuts: a blended ACV that's flat may hide an upmarket cohort growing 20% offset by a downmarket cohort growing 50% in count. Persistent decline with flat NRR signals discounting / seat compression — surface the cause in `retention_insights` or `expansion_opportunities`.", "relatedKpiIds": [ "sales.avg_contract_value", "customers.total_customers", "customers.net_revenue_retention", "customers.expansion_opportunities", "sales.arr" ], "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "customers.arr_at_risk", "slug": "arr_at_risk", "domain": "customers", "defaultLabel": "ARR at Risk", "description": "Sum of ARR from customers flagged \"at-risk\" by the customer-success team — typically driven by usage decline, low health score, executive turnover at the customer, missed milestones, or explicit churn intent. The board reads this as the worst-case near-term churn exposure if no intervention happens. Common pitfall: the \"at-risk\" definition drifts across CSMs and quarters; standardize the criteria (e.g. health score below threshold OR 30-day usage drop > X% OR cancellation request received) and version-control the playbook so the absolute number is comparable period-over-period. Pair with `percent_arr_at_risk` for the proportional read.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "arr_at_risk = Σ(ARR of customers flagged at-risk by CS team). The \"at-risk\" flag itself is a company-specific definition (typical components: health score below threshold, 30-day usage decline, executive churn at customer, missed onboarding milestones, explicit churn signal). Document the flag rule in `customer_definition_note` so the number is comparable across periods.", "whyItMatters": "Converts the qualitative CS pipeline into a board-readable dollar exposure. Forces the team to put a number on hand-wavy customer-health concerns and surfaces concentration risk (a single $500K at-risk account is a different conversation than fifty $10K accounts).", "interpretationGuidance": "Always present alongside `percent_arr_at_risk` — $500K at-risk is a 5% problem at $10M ARR but a 0.5% problem at $100M ARR. There is no citation-grade industry benchmark for the absolute number; the >15% destructive threshold the `ArrAtRiskGauge` widget uses is internal heuristic, not an external standard. Trend month-over-month — sustained growth in `arr_at_risk` is the leading indicator that NRR will deteriorate next quarter.", "relatedKpiIds": [ "customers.percent_arr_at_risk", "customers.churn_risks", "customers.top_customer_concentration", "customers.net_revenue_retention", "customers.gross_revenue_retention", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Sum the contracted ARR of every customer flagged \"at-risk\" by the CS team as of the reporting date — a point-in-time exposure snapshot.", "Use each at-risk customer's current contracted ARR (the exposure if they churn), consistent with `sales.arr`'s contracted-recurring definition.", "The \"at-risk\" flag is company-specific: standardize and version-control the trigger criteria (e.g. health score below threshold, 30-day usage decline > X%, executive churn at the customer, missed onboarding milestones, explicit churn/cancellation signal)." ], "exclusionRules": [ "ARR of healthy / not-flagged customers.", "One-time fees, services, and non-committed usage — same exclusions as ARR; this is contracted-recurring exposure.", "Expansion pipeline or upside — this is downside exposure, not opportunity.", "Customers already churned — their ARR is realized loss, not \"at risk\"." ], "requiredInputs": [ "Per-customer at-risk flag with the documented, versioned trigger rule.", "Per-customer contracted ARR as of the reporting date.", "The at-risk-definition playbook version (so the number is comparable period-over-period)." ], "dataSourcePriority": [ "CS platform / health-scoring system joined to the ARR ledger by a stable account ID.", "Manual CSM at-risk list joined to billing ARR as a fallback — flag the subjectivity." ], "edgeCases": [ "A single large at-risk account vs. many small ones is a different conversation — surface the concentration alongside (one $500K account ≠ fifty $10K accounts).", "At-risk flag toggling on and off within the period: take the flag state as of the reporting date (point-in-time), not the max during the period.", "Customer at-risk AND in active expansion talks: still count the full at-risk ARR; the upside is tracked separately." ], "validationChecks": [ "`arr_at_risk` ≤ `sales.arr` — you cannot have more ARR at risk than total ARR.", "Present with `percent_arr_at_risk` (= `arr_at_risk ÷ sales.arr`); the absolute dollar figure is meaningless without the proportion.", "Non-negative." ], "commonMiscomputations": [ "Drifting \"at-risk\" criteria across CSMs or quarters — the trend then reflects bookkeeping, not customer health; standardize and version the flag.", "Using recognized or invoiced revenue instead of contracted ARR for the exposure amount.", "Reporting the absolute dollar figure without `percent_arr_at_risk` — $500K is a 5% problem at $10M ARR but a 0.5% problem at $100M ARR.", "Including already-churned customers (realized loss, not risk) or netting expansion upside against the exposure." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "production": "primary" } }, { "rogueId": "customers.avg_contract_value", "slug": "avg_contract_value", "domain": "customers", "defaultLabel": "Average Contract Value (ACV)", "description": "Average annualized contract value across the active customer base (or across new logos, depending on the board's convention — document which). Expressed in the reporting currency. The board reads ACV alongside total customers to disambiguate logo-led vs. value-led growth, and against `customers.prior_quarter_acv` to see whether deal sizes are trending up (enterprise mix shift) or down (SMB dilution). Common pitfall: mixing new-logo ACV and blended-base ACV across periods — they trend differently; pick one and hold it.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "ACV = total annualized contract value ÷ customer count, over the chosen population (active base or new logos). Hold the population definition constant period-over-period.", "whyItMatters": "The unit-economics lever beneath ARR — rising ACV with flat logo growth signals a successful move up-market; falling ACV signals SMB dilution or discounting.", "interpretationGuidance": "Trend against `customers.prior_quarter_acv` for direction. Absolute ACV bands are segment-specific (SMB vs. enterprise) — industry folk-wisdom, not citation-grade.", "relatedKpiIds": [ "customers.prior_quarter_acv", "customers.total_customers", "customers.new_customers_added", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: total annualized contract value across the chosen population (active base OR new logos — document which and hold it constant).", "Denominator: the customer-logo count over the SAME population, using the same counting unit as `customers.total_customers`.", "Use annualized contract value (multi-year divided by term in years), expressed in the reporting currency; point-in-time as of the period close." ], "exclusionRules": [ "One-time fees, services, and setup — same exclusions as ARR; ACV is contracted-recurring per logo.", "Mixing new-logo ACV and blended-base ACV across periods — pick one population convention and hold it.", "Trials / $0 contracts in the denominator." ], "requiredInputs": [ "Total annualized contract value for the chosen population, same period.", "Customer-logo count for that population (same logo unit as `total_customers`).", "The population-definition flag (active base vs. new logos)." ], "dataSourcePriority": [ "Billing / subscription ledger (annualized contract value) ÷ the same logo source as `customers.total_customers`.", "CRM as a fallback — verify the population and logo unit match." ], "edgeCases": [ "A single very large enterprise deal pulls the mean up — surface median deal size alongside when one mega-deal masks the distribution.", "Multi-currency base: normalize to the reporting currency at a stable rate before averaging.", "Mid-period logo-unit change makes ACV non-comparable across the boundary — re-state." ], "validationChecks": [ "ACV = total annualized contract value ÷ customer count — recompute against any pre-computed value.", "ACV × customer count ≈ the population's total ARR within rounding.", "Compare to `customers.prior_quarter_acv` only when the population definition matches." ], "commonMiscomputations": [ "Mixing new-logo ACV in one period with blended-base ACV in another — the trend becomes an artifact of the population swap, not a price move.", "Using TCV instead of annualized value — overstates by the contract term.", "Counting logos with a different unit than the numerator's population — produces nonsense.", "Letting a single mega-deal set the headline ACV without flagging the outlier." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "production": "primary" } }, { "rogueId": "customers.churn_risks", "slug": "churn_risks", "domain": "customers", "defaultLabel": "Churn Risks", "description": "Named at-risk accounts, root-cause analysis of why they're at risk, and the mitigation plan in flight. Pairs with the quantitative `arr_at_risk` and `percent_arr_at_risk` and gives the board the names + the playbook. Common pitfall: listing the at-risk accounts without the diagnosis or the plan — the board reader needs to see what the team is doing about it, not just what the team is worried about. Also: avoid using this surface as a generic \"things are bad\" venting forum — keep it account-specific and action-specific.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Qualitative — no calculation. Per-account list: account name, ARR exposure, churn driver (usage decline, exec churn, missed milestone, competitive loss, integration friction, etc.), mitigation owner, mitigation plan, next checkpoint date.", "whyItMatters": "Converts the dollar exposure (`arr_at_risk`) into a board-readable narrative of named accounts and concrete plans. Forces the CS team to articulate the diagnosis, not just the symptom.", "interpretationGuidance": "Anti-pattern: an aggregate \"we have $X at risk\" with no per-account breakdown. Strong content lists the top 3–5 at-risk accounts by ARR, with cause and plan for each. If the team is asking the board for help (intro, exec sponsor, pricing relief), surface the ask here explicitly — boards routinely catch resolvable churn that the team would not have escalated.", "relatedKpiIds": [ "customers.arr_at_risk", "customers.percent_arr_at_risk", "customers.top_customer_concentration", "customers.retention_insights", "customers.key_initiatives" ] }, { "rogueId": "customers.customer_segments", "slug": "customer_segments", "domain": "customers", "defaultLabel": "Customer Segments", "description": "Container handle for the field-array of customer segments — each entry carries a segment name, its customer count, and its ARR. Feeds the bespoke customers card's segmentation stack-bars (customer-count + revenue distribution across segments). The \"where does the revenue / logo base concentrate\" surface (e.g. Enterprise / Mid-Market / SMB). Common pitfall: segment definitions drifting over time, or segment ARR not summing to total ARR because a segment is missing — keep the segmentation exhaustive and the cut stable.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — field-array of { name, customerCount, segmentARR } rows. No aggregate calculation; the surface's purpose is to show the distribution. Segment counts should sum to total customers and segment ARR to total ARR.", "whyItMatters": "Shows where the book concentrates by logo and by revenue — a base that is logo-heavy in SMB but revenue-heavy in Enterprise has a very different risk profile than its headline ARR suggests.", "interpretationGuidance": "Compare the logo distribution to the ARR distribution: a small Enterprise logo share carrying most of the ARR is a concentration flag worth reading with `customers.top_customer_concentration`.", "relatedKpiIds": [ "customers.total_customers", "customers.top_customer_concentration", "sales.arr" ] }, { "rogueId": "customers.customers_churned", "slug": "customers_churned", "domain": "customers", "defaultLabel": "Customers Churned", "description": "Count of customer logos that ended their subscription/contract during the period. Includes voluntary cancellations and non-renewals. Some companies separately track downgrade-to-zero as churn — be explicit about whether downgrades that drop ARR to $0 count as churn (typical: yes) vs. material contraction that keeps ARR > 0 (typical: tracked under contraction, not churn). The board reads this as the raw count behind `logo_churn_rate`; the percentage tells you the rate, the absolute count tells you the volume of CS pain. Common pitfall: counting customers that re-activate (sometimes called \"boomerang\" or resurrection) — settle the rule (typical: count each cancellation event, do not net resurrection).", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "customers_churned = count of customer logos that ended their paid subscription/contract during the period. Voluntary cancellations + non-renewals. Downgrade-to-$0 typically counts; document the rule and hold it constant.", "whyItMatters": "The absolute volume read on customer loss. The percentage (`logo_churn_rate`) tells you the rate; the count tells you the CS team load and the number of post-mortem conversations needed.", "interpretationGuidance": "No citation-grade absolute benchmark exists — the right comparison is to the company's own trailing periods and to its starting logo count. Pair with `logo_churn_rate` for proportional context and with `churn_risks` for the qualitative narrative. A spike with stable rate means the install base grew; a spike with rising rate is a quality signal — both deserve a board comment.", "relatedKpiIds": [ "customers.logo_churn_rate", "customers.logo_retention_rate", "customers.total_customers", "customers.churn_risks" ], "calculationPolicy": { "inclusionRules": [ "Count one per customer logo that ended its paid subscription / contract during the period — a period-flow count, not a point-in-time snapshot.", "Include voluntary cancellations and non-renewals.", "Include downgrade-to-$0 as churn (typical convention) — document the rule and hold it constant." ], "exclusionRules": [ "Material contractions that keep ARR > $0 — those are downgrades / contraction, not logo churn.", "Logos that never went live or were refunded — they were never paying customers.", "Re-activations (\"boomerang\" / resurrection) netted against churn — count each cancellation event; document the resurrection rule." ], "requiredInputs": [ "Per-logo contract-end / cancellation events within the period.", "The downgrade-to-$0 = churn rule (documented).", "Period boundaries; the same logo unit as `total_customers`." ], "dataSourcePriority": [ "Subscription ledger with churn / cancellation events keyed by a stable account ID.", "CRM renewal / opportunity stages as a fallback." ], "edgeCases": [ "Attribute to the contract-end / effective-cancellation date, NOT the cancellation-request date.", "Account merger: the absorbed logo is not churn — the relationship continued.", "Downgrade-to-$0 vs. churn: pick one rule and apply it consistently (typical: counts as churn).", "A logo that churned and re-activated in the same period: count the churn event per the documented resurrection rule; disclose if material." ], "validationChecks": [ "`logo_churn_rate = customers_churned ÷ (customers active at period start)` — the count and the rate must reconcile.", "`prior_quarter_total_customers + new_customers_added − customers_churned = total_customers`.", "Non-negative integer; ≤ the starting logo count." ], "commonMiscomputations": [ "Counting material contractions (ARR still > $0) as churn — corrupts both the churn count and `logo_churn_rate`.", "Using the cancellation-request date instead of the contract-end date — produces phantom churn in the wrong period.", "Netting re-activations against churn instead of counting each cancellation event.", "Counting never-live / refunded logos as churn — they were never customers." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "customers.expansion_opportunities", "slug": "expansion_opportunities", "domain": "customers", "defaultLabel": "Expansion Opportunities", "description": "Identified upsell, cross-sell, and seat-expansion opportunities inside the existing customer base, with deal size and timing where known. This is the qualitative narrative behind the expansion component of NRR — what the CS / Sales team sees in the pipeline that has not yet converted. The board reads this as forward-looking signal on whether NRR will trend up or down next quarter. Common pitfall: confusing \"opportunities\" (real conversations with named accounts) with \"addressable upside\" (theoretical TAM uplift) — keep this field anchored in actual pipeline.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Qualitative — no calculation. Narrative list of named-account expansion opportunities (seat count, module add-on, tier upgrade, cross-sell) with estimated deal size and target close period when available.", "whyItMatters": "Forward-looking signal on NRR trajectory. A thin expansion pipeline is the leading indicator of NRR compression — boards catch it here before it shows up in the metric next quarter.", "interpretationGuidance": "Anti-pattern: vague \"we see room to expand in mid-market\" framing without named accounts or sizing. Strong content lists ≥3 named opportunities with deal size estimates and target timing, plus a short note on the blocking gate (procurement, integration, exec sponsor) for each. If the pipeline is genuinely thin, write that explicitly — the board needs to know.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.retention_insights", "customers.key_initiatives", "sales.arr" ] }, { "rogueId": "customers.gross_revenue_retention", "slug": "gross_revenue_retention", "domain": "customers", "defaultLabel": "Gross Revenue Retention (GRR)", "description": "Recurring revenue retained from the cohort of customers present at the start of the period, excluding expansion — so the metric captures only churn and contraction. Per the SaaS Metrics Standards Board (SMSB) GRR standard. GRR is bounded at 100% (cannot exceed it) and reads as the \"no-defense-against-churn\" floor on retention. The board reads GRR alongside NRR (`customers.net_revenue_retention`) — the gap between them is the expansion contribution. Common pitfall: treating GRR and NRR as substitutes — they answer fundamentally different questions, and a healthy NRR with sliding GRR signals churn masked by upsell.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/gross-revenue-retention", "sectionRef": "GRR", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "benchmark": { "p25": 82, "median": 91, "p75": 95, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "GRR = (Starting ARR − Contraction − Churn) ÷ Starting ARR, on the cohort active at period start. Excludes expansion. Capped at 100% by definition. Per SMSB GRR standard.", "whyItMatters": "Isolates the \"do customers stay and not shrink\" signal from expansion noise. GRR is the true downside floor on retention — boards use it to spot product or onboarding deterioration that NRR can hide.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024 (§ \"Gross Dollar Retention\"), private SaaS GRR medians typically sit in the high-80s to low-90s, with top-quartile in the mid-90s — distributions vary by ACV cohort and vintage, so pull the current edition. The NRR − GRR gap quantifies expansion contribution; a widening gap with declining GRR is a yellow flag (expansion masking churn). Trend it quarterly — a single-period drop with steady NRR usually means a one-off contraction; persistent decline with flat NRR is a product issue.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.logo_retention_rate", "customers.logo_churn_rate", "customers.churn_risks", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Cohort = customers active at the start of the period (same cohort as NRR).", "Numerator: Starting ARR − Contraction − Churn. Expansion is excluded by definition.", "Capped at 100% — if a calculation produces > 100%, expansion is leaking in." ], "exclusionRules": [ "Expansion ARR, cross-sell ARR, price increases — none of these enter GRR (that is exactly what distinguishes GRR from NRR).", "New-logo ARR (same exclusion as NRR)." ], "requiredInputs": [ "Customer-level ARR snapshot at period start (cohort identity).", "Customer-level ARR snapshot at period end for the same cohort.", "Classification of each per-customer change as contraction vs churn vs (excluded) expansion." ], "dataSourcePriority": [ "Same cohort-tracking source as NRR; the two metrics share inputs." ], "edgeCases": [ "Customer with both expansion and contraction in the period: zero out the expansion, keep the contraction.", "Customer renaming or re-keying: hold cohort identity by account, not by name." ], "validationChecks": [ "GRR ≤ 100% always; > 100% means expansion is being counted (recompute with strict exclusion).", "GRR ≤ NRR for the same cohort; the gap is the expansion contribution." ], "commonMiscomputations": [ "Letting expansion in — produces GRR > 100%, which is definitionally impossible; the most common GRR error.", "Reporting GRR alone without NRR — boards always want the pair to see whether expansion is masking churn.", "Conflating GRR with logo retention — GRR is dollar-based; logo retention is count-based; they answer different questions.", "Using a different cohort base than NRR — the two must use the same starting cohort to make the gap meaningful." ], "inclusionRulesStructured": [ { "rule": "Cohort = customers active at the start of the period (the closed start cohort, shared with NRR).", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" }, { "rule": "Numerator = Starting ARR − Contraction − Churn; expansion is excluded by definition.", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" }, { "rule": "Capped at 100% — a result > 100% means expansion is leaking in; recompute with strict exclusion.", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" } ], "exclusionRulesStructured": [ { "rule": "Exclude expansion ARR, cross-sell ARR, and price increases — these are exactly what distinguish GRR from NRR.", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" }, { "rule": "Exclude new-logo ARR (same exclusion as NRR).", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" } ], "validationAssertions": [ { "assert": "result <= 100", "severity": "error", "message": "GRR ≤ 100% always; GRR excludes expansion, so it cannot exceed the starting cohort base." } ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" }, "dependencies": [ { "kpi": "sales.starting_arr", "edge": "computesFrom" }, { "kpi": "sales.churn_arr", "edge": "computesFrom" }, { "kpi": "customers.net_revenue_retention", "edge": "validatesAgainst" } ] }, { "rogueId": "customers.key_initiatives", "slug": "key_initiatives", "domain": "customers", "defaultLabel": "Customer Success Initiatives", "description": "Active programs the CS / Product / Sales team is running to improve customer health, NPS, retention, or expansion — onboarding revamps, health-score model updates, success-plan rollouts, expansion playbooks, advocacy programs, executive-business-review cadence changes. The board reads this as the \"what are we doing about it\" companion to the metric pages and the at-risk narrative. Common pitfall: listing initiatives without owner, target metric movement, or checkpoint date — the board cannot follow up on vague programs.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Qualitative — no calculation. Per-initiative list: initiative name, target metric (which KPI it intends to move), owner, status (planned / in-progress / launched / measuring), next checkpoint date.", "whyItMatters": "Closes the loop between the metrics page and the \"what we're doing\" board narrative. Lets the board hold the team accountable to the actions, not just the outcomes — especially valuable when KPI movement lags initiative launch by a quarter or two.", "interpretationGuidance": "Anti-pattern: a wishlist of initiatives without owners or target metrics. Strong content states which KPI each initiative aims to move (e.g. \"Onboarding revamp → targeting +5pp lift in 90-day GRR for SMB cohort by Q2\"), names the owner, and gives a checkpoint date. Closed initiatives should report the actual metric movement vs. target — wins and misses both teach the board.", "relatedKpiIds": [ "customers.retention_insights", "customers.expansion_opportunities", "customers.churn_risks", "customers.net_revenue_retention", "customers.nps_score" ] }, { "rogueId": "customers.logo_churn_rate", "slug": "logo_churn_rate", "domain": "customers", "defaultLabel": "Logo Churn Rate", "description": "Share of customer logos lost during the period — the inverse of logo retention. Numerator is logos that churned during the period; denominator is logos present at period start. Per the KBCM/Sapphire Private SaaS Company Survey definition (treated as the de-facto private-SaaS reporting convention). The board reads this as the simplest churn signal — independent of revenue-weighting. Common pitfall: confusing annualized vs. period-rate (monthly churn × 12 ≠ annualized churn for a compounding base) — be explicit about the time window and annualization method.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "Logo Churn", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 5, "median": 13, "p75": 20, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": false }, "formula": "logo_churn_rate = customers_churned ÷ (customers active at period start). Mathematically: 1 − logo_retention_rate. Annualization for monthly/quarterly rates should be explicit (e.g. (1 − monthly_retention)^12, not monthly_churn × 12).", "whyItMatters": "Direct read on whether customers are walking away. Independent of revenue-weighting, so it cannot be masked by a few large expansions.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024 (§ \"Customer Churn\"), private SaaS logo churn typically sits in the high single digits annually, with top-quartile below 5% — but distributions are highly sensitive to ACV cohort (low-ACV SMB SaaS routinely sees 20%+ annual logo churn; six-figure enterprise contracts often see <3%). Pull the current vintage rather than citing a stale point estimate. Pair with `customers_churned` (absolute count) and `gross_revenue_retention` (revenue-weighted view).", "relatedKpiIds": [ "customers.logo_retention_rate", "customers.customers_churned", "customers.gross_revenue_retention", "customers.net_revenue_retention", "customers.churn_risks" ], "calculationPolicy": { "inclusionRules": [ "Numerator: count of logos that churned (fully left) during the period.", "Denominator: count of logos active at period start (the closed starting cohort).", "Result is a percentage; the exact complement of `customers.logo_retention_rate`." ], "exclusionRules": [ "Net-new logos acquired in-period — not in the denominator.", "Downgrades / contractions where the logo remains — this is a count-of-departures metric, not a revenue one.", "Trials / pilots that never converted." ], "requiredInputs": [ "Count of churned logos in the period.", "Count of logos active at period start.", "Time window + annualization method (state explicitly)." ], "dataSourcePriority": [ "Customer-level subscription ledger with churn events.", "CRM as a fallback." ], "edgeCases": [ "Annualizing a monthly or quarterly rate: use `1 − (1 − periodic_churn)^periods` (geometric), NOT `periodic_churn × periods` (arithmetic). The two diverge materially as churn rises.", "Account merger: the absorbed logo is not churn — the relationship continued.", "Reactivation within the period: if the logo is active at period end, it is retained, not churned. Disclose if reactivations are material.", "ACV-cohort mixing: blended logo churn is misleading when SMB and enterprise are pooled — SMB routinely 20%+, enterprise <3%. Segment when material." ], "validationChecks": [ "Logo Churn Rate + Logo Retention Rate = 100% exactly.", "Bounded 0–100%.", "Churned-logo count ≤ starting-cohort count." ], "commonMiscomputations": [ "Annualizing via `monthly_churn × 12` instead of the geometric `1 − (1 − monthly_retention)^12` — overstates annual churn, badly so when churn is high.", "Confusing logo churn with revenue churn — they diverge; logo churn cannot be masked by expansion, revenue churn can.", "Using period-end logo count as the denominator — the cohort must be fixed at period start.", "Counting account mergers or contractions as churn — only full departures count.", "Reporting a blended rate across wildly different ACV cohorts without segmenting — the blend is not actionable." ], "validationAssertions": [ { "assert": "abs(result + customers.logo_retention_rate - 100) <= 0.5", "severity": "error", "message": "Logo churn + logo retention = 100% — they partition the same starting-logo cohort.", "refs": [ "customers.logo_retention_rate" ] } ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" } }, { "rogueId": "customers.logo_retention_rate", "slug": "logo_retention_rate", "domain": "customers", "defaultLabel": "Logo Retention Rate", "description": "Share of customer logos retained from the prior period, counted by logo (not by revenue). Per the SaaS Metrics Standards Board (SMSB) Logo Retention standard: numerator is logos present at both period start and period end; denominator is logos present at period start. New logos acquired during the period are excluded from both. The board reads this as a \"stickiness\" signal independent of ACV: high logo retention with weak NRR points to flat/contracting expansion; weak logo retention with strong NRR points to high concentration risk. Common pitfall: conflating logo retention with revenue retention — they answer different questions and routinely diverge.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/logo-retention", "sectionRef": "Logo Retention", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "logo_retention_rate = (logos active at period start AND active at period end) ÷ (logos active at period start). Excludes net-new logos acquired in-period. Per SMSB Logo Retention standard.", "whyItMatters": "Isolates retention quality from revenue-weighting effects. A handful of large expansions can mask high logo churn in NRR — logo retention surfaces it directly.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024, private SaaS logo retention concentrates in the high-80s to mid-90s (median around 90% for the broad sample, higher for enterprise contract ACVs). Treat distributional ranges as period- and segment-specific; pull the current vintage of the source rather than relying on a memorized number. Pair every value with `logo_churn_rate` (1 − this) for the inverse view and `customers_churned` for the absolute count.", "relatedKpiIds": [ "customers.logo_churn_rate", "customers.customers_churned", "customers.gross_revenue_retention", "customers.net_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "Numerator: count of logos active at BOTH period start and period end.", "Denominator: count of logos active at period start (the closed starting cohort).", "Result is a percentage; counted by logo, not by revenue." ], "exclusionRules": [ "Net-new logos acquired during the period — excluded from BOTH numerator and denominator.", "Logos that were never active (trials, unconverted pilots).", "Revenue weighting of any kind — this is a count metric. Revenue-weighted retention is GRR/NRR." ], "requiredInputs": [ "Logo list active at period start (with stable account IDs).", "Logo list active at period end.", "The \"logo unit\" definition (parent account vs billing entity) — consistent with the rest of the catalog." ], "dataSourcePriority": [ "Customer-level subscription ledger keyed by stable account ID.", "CRM customer table as a fallback." ], "edgeCases": [ "Account merger (two starting logos consolidate into one): count the survivor as retained; the absorbed logo is NOT churn (the relationship continued). Disclose the consolidation.", "Logo churned and then reactivated within the same period: per SMSB, if active at both endpoints it counts as retained; disclose if reactivations are material.", "Logo-unit change mid-trend: re-state, or the rate is not comparable." ], "validationChecks": [ "Logo Retention Rate + Logo Churn Rate = 100% (they are exact complements).", "Bounded 0–100%. A value > 100% means new logos leaked into the numerator.", "Retained-logo count ≤ starting-cohort count always." ], "commonMiscomputations": [ "Conflating logo retention with revenue retention (GRR/NRR) — they answer different questions and routinely diverge; a few big expansions can hide heavy logo churn in NRR.", "Letting new-logo acquisitions into the numerator — inflates retention above 100%, which is impossible for a count metric.", "Using period-end logo count as the denominator instead of period-start — the cohort must be fixed at the start.", "Counting an account merger as churn — the customer relationship continued; only the logo count changed.", "Logo-unit drift between periods." ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" }, "dependencies": [ { "kpi": "customers.customers_churned", "edge": "computesFrom" }, { "kpi": "customers.total_customers", "edge": "contextualizes" }, { "kpi": "customers.gross_revenue_retention", "edge": "validatesAgainst" } ] }, { "rogueId": "customers.net_revenue_retention", "slug": "net_revenue_retention", "domain": "customers", "defaultLabel": "Net Revenue Retention (NRR)", "description": "Recurring revenue retained from the cohort of customers present at the start of the period, including expansion (upsell, cross-sell, price increases) and net of churn and contraction — but excluding revenue from net-new logos acquired in-period. Per the SaaS Metrics Standards Board (SMSB) NRR standard. NRR above 100% means the cohort grew faster than it lost — a hallmark of strong product-led expansion. The board reads NRR alongside GRR (`customers.gross_revenue_retention`) to separate the \"keep + expand\" signal from the \"just keep\" signal. Common pitfall: mixing GAAP revenue and ARR in numerator vs. denominator, or letting net-new logo revenue leak in — both inflate the number; SMSB is explicit that the cohort is closed at period start.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/net-revenue-retention", "sectionRef": "NRR", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "benchmark": { "p25": 96, "median": 101, "p75": 109, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "NRR = (Starting ARR + Expansion − Contraction − Churn) ÷ Starting ARR, measured on the cohort active at period start. New-logo ARR acquired in-period is excluded from both numerator and denominator. Per SMSB NRR standard.", "whyItMatters": "The single best read on whether existing customers love the product enough to pay more over time. Strong NRR (>100%) compounds — it lets growth come from inside the install base, lowering reliance on new-logo acquisition and improving capital efficiency.", "interpretationGuidance": "Per KBCM/Sapphire Private SaaS Company Survey 2024 (§ \"Net Dollar Retention\"), private SaaS NRR medians have historically clustered around the low-to-mid 100s, with top-quartile in the 110s+ — but cuts vary year-over-year and by ACV segment, so pull the current edition rather than citing a stale point estimate. Top-quartile public SaaS (per typical Bessemer State of the Cloud commentary) cite NRR ≥ ~120% as the benchmark for \"best-in-class\" expansion — treat that thresholds as industry folk-wisdom unless cited to a named edition. Always pair NRR with GRR: a wide gap means expansion is propping up underlying churn.", "relatedKpiIds": [ "customers.gross_revenue_retention", "customers.logo_retention_rate", "customers.logo_churn_rate", "customers.expansion_opportunities", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Cohort = customers active at the start of the period (closed cohort).", "Numerator components: Starting ARR + Expansion + Cross-sell − Contraction − Churn — for the same cohort only.", "Expansion includes price-increase ARR and upsell ARR (more product, more seats, higher tier)." ], "exclusionRules": [ "New-logo ARR acquired during the period — must NOT appear in numerator or denominator.", "Customers acquired and churned within the same period (they were never in the cohort).", "Implementation fees, one-time services — same exclusions as ARR." ], "requiredInputs": [ "Customer-level ARR snapshot at the start of the period.", "Customer-level ARR snapshot at the end of the period, filtered to the starting cohort.", "Per-customer change classification: expansion / contraction / churn (so contraction and churn are not double-counted)." ], "dataSourcePriority": [ "Customer-level ARR ledger keyed to a stable account ID (preserves cohort identity across mergers/renames).", "CRM customer table joined to subscription system as a fallback — flag stale joins." ], "edgeCases": [ "Account mergers (two customers consolidate to one): preserve the cohort identity of the survivor; the absorbed account is treated as churn unless the merge happened pre-period.", "Currency moves on multi-currency cohorts: hold FX flat across the cohort window so retention is not confused with FX swing.", "Pause / suspension: treat as contraction or churn per the same rule used in ARR; be consistent.", "Mid-period contract amendments: take the period-end value for the customer; do not double-book intermediate changes." ], "validationChecks": [ "NRR is unbounded above 100% but should never exceed ~150% for a healthy cohort; > 150% almost always means new-logo or expansion-of-new-logo leaked in.", "NRR − GRR = expansion contribution (in percentage points); the sign must be ≥ 0.", "Cohort definition matches between numerator and denominator (same start-of-period customer set)." ], "commonMiscomputations": [ "Letting new-logo ARR leak into the numerator — the most common error; produces an inflated NRR that looks like world-class retention but is just growth.", "Mixing recognized revenue with contracted ARR across numerator and denominator — the timing mismatch can produce 5–15 percentage points of phantom retention.", "Using rolling-12 ARR snapshots without locking the cohort — the cohort drifts and the metric becomes a blended growth + retention number.", "Reporting NRR without GRR — the gap is the expansion story and boards will ask for it; computing only one of the two is incomplete.", "Computing NRR on logos instead of revenue — that is logo retention, a different metric (`customers.logo_retention_rate`)." ], "validationAssertions": [ { "assert": "result - customers.gross_revenue_retention >= 0", "severity": "error", "message": "NRR ≥ GRR for the same cohort — NRR adds expansion to the same retained base, so NRR − GRR (the expansion contribution) cannot be negative.", "refs": [ "customers.gross_revenue_retention" ] } ] }, "metricBasis": { "timeBasis": "period_flow", "cohortBasis": "closed_start_cohort", "production": "computed" }, "dependencies": [ { "kpi": "sales.starting_arr", "edge": "computesFrom" }, { "kpi": "sales.expansion", "edge": "computesFrom" }, { "kpi": "sales.churn_arr", "edge": "computesFrom" }, { "kpi": "sales.arr", "edge": "validatesAgainst" }, { "kpi": "customers.retention_insights", "edge": "narrates" } ] }, { "rogueId": "customers.new_customers_added", "slug": "new_customers_added", "domain": "customers", "defaultLabel": "New Customers Added", "description": "Count of net-new customer logos acquired during the period (excludes expansion of existing accounts and re-activated churned logos unless they signed a fresh contract). The board reads this alongside `customers.customers_churned` to derive the net logo change and alongside `customers.prior_quarter_total_customers` to reconcile the logo bridge (prior total + new − churned = current total). Common pitfall: counting signed-but-not-yet-live logos here while counting them as live in `customers.total_customers` — keep the activation cut-off consistent across both.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of customer logos that signed their first paid contract in the period. Excludes expansion/upsell on existing logos. Net logo change = new_customers_added − customers_churned.", "whyItMatters": "The acquisition half of the logo bridge — pairs with churn to show whether the customer base is growing by count, independent of ARR mix.", "interpretationGuidance": "Read with `customers.customers_churned` and `customers.prior_quarter_total_customers` to reconcile the logo bridge. Absolute counts are stage- and ACV-specific (industry folk-wisdom, not citation-grade) — compare to the company's own trailing trend.", "relatedKpiIds": [ "customers.total_customers", "customers.customers_churned", "customers.prior_quarter_total_customers", "customers.avg_contract_value" ], "calculationPolicy": { "inclusionRules": [ "Count one per customer logo that signed its first-ever paid contract during the period — a period-flow count.", "Use the same logo unit as `customers.total_customers`.", "Keep the activation cut-off (signed vs. live) consistent with how the same logo is counted in `total_customers`." ], "exclusionRules": [ "Expansion / upsell on existing accounts — no new logo.", "Re-activated previously-churned logos, unless they signed a fresh contract (document the policy and apply consistently).", "Trials / pilots until the first paid contract starts.", "Sub-accounts under an existing parent when the parent is the counting unit." ], "requiredInputs": [ "Per-logo first-paid-contract date within the period.", "The logo unit + activation cut-off (consistent with `total_customers`).", "Period boundaries." ], "dataSourcePriority": [ "CRM / billing with a stable customer-since (first-paid) field per logo unit.", "Billing first-billed-date as a fallback." ], "edgeCases": [ "Logo signs in period N but goes live in N+1: pick signing-date vs. go-live-date and apply it consistently with how `total_customers` counts that logo.", "Re-activated former customer: pin \"count as new\" vs. \"count as recovery\" and apply consistently; most boards report it separately.", "Parent / child shift mid-period: a consolidation is not a logo gain." ], "validationChecks": [ "`prior_quarter_total_customers + new_customers_added − customers_churned = total_customers` (the logo bridge).", "Non-negative integer.", "`new_customers_added × new-logo ACV` ≈ new-logo ARR within rounding when the populations match." ], "commonMiscomputations": [ "Counting expansion or sub-account adds as new customers — inflates the acquisition signal.", "Counting signed-but-not-live logos here while excluding them from `total_customers` (or vice versa) — breaks the logo bridge.", "Logo-unit inconsistency across periods.", "Double-counting a trial conversion (once at trial start, once at paid start)." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "customers.nps_responses", "slug": "nps_responses", "domain": "customers", "defaultLabel": "NPS Responses", "description": "The number of survey responses the current `customers.nps_score` is computed from — the confidence qualifier the board must read alongside any NPS value. Per the NPS methodology (Reichheld/Bain), a score from a small or unrepresentative sample is unreliable; surfacing the response count lets the board discount low-n scores. Common pitfall: celebrating (or alarming at) an NPS swing that is actually a sample-size artifact — always read the score and the response count together.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product", "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of completed survey responses behind the period's NPS score. Response rate = nps_responses ÷ customers surveyed.", "whyItMatters": "The confidence denominator under NPS — an NPS based on <50 responses or <10% response rate should be flagged low-confidence rather than trended.", "interpretationGuidance": "Read with `customers.nps_score` and `customers.nps_trend`. A trend across periods with materially different response counts may be measurement noise, not a real movement.", "relatedKpiIds": [ "customers.nps_score", "customers.nps_trend" ], "calculationPolicy": { "inclusionRules": [ "Count completed survey responses behind the period's `customers.nps_score` — the confidence denominator under any NPS value.", "Count one per completed response (a usable 0–10 score) within the survey window that produced the reported score." ], "exclusionRules": [ "Partial / abandoned surveys that did not yield a usable 0–10 score.", "Responses outside the survey window for the reported score.", "Customers surveyed but who did not respond — those belong to the response-rate denominator, not the response count." ], "requiredInputs": [ "Count of completed responses for the period's survey.", "The number of customers surveyed (for the response-rate calculation)." ], "dataSourcePriority": [ "Survey platform (Delighted, Pendo, in-app NPS) response export.", "Manual survey tally as a fallback." ], "edgeCases": [ "Multiple surveys in one period: define whether the count is the latest survey or the pooled set, and keep it consistent with how `nps_score` is computed.", "A response count materially different from prior periods means a trend may be measurement noise, not a real movement — flag it." ], "validationChecks": [ "`nps_responses` ≥ promoters + passives + detractors used in the score.", "Non-negative integer.", "Flag the score low-confidence when `nps_responses` < ~50 or the response rate < ~10%." ], "commonMiscomputations": [ "Reporting `nps_score` without the response count — a swing on a tiny sample reads as signal when it is noise.", "Counting customers surveyed (sent) as responses (received) — inflates confidence.", "Pooling responses across surveys for the count but computing the score from a single survey (or vice versa)." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "customers.nps_score", "slug": "nps_score", "domain": "customers", "defaultLabel": "NPS Score", "description": "Net Promoter Score — % of survey respondents who are promoters (score 9–10) minus % detractors (0–6), passives (7–8) excluded. Per the original NPS methodology (Reichheld, Bain & Company, 2003). The score ranges from −100 to +100. The board reads NPS as one read on product-market fit and word-of-mouth potential, not as a precise customer-loyalty measurement — the methodology is well-known for being sensitive to sample bias, response rate, and survey timing. Common pitfall: comparing NPS across companies without normalizing for industry — B2B SaaS NPS distributions sit much higher than consumer-app NPS, and the absolute number means little without a peer cohort.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "Retently NPS Benchmarks 2025", "sourceUrl": "https://www.retently.com/blog/good-net-promoter-score/", "sectionRef": "NPS Benchmarks", "publicationDate": "2025-01-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 20, "median": 36, "p75": 50, "unit": "count", "sourceName": "Retently NPS Benchmarks 2025", "sourceYear": "2025", "higherIsBetter": true }, "formula": "NPS = (% promoters, score 9–10) − (% detractors, score 0–6). Passives (7–8) are excluded from both. Range: −100 to +100. Per Bain & Company / Reichheld NPS methodology (HBR 2003, \"The One Number You Need to Grow\").", "whyItMatters": "A coarse-grained directional read on customer affection and word-of-mouth potential. Sustained movement (especially regressions) is the signal the board should focus on, not absolute values — the methodology is too noisy for fine comparisons across companies.", "interpretationGuidance": "Per Retently NPS Benchmarks 2025, B2B SaaS NPS medians by industry cluster around the +30 to +50 band, with top-quartile +50 to +70. Translate scores to categories: −100 to 0 = needs work, 0–30 = good, 30–70 = great, 70–100 = excellent — these category bands are widely circulated industry folk-wisdom (Bain does not publish strict thresholds). Always pair the score with sample size and response rate; an NPS based on <50 responses or <10% response rate should be flagged as low-confidence.", "relatedKpiIds": [ "customers.nps_trend", "customers.retention_insights", "customers.churn_risks", "customers.key_initiatives" ], "calculationPolicy": { "inclusionRules": [ "NPS = (% promoters, score 9–10) − (% detractors, score 0–6), per the Reichheld / Bain methodology (HBR 2003).", "Compute the promoter and detractor percentages over the completed responses (`customers.nps_responses`).", "Result ranges −100 to +100; point-in-time as of the survey window." ], "exclusionRules": [ "Passives (score 7–8) from the numerator — excluded from both promoter and detractor counts, but they REMAIN in the response base / denominator.", "Partial / abandoned surveys with no usable score.", "Cross-company comparison without an industry-normalized peer cohort — B2B SaaS distributions sit far above consumer-app NPS." ], "requiredInputs": [ "Counts of promoters (9–10), passives (7–8), and detractors (0–6).", "Total completed responses (`customers.nps_responses`).", "Survey window + response rate (the confidence qualifier)." ], "dataSourcePriority": [ "Survey platform with the raw 0–10 score distribution.", "Manual tally of the 0–10 distribution as a fallback." ], "edgeCases": [ "Small sample (< ~50 responses) or low response rate (< ~10%): report but flag low-confidence rather than trending.", "Survey-timing / sample-bias swings: a movement driven by who was surveyed, not by sentiment — note the survey context.", "Passives must stay in the denominator even though they net to zero — dropping them inflates the magnitude." ], "validationChecks": [ "NPS = %promoters − %detractors — recompute against any pre-computed value; bounded −100 to +100.", "%promoters + %passives + %detractors = 100%.", "Always present with `nps_responses` and the response rate." ], "commonMiscomputations": [ "Excluding passives from the denominator (computing the spread over promoters + detractors only) — overstates the magnitude.", "Reporting the score without sample size — a low-n swing mis-reads as a real movement.", "Comparing the absolute score across industries without a peer cohort — B2B SaaS NPS is not comparable to consumer-app NPS.", "Averaging the raw 0–10 scores instead of applying the promoter-minus-detractor formula." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "customers.nps_trend", "slug": "nps_trend", "domain": "customers", "defaultLabel": "NPS Trend", "description": "Period-over-period change in NPS score — the trajectory signal that matters more than any single absolute score. A 5-point swing between adjacent quarters is usually more informative than a \"good\" or \"bad\" absolute label, because the methodology's noise floor is high enough that absolute comparisons across companies (or even across quarters with different sample sizes) are unreliable. The board reads this to spot deterioration early — a persistent multi-quarter decline is one of the leading indicators of pending churn. Common pitfall: comparing periods with very different sample sizes or response rates — a \"decline\" from 45 to 35 means very different things at n=30 vs. n=300.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "nps_trend = NPS_current_period − NPS_prior_period (delta in points, not %). Sample size and response rate should be reported alongside both periods.", "whyItMatters": "NPS's methodology noise makes absolute scores hard to interpret across companies. The trend within a single company's own measurement cadence is more reliable — a sustained decline is a leading indicator of churn risk even when the absolute score still reads \"good\".", "interpretationGuidance": "There is no citation-grade benchmark for trend magnitude; treat any single-quarter swing of ±5 points or more as worth narrative explanation, and any 2+ consecutive declines as a yellow flag for the board. Always cite sample size deltas — if response rate or n changed materially, the trend may be measurement artifact rather than real movement.", "relatedKpiIds": [ "customers.nps_score", "customers.retention_insights", "customers.churn_risks", "customers.key_initiatives" ], "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "customers.percent_arr_at_risk", "slug": "percent_arr_at_risk", "domain": "customers", "defaultLabel": "% ARR at Risk", "description": "Share of total ARR flagged as at-risk for churn or contraction — the proportional view that complements the absolute `arr_at_risk` dollar figure. Computed as `arr_at_risk ÷ total ARR`. The board reads this as the worst-case-near-term-NRR-impact ceiling: if every at-risk account actually churned in-period, NRR would drop by roughly this percentage (before expansion offset). Common pitfall: the \"at-risk\" definition is internal and varies by company — a 12% percent_arr_at_risk under a conservative flagging rule is a very different signal than 12% under an aggressive rule. Document the flag rule and hold it constant.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "percent_arr_at_risk = arr_at_risk ÷ total ARR. The numerator inherits the company-specific \"at-risk\" flag definition documented on `customers.arr_at_risk`.", "whyItMatters": "Normalizes the at-risk dollar figure so it scales with the business. A 10% at-risk share is the same proportional threat at $5M ARR as at $50M ARR; the absolute figure alone hides that.", "interpretationGuidance": "No citation-grade industry benchmark; widely-cited industry folk-wisdom (not citation-grade) flags >15% percent_arr_at_risk as a destructive threshold worth board escalation — the `ArrAtRiskGauge` widget uses this internally. Trend it month-over-month — sustained growth in this share predicts a downward NRR move next quarter even if no single account has churned yet.", "relatedKpiIds": [ "customers.arr_at_risk", "customers.churn_risks", "customers.top_customer_concentration", "customers.net_revenue_retention", "customers.gross_revenue_retention", "sales.arr" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "customers.prior_quarter_acv", "slug": "prior_quarter_acv", "domain": "customers", "defaultLabel": "Prior-Quarter ACV", "description": "The average contract value reported in the PRIOR period — the comparison anchor for the current `customers.avg_contract_value`. The board reads the two together to render the ACV trend chip on the bespoke customers card (delta + direction) without recomputing it. Common pitfall: comparing a prior new-logo ACV to a current blended-base ACV — keep the population definition identical across the two periods or the trend is an artifact.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "ACV from the prior period, computed over the SAME population as the current `customers.avg_contract_value`. acv_trend ≈ (avg_contract_value − prior_quarter_acv) ÷ prior_quarter_acv.", "whyItMatters": "Lets the board read ACV direction at a glance — the single most useful framing of an ACV number is its own trajectory.", "interpretationGuidance": "Only meaningful when the population definition matches the current-period ACV. A large jump usually reflects mix shift (a few large enterprise signings), not a uniform price increase.", "relatedKpiIds": [ "customers.avg_contract_value", "customers.acv_trend_pct", "customers.total_customers" ], "calculationPolicy": { "inclusionRules": [ "The `customers.avg_contract_value` value AS REPORTED for the immediately-prior reporting period — the prior-period CLOSE snapshot, not a value recomputed on this period's base.", "Computed over the SAME population (active base vs. new logos) and the same logo unit as the current `avg_contract_value`.", "Annualized contract value in the reporting currency, as of the prior period close." ], "exclusionRules": [ "Any current-period contracts or activity — this is strictly the prior-period snapshot.", "A prior value computed over a different population than the current ACV (would make the trend an artifact).", "One-time fees / services (same exclusions as ACV)." ], "requiredInputs": [ "The prior period's reported ACV (the agreed board number).", "Confirmation that the prior population / logo-unit definition matches the current period." ], "dataSourcePriority": [ "The prior period's board-reported ACV (the audited / agreed figure).", "Re-derive from the prior-period ledger over the matching population ONLY if no reported value exists." ], "edgeCases": [ "As-of semantics: pin to the prior reporting period's CLOSE date, never a rolling trailing window.", "Population mismatch (prior new-logo ACV vs. current blended-base ACV): the trend is meaningless — re-state the prior value on the current population.", "Currency: hold FX consistent with the current ACV when comparing." ], "validationChecks": [ "`acv_trend ≈ (avg_contract_value − prior_quarter_acv) ÷ prior_quarter_acv`.", "Equals the prior period's reported `avg_contract_value` when the population definition is unchanged." ], "commonMiscomputations": [ "Comparing a prior new-logo ACV to a current blended-base ACV — produces a phantom trend.", "Recomputing the prior value on the current period's cohort instead of using the prior-period snapshot.", "Using a rolling-window \"prior\" instead of the explicit prior-quarter close." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "production": "primary" } }, { "rogueId": "customers.prior_quarter_concentration", "slug": "prior_quarter_concentration", "domain": "customers", "defaultLabel": "Prior-Quarter Concentration", "description": "The top-customer ARR concentration reported in the PRIOR period — the comparison anchor for the current `customers.top_customer_concentration`. The board reads the two together to render the concentration trend on the bespoke customers card (rising concentration = growing single-account dependency risk). Common pitfall: comparing a top-1 concentration to a top-5 concentration across periods — keep the \"top-N\" cut identical.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Top-customer ARR concentration from the prior period, on the same top-N cut as the current `customers.top_customer_concentration`. concentrationTrend = top_customer_concentration − prior_quarter_concentration.", "whyItMatters": "Direction is the signal — rising concentration means a single account's health increasingly drives the whole book's risk.", "interpretationGuidance": "A rising trend warrants a board note on the largest accounts' renewal timing and health. Hold the top-N cut constant across periods.", "relatedKpiIds": [ "customers.top_customer_concentration", "customers.arr_at_risk", "customers.percent_arr_at_risk" ], "calculationPolicy": { "inclusionRules": [ "The `customers.top_customer_concentration` value AS REPORTED for the immediately-prior reporting period — the prior-close snapshot.", "Use the SAME top-N cut (top-1, top-5, top-10) as the current concentration metric.", "A percentage of total ARR, as of the prior period close." ], "exclusionRules": [ "Any current-period activity.", "A prior value computed on a different top-N cut than the current metric." ], "requiredInputs": [ "The prior period's reported top-customer concentration.", "Confirmation the top-N cut matches the current period." ], "dataSourcePriority": [ "The prior period's board-reported concentration figure.", "Re-derive from the prior-period ARR ledger on the matching top-N cut ONLY if no reported value exists." ], "edgeCases": [ "As-of semantics: the prior reporting-period CLOSE, never a trailing window.", "Top-N mismatch (top-1 vs. top-5 across periods): not comparable — keep the cut identical.", "An account merger between periods can step concentration up without new underlying risk — disclose." ], "validationChecks": [ "`concentrationTrend = top_customer_concentration − prior_quarter_concentration` (in points).", "Bounded 0–100%.", "Equals the prior period's reported concentration on an unchanged top-N cut." ], "commonMiscomputations": [ "Comparing different top-N cuts across periods — produces a fake trend.", "Using a trailing window instead of the explicit prior-quarter close.", "Recomputing on the current book instead of using the prior snapshot." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "customers.prior_quarter_grr", "slug": "prior_quarter_grr", "domain": "customers", "defaultLabel": "Prior-Quarter GRR", "description": "Gross Revenue Retention reported in the PRIOR period — the comparison anchor for the current `customers.gross_revenue_retention`. The board reads the two together to render the GRR trend on the bespoke customers retention grid. Per the SMSB GRR definition (excludes expansion, capped at 100%), both periods must use the same cohort basis for the delta to mean anything. Common pitfall: reading a GRR trend without the matching NRR trend — the gap between them is the expansion signal.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "GRR from the prior period, on the same SMSB closed-start cohort basis as the current `customers.gross_revenue_retention`. grrTrend = gross_revenue_retention − prior_quarter_grr (in points).", "whyItMatters": "A declining GRR is the truest early churn signal — it cannot be masked by expansion the way NRR can.", "interpretationGuidance": "Persistent GRR decline with flat NRR is a product/onboarding problem hidden by upsell. Pair with `customers.prior_quarter_nrr` to read the expansion gap.", "relatedKpiIds": [ "customers.gross_revenue_retention", "customers.prior_quarter_nrr", "customers.net_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "The `customers.gross_revenue_retention` value AS REPORTED for the immediately-prior reporting period — a point-in-time restatement of that past period's GRR, NOT recomputed on this period's cohort.", "The prior GRR must itself have used the SMSB closed-start-cohort basis (excludes expansion, capped at 100%) consistent with the current GRR.", "A percentage, as of the prior period close." ], "exclusionRules": [ "Current-period cohort or activity — this is the prior period's snapshot.", "A prior GRR computed on a different cohort window / basis than the current metric.", "Expansion ARR (GRR excludes it by definition)." ], "requiredInputs": [ "The prior period's reported GRR (closed-start cohort basis).", "Confirmation the prior cohort basis matches the current GRR." ], "dataSourcePriority": [ "The prior period's board-reported GRR.", "The prior period's cohort ledger ONLY if no reported value exists." ], "edgeCases": [ "As-of semantics: the prior reporting period's GRR value fixed at that period's close — not this period's cohort recomputed for a prior window.", "A cohort-window mismatch across the two periods makes the delta meaningless.", "Read with `prior_quarter_nrr`: the gap is the prior period's expansion signal." ], "validationChecks": [ "`grrTrend = gross_revenue_retention − prior_quarter_grr` (in points).", "Bounded ≤ 100% — GRR cannot exceed 100%.", "`prior_quarter_grr` ≤ `prior_quarter_nrr` for the same prior cohort." ], "commonMiscomputations": [ "Recomputing the prior value on the current period's cohort instead of using the prior-period reported GRR.", "Comparing a prior GRR on a different cohort basis to the current one.", "Letting expansion leak in (GRR > 100%)." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "customers.prior_quarter_nrr", "slug": "prior_quarter_nrr", "domain": "customers", "defaultLabel": "Prior-Quarter NRR", "description": "Net Revenue Retention reported in the PRIOR period — the comparison anchor for the current `customers.net_revenue_retention`. The board reads the two together to render the NRR trend on the bespoke customers retention grid. Per the SMSB NRR cohort definition, both periods must use the same closed-start-cohort methodology for the delta to be meaningful. Common pitfall: comparing an NRR computed on a different cohort window across the two periods.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "NRR from the prior period, on the same SMSB closed-start cohort basis as the current `customers.net_revenue_retention`. nrrTrend = net_revenue_retention − prior_quarter_nrr (in points).", "whyItMatters": "Direction matters more than level for retention — a slipping NRR is an early expansion-engine warning even while still above 100%.", "interpretationGuidance": "A multi-point decline with steady GRR means expansion is decelerating; pair with `customers.prior_quarter_grr` to separate the \"keep\" signal from the \"expand\" signal.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.prior_quarter_grr", "customers.gross_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "The `customers.net_revenue_retention` value AS REPORTED for the immediately-prior reporting period — a point-in-time restatement of that past period's NRR, NOT recomputed on this period's cohort.", "The prior NRR must have used the SMSB closed-start-cohort basis consistent with the current NRR.", "A percentage (can exceed 100%), as of the prior period close." ], "exclusionRules": [ "Current-period cohort or activity.", "New-logo ARR (same exclusion as NRR).", "A prior NRR computed on a different cohort window than the current metric." ], "requiredInputs": [ "The prior period's reported NRR (closed-start cohort basis).", "Confirmation the cohort basis matches the current NRR." ], "dataSourcePriority": [ "The prior period's board-reported NRR.", "The prior cohort ledger ONLY if no reported value exists." ], "edgeCases": [ "As-of semantics: the prior reporting period's NRR value at that period's close — not this period's cohort over a prior window.", "A cohort-window mismatch makes the delta meaningless.", "Read with `prior_quarter_grr`: the gap is the prior period's expansion contribution." ], "validationChecks": [ "`nrrTrend = net_revenue_retention − prior_quarter_nrr` (in points).", "`prior_quarter_nrr` ≥ `prior_quarter_grr` for the same prior cohort (expansion gap ≥ 0).", "Should not exceed ~150% for a healthy cohort; higher suggests new-logo leakage in the prior figure." ], "commonMiscomputations": [ "Recomputing the prior value on the current cohort instead of using the prior-period reported NRR.", "Comparing across mismatched cohort windows.", "Letting new-logo ARR leak into the prior NRR — inflates it." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "customers.prior_quarter_total_customers", "slug": "prior_quarter_total_customers", "domain": "customers", "defaultLabel": "Prior-Quarter Total Customers", "description": "The total active customer-logo count at the END of the prior reporting period — the opening balance for the current period's logo bridge. The board reads this so the bespoke customers card can show beginning vs. ending logos and the net change without having to re-derive the opening balance from `total_customers − new + churned`. Common pitfall: silently re-stating the prior total after a definitional change to \"customer\" — hold the counting unit constant or footnote the restatement.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Active paying customer logos at the prior period close. Serves as the opening balance: prior_quarter_total_customers + new_customers_added − customers_churned = total_customers.", "whyItMatters": "Gives the board the explicit beginning-of-period logo balance so the logo bridge reconciles without inference.", "interpretationGuidance": "When this plus net change does not equal `customers.total_customers`, a definitional change or mid-period restatement happened — surface it rather than absorbing it silently.", "relatedKpiIds": [ "customers.total_customers", "customers.new_customers_added", "customers.customers_churned" ], "calculationPolicy": { "inclusionRules": [ "The total active paying customer-logo count at the prior period's CLOSE — the opening balance for the current period's logo bridge.", "Same \"active = live paid sub on the reporting date; not trial, not cancelled, not $0\" rule as `customers.total_customers`.", "Same counting unit (parent vs. account vs. seat) as the current total." ], "exclusionRules": [ "Any current-period activity — this is strictly the prior-close snapshot.", "Trials, $0, and cancelled logos at the prior close (same exclusions as `total_customers`).", "A prior count taken under a different \"customer\" definition than the current one (re-state or footnote)." ], "requiredInputs": [ "The prior period's reported active-logo count.", "Confirmation the counting unit / \"customer\" definition matches the current period." ], "dataSourcePriority": [ "The prior period's board-reported total-customer count.", "Re-derive from the prior-close subscription ledger ONLY if no reported value exists." ], "edgeCases": [ "As-of semantics: the prior reporting-period CLOSE, which is also the current period's opening balance.", "A silent restatement after a \"customer\" redefinition breaks the bridge — hold the unit constant or footnote it.", "An account merger between the prior close and now is reflected via the bridge, not by editing the opening balance." ], "validationChecks": [ "`prior_quarter_total_customers + new_customers_added − customers_churned = total_customers` — when it does not reconcile, a definitional change or restatement happened; surface it.", "Non-negative integer.", "Equals the prior period's reported `total_customers` under an unchanged definition." ], "commonMiscomputations": [ "Silently re-stating the prior total after a \"customer\" redefinition instead of footnoting it.", "Using current total minus net change as a circular proxy instead of the actual prior-close count.", "Counting trials / $0 in the prior count but not the current (or vice versa) — breaks the bridge." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "customers.reporting_method", "slug": "reporting_method", "domain": "customers", "defaultLabel": "Retention Reporting Method", "description": "Whether the company TRACKS cohort retention (NRR/GRR) or does NOT yet track it — the explicit signal the bespoke customers retention grid reads to choose between the tracked 4-card retention view and the not-tracked empty state. Value is `tracked` or `not_tracked`. Without this canonical field the card has to INFER \"tracked\" and can never honestly render the not-tracked state. Common pitfall: leaving NRR/GRR blank to mean \"not tracked\" — that is ambiguous with \"tracked but zero\"; this explicit enum removes the ambiguity.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Enum: 'tracked' (the company computes cohort NRR/GRR) or 'not_tracked' (it does not yet). Drives whether the retention grid renders values or its not-tracked state.", "whyItMatters": "Lets the board distinguish \"retention is bad\" from \"retention is not yet measured\" — two very different early-stage situations that a blank NRR cannot tell apart.", "interpretationGuidance": "When 'not_tracked', the absence of NRR/GRR is expected (not a red flag); the board's ask is to start tracking. When 'tracked', read the NRR/GRR values normally.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.gross_revenue_retention" ] }, { "rogueId": "customers.retention_insights", "slug": "retention_insights", "domain": "customers", "defaultLabel": "Retention Insights", "description": "Free-form commentary from the CS / Sales leadership on retention trends, cohort behavior, and underlying drivers of loyalty (or its absence). Pairs with the quantitative retention KPIs (NRR, GRR, logo retention) and gives the board the \"why\" behind the numbers — which cohorts are strong, which are weak, what feature engagement correlates with retention, what onboarding changes are landing. Common pitfall: filler prose that restates the numbers without adding causal insight — a board reader should learn something here they could not infer from the metrics page alone.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Qualitative — no calculation. Free-form narrative commentary, typically 100–300 words, with concrete cohort references (e.g. \"Q3 2024 cohort showing 12% better NRR than Q2 2024 cohort, driven by adoption of feature X within 30 days of go-live\").", "whyItMatters": "Adds causal explanation to the retention numbers — boards optimize for diagnoses, not just descriptions. Reading \"NRR slipped from 115% to 108%\" is half the story; reading \"NRR slipped because two large customers cut seat counts as they integrated us with an acquired vendor — non-recurring\" is the actionable version.", "interpretationGuidance": "Anti-pattern: prose that restates the numbers (\"NRR was 108% this quarter, down from 115%\") without explaining drivers. Strong content names specific cohorts, customer segments, or product surfaces and ties them to the metric movement. If the team cannot articulate the \"why\" yet, write \"diagnosis in progress — investigating with CS team, update next board\" rather than padding.", "relatedKpiIds": [ "customers.net_revenue_retention", "customers.gross_revenue_retention", "customers.logo_retention_rate", "customers.expansion_opportunities", "customers.churn_risks" ] }, { "rogueId": "customers.top_customer_concentration", "slug": "top_customer_concentration", "domain": "customers", "defaultLabel": "Top Customer Concentration", "description": "Share of total ARR contributed by the top N customers — typically top 5 or top 10. Measures revenue concentration risk: a high concentration means losing one big customer would materially dent ARR. The board reads this alongside `arr_at_risk` and the customer list to gauge how much of the company's future is tied to a handful of accounts. Common pitfall: hiding parent-account aggregation — if three \"customers\" are subsidiaries of the same parent, true concentration is higher than the count-by-logo view shows; settle parent-rollup rules and document them in `customer_definition_note`.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "top_customer_concentration = Σ(ARR of top N customers) ÷ total ARR. N is typically 5 or 10 — fix it for the company and hold it constant. Parent-account roll-up rules must be explicit and stable across periods.", "whyItMatters": "Quantifies \"single-account risk.\" For early-stage companies, high concentration is expected and not necessarily a problem; for growth-stage companies, it constrains valuation multiples and is a frequent due-diligence flag in fundraising and M&A.", "interpretationGuidance": "No single citation-grade benchmark exists; commonly-cited industry folk-wisdom (not citation-grade) holds that top-10 customer concentration above 50% is a yellow flag and any single customer above 20% of ARR is a serious risk that fundraising and acquirer diligence will flag. Trend it across quarters — falling concentration is healthy customer-base diversification; rising concentration deserves a board note even if the absolute number is acceptable today.", "relatedKpiIds": [ "customers.arr_at_risk", "customers.percent_arr_at_risk", "customers.total_customers", "customers.churn_risks", "sales.arr" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "customers.total_customers", "slug": "total_customers", "domain": "customers", "defaultLabel": "Total Customers", "description": "Count of active paying customer logos at the end of the period. \"Active\" means the customer has a live paid subscription or contract on the reporting date — not trial, not cancelled, not zero-revenue. The board reads this alongside ARR to triangulate whether growth is logo-driven (more customers at similar ACV) or expansion-driven (existing customers paying more). Common pitfall: definitions of \"customer\" drift over time as the company sells to subsidiaries, parent accounts, or self-serve users — settle the counting unit (parent vs. account vs. seat) and document it in `customer_definition_note` so cross-period comparisons stay honest.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of customer logos with an active paid subscription/contract on the reporting date. Excludes trials, paused accounts, and $0 contracts. Counting unit (parent vs. account vs. seat) must be documented and held constant period-over-period.", "whyItMatters": "The denominator beneath every retention, churn, and concentration metric — and the simplest read on whether the company is winning new logos at the headline level. Boards use it to disambiguate logo-led vs. ARR-led growth.", "interpretationGuidance": "Net change = new logos − churned logos; pair with `customers_churned` and ARR delta. Stage-typical absolute counts vary so widely (B2B enterprise vs. SMB SaaS) that an absolute count is industry folk-wisdom, not citation-grade — compare instead to the company's own trailing 4-quarter trend. A definitional change to \"customer\" must be flagged on the chart, not absorbed silently.", "relatedKpiIds": [ "customers.customers_churned", "customers.logo_retention_rate", "customers.logo_churn_rate", "customers.top_customer_concentration", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Count one unit per customer logo that holds a LIVE paid subscription or contract on the reporting date — a period-end, point-in-time snapshot.", "\"Active\" means revenue > $0 and the subscription has gone live on the reporting date — a real paying relationship, not a promise.", "Pin the counting unit (parent organization vs. billing account vs. seat) and hold it constant period-over-period; document it in `customer_definition_note`." ], "exclusionRules": [ "Trials, free / freemium accounts, and unconverted pilots — no live paid contract.", "Cancelled / churned logos whose contract is not live on the reporting date.", "$0 contracts (fully-discounted, design-partner, or paused-to-zero accounts) — they are not paying customers.", "Signed-but-not-yet-live logos — count a logo only once its contract goes live, consistent with `customers.new_customers_added`." ], "requiredInputs": [ "Subscription / contract ledger with per-logo live-and-paid status as of the reporting date.", "The pinned counting-unit definition (parent vs. account vs. seat).", "The reporting-date (period-close) boundary." ], "dataSourcePriority": [ "Billing / subscription system with live-paid status keyed by a stable account ID.", "CRM customer table as a fallback — verify against billing, since CRM can lag activation and retain dead logos." ], "edgeCases": [ "Parent / subsidiary deals: count by the pinned logo unit; do not count each subsidiary when the parent is the unit.", "Account merger (two starting logos consolidate into one): the survivor is one logo and the count drops by one — that is NOT churn; disclose the consolidation.", "Paused / suspended account held open at $0 on the reporting date: exclude from the active count (consistent with the $0-contract exclusion) and flag separately.", "A logo holding several contracts or products counts once." ], "validationChecks": [ "`prior_quarter_total_customers + new_customers_added − customers_churned = total_customers`. If the logo bridge does not reconcile, a definitional change or restatement happened — surface it rather than absorbing it.", "The count is a non-negative integer.", "A change to the \"customer\" definition must be flagged on the chart, never silently absorbed into the count." ], "commonMiscomputations": [ "Counting trials, free users, or $0 design-partner accounts as customers — inflates the denominator beneath every retention / churn / concentration metric (this is the count-tree root).", "Counting signed-but-not-yet-live logos here while excluding them in `new_customers_added` (or vice versa) — breaks the logo bridge.", "Logo-unit drift (parent one period, billing-account the next) — manufactures phantom logo growth or shrinkage.", "Double-counting a multi-product or multi-contract logo as several customers.", "Silently restating the count after a \"customer\" redefinition instead of footnoting the change." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" }, "inputContract": { "fields": [ { "name": "subscription_status", "type": "enum", "required": true, "description": "Raw billing-system status, normalized onto whether a logo is counted.", "values": [ "active", "past_due", "trialing", "canceled", "paused" ], "normalizationMap": { "active": "included", "past_due": "included", "trialing": "excluded", "canceled": "excluded", "paused": "excluded" } }, { "name": "counting_unit", "type": "enum", "required": true, "description": "The logo-counting grain. Must be documented and held constant period-over-period.", "values": [ "parent", "account", "seat" ] }, { "name": "contract_amount", "type": "currency", "required": false, "description": "Used to exclude $0 / zero-revenue contracts from the active count." }, { "name": "reporting_date", "type": "date", "required": true, "description": "Logos are counted as of the reporting date (point-in-time)." } ] } }, { "rogueId": "finance.assumptions", "slug": "assumptions", "domain": "finance", "defaultLabel": "Financial Assumptions", "description": "Narrative listing of the key inputs the forecast rests on — growth-rate assumptions, churn assumptions, hiring plan, FX rates, expected timing of large bookings, planned price changes, capitalized-vs-expensed R&D treatment, etc. Without this field, the board cannot tell whether a forecast change reflects a real-world update or a quietly changed assumption. Common pitfall: assumptions are written once at planning and never updated when the underlying reality shifts — track explicitly which assumption changed each quarter and why. Best practice (per \"Venture Deals\" by Feld & Mendelson, and standard board-pack guidance): every material variance vs. forecast should be traceable to either an executed plan or a changed assumption.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "No calculation — free-text narrative. Convention: enumerate top 5–8 assumptions with the value used and the source (plan, observed run-rate, investor letter, board-approved hiring cap).", "whyItMatters": "Makes the forecast auditable across periods. Boards cannot challenge or endorse a number whose assumptions are invisible — and quietly changing assumptions is the single most common source of forecast drift.", "interpretationGuidance": "Flag whenever an assumption changes vs. prior period and note the reason. If the list is missing or stale (unchanged for >2 reporting cycles while reality has clearly moved), treat as a yellow flag on financial-process maturity. No published threshold for completeness — coverage is judged by whether a board member can recompute the forecast from the listed assumptions.", "relatedKpiIds": [ "finance.forecast_notes", "finance.risk_factors", "finance.burn_rate_scenarios" ] }, { "rogueId": "finance.bank_accounts_list", "slug": "bank_accounts_list", "domain": "finance", "defaultLabel": "Bank Accounts", "description": "FX-aware enumeration of the company's bank, brokerage, and money-market accounts — each with bank name, account type, restricted flag, currency, balance, as-of date, and notes. The underlying data source for `finance.total_cash_in_bank`, `finance.total_restricted_cash`, `finance.total_unrestricted_cash`, and the FX conversion that turns multi-currency holdings into a single reporting-currency number. Common pitfall: a single forgotten account (often a legacy operational account or a money-market sweep) silently misstates the total — boards should ask for a checklist reconciliation against the prior board pack each cycle. Best practice: include account-number last-4 (not full numbers, for security) and the FX rate used per non-functional-currency account.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "No calculation — structured list. Sum of balances (converted via per-row FX rate) equals `finance.total_cash_in_bank`; rows flagged `restricted: true` sum to `finance.total_restricted_cash`.", "whyItMatters": "The auditable line-item basis for every aggregate cash KPI on the board pack. Without it, the headline numbers cannot be reconciled and a missing account cannot be detected.", "interpretationGuidance": "Watch for account churn (new accounts opened mid-period without commentary, accounts dropped without explanation) and FX-rate staleness (rates older than the as-of date). A growing number of accounts at growth stage is normal (multiple currencies, multiple banks); a sudden change in account count warrants a footnote.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_restricted_cash", "finance.total_unrestricted_cash", "finance.operationally_available_cash" ] }, { "rogueId": "finance.burn_rate_actual", "slug": "burn_rate_actual", "domain": "finance", "defaultLabel": "Actual Burn Rate (Past Period)", "description": "The single past-period observed burn — gross and net — that anchors the forecast-scenario matrix. The \"we just lived through this\" baseline against which conservative / most-likely / best-case forecasts are projected. Differs from `finance.gross_burn_rate` and `finance.net_burn_rate` in being explicitly a point-in-time historical anchor with both components paired in one object, rather than the standalone monthly KPI values. Common pitfall: anchoring forecasts off a single month with a known one-off (large bill, prepayment received) bakes a distortion into all scenarios — pick a representative period or document the adjustment.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Paired historical observation: `{ gross: finance.gross_burn_rate_for_anchor_period, net: finance.net_burn_rate_for_anchor_period }`. The anchor period is typically the most recently closed reporting period.", "whyItMatters": "Anchors the credibility of the forecast matrix — scenarios that diverge wildly from the actual baseline without explicit drivers are not credible. Boards typically interrogate any scenario whose burn differs from actual by more than ~20% without a named driver.", "interpretationGuidance": "Cross-check the anchor against the 3-month trailing average; if they differ materially, the anchor period was atypical and the forecast may be unrealistic. Pair every anchor with a one-line note on what was one-off and how the forecast normalizes for it.", "relatedKpiIds": [ "finance.gross_burn_rate", "finance.net_burn_rate", "finance.burn_rate_scenarios", "finance.forecast_notes" ], "calculationPolicy": { "inclusionRules": [ "One representative, recently-closed anchor period's observed burn, with gross and net components paired in a single object.", "Use the most recently closed reporting period unless a known one-off makes it unrepresentative — then pick a representative period and document the choice." ], "exclusionRules": [ "Forecast or scenario values — those live in finance.burn_rate_scenarios; this line is the lived-through actual that anchors them.", "Financing flows (raises, debt) — burn is an operating metric.", "Unadjusted single-month distortions (a large bill or prepayment received) unless explicitly normalized and noted." ], "requiredInputs": [ "The anchor period's closed-actual finance.gross_burn_rate and finance.net_burn_rate.", "A one-line note on what was one-off in the anchor period and how the forecast normalizes for it." ], "dataSourcePriority": [ "Closed-period actuals from the same source feeding the standalone gross/net burn KPIs." ], "edgeCases": [ "If the anchor period contained a known one-off, document the adjustment rather than baking the distortion into every scenario.", "If the anchor diverges materially from the trailing-3-month average, the period was atypical and the forecast may be unrealistic." ], "validationChecks": [ "Net ≤ gross for the anchor period.", "Cross-check the anchor against the trailing-3-month average; large divergence flags an atypical anchor." ], "commonMiscomputations": [ "Anchoring forecasts off a single month with a known one-off — bakes the distortion into all scenarios.", "Using a forecast/budget figure as the \"actual\" anchor." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.burn_rate_scenarios", "slug": "burn_rate_scenarios", "domain": "finance", "defaultLabel": "Burn Rate Scenarios", "description": "Forecast burn-rate matrix across three scenarios — conservative (defensive cost plan, slow revenue), mostLikely (current best-estimate), bestCase (aggressive investment with strong revenue) — with gross + net burn for each. Bound to the ScenarioBurnRateMatrix widget alongside the historical `finance.burn_rate_actual` anchor. The board reads this to understand what range of cash trajectories the company is planning for and which one management has chosen as the base case. Common pitfall: the three scenarios cluster tightly (all within ±10% of each other) — that's not three scenarios, it's one scenario with rounding error. Real scenarios should reflect meaningfully different operating decisions and produce visibly different runways.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Structured matrix: `{ conservative: { gross, net }, mostLikely: { gross, net }, bestCase: { gross, net } }`. Each scenario's implied runway = unrestricted_cash / scenario.net.", "whyItMatters": "Forces explicit scenario thinking and surfaces the risk-adjusted range of outcomes the board should plan for — without this, the single-number forecast invites false confidence.", "interpretationGuidance": "Inspect the spread between scenarios — a conservative net burn within 10–15% of best-case usually means the team has not stress-tested its plan (industry folk-wisdom, not citation-grade). Cross-check `mostLikely` against `finance.burn_rate_actual` (trailing 3 months) — divergence > ±15–20% should be footnoted with named drivers in `finance.forecast_notes`.", "relatedKpiIds": [ "finance.burn_rate_actual", "finance.net_burn_rate", "finance.gross_burn_rate", "finance.runway_months", "finance.forecast_notes", "finance.assumptions" ] }, { "rogueId": "finance.cloud_hosting", "slug": "cloud_hosting", "domain": "finance", "defaultLabel": "Cloud / Hosting", "description": "Direct cost of cloud infrastructure, hosting, storage, and compute used to deliver the product (AWS, GCP, Azure, CDN). A cost-of-revenue line because it scales with serving customers. For infrastructure-heavy and AI products this is often the largest COGS component.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Direct cloud / hosting / compute cost of delivering the product for the period.", "whyItMatters": "A primary driver of gross margin, especially for infrastructure- and AI-heavy products.", "interpretationGuidance": "Track as a percentage of total revenue; a rising ratio signals margin pressure or unoptimized infrastructure.", "relatedKpiIds": [ "finance.total_cogs", "finance.gross_margin_pct" ], "calculationPolicy": { "inclusionRules": [ "Production cloud, hosting, storage, compute, and CDN that serves customer traffic and delivers the product — the serving portion of infrastructure.", "A cost-of-revenue line: it scales with serving customers and is often the largest COGS component for infrastructure- and AI-heavy products." ], "exclusionRules": [ "Internal developer tooling and non-production / CI infrastructure — that is finance.rd_tools_software (OpEx).", "External APIs, data providers, and model/LLM inference — broken out to finance.third_party_data.", "Company-wide corporate IT (finance.software_it)." ], "requiredInputs": [ "Cloud bill split between production-serving and non-production environments.", "An allocation method for shared accounts spanning dev and prod." ], "dataSourcePriority": [ "Cloud-provider billing tagged by environment / cost-center.", "FinOps allocation as a fallback where tagging is incomplete." ], "edgeCases": [ "Shared dev+prod accounts need an explicit allocation between COGS and R&D.", "Reserved-instance or committed-use prepayments amortize to the period of benefit, not the payment month.", "Free-tier credits net down the cost." ], "validationChecks": [ "Track as a percentage of total revenue; a rising ratio signals margin pressure or unoptimized infrastructure.", "Feeds finance.total_cogs and finance.gross_margin_pct." ], "commonMiscomputations": [ "Putting all cloud spend (including dev/CI) into COGS — overstates COGS and understates R&D.", "Leaving model-inference / external-API costs here instead of finance.third_party_data, hiding the AI-margin driver." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.contractors_outsourcing", "slug": "contractors_outsourcing", "domain": "finance", "defaultLabel": "Contractors / Outsourcing", "description": "Cost of freelancers, dev shops, outsourced QA, and temporary engineering help for the period. Often used to flex capacity without permanent headcount.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "External / contract R&D labor cost for the period.", "whyItMatters": "A flexible-capacity lever; sustained high spend can signal an under-hired team.", "interpretationGuidance": "Persistent large contractor spend often warrants a build-vs-hire discussion at the board.", "relatedKpiIds": [ "finance.total_rnd", "finance.rd_payroll" ], "calculationPolicy": { "inclusionRules": [ "External / contract R&D labor for the period — freelancers, dev shops, outsourced QA, and temporary engineering help used to flex capacity without permanent headcount." ], "exclusionRules": [ "W-2 employee payroll (finance.rd_payroll / finance.product_design_payroll).", "Non-R&D contractors (a marketing agency belongs in finance.other_sm; outside bookkeeping in finance.legal_accounting_professional).", "Staffing-agency placement fees for permanent hires (finance.recruiting)." ], "requiredInputs": [ "Contractor/vendor invoices for R&D labor.", "1099-vs-W-2 (contractor-vs-employee) classification." ], "edgeCases": [ "A long-term contractor effectively functioning as staff raises classification and co-employment considerations — flag it.", "Used to flex capacity around delivery spikes." ], "validationChecks": [ "Sustained large contractor spend can signal an under-hired team (a build-vs-hire discussion).", "Rolls into finance.total_rnd — part of the same R&D pool as rd_payroll; do not double-count against product.rd_monthly_spend." ], "commonMiscomputations": [ "Classifying contractors as employee payroll (or vice versa) — distorts the employee-vs-contractor mix the board reads.", "Double-counting contractor spend against the product.rd_monthly_spend roll-up." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.cs_payroll", "slug": "cs_payroll", "domain": "finance", "defaultLabel": "CS Payroll", "description": "Fully-loaded compensation for customer success managers, onboarding, and account management (where not sales-owned) for the period. The retention/expansion-oriented people cost, distinct from cost-of-revenue support.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Fully-loaded customer-success personnel cost for the period.", "whyItMatters": "The investment behind retention and expansion; pairs with NRR.", "interpretationGuidance": "Read against NRR/GRR — CS spend that is not moving retention warrants scrutiny.", "relatedKpiIds": [ "finance.total_cs", "customers.net_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "Fully-loaded compensation for customer success managers, onboarding, and account management oriented to retention and expansion (where not sales-owned)." ], "exclusionRules": [ "COGS-classified support and delivery (finance.customer_support_delivery).", "Sales (finance.sales_payroll) and CS tooling (finance.cs_tools_software)." ], "requiredInputs": [ "CS roster with fully-loaded cost.", "The classification rule separating COGS support from OpEx success." ], "edgeCases": [ "A CSM doing both front-line support (COGS) and expansion (OpEx) is allocated by time across the two lines." ], "validationChecks": [ "Read against customers.net_revenue_retention / GRR — CS spend not moving retention warrants scrutiny.", "Rolls into finance.total_cs; distinct from finance.customer_support_delivery — the same human cannot be fully in both." ], "commonMiscomputations": [ "Double-counting a person in cs_payroll and customer_support_delivery.", "Classifying all customer-facing staff as OpEx — overstates gross margin." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.cs_tools_software", "slug": "cs_tools_software", "domain": "finance", "defaultLabel": "CS Tools / Software", "description": "Cost of customer-success tooling for the period — customer-health platforms, support/ticketing, chat, and onboarding tools.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Customer-success tools / software subscriptions for the period.", "whyItMatters": "The tooling overhead of the retention motion.", "interpretationGuidance": "Scales with customer count; watch for overlap with support tooling in COGS.", "relatedKpiIds": [ "finance.total_cs" ], "calculationPolicy": { "inclusionRules": [ "Customer-success tooling — customer-health platforms, support/ticketing, chat, and onboarding tools." ], "exclusionRules": [ "COGS support infrastructure that is a delivery cost (finance.customer_support_delivery).", "GTM sales tools (finance.sm_tools_software) and company-wide IT (finance.software_it)." ], "requiredInputs": [ "The CS SaaS-subscription list." ], "edgeCases": [ "A support tool spanning COGS delivery and OpEx CS is allocated." ], "validationChecks": [ "Scales with customer count; watch for overlap with support tooling in COGS; rolls into finance.total_cs." ], "commonMiscomputations": [ "Double-counting a support tool in COGS and CS OpEx." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.current_asset_adjustments", "slug": "current_asset_adjustments", "domain": "finance", "defaultLabel": "Current Asset Adjustments", "description": "Signed cash effect of period-over-period changes in current assets — accounts receivable, prepaid expenses, deposits, and other short-term assets. Positive when assets are converting back to cash (AR collections, prepaid expenses being consumed); negative when assets are growing and absorbing cash (AR balance up, new prepayments made). Half of the `finance.net_working_capital_adjustment` rollup. Common pitfall: a one-off enterprise prepayment to a vendor (e.g. 12-month infra commit) shows up here as a large negative without the P&L showing the cost yet — flag it explicitly so the board does not read deterioration where there is none.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "-(Δ accounts_receivable + Δ prepaid_expenses + Δ other_current_assets) for the period. The negative sign converts the balance-sheet direction (asset increase = cash decrease) into a signed cash adjustment.", "whyItMatters": "Surfaces the cash impact of growing receivables and prepayments separately from operating spend — important when DSO is moving or large prepaid commitments are taken.", "interpretationGuidance": "A sustained negative trend usually means AR is growing faster than collections (DSO lengthening) — pair with sales-side bookings and ARR to confirm. Industry folk-wisdom (not citation-grade): the cash drag from a growing AR book typically peaks late in the year when annual contracts billed in Q4 land as Q1 receipts.", "relatedKpiIds": [ "finance.current_liability_adjustments", "finance.net_working_capital_adjustment", "finance.operationally_available_cash", "finance.working_capital_adjustments_list" ], "calculationPolicy": { "inclusionRules": [ "The signed cash effect of period-over-period changes in current assets — accounts receivable, prepaid expenses, deposits, and other short-term assets.", "Sign convention: −(Δ AR + Δ prepaid + Δ other current assets). Positive when assets convert back to cash (AR collected, prepaids consumed); negative when assets grow and absorb cash." ], "exclusionRules": [ "Non-current / long-term assets — this is a working-capital (current) line only.", "The current-liability side — that is finance.current_liability_adjustments.", "P&L expense recognition — this is a cash-timing adjustment, not an expense." ], "requiredInputs": [ "Opening and closing current-asset balances by component (AR, prepaid, deposits, other).", "A flag for large one-off prepayments (e.g. a 12-month infra commit) so the negative is not misread." ], "dataSourcePriority": [ "Comparative balance sheets, period-over-period.", "AR aging for the receivables component." ], "edgeCases": [ "A one-off large vendor prepayment shows a big negative here before the P&L shows the cost — flag it explicitly.", "A sustained negative trend usually means AR is growing faster than collections (DSO lengthening)." ], "validationChecks": [ "Sign convention holds: an asset increase produces a negative cash adjustment.", "Rolls into finance.net_working_capital_adjustment together with the liability side." ], "commonMiscomputations": [ "Sign flip — treating an asset increase as a cash inflow.", "Reading a prepayment-driven negative as operating deterioration when no cost has hit the P&L yet." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.current_liability_adjustments", "slug": "current_liability_adjustments", "domain": "finance", "defaultLabel": "Current Liability Adjustments", "description": "Signed cash effect of period-over-period changes in current liabilities — accounts payable, accrued payroll/taxes/bonuses, deferred revenue from customer prepayments, and other short-term liabilities. Positive when liabilities grow and absorb less cash than the matched expense suggests (e.g. AP balance growing means vendor cash payments lag); negative when liabilities are being paid down faster than they accrue. Deferred revenue is the most powerful component in SaaS — a large annual prepayment received increases deferred revenue and supplies cash now against expense recognized later. Common pitfall: a board reading this as straight cash improvement misses that deferred revenue must still be earned out, and a stretched AP balance signals supplier strain. Best practice: footnote large components (deferred revenue, accrued bonus) separately.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "+(Δ accounts_payable + Δ accrued_liabilities + Δ deferred_revenue + Δ other_current_liabilities) for the period. Liability increase = cash supplied, so positive sign.", "whyItMatters": "Captures the cash benefit (or drag) of working-capital liability movements — deferred revenue inflows in particular can mask underlying cash burn at SaaS companies that book annual upfront.", "interpretationGuidance": "A sustained positive trend driven by AP growth (not deferred revenue) is a yellow flag — it means the company is funding itself by lengthening supplier payment cycles. A surge driven by deferred revenue (annual contract closes) is a one-time cash benefit that doesn't recur. Separate the components in commentary.", "relatedKpiIds": [ "finance.current_asset_adjustments", "finance.net_working_capital_adjustment", "finance.operationally_available_cash", "finance.working_capital_adjustments_list" ], "calculationPolicy": { "inclusionRules": [ "The signed cash effect of period-over-period changes in current liabilities — accounts payable, accrued payroll/taxes/bonuses, deferred revenue, and other short-term liabilities.", "Sign convention: +(Δ AP + Δ accrued + Δ deferred revenue + Δ other current liabilities). A liability increase supplies cash, so it is positive." ], "exclusionRules": [ "Long-term / non-current liabilities and debt principal — those are financing, not working capital.", "The current-asset side — that is finance.current_asset_adjustments.", "P&L expense recognition — this is a cash-timing adjustment." ], "requiredInputs": [ "Opening and closing current-liability balances by component.", "Deferred-revenue schedule and accrued-bonus balance, footnoted separately because they behave very differently." ], "dataSourcePriority": [ "Comparative balance sheets, period-over-period.", "AP aging and the deferred-revenue rollforward for the key components." ], "edgeCases": [ "A deferred-revenue surge from an annual contract close is a one-time cash benefit that must still be earned out — not a recurring improvement.", "A positive trend driven by AP growth (not deferred revenue) signals the company is funding itself by stretching supplier payment cycles — a yellow flag." ], "validationChecks": [ "Sign convention holds: a liability increase produces a positive cash adjustment.", "Separate the deferred-revenue driver from the AP driver in commentary — they tell opposite stories." ], "commonMiscomputations": [ "Reading AP-stretch (delayed supplier payment) as a healthy cash improvement.", "Treating deferred-revenue cash as already earned rather than an obligation to deliver." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.customer_support_delivery", "slug": "customer_support_delivery", "domain": "finance", "defaultLabel": "Customer Support & Delivery", "description": "Direct cost of supporting and serving customers that is part of cost-of-revenue (front-line support, delivery operations tied to the product). Distinct from the Customer Success OpEx section, which covers retention/expansion-oriented account management.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Direct cost of serving/supporting customers included in cost of revenue.", "whyItMatters": "Captures the service cost embedded in gross margin, separate from go-to-market CS.", "interpretationGuidance": "If this scales linearly with customers, it caps gross margin; automation should bend the curve over time.", "relatedKpiIds": [ "finance.total_cogs" ], "calculationPolicy": { "inclusionRules": [ "Front-line support and delivery operations that are part of serving the product, classified into cost of revenue (support reps, delivery ops tied to the product)." ], "exclusionRules": [ "Retention/expansion-oriented Customer Success account management — that is finance.cs_payroll (OpEx, finance.total_cs).", "Sales and go-to-market functions." ], "requiredInputs": [ "Support/delivery headcount cost classified to COGS.", "A time-allocation basis for individuals who split between COGS support and OpEx success." ], "edgeCases": [ "A person who both supports (COGS) and drives expansion (OpEx CS) must be allocated by time across the two lines.", "Automation should bend the per-customer support cost curve over time." ], "validationChecks": [ "If this scales linearly with customer count it caps gross margin.", "Distinct from finance.cs_payroll — the same person cannot sit fully in both without an allocation." ], "commonMiscomputations": [ "Double-counting the same person in customer_support_delivery (COGS) and cs_payroll (OpEx).", "Classifying all customer-facing staff as COGS (overstates COGS) or all as OpEx (overstates gross margin)." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.depreciation_amortization", "slug": "depreciation_amortization", "domain": "finance", "defaultLabel": "Depreciation & Amortization", "description": "Non-cash expense allocating the cost of capitalized assets (equipment, capitalized software, intangibles) over their useful life for the period. Below the EBITDA line precisely because EBITDA excludes it; usually small for early-stage software companies.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Non-cash depreciation + amortization expense for the period.", "whyItMatters": "Bridges EBITDA to net income; non-cash, so it affects accounting profit but not burn.", "interpretationGuidance": "Typically immaterial for asset-light software companies; flag if it becomes large (capitalized software/assets).", "relatedKpiIds": [ "finance.ebitda", "finance.net_income" ], "calculationPolicy": { "inclusionRules": [ "Non-cash expense allocating the cost of capitalized assets (equipment, capitalized software, intangibles) over their useful life for the period.", "Sits below the EBITDA line precisely because EBITDA excludes it." ], "exclusionRules": [ "Cash capex — that is an investing outflow, not this line.", "Stock-based compensation — a separate non-cash item.", "Operating-lease cash rent (finance.office_facilities), though ROU-asset amortization under ASC 842 may appear here — state the convention." ], "requiredInputs": [ "Fixed-asset and intangibles register with depreciation schedules and capitalized-software amortization." ], "edgeCases": [ "Typically immaterial for asset-light software companies; large only with capitalized software, equipment, or acquired intangibles." ], "validationChecks": [ "Non-cash — it affects accounting profit and the EBITDA-to-net-income bridge, NOT burn or operating outflow.", "Reconcile to the fixed-asset rollforward." ], "commonMiscomputations": [ "Including D&A in burn or operating outflow — it is non-cash.", "Confusing cash capex with the D&A expense." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.ebitda", "slug": "ebitda", "domain": "finance", "defaultLabel": "EBITDA", "description": "Earnings before interest, taxes, depreciation, and amortization for the period — gross profit minus total operating expense. The core operating result for a startup P&L: the clean view of operating profit or loss before non-operating and non-cash effects.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "ebitda = gross_profit − total_opex.", "whyItMatters": "The headline operating-result line the board reads for profitability/loss before financing and accounting effects.", "interpretationGuidance": "Trend toward break-even is the key read; pair with burn and runway for the cash picture (EBITDA is accrual, not cash).", "relatedKpiIds": [ "finance.gross_profit", "finance.total_opex", "finance.net_burn_rate", "finance.runway_months" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.events_conferences", "slug": "events_conferences", "domain": "finance", "defaultLabel": "Events / Conferences", "description": "Cost of conferences, booths, sponsorships, and event-linked travel for the period. Often lumpy quarter to quarter around event calendars.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Event / conference / sponsorship spend for the period.", "whyItMatters": "A material, lumpy GTM line worth isolating so it does not distort the marketing trend.", "interpretationGuidance": "Expect seasonality around major events; flag the timing when comparing periods.", "relatedKpiIds": [ "finance.total_sm" ], "calculationPolicy": { "inclusionRules": [ "Conference fees, booths, sponsorships, and event-linked travel for the period." ], "exclusionRules": [ "Routine non-event travel (finance.travel_entertainment) and paid digital media (finance.paid_marketing).", "Event-staff compensation (marketing/sales payroll)." ], "requiredInputs": [ "Event invoices and the travel linked to each event." ], "edgeCases": [ "Lumpy and seasonal around event calendars; prepaid sponsorships amortize to the event period." ], "validationChecks": [ "Isolate it so it does not distort the underlying marketing trend; rolls into finance.total_sm." ], "commonMiscomputations": [ "Leaving event spikes inside the paid_marketing trend.", "Double-counting event travel in finance.travel_entertainment." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.forecast_notes", "slug": "forecast_notes", "domain": "finance", "defaultLabel": "Forecast Commentary", "description": "Executive narrative on what the latest forecast says and how it has changed since prior reporting — which scenarios were considered, which was picked as \"most likely\" and why, what changed since last quarter, and what would push the forecast into a different scenario. Pairs with `finance.burn_rate_scenarios` (the numeric scenarios) to provide the qualitative \"why\" beside the quantitative \"what\". Common pitfall: this becomes a restatement of the numbers rather than commentary — every paragraph should add interpretation the numbers do not by themselves convey (drivers, decisions taken, decisions deferred).", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "No calculation — narrative commentary. Convention: cover (1) selected scenario and rationale, (2) deltas vs. prior forecast with reasons, (3) trigger conditions that would move the forecast.", "whyItMatters": "Gives the board the interpretation layer that raw scenario numbers lack — without it, the burn-rate-scenarios table is data without meaning. Disciplined commentary also creates a record of management's rationale that can be re-examined when reality plays out.", "interpretationGuidance": "Compare commentary across periods — if the rationale shifts without the underlying numbers shifting, the team is rationalizing rather than analyzing. If numbers shift without the rationale acknowledging it, controls maturity is the concern. Length is not a quality signal; concrete drivers and named triggers are.", "relatedKpiIds": [ "finance.assumptions", "finance.burn_rate_scenarios", "finance.burn_rate_actual", "finance.risk_factors" ] }, { "rogueId": "finance.fx_gain_loss", "slug": "fx_gain_loss", "domain": "finance", "defaultLabel": "FX Gain / Loss", "description": "Foreign-exchange gain (positive) or loss (negative) for the period from revaluing non-functional-currency balances and transactions. A SIGNED line; relevant for companies holding cash or transacting in multiple currencies.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Signed FX gain (positive) / loss (negative) for the period.", "whyItMatters": "Can swing net income for multi-currency companies even when operations are stable.", "interpretationGuidance": "Enter signed: gain positive, loss negative. Large swings should be footnoted as FX, not operating, effects.", "relatedKpiIds": [ "finance.net_income" ], "calculationPolicy": { "inclusionRules": [ "SIGNED realized and unrealized foreign-exchange gain (positive) or loss (negative) from revaluing non-functional-currency balances and transactions for the period." ], "exclusionRules": [ "Foreign-currency operating revenue/expense translated at the transaction date — that hits the operating lines, not here.", "Interest (finance.interest_income_expense)." ], "requiredInputs": [ "Multi-currency balances with period-end rates, and realized FX on settled transactions." ], "edgeCases": [ "Large swings should be footnoted as FX, not operating, effects.", "The functional-currency designation determines what revalues." ], "validationChecks": [ "Enter signed: gain positive, loss negative.", "Exclude from burn and operating reads when material — it is a revaluation effect, not operations." ], "commonMiscomputations": [ "Leaving FX swings inside the operating lines — distorts the operating trend.", "Sign errors on a loss." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.ga_payroll", "slug": "ga_payroll", "domain": "finance", "defaultLabel": "G&A Payroll", "description": "Fully-loaded compensation for finance, HR, operations, admin, and executive/admin allocation for the period. The people cost of running the company.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Fully-loaded G&A personnel cost for the period.", "whyItMatters": "Overhead that should grow slower than revenue as the company scales.", "interpretationGuidance": "Track as a percentage of revenue; the ratio should trend down with scale.", "relatedKpiIds": [ "finance.total_ga" ], "calculationPolicy": { "inclusionRules": [ "Fully-loaded compensation for finance, HR, operations, admin, and the executive/admin allocation (employees)." ], "exclusionRules": [ "Revenue-generating functions (sales, CS, marketing payroll) and R&D.", "Outsourced recruiter fees (finance.recruiting) and founder time allocated to building product (R&D)." ], "requiredInputs": [ "G&A roster with fully-loaded cost.", "The executive-time allocation method across functions." ], "validationChecks": [ "Track as a percentage of revenue — the ratio should trend down with scale; rolls into finance.total_ga." ], "commonMiscomputations": [ "Dumping all unclassified headcount into G&A.", "Allocating founder engineering time to G&A instead of R&D." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.gross_burn_rate", "slug": "gross_burn_rate", "domain": "finance", "defaultLabel": "Gross Burn Rate", "description": "Average monthly cash outflow before any inflows are netted off — essentially the company's monthly cost base in cash terms. Tracked alongside net burn because net burn alone can mask a structural problem when revenue is masking high cost. The board reads gross burn to understand the absolute cost commitment (mostly payroll, infra, COGS, sales spend) regardless of revenue mix. Common pitfall: founders often optimize the net burn narrative (\"we cut burn 30%\") via a one-time inflow without addressing the gross-burn cost base — the next quarter without that inflow re-exposes the underlying spend. Always present gross and net side-by-side.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "gross_burn_rate = total_operational_outflow / months_in_period. Same denominator and averaging convention as net burn (3-month trailing average is standard). Always greater than or equal to net burn.", "whyItMatters": "Strips revenue volatility from the survival picture — shows the cost commitment the company must support each month regardless of bookings outcomes. A widening gap between gross and net burn that depends on a single deal or one-off inflow is a fragility signal.", "interpretationGuidance": "Compare gross-burn composition (payroll, infra, GTM, COGS) to revenue mix; sustained gross burn growing faster than ARR is a leading deterioration signal even when net burn looks flat. No single published gross-burn threshold exists — interpret relative to ARR and revenue per FTE (`hr.arr_per_fte`). Practitioner consensus (industry folk-wisdom, not citation-grade): payroll typically accounts for 65–80% of gross burn in venture-backed SaaS.", "relatedKpiIds": [ "finance.net_burn_rate", "finance.burn_rate_actual", "finance.total_operational_outflow", "finance.runway_months", "hr.arr_per_fte", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "All cash outflow from operations — payroll, benefits, infra, GTM, COGS, G&A, taxes paid, professional fees, software. No netting of inflows.", "Divide by months in period. Use the same trailing-3-month smoothing as net burn for direct comparability.", "Result is always positive (or zero in the degenerate case of a brand-new entity)." ], "exclusionRules": [ "Financing outflows: debt repayments, equity buybacks, dividend payments. Gross burn is an operating metric.", "M&A outflows (acquisition consideration, transaction fees). Flag separately.", "Non-cash expenses: D&A, stock-based compensation, accrued-but-unpaid items.", "Cash inflows of any kind — gross burn is outflow-only by definition." ], "requiredInputs": [ "Period-by-period total operational outflow.", "Period length and smoothing window.", "Optional: outflow composition breakdown (payroll / infra / GTM / G&A) for narrative." ], "dataSourcePriority": [ "Cash-basis P&L outflow lines.", "Accrual P&L with non-cash items removed (D&A, SBC, accruals)." ], "edgeCases": [ "Annual employer-tax payment cycles cause a 1–2-month outflow spike (typically Jan/Apr in the US). Smoothing window handles this if applied; if not, footnote it.", "Lumpy annual SaaS / infra prepayments (insurance, software renewals) spike outflow in their month. Same handling as employer-tax: smooth or footnote.", "Layoff severance: one-time outflow that can be 2-3x a normal month. ALWAYS flag as one-off and present a \"normalized gross burn\" alongside." ], "validationChecks": [ "Gross burn ≥ net burn always. If gross < net, the inflow side has crossed into the outflow accidentally.", "Payroll typically accounts for 65–80% of gross burn in venture-backed SaaS (industry consensus). Materially outside this band invites a composition narrative.", "Gross burn ÷ ARR provides a cost-coverage view; sustained growth in this ratio while ARR flatlines is a leading deterioration signal." ], "commonMiscomputations": [ "Subtracting any inflow — converts gross burn into net burn and erases the metric's purpose.", "Including financing outflows (debt repayment, buybacks) — makes \"operating cost base\" look higher than it is.", "Counting SBC or D&A as gross burn — these are accounting, not cash.", "Failing to flag severance / restructuring as one-off — a layoff month produces a gross-burn spike that mis-reads as a structural cost expansion." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.gross_margin_pct", "slug": "gross_margin_pct", "domain": "finance", "defaultLabel": "Gross Margin %", "description": "Gross profit as a percentage of total revenue for the period — the headline quality-of-revenue and delivery-efficiency metric. Expressed 0–100. The P&L-statement margin computed from the revenue/COGS split; complements the GTM-level `sales.gross_margin`.", "fieldType": "percentage", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "gross_margin_pct = (gross_profit / total_revenue) × 100.", "whyItMatters": "Signals revenue quality and how much each revenue dollar contributes to covering OpEx.", "interpretationGuidance": "Read the trend and the mix behind it: a services- or usage-heavy period typically lowers blended margin. Benchmark against the company’s own plan; external SaaS benchmarks vary by model (pull a current source rather than assuming a fixed band).", "relatedKpiIds": [ "finance.gross_profit", "finance.total_revenue", "sales.gross_margin" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.gross_profit", "slug": "gross_profit", "domain": "finance", "defaultLabel": "Gross Profit", "description": "Total revenue minus total cost of revenue for the period — the profit left to fund operating expenses. The dollar complement to gross margin and the starting point for the operating-result section.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "gross_profit = total_revenue − total_cogs.", "whyItMatters": "The dollars available to cover OpEx — the bridge from revenue to operating result.", "interpretationGuidance": "Growing gross profit faster than OpEx is the path to EBITDA; read with `finance.gross_margin_pct` for quality.", "relatedKpiIds": [ "finance.total_revenue", "finance.total_cogs", "finance.gross_margin_pct" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.insurance_compliance", "slug": "insurance_compliance", "domain": "finance", "defaultLabel": "Insurance / Compliance", "description": "Cost of D&O and cyber insurance, SOC 2, and regulatory compliance for the period. Rises with company size, customer requirements, and financing stage.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Insurance & compliance cost for the period.", "whyItMatters": "A step-fixed cost driven by stage, customer requirements, and risk posture.", "interpretationGuidance": "Expect step-ups at financings and enterprise-customer thresholds (e.g. SOC 2).", "relatedKpiIds": [ "finance.total_ga" ], "calculationPolicy": { "inclusionRules": [ "D&O, cyber, and general insurance premiums; SOC 2 / ISO audits; and regulatory-compliance costs for the period." ], "exclusionRules": [ "Legal and accounting professional fees (finance.legal_accounting_professional).", "Employee health/benefits, which are loaded into the payroll lines." ], "requiredInputs": [ "Insurance premium schedule (often annual — amortize) and compliance-audit invoices." ], "edgeCases": [ "Step-ups at financings and at enterprise-customer thresholds (e.g. SOC 2).", "Annual premiums amortize monthly rather than expensing in one month." ], "validationChecks": [ "A step-fixed cost driven by stage, customer requirements, and risk posture; rolls into finance.total_ga." ], "commonMiscomputations": [ "Classifying employee health insurance here instead of loaded payroll.", "Expensing an annual premium in a single month." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.interest_income_expense", "slug": "interest_income_expense", "domain": "finance", "defaultLabel": "Interest Income / Expense", "description": "Net interest for the period as a SIGNED line: interest earned on cash/deposits (positive) net of interest paid on loans, venture debt, or other financing (negative). For cash-rich post-raise companies this is often net positive income.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Signed net interest: interest income − interest expense for the period (positive = net income).", "whyItMatters": "Surfaces financing effects below the operating line; meaningful for companies with venture debt or large cash balances.", "interpretationGuidance": "Enter signed: net interest income positive, net interest expense negative. Material venture-debt interest should be footnoted.", "relatedKpiIds": [ "finance.net_income", "finance.total_cash_in_bank" ], "calculationPolicy": { "inclusionRules": [ "SIGNED net interest for the period: interest earned on cash, deposits, and money-market balances (positive) net of interest paid on loans, venture debt, or other financing (negative)." ], "exclusionRules": [ "Debt principal movements — those are financing cash flows, not P&L interest.", "FX revaluation on those balances (finance.fx_gain_loss).", "Operating revenue." ], "requiredInputs": [ "Treasury interest-income statements and debt schedules with interest expense." ], "edgeCases": [ "Cash-rich post-raise companies are often net-positive here.", "Material venture-debt interest should be footnoted." ], "validationChecks": [ "Enter signed: net interest income positive, net interest expense negative.", "Sits below the operating line on the path to net income." ], "commonMiscomputations": [ "Sign errors flipping income and expense.", "Netting debt principal repayment into interest, or classifying interest income as operating inflow." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.legal_accounting_professional", "slug": "legal_accounting_professional", "domain": "finance", "defaultLabel": "Legal, Accounting & Professional Services", "description": "Cost of legal, accounting, audit, tax, fractional CFO, and outside consultants for the period. Often spikes around financings, audits, and major contracts.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Legal / accounting / professional-services fees for the period.", "whyItMatters": "A lumpy overhead line; spikes usually map to financing or compliance events.", "interpretationGuidance": "Footnote one-off drivers (a raise, an audit) so the board reads the trend, not the spike.", "relatedKpiIds": [ "finance.total_ga" ], "calculationPolicy": { "inclusionRules": [ "Legal, accounting, audit, tax-preparation, fractional-CFO, and outside-consultant fees for the period." ], "exclusionRules": [ "In-house finance/legal staff compensation (finance.ga_payroll).", "Insurance and compliance certifications (finance.insurance_compliance) and recruiting agencies (finance.recruiting)." ], "requiredInputs": [ "Professional-services invoices, with financing/audit-driven spikes flagged." ], "edgeCases": [ "Spikes around financings, audits, and major contracts — footnote the one-off driver." ], "validationChecks": [ "Lumpy line — read the trend, not the spike; rolls into finance.total_ga." ], "commonMiscomputations": [ "Treating a financing-driven legal spike as run-rate.", "Classifying SOC 2 / insurance certifications here instead of finance.insurance_compliance." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.marketing_payroll", "slug": "marketing_payroll", "domain": "finance", "defaultLabel": "Marketing Payroll", "description": "Fully-loaded compensation for marketing leadership, demand generation, content, and growth for the period.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Fully-loaded marketing personnel cost for the period.", "whyItMatters": "The people cost of demand generation, distinct from paid media spend.", "interpretationGuidance": "Read alongside paid marketing to understand the people-vs-media split of GTM spend.", "relatedKpiIds": [ "finance.total_sm", "finance.paid_marketing" ], "calculationPolicy": { "inclusionRules": [ "Fully-loaded compensation for marketing leadership, demand generation, content, and growth (employees)." ], "exclusionRules": [ "Paid media spend (finance.paid_marketing) and marketing tooling (finance.sm_tools_software).", "Marketing agencies/contractors and sales staff (finance.sales_payroll)." ], "requiredInputs": [ "Marketing roster with fully-loaded cost." ], "validationChecks": [ "Read alongside finance.paid_marketing to see the people-vs-media split of GTM spend; rolls into finance.total_sm." ], "commonMiscomputations": [ "Mixing agency/contractor spend into payroll.", "Conflating media spend with people cost." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.net_burn_rate", "slug": "net_burn_rate", "domain": "finance", "defaultLabel": "Net Burn Rate", "description": "Average monthly net cash outflow over the reporting period — total cash spent minus total cash collected, divided by the number of months in the period. The headline survival number for venture-backed startups: it pairs with `finance.total_cash_in_bank` to produce runway, and pairs with revenue growth to produce the Bessemer \"burn multiple\". Common pitfall: net burn is volatile — large quarterly bills (annual SaaS renewals, employer-tax true-ups), enterprise prepayments, and FX swings can mask the underlying trend. Smoothing over a trailing 3-month average is standard board practice. Equally important: do not silently include one-off cash events (acquisitions, settlements, large prepayments received) without flagging them — boards prefer a \"core burn\" and \"headline burn\" pair when the period is noisy.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "net_burn_rate = (total_operational_outflow − total_operational_inflow) / months_in_period. Most boards average over a trailing 3 months to dampen lumpy items; flag the methodology explicitly. When net burn is negative, the company is net-cash-generative for the period.", "whyItMatters": "Single most-watched metric below revenue at venture-backed companies — drives runway, valuation reads (via the burn multiple), and the calculus on when to fundraise vs. cut.", "interpretationGuidance": "Compare against the company's own forecast first (`finance.burn_rate_scenarios`); deviation > ±15–20% from the most-likely scenario typically warrants a board note (industry folk-wisdom, not citation-grade). Stage-level industry context: per the SaaS Capital 2025 Spending Benchmarks for Private B2B SaaS Companies, total median spend runs ~95% of ARR for bootstrapped and ~107% of ARR for equity-backed private SaaS, with 55% of equity-backed companies operating at a loss. For burn-multiple framing (net burn ÷ net new ARR), Series A medians sit near 1.2x and growth-stage companies above $25M ARR target ~1.4x with best performers below 1.0x (per cited 2025 industry analyses; pull the live edition to confirm).", "relatedKpiIds": [ "finance.gross_burn_rate", "finance.runway_months", "finance.total_cash_in_bank", "finance.burn_rate_actual", "finance.burn_rate_scenarios", "finance.total_operational_inflow", "finance.total_operational_outflow", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Total cash outflow from operations over the period: payroll + benefits, infrastructure, GTM spend (S&M programs + tooling), COGS, G&A, professional fees, software, taxes.", "Subtract total cash inflow from operations: invoiced revenue collected, customer prepayments received, refunds received.", "Divide the net by the number of months in the period to produce a monthly rate.", "Standard board practice is a trailing-3-month average to dampen single-month lumpiness — state the smoothing window explicitly in any output." ], "exclusionRules": [ "Financing activities: equity raises, venture debt drawdowns, debt repayments. Burn is an operating metric.", "Acquisitions, divestitures, and other M&A cash movements. Flag as one-off, do not net into burn.", "Pure FX revaluation gains/losses on cash balances (when material).", "Stock-based compensation expense — it is not cash." ], "requiredInputs": [ "Period-by-period total operational outflow (`finance.total_operational_outflow`).", "Period-by-period total operational inflow (`finance.total_operational_inflow`).", "Period length and smoothing window (e.g. trailing-3-month).", "Flagged list of known one-off items in the period (large enterprise prepayments received, annual SaaS bills paid, true-ups)." ], "dataSourcePriority": [ "Cash-basis P&L for the period (closes faster than accrual; better matches \"burn\").", "Accrual P&L with a working-capital reconciliation as a fallback — net out non-cash items explicitly." ], "edgeCases": [ "Cash-flow-positive periods: net burn goes negative. Present as \"net cash generation\" rather than \"negative burn\" to avoid misreading.", "Annual SaaS prepayment from a large customer hits in one month: spike the inflow that month and net burn looks artificially good. Boards prefer a \"core burn excluding one-offs\" companion line.", "Employer-tax true-ups (typically Jan/Apr in the US): a single-month outflow up to 30-50% above run-rate. Note the calendar effect in commentary.", "FX swings on a foreign payroll: significant when the period spans currency volatility — break out the FX impact when material." ], "validationChecks": [ "Net burn ≤ gross burn always. If net > gross, the inflow definition is wrong (likely double-counting or including financing inflows).", "Sum of monthly net-burn numbers should reconcile to period-net-burn × months within 1-2%. Larger drift means smoothing is being misapplied.", "Net burn ÷ ARR (burn multiple) should sit within stage-typical bands — out-of-band burn multiple is more often a calculation error than a real outlier." ], "commonMiscomputations": [ "Using accrual-basis operating expenses without removing non-cash items (D&A, SBC, accrued-but-unpaid expense) — overstates burn.", "Netting in equity raise proceeds or venture debt — turns a fundraising month into \"negative burn\" and lies about run-rate spend.", "Spot-month burn instead of a trailing average — a single noisy month becomes the headline number and runway swings wildly.", "Silently including one-off prepayments or M&A consideration — boards want \"core\" and \"headline\" separated; collapsing them hides the trend.", "Counting refunds issued as part of the outflow but not refunds received in the inflow (or vice versa) — sign-mismatch errors are surprisingly common when refunds are large." ], "validationAssertions": [ { "assert": "result <= finance.gross_burn_rate", "severity": "error", "message": "Net burn ≤ gross burn always — net burn is gross burn minus operating inflows. If net > gross, the inflow definition is wrong (double-counting or financing inflows).", "refs": [ "finance.gross_burn_rate" ] } ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" }, "dependencies": [ { "kpi": "finance.gross_burn_rate", "edge": "computesFrom" } ] }, { "rogueId": "finance.net_income", "slug": "net_income", "domain": "finance", "defaultLabel": "Net Income / Loss", "description": "The accounting bottom line for the period — EBITDA less depreciation & amortization and tax, plus the signed interest and FX lines. The final result of the income statement. Distinct from cash burn (an accrual figure, not a cash-flow measure).", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "net_income = ebitda − depreciation_amortization + interest_income_expense − tax + fx_gain_loss (interest and FX are signed inputs).", "whyItMatters": "The statutory bottom line; read alongside burn/runway, since net income is accrual and does not equal cash consumed.", "interpretationGuidance": "For startups, burn and runway usually matter more than net income — but a widening accrual loss is still a board signal. Reconcile to burn via the working-capital and non-cash lines.", "relatedKpiIds": [ "finance.ebitda", "finance.depreciation_amortization", "finance.interest_income_expense", "finance.tax", "finance.fx_gain_loss", "finance.net_burn_rate" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.net_working_capital_adjustment", "slug": "net_working_capital_adjustment", "domain": "finance", "defaultLabel": "Net Working Capital Adjustment", "description": "Signed net effect on cash of changes in current assets and current liabilities — receivables coming in (positive), payables going out (negative), prepaid expenses (negative when paid, positive when burned down), and accrued liabilities (positive when accrued, negative when settled). The rollup of `finance.current_asset_adjustments` and `finance.current_liability_adjustments`. Common pitfall: at early stage this is dominated by payroll-cycle noise and is near zero — once the company adds enterprise contracts with annual prepayments or 60-day net terms, this can swing 1–3 months of burn either direction. Becomes material at Series A+; ignored before that.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "net_working_capital_adjustment = current_asset_adjustments + current_liability_adjustments (signed). Positive value means working capital is releasing cash; negative means working capital is consuming cash beyond what the P&L shows.", "whyItMatters": "Bridges the gap between accrual-basis P&L and cash-basis runway. A board reading the P&L alone can miss a working-capital headwind that is materially shortening runway.", "interpretationGuidance": "Track period-over-period: a multi-period negative trend (working capital absorbing cash) usually means DSO is lengthening or supplier terms are tightening — both warrant a board note. No published threshold exists for \"good\" magnitude — it scales with revenue and contract mix.", "relatedKpiIds": [ "finance.current_asset_adjustments", "finance.current_liability_adjustments", "finance.operationally_available_cash", "finance.working_capital_adjustments_list" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.office_facilities", "slug": "office_facilities", "domain": "finance", "defaultLabel": "Office / Facilities", "description": "Cost of rent, coworking, and office facilities for the period. Smaller for remote-first companies; a fixed commitment where leased.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Office / facilities / rent cost for the period.", "whyItMatters": "A fixed cost and lease commitment that affects runway flexibility.", "interpretationGuidance": "Note lease commitments separately from period cost when discussing runway.", "relatedKpiIds": [ "finance.total_ga" ], "calculationPolicy": { "inclusionRules": [ "Rent, coworking, office facilities, utilities, and maintenance for the period." ], "exclusionRules": [ "The capital/right-of-use lease asset amortization (depreciation & amortization) where presented separately.", "Lease commitment principal — a balance-sheet liability, not period cost." ], "requiredInputs": [ "Lease schedule and period rent; coworking invoices." ], "edgeCases": [ "ASC 842 splits right-of-use asset amortization from cash rent — state which is shown.", "Smaller for remote-first companies; a fixed commitment where leased." ], "validationChecks": [ "A fixed cost and lease commitment affecting runway flexibility — note the remaining commitment separately from period cost; rolls into finance.total_ga." ], "commonMiscomputations": [ "Confusing cash rent with ROU-asset depreciation under ASC 842.", "Ignoring the remaining lease commitment when discussing runway." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.operationally_available_cash", "slug": "operationally_available_cash", "domain": "finance", "defaultLabel": "Operationally Available Cash", "description": "Unrestricted cash adjusted for near-term working-capital effects — i.e. the cash that is actually deployable after accounting for receivables coming in, payables going out, and accrued obligations crystallizing in the next reporting period. More conservative than `finance.total_unrestricted_cash` because it nets out the cash a healthy AR/AP cycle is already promising or claiming. The board reads this as the \"real\" cash position when working capital is material to the business (typical at Series A+, when AR/AP cycles get sizeable). Common pitfall: at early stage AR is small and AP is mostly payroll/SaaS, so this collapses to unrestricted cash — once enterprise deals or 60-day net terms appear, the gap widens fast.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "finance.total_unrestricted_cash + finance.net_working_capital_adjustment. The working-capital adjustment is signed (positive when AR collection > AP outflow over the horizon, negative otherwise).", "whyItMatters": "Best single-number answer to \"how much cash do we really have to deploy this quarter\" once working capital is material. Substituted for unrestricted cash in the runway denominator at growth stage.", "interpretationGuidance": "A large negative gap between unrestricted and operationally-available cash means working-capital headwinds are eating into apparent runway — common when DSO is lengthening. Track the gap quarter-over-quarter; widening signals deteriorating collections or stretched payables. No published industry threshold — interpretation is company- and cycle-specific.", "relatedKpiIds": [ "finance.total_unrestricted_cash", "finance.net_working_capital_adjustment", "finance.current_asset_adjustments", "finance.current_liability_adjustments", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "Start with `finance.total_unrestricted_cash` (all unrestricted cash + cash equivalents, not segregated for a specific purpose).", "Add the signed `finance.net_working_capital_adjustment` for the lookahead horizon (positive when AR collections exceed AP outflows over the window, negative otherwise).", "Use the same lookahead horizon as the company's burn calculation — typically one reporting period (month or quarter)." ], "exclusionRules": [ "Restricted cash (collateral for leases, prepaid customer balances, escrow). It is not deployable.", "Long-term receivables that will not collect within the lookahead horizon.", "Undrawn venture debt or credit facilities — those are funding capacity, not cash." ], "requiredInputs": [ "Period-end unrestricted cash balance.", "AR aging bucketed by collection horizon.", "AP aging + scheduled cash outflows over the lookahead horizon.", "Any accrued obligations crystallizing in the horizon (payroll true-ups, employer-tax payments)." ], "dataSourcePriority": [ "Audited or reviewed balance sheet for cash + AR + AP + accruals.", "Treasury / FP&A working-capital forecast as a fallback when accounting is closing-period-only." ], "edgeCases": [ "Multi-currency cash: convert each currency to reporting currency at a stable period-end rate, then sum.", "Customer prepayments held in restricted accounts: NOT deployable — flag separately.", "Pending acquisition or M&A consideration earmarked but not yet wired: exclude from operationally-available; show as a memo line." ], "validationChecks": [ "Operationally-available cash ≤ total unrestricted cash + maximum-net-positive working-capital swing — if it exceeds, the working-capital adjustment is wrong.", "When working capital is small (typical pre-Series-A), this should be within ~5% of `finance.total_unrestricted_cash`. Wide divergence at early stage is a calculation red flag." ], "commonMiscomputations": [ "Using total cash (including restricted) — inflates the deployable position and overstates runway.", "Omitting the working-capital adjustment entirely — defaults back to unrestricted cash and misses the AR/AP timing mismatch that this KPI exists to capture.", "Mixing fiscal-year-end snapshot with mid-quarter working-capital adjustment — periods must align.", "Treating an undrawn credit facility as \"operationally available\" — facility access is not cash on hand." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "computed" }, "dependencies": [ { "kpi": "finance.total_unrestricted_cash", "edge": "computesFrom" } ] }, { "rogueId": "finance.other_cogs", "slug": "other_cogs", "domain": "finance", "defaultLabel": "Other COGS", "description": "Direct cost-of-revenue items not captured by the named COGS lines — a catch-all kept small by design. If it becomes material it should be split into a named line.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Direct cost-of-revenue not classified in the named COGS lines.", "whyItMatters": "Keeps total COGS complete without distorting the primary cost categories.", "interpretationGuidance": "If \"Other\" grows beyond a few percent of COGS, split it into a named line.", "relatedKpiIds": [ "finance.total_cogs" ], "calculationPolicy": { "inclusionRules": [ "Direct cost-of-revenue items not captured by the named COGS lines — a deliberately small catch-all." ], "exclusionRules": [ "Operating expenses — only true cost-of-delivery belongs above the gross-margin line.", "Material items that deserve their own named COGS line." ], "validationChecks": [ "Keep within a few percent of total COGS; if it grows, split it into a named line." ], "commonMiscomputations": [ "Parking OpEx in Other COGS to flatter gross margin.", "Letting it become a material, unexplained bucket." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.other_cs", "slug": "other_cs", "domain": "finance", "defaultLabel": "Other CS", "description": "Customer-success operating costs not captured by the named CS lines for the period — a catch-all kept small by design.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "CS operating costs not classified in the named CS lines.", "whyItMatters": "Keeps Total Customer Success complete without distorting the primary lines.", "interpretationGuidance": "If it grows beyond a few percent of CS, split into a named line.", "relatedKpiIds": [ "finance.total_cs" ], "calculationPolicy": { "inclusionRules": [ "Customer Success operating costs not captured by the named Customer Success lines — a deliberately small catch-all." ], "exclusionRules": [ "Anything that fits a named line within the Customer Success section — classify it there first.", "Costs belonging to a different section (R&D vs S&M vs CS vs G&A) — keep section boundaries clean.", "Material items that deserve their own named line." ], "validationChecks": [ "Keep within a few percent of finance.total_cs; if it grows beyond that, split it into a named line; rolls into finance.total_cs." ], "commonMiscomputations": [ "Using Other as a dumping ground that hides a growing real cost.", "Misclassifying another section's cost into this Other line." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.other_ga", "slug": "other_ga", "domain": "finance", "defaultLabel": "Other G&A", "description": "G&A operating costs not captured by the named G&A lines for the period — the roll-up home for minor overhead (bank fees, office supplies, small licenses). Kept small by design.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "G&A operating costs not classified in the named G&A lines.", "whyItMatters": "Keeps Total G&A complete and absorbs the many small overhead items.", "interpretationGuidance": "If it grows beyond a few percent of G&A, split into a named line.", "relatedKpiIds": [ "finance.total_ga" ], "calculationPolicy": { "inclusionRules": [ "G&A operating costs not captured by the named G&A lines — a deliberately small catch-all (bank fees, office supplies, small licenses)." ], "exclusionRules": [ "Anything that fits a named line within the G&A section — classify it there first.", "Costs belonging to a different section (R&D vs S&M vs CS vs G&A) — keep section boundaries clean.", "Material items that deserve their own named line." ], "validationChecks": [ "Keep within a few percent of finance.total_ga; if it grows beyond that, split it into a named line; rolls into finance.total_ga." ], "commonMiscomputations": [ "Using Other as a dumping ground that hides a growing real cost.", "Misclassifying another section's cost into this Other line." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.other_revenue", "slug": "other_revenue", "domain": "finance", "defaultLabel": "Other Revenue", "description": "Recognized revenue not captured by the subscription, usage, or services lines — a catch-all for small or unusual revenue items. Kept small by design; if it becomes material it should be split into a named line.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Recognized revenue not classified as subscription, usage, or services.", "whyItMatters": "Keeps total revenue complete without polluting the primary revenue categories.", "interpretationGuidance": "If \"Other\" grows beyond a few percent of total revenue, split it into a named line for the board.", "relatedKpiIds": [ "finance.total_revenue" ], "calculationPolicy": { "inclusionRules": [ "Recognized revenue not classified as subscription, usage, or services — a deliberately small catch-all for minor or unusual revenue items." ], "exclusionRules": [ "Any item large enough to deserve a named line — split it out rather than parking it here.", "Non-revenue items: interest income (finance.interest_income_expense), FX (finance.fx_gain_loss), and financing proceeds." ], "requiredInputs": [ "An itemization of what currently sits in Other so it can be monitored." ], "validationChecks": [ "Other should stay within a few percent of total revenue; if it grows beyond that, split it into a named line for the board." ], "commonMiscomputations": [ "Parking interest income, FX, or financing items in Other revenue.", "Letting Other become a material catch-all that hides the true revenue mix." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "recognized_revenue", "production": "primary" } }, { "rogueId": "finance.other_rnd", "slug": "other_rnd", "domain": "finance", "defaultLabel": "Other R&D", "description": "R&D operating costs not captured by the named R&D lines for the period — a catch-all kept small by design.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "R&D operating costs not classified in the named R&D lines.", "whyItMatters": "Keeps Total R&D complete without distorting the primary lines.", "interpretationGuidance": "If it grows beyond a few percent of R&D, split into a named line.", "relatedKpiIds": [ "finance.total_rnd" ], "calculationPolicy": { "inclusionRules": [ "R&D operating costs not captured by the named R&D lines — a deliberately small catch-all." ], "exclusionRules": [ "Anything that fits a named line within the R&D section — classify it there first.", "Costs belonging to a different section (R&D vs S&M vs CS vs G&A) — keep section boundaries clean.", "Material items that deserve their own named line." ], "validationChecks": [ "Keep within a few percent of finance.total_rnd; if it grows beyond that, split it into a named line; rolls into finance.total_rnd." ], "commonMiscomputations": [ "Using Other as a dumping ground that hides a growing real cost.", "Misclassifying another section's cost into this Other line." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.other_sm", "slug": "other_sm", "domain": "finance", "defaultLabel": "Other S&M", "description": "Sales & marketing operating costs not captured by the named S&M lines for the period — a catch-all kept small by design.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "S&M operating costs not classified in the named S&M lines.", "whyItMatters": "Keeps Total S&M complete without distorting the primary lines.", "interpretationGuidance": "If it grows beyond a few percent of S&M, split into a named line.", "relatedKpiIds": [ "finance.total_sm" ], "calculationPolicy": { "inclusionRules": [ "S&M operating costs not captured by the named S&M lines — a deliberately small catch-all." ], "exclusionRules": [ "Anything that fits a named line within the S&M section — classify it there first.", "Costs belonging to a different section (R&D vs S&M vs CS vs G&A) — keep section boundaries clean.", "Material items that deserve their own named line." ], "validationChecks": [ "Keep within a few percent of finance.total_sm; if it grows beyond that, split it into a named line; rolls into finance.total_sm." ], "commonMiscomputations": [ "Using Other as a dumping ground that hides a growing real cost.", "Misclassifying another section's cost into this Other line." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.paid_marketing", "slug": "paid_marketing", "domain": "finance", "defaultLabel": "Paid Marketing", "description": "Paid demand-generation spend for the period — search, social, performance marketing, and sponsorships. The variable media component of go-to-market.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Paid media / performance-marketing spend for the period.", "whyItMatters": "A directly-tunable growth lever; the core input to paid CAC.", "interpretationGuidance": "Judge against pipeline/bookings generated, not in isolation.", "relatedKpiIds": [ "finance.total_sm", "finance.marketing_payroll" ], "calculationPolicy": { "inclusionRules": [ "Paid demand-generation media for the period — search, social, performance marketing, and paid sponsorships." ], "exclusionRules": [ "Marketing staff compensation (finance.marketing_payroll) and marketing tooling (finance.sm_tools_software).", "Events and conferences (finance.events_conferences) and organic/content production labor." ], "requiredInputs": [ "Ad-platform spend and sponsorship invoices." ], "validationChecks": [ "Judge against the pipeline/bookings generated (paid CAC), not in isolation; rolls into finance.total_sm." ], "commonMiscomputations": [ "Bundling agency management fees or tooling into media spend.", "Reading media spend without the pipeline it produced." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.payment_transaction_costs", "slug": "payment_transaction_costs", "domain": "finance", "defaultLabel": "Payment / Transaction Costs", "description": "Direct payment-processing and transaction fees attributable to delivering revenue (card processing, gateway fees, marketplace take rates). A cost-of-revenue line where relevant; omitted or near-zero for invoice-only businesses.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Payment-processing / transaction fees attributable to revenue for the period.", "whyItMatters": "Directly reduces gross margin on transaction- or consumer-billed revenue.", "interpretationGuidance": "Expressed as a percentage of processed revenue it should be roughly stable; spikes usually mean a pricing/mix change.", "relatedKpiIds": [ "finance.total_cogs" ], "calculationPolicy": { "inclusionRules": [ "Direct payment-processing and transaction fees attributable to collecting revenue — card processing, gateway fees, and marketplace take rates." ], "exclusionRules": [ "Corporate banking and wire fees that are G&A (finance.other_ga / finance.software_it).", "Near-zero or omitted entirely for invoice-only businesses." ], "requiredInputs": [ "Processor statements and the fee expressed as a percentage of processed volume." ], "validationChecks": [ "As a percentage of processed revenue it should be roughly stable; spikes usually mean a pricing or mix change." ], "commonMiscomputations": [ "Classifying corporate banking fees here.", "Omitting marketplace take rates on partner-billed revenue." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.product_design_payroll", "slug": "product_design_payroll", "domain": "finance", "defaultLabel": "Product / Design Payroll", "description": "Compensation for product managers and designers for the period. Can be folded into R&D payroll at smaller companies; kept separate where product/design is a distinct cost center.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Fully-loaded product + design personnel cost for the period.", "whyItMatters": "Separates product/design investment from pure engineering for a clearer R&D mix.", "interpretationGuidance": "Read alongside R&D payroll; a rising ratio signals heavier product investment.", "relatedKpiIds": [ "finance.total_rnd", "finance.rd_payroll" ], "calculationPolicy": { "inclusionRules": [ "Fully-loaded compensation for product managers and designers (employees)." ], "exclusionRules": [ "Engineering (finance.rd_payroll) and design contractors/agencies (finance.contractors_outsourcing).", "Marketing design (finance.marketing_payroll)." ], "requiredInputs": [ "Product/design roster with fully-loaded cost." ], "edgeCases": [ "A designer serving marketing rather than product is classified by the function they support.", "At smaller companies this can be folded into finance.rd_payroll — if so, do not also count it here." ], "validationChecks": [ "Read alongside finance.rd_payroll for the R&D mix; rolls into finance.total_rnd." ], "commonMiscomputations": [ "Double-counting when product/design is also folded into rd_payroll.", "Classifying a product-marketing designer here instead of marketing." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.rd_payroll", "slug": "rd_payroll", "domain": "finance", "defaultLabel": "R&D Payroll", "description": "Fully-loaded compensation for engineering, data, QA, DevOps, and technical leadership for the period (salary, employer taxes, benefits). The largest R&D cost for most software companies.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Fully-loaded R&D personnel cost for the period.", "whyItMatters": "The dominant input to R&D spend and a primary driver of total burn.", "interpretationGuidance": "Track against headcount plan; step-changes usually reflect hiring or comp true-ups.", "relatedKpiIds": [ "finance.total_rnd", "hr.total_headcount" ], "calculationPolicy": { "inclusionRules": [ "Fully-loaded compensation (salary + employer taxes + benefits) for engineering, data, QA, DevOps, and technical leadership EMPLOYEES." ], "exclusionRules": [ "Contractors, freelancers, and dev shops — those are finance.contractors_outsourcing, not payroll.", "Product managers and designers (finance.product_design_payroll) and engineering tooling (finance.rd_tools_software).", "Production cloud serving customers (finance.cloud_hosting, COGS)." ], "requiredInputs": [ "R&D-classified employee roster with fully-loaded cost.", "Period payroll register mapped to department." ], "dataSourcePriority": [ "Payroll system grouped by department.", "HRIS headcount mapping as the classification source." ], "edgeCases": [ "An engineer split between R&D and COGS support is allocated by time.", "Mid-period new hires are prorated; comp true-ups step the line.", "If the company capitalizes software-development labor, state the convention — capitalized labor is not expensed here." ], "validationChecks": [ "Track against the headcount plan; step-changes should map to hiring or comp true-ups.", "Rolls into finance.total_rnd. NOTE: finance.total_rnd and product.rd_monthly_spend are two views of the SAME R&D spend — never sum them." ], "commonMiscomputations": [ "Reporting base payroll instead of fully-loaded cost — under-reports true R&D burn by 25–40%.", "Folding contractors into payroll — breaks the employee-vs-contractor read and double-counts against finance.contractors_outsourcing.", "Double-counting R&D payroll against the product.rd_monthly_spend roll-up." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.rd_tools_software", "slug": "rd_tools_software", "domain": "finance", "defaultLabel": "R&D Tools / Software", "description": "Cost of engineering tooling and platforms for the period (source control, CI/CD, testing, observability, developer platforms). Operating expense — distinct from cloud/hosting COGS that serves customer traffic.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Engineering tools / software subscriptions for the period.", "whyItMatters": "Scales with team size; a useful efficiency read per engineer.", "interpretationGuidance": "Do not confuse with cloud/hosting COGS — this is internal developer tooling, not delivery infrastructure.", "relatedKpiIds": [ "finance.total_rnd", "finance.cloud_hosting" ], "calculationPolicy": { "inclusionRules": [ "Internal engineering tooling and platforms — source control, CI/CD, testing, observability, and developer platforms." ], "exclusionRules": [ "Production cloud/hosting that serves customers (finance.cloud_hosting, COGS).", "Company-wide IT/SaaS (finance.software_it) and GTM tools (finance.sm_tools_software)." ], "requiredInputs": [ "The engineering SaaS-subscription list." ], "edgeCases": [ "A tool used both for CI (R&D) and production monitoring (COGS) is allocated.", "Useful as a per-engineer tooling-efficiency read." ], "validationChecks": [ "Scales with team size; rolls into finance.total_rnd.", "Do NOT confuse with finance.cloud_hosting — this is internal developer tooling, not delivery infrastructure." ], "commonMiscomputations": [ "Classifying production infrastructure as R&D tooling — understates COGS.", "Classifying internal dev tooling as COGS — overstates COGS." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.recruiting", "slug": "recruiting", "domain": "finance", "defaultLabel": "Recruiting", "description": "Cost of agencies, job boards, and referral bonuses for the period. Scales with the pace of hiring and is lumpy around growth pushes.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Recruiting / agency / referral cost for the period.", "whyItMatters": "A leading indicator of headcount growth and future payroll.", "interpretationGuidance": "Expect it to lead payroll increases; spikes precede hiring waves.", "relatedKpiIds": [ "finance.total_ga", "hr.total_headcount" ], "calculationPolicy": { "inclusionRules": [ "Agency fees, job-board spend, referral bonuses, and recruiting tooling/events for the period." ], "exclusionRules": [ "In-house recruiter salaries — those sit in the relevant payroll line (finance.ga_payroll or the hiring function's payroll).", "Relocation and sign-on bonuses for a specific hire (the hire's payroll)." ], "requiredInputs": [ "Recruiting vendor invoices and referral-bonus payouts." ], "edgeCases": [ "Lumpy around hiring waves; it leads payroll increases." ], "validationChecks": [ "A leading indicator of headcount and future payroll growth; rolls into finance.total_ga." ], "commonMiscomputations": [ "Counting in-house recruiter compensation here — double-counts with payroll.", "Smoothing inherently lumpy recruiting spend and hiding the hiring-wave signal." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.risk_factors", "slug": "risk_factors", "domain": "finance", "defaultLabel": "Financial Risk Factors", "description": "Material risks that could break the forecast or the cash position — customer concentration, contract renewal risk in the next 2 quarters, debt-covenant proximity, FX exposure on multi-currency revenue/cost mix, payment-processor concentration, audit/tax adjustments under review, regulatory changes affecting revenue recognition. Distinct from `risk_factors` at the operations level — this is explicitly financial. Common pitfall: this field becomes boilerplate (\"market risk, execution risk\") instead of naming the specific risks the board can act on this quarter. Best practice (per the standard board-pack guidance reflected in NVCA Model Investor Rights Agreement information-rights conventions): name the top 3–5 risks with a probability/impact note and a current mitigation status.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "No calculation — narrative. Convention: 3–5 risks, each with a one-line statement, qualitative likelihood, qualitative impact, and current mitigation action.", "whyItMatters": "Gives the board a defensible answer to \"what should worry us next quarter\" — and creates an audit trail of which risks management saw coming vs. which surprised them. Frequently the highest-signal part of the cash dashboard at growth stage.", "interpretationGuidance": "Track risks across periods — risks that disappear without explicit resolution are usually still active, just not being managed. Boards should treat a thin or unchanged list (no movement quarter-over-quarter on multiple periods) as a yellow flag on financial-controls maturity.", "relatedKpiIds": [ "finance.assumptions", "finance.forecast_notes", "finance.burn_rate_scenarios", "fundraising.risk_factors" ] }, { "rogueId": "finance.runway_months", "slug": "runway_months", "domain": "finance", "defaultLabel": "Runway (Months)", "description": "Estimated number of months the company can operate at the current net burn before unrestricted cash reaches zero, holding everything else constant. The single most consequential survival input for venture-backed companies — it sets the urgency of every fundraising, hiring, and cost decision. Common pitfall: runway is often quoted off `finance.total_cash_in_bank` and a single-month spot-burn instead of operationally-available cash and a 3-month-trailing burn — the result is a runway that looks 2–4 months longer than it actually is when working capital tightens. Boards should ask which cash and which burn went into the calculation.", "fieldType": "number", "unit": "months", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "Months of Cash (Runway) by ARR Cohort", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "formula": "runway_months = cash_basis / finance.net_burn_rate, where cash_basis is finance.operationally_available_cash when working capital is material (Series A+), and finance.total_unrestricted_cash otherwise (early stage, when AR/AP is immaterial and the two converge). Never use max() of the two — that discards the more conservative number exactly when working capital is a headwind, the very pitfall this KPI warns about. When net burn is negative (cash-flow positive), runway is unbounded — render as ∞ rather than negative. Most boards use a 3-month-trailing-average net burn for the denominator to dampen single-month noise.", "whyItMatters": "Drives the timing of every fundraise, hire, and budget cut — and is the number investors lead with in diligence. Crossing under stage-typical thresholds usually triggers a board-level cost or fundraising conversation.", "interpretationGuidance": "Stage-typical industry context (per the 2024 KeyBanc Capital Markets & Sapphire Ventures SaaS Survey §runway / month-of-cash discussion): private SaaS companies with $10M–$50M year-end ARR median ~25 months of cash; those <$10M or >$50M ARR median ~18 months. Practitioner heuristics (industry folk-wisdom, not citation-grade): under 6 months is critical (immediate fundraise or cost action); 12–18 months is healthy for active fundraising; 24+ months gives optionality. Recalculate any time burn changes materially or a tranche closes.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_unrestricted_cash", "finance.operationally_available_cash", "finance.net_burn_rate", "finance.burn_rate_scenarios", "fundraising.target_raise" ], "calculationPolicy": { "inclusionRules": [ "Numerator: at growth stage (Series A+) use `finance.operationally_available_cash`. At early stage, `finance.total_unrestricted_cash` is acceptable when AR/AP are immaterial.", "Denominator: `finance.net_burn_rate` on a trailing-3-month-average basis. Match the smoothing window used in the burn calculation.", "Result is in months. Express to one decimal place when ≥ 6; whole months when < 6 (decimals at sub-6-month runway suggest false precision)." ], "exclusionRules": [ "Restricted cash from the numerator (collateral, escrow, customer-prepaid-restricted balances).", "Undrawn credit facilities or venture-debt capacity — those are funding capacity, not runway. List separately as \"available capital outside runway.\"", "Equity raises in process but not closed. Runway is a backward-looking metric; pending fundraises go in the fundraising-strategy KPI, not here." ], "requiredInputs": [ "Operationally-available (or unrestricted) cash for the period close.", "Trailing-3-month net burn rate.", "Methodology flag: which cash definition and which burn smoothing window were used." ], "dataSourcePriority": [ "Audited or reviewed cash balance + a closed-period burn calculation.", "Treasury-system cash + FP&A burn forecast as a fallback — flag uncertainty." ], "edgeCases": [ "Negative net burn (cash-flow positive): runway is mathematically unbounded. Render as \"∞\" or \"cash-flow positive\" — never a negative or null number.", "Net burn very close to zero (break-even): runway becomes hyper-sensitive to denominator noise. Use a wider smoothing window (6-month) or flag the runway as \"approaching breakeven, not meaningful as a single number.\"", "Pending tranche close: typical practice is to compute runway both with and without the expected tranche, label clearly.", "Material foreign-currency cash: convert to reporting currency at a stable rate and disclose the conversion." ], "validationChecks": [ "Result is positive (or infinity). A negative or NaN runway indicates a bug — most often a negative cash balance or a zero burn.", "Recompute monthly; runway should change roughly linearly with elapsed time when burn is stable. Step-function jumps usually mean the burn smoothing window slid or a tranche closed.", "Cross-check against stage-typical KBCM bands (~25 months for $10–50M ARR, ~18 months below or above). Out-of-band runway is more often a calculation issue than a real outlier." ], "commonMiscomputations": [ "Using total cash (including restricted) in the numerator — overstates runway by the restricted balance.", "Using a single-month spot burn instead of a trailing average — runway whipsaws on monthly noise; boards see \"we lost 4 months of runway in a month\" when it's just a lumpy outflow.", "Mixing unrestricted-cash numerator with operationally-available-cash burn (or vice versa) — definitions must agree on what cash is being depleted.", "Counting undrawn venture debt as \"runway\" — boards see ~6 extra months of runway that aren't actually deployable without drawing the facility (which itself takes weeks and has covenants).", "Reporting runway from total cash but using a burn that already includes financing inflows — double counts and reads ~2x longer than reality." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "computed" }, "dependencies": [ { "kpi": "finance.net_burn_rate", "edge": "computesFrom" }, { "kpi": "finance.operationally_available_cash", "edge": "computesFrom" }, { "kpi": "finance.burn_rate_scenarios", "edge": "narrates" } ] }, { "rogueId": "finance.sales_commissions", "slug": "sales_commissions", "domain": "finance", "defaultLabel": "Sales Commissions", "description": "Variable sales compensation earned on bookings for the period. Separated from sales payroll because it scales with deals closed and explains period-to-period variance differently.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Variable commission expense recognized for the period.", "whyItMatters": "Ties go-to-market cost to bookings; a key input to CAC.", "interpretationGuidance": "Should move with bookings; a spike without bookings growth warrants a note.", "relatedKpiIds": [ "finance.total_sm", "finance.sales_payroll" ], "calculationPolicy": { "inclusionRules": [ "Variable sales compensation EARNED on bookings, recognized for the period." ], "exclusionRules": [ "Base salary (finance.sales_payroll) and marketing/partner referral spend.", "SPIFFs or non-sales incentives if tracked elsewhere." ], "requiredInputs": [ "Commission plan and period bookings.", "The capitalization/amortization policy (ASC 340-40 on incremental costs to obtain a contract)." ], "edgeCases": [ "Under ASC 606/340-40 incremental commissions may be capitalized and amortized over the contract life rather than expensed at booking — state the convention.", "Clawbacks on early churn reduce the expense." ], "validationChecks": [ "Should move with bookings; a spike without bookings growth warrants a note.", "Rolls into finance.total_sm." ], "commonMiscomputations": [ "Expensing at the cash-payment date instead of the earned/recognition date.", "Ignoring ASC 606 capitalization where the amounts are material." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.sales_payroll", "slug": "sales_payroll", "domain": "finance", "defaultLabel": "Sales Payroll", "description": "Fully-loaded base compensation for account executives, SDRs, and sales leadership for the period. Excludes commissions, which are tracked separately because they scale with bookings.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Fully-loaded sales base personnel cost for the period (excl. commissions).", "whyItMatters": "The fixed component of go-to-market cost; pairs with commissions for full sales cost.", "interpretationGuidance": "Read with bookings to gauge sales efficiency; keep separate from variable commissions.", "relatedKpiIds": [ "finance.total_sm", "finance.sales_commissions" ], "calculationPolicy": { "inclusionRules": [ "Fully-loaded BASE compensation for account executives, SDRs, and sales leadership (employees), excluding commissions." ], "exclusionRules": [ "Variable commissions — those are finance.sales_commissions, kept separate because they scale with bookings.", "Marketing staff (finance.marketing_payroll) and customer-success staff (finance.cs_payroll)." ], "requiredInputs": [ "Sales roster with fully-loaded base cost.", "A clean split of base vs variable compensation." ], "edgeCases": [ "A guaranteed draw is base-like; earned commission above the draw belongs in finance.sales_commissions.", "Ramp/guarantee comp for new reps sits in base until commissions are earned." ], "validationChecks": [ "Pairs with finance.sales_commissions for full sales cost; rolls into finance.total_sm." ], "commonMiscomputations": [ "Bundling commissions into base payroll — hides the bookings-linked variable component and distorts the fixed-vs-variable view of CAC." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.services_delivery_costs", "slug": "services_delivery_costs", "domain": "finance", "defaultLabel": "Services Delivery Costs", "description": "Direct cost of delivering implementation and professional services — the cost paired with services/implementation revenue. Tracking it against `finance.services_revenue` reveals whether services are run at, above, or below cost.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Direct cost of delivering implementation / professional services for the period.", "whyItMatters": "Pairs with services revenue to show services margin — often a board question.", "interpretationGuidance": "Compare to `finance.services_revenue`: services run below cost dilute blended gross margin and should be flagged.", "relatedKpiIds": [ "finance.total_cogs", "finance.services_revenue" ], "calculationPolicy": { "inclusionRules": [ "Direct cost of delivering implementation and professional services — delivery-team compensation, delivery subcontractors, and project-specific costs.", "The cost paired with finance.services_revenue." ], "exclusionRules": [ "Product engineering (finance.rd_payroll) and recurring support (finance.customer_support_delivery).", "Services sold but not yet delivered." ], "requiredInputs": [ "Delivery-team time and cost by project.", "Subcontractor invoices attributable to delivery." ], "validationChecks": [ "Compare to finance.services_revenue to compute services margin.", "Services run below cost dilute blended gross margin and should be flagged." ], "commonMiscomputations": [ "Omitting subcontractor or delivery cost — overstates services margin.", "Mixing product-engineering cost into services delivery." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.services_revenue", "slug": "services_revenue", "domain": "finance", "defaultLabel": "Services / Implementation Revenue", "description": "Recognized non-recurring revenue from implementation, onboarding, or professional services for the period. Kept separate from recurring revenue because it is lower-margin and does not compound — a services-heavy quarter can grow total revenue while ARR stays flat.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Recognized professional-services / implementation revenue for the period.", "whyItMatters": "Separating services keeps recurring revenue clean and exposes margin dilution from delivery-heavy periods.", "interpretationGuidance": "A rising services share of total revenue often pressures blended gross margin — read against `finance.gross_margin_pct`.", "relatedKpiIds": [ "finance.total_revenue", "finance.services_delivery_costs" ], "calculationPolicy": { "inclusionRules": [ "Recognized non-recurring implementation, onboarding, or professional-services revenue, recognized as delivered (milestone or percentage-of-completion)." ], "exclusionRules": [ "Recurring subscription and usage revenue.", "Services billed but not yet delivered (deferred until the performance obligation is satisfied).", "Services bundled with the subscription that are NOT a distinct performance obligation under ASC 606 — those stay in subscription revenue." ], "requiredInputs": [ "SOW / project recognition schedule and delivery milestones." ], "dataSourcePriority": [ "PSA / project-tracking system.", "Revenue-recognition subledger for the services component." ], "edgeCases": [ "Services bundled with a subscription must be split per the ASC 606 distinct-obligation test.", "Fixed-fee vs time-and-materials engagements recognize differently (percentage-of-completion vs as-delivered)." ], "validationChecks": [ "Pair with finance.services_delivery_costs to read services margin.", "A rising services share of total revenue pressures blended gross margin — read against finance.gross_margin_pct." ], "commonMiscomputations": [ "Recognizing services at billing or signing instead of delivery.", "Leaving non-distinct bundled services in this line instead of subscription." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "recognized_revenue", "production": "primary" } }, { "rogueId": "finance.sm_tools_software", "slug": "sm_tools_software", "domain": "finance", "defaultLabel": "S&M Tools / Software", "description": "Cost of go-to-market tooling for the period — CRM, enrichment, outbound, attribution, and sales-engagement platforms.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sales & marketing tools / software subscriptions for the period.", "whyItMatters": "The tooling overhead of the GTM motion; scales with team size.", "interpretationGuidance": "Watch per-rep tooling cost; tool sprawl is a common, quiet cost creep.", "relatedKpiIds": [ "finance.total_sm" ], "calculationPolicy": { "inclusionRules": [ "Go-to-market tooling — CRM, enrichment, outbound, attribution, and sales-engagement platforms." ], "exclusionRules": [ "Paid media (finance.paid_marketing) and customer-success tooling (finance.cs_tools_software).", "Company-wide IT (finance.software_it)." ], "requiredInputs": [ "The GTM SaaS-subscription list and per-rep tooling cost." ], "validationChecks": [ "Watch tool sprawl and per-rep tooling cost; rolls into finance.total_sm." ], "commonMiscomputations": [ "Classifying media spend as tooling.", "Overlap with CS or IT tools double-counted across sections." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.software_it", "slug": "software_it", "domain": "finance", "defaultLabel": "Software & IT", "description": "Cost of internal software, IT, security, devices, and admin tooling for the period (company-wide SaaS not specific to R&D or GTM).", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Company-wide software / IT / security cost for the period.", "whyItMatters": "A quiet cost-creep area as headcount and tool sprawl grow.", "interpretationGuidance": "Track per-employee software cost; rationalize overlapping subscriptions.", "relatedKpiIds": [ "finance.total_ga" ], "calculationPolicy": { "inclusionRules": [ "Company-wide internal software, IT, security, devices, and admin tooling not specific to R&D, GTM, or CS." ], "exclusionRules": [ "Department-specific tooling (finance.rd_tools_software / finance.sm_tools_software / finance.cs_tools_software).", "Production infrastructure (finance.cloud_hosting)." ], "requiredInputs": [ "The company-wide SaaS/IT subscription list and per-employee software cost." ], "validationChecks": [ "Track per-employee software cost and rationalize overlapping subscriptions; rolls into finance.total_ga." ], "commonMiscomputations": [ "Double-counting department tools here and in their section tooling lines.", "Letting quiet subscription sprawl creep up unmonitored." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.subscription_revenue", "slug": "subscription_revenue", "domain": "finance", "defaultLabel": "Subscription Revenue", "description": "Recognized recurring software revenue for the period — the recurring subscription fees earned under contract, recognized on an accrual basis over the service period. The core revenue line for a SaaS P&L; kept separate from usage and services so the board can read the recurring-vs-non-recurring mix. Distinct from ARR (a forward run-rate) and from cash collected (a financing-timing view).", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Recognized recurring subscription revenue for the period (accrual basis), excluding usage, services, and one-time fees.", "whyItMatters": "Isolates durable recurring revenue — the basis of SaaS quality-of-revenue and gross-margin reads.", "interpretationGuidance": "Read alongside `sales.arr`: recognized subscription revenue trails ARR and the gap reflects timing and mid-period changes. Persistent divergence warrants a note.", "relatedKpiIds": [ "finance.total_revenue", "sales.arr", "sales.total_revenue" ], "calculationPolicy": { "inclusionRules": [ "Recurring subscription fees RECOGNIZED ratably over the service period under ASC 606 / IFRS 15 — the recurring contracted component only." ], "exclusionRules": [ "Usage / consumption / overage revenue (finance.usage_revenue) and implementation / professional services (finance.services_revenue).", "Billed-but-unearned amounts — those sit in deferred revenue until recognized; do not pull them forward.", "Cash collected (a financing-timing view) and ARR (a forward run-rate) — recognized revenue is neither." ], "requiredInputs": [ "Per-contract revenue-recognition schedule and service-period dates.", "The deferred-revenue waterfall." ], "dataSourcePriority": [ "Revenue-recognition subledger / billing-system rev schedules.", "GL revenue accounts reconciled to the subledger." ], "edgeCases": [ "Mid-period upgrades/downgrades are recognized prorata from the change date.", "An annual prepaid contract is recognized monthly over the term, never at the billing date." ], "validationChecks": [ "Recognized subscription revenue trails sales.arr; the gap reflects timing and mid-period changes — persistent divergence warrants a note.", "Reconcile to the deferred-revenue rollforward (opening deferred + billings − recognized = closing deferred)." ], "commonMiscomputations": [ "Recognizing at invoice or cash-collection date instead of over the service period — pulls revenue forward.", "Lumping usage or services into subscription — overstates the recurring quality of revenue." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "recognized_revenue", "production": "primary" } }, { "rogueId": "finance.tax", "slug": "tax", "domain": "finance", "defaultLabel": "Tax", "description": "Corporate income tax, withholding tax, or other tax expense for the period. Often minimal for loss-making startups, but can be non-trivial with multi-jurisdiction operations or specific tax regimes.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Tax expense for the period (subtracted in net income).", "whyItMatters": "Completes the path to net income; can surprise multi-entity companies even while loss-making.", "interpretationGuidance": "Usually small at a loss-making startup; flag if multi-jurisdiction operations make it material.", "relatedKpiIds": [ "finance.net_income" ], "calculationPolicy": { "inclusionRules": [ "Corporate income tax, withholding tax, and other tax expense for the period, subtracted in net income." ], "exclusionRules": [ "Employer payroll taxes — those are loaded into the payroll lines.", "Sales tax / VAT collected on behalf of authorities — a liability, not an expense.", "Deferred-tax non-cash movements unless explicitly presented." ], "requiredInputs": [ "Tax provision by jurisdiction and withholding on cross-border payments." ], "edgeCases": [ "Usually small at a loss-making startup, but multi-jurisdiction operations or minimum taxes can make it non-trivial.", "Distinguish current tax from deferred tax." ], "validationChecks": [ "Completes the path to net income; flag if multi-jurisdiction operations make it material." ], "commonMiscomputations": [ "Classifying employer payroll taxes as income tax.", "Treating collected VAT / sales tax as an expense." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.third_party_data", "slug": "third_party_data", "domain": "finance", "defaultLabel": "Third-Party / API / Data Costs", "description": "Direct cost of external APIs, data providers, enrichment, and model/LLM inference consumed to deliver the product. Broken out from cloud/hosting because for AI products these costs can move gross margin materially and scale with usage rather than headcount.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Direct external API / data / model-inference cost of delivery for the period.", "whyItMatters": "For AI-native products this can be the swing factor in gross margin and deserves its own board line.", "interpretationGuidance": "Watch the ratio to usage revenue and total revenue; per-unit inference cost trends matter more than the absolute.", "relatedKpiIds": [ "finance.total_cogs", "finance.usage_revenue", "finance.gross_margin_pct" ], "calculationPolicy": { "inclusionRules": [ "Direct cost of external APIs, data providers, enrichment, and model/LLM inference consumed to DELIVER the product (per-unit serving cost).", "Broken out from cloud/hosting because for AI products it can swing gross margin materially and scales with usage rather than headcount." ], "exclusionRules": [ "Cloud compute and hosting (finance.cloud_hosting).", "Internal tooling or data used for R&D rather than serving customers (finance.rd_tools_software).", "Model spend for internal experimentation / evaluation that is not production serving." ], "requiredInputs": [ "Vendor bills split between production-serving and internal use.", "Per-unit inference / API cost." ], "dataSourcePriority": [ "Vendor / model-provider billing tagged by production vs internal use." ], "edgeCases": [ "A model API used both for production inference (COGS) and internal evaluation (R&D) must be allocated.", "Cost scales with usage, not headcount — track per-unit inference trend." ], "validationChecks": [ "Watch the ratio to finance.usage_revenue and total revenue; per-unit inference cost trend matters more than the absolute.", "Feeds finance.total_cogs and finance.gross_margin_pct." ], "commonMiscomputations": [ "Burying inference cost inside finance.cloud_hosting — hides the AI gross-margin driver.", "Counting internal-experiment model spend as COGS." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.total_cash_in_bank", "slug": "total_cash_in_bank", "domain": "finance", "defaultLabel": "Total Cash in Bank", "description": "Sum of all bank account balances at the reporting cut-off, expressed in a single reporting currency after FX conversion. This is the gross top-of-house cash number — it does not net out restrictions, near-term liabilities, or commitments. The board reads this as the absolute denominator for runway and as a checksum against the cap table (capital raised − cumulative net burn ≈ cash). Common pitfall: founders sometimes report a USD figure that silently includes ILS/EUR accounts at stale FX rates — always reconcile against the bank-accounts list (per FX-aware MultiCurrencyAccountList) and tag the rate date.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of period-end balances across all bank accounts, converted to the board reporting currency at the cut-off date FX rate. See `finance.bank_accounts_list` for the underlying line items.", "whyItMatters": "The denominator of runway and the single most important survival input — every other cash KPI is read in proportion to this number. Also the basic cap-table sanity check: capital raised minus cumulative net burn should reconcile to total cash within working-capital noise.", "interpretationGuidance": "Read in conjunction with `finance.total_restricted_cash` and `finance.net_burn_rate` to derive operationally available runway. A drop materially larger than net burn for the period signals an unreported outflow (deposit, settlement, FX) that deserves a board note. No published industry threshold exists for \"good\" — interpretation is always company- and stage-specific.", "relatedKpiIds": [ "finance.total_restricted_cash", "finance.total_unrestricted_cash", "finance.operationally_available_cash", "finance.net_burn_rate", "finance.runway_months", "finance.bank_accounts_list" ], "calculationPolicy": { "inclusionRules": [ "Every bank, brokerage, and money-market account balance at the reporting cut-off, summed.", "Both restricted AND unrestricted balances — this is the gross top-of-house number, before any restriction is stripped out (that split lives in finance.total_restricted_cash / finance.total_unrestricted_cash).", "Convert each non-reporting-currency balance to the board reporting currency at the cut-off-date FX rate, and tag the rate date.", "Reconcile the total against the enumerated finance.bank_accounts_list so no account is silently missing." ], "exclusionRules": [ "Undrawn venture debt or credit-facility capacity — that is funding access, not cash on hand.", "Cash receipts in transit that had not cleared into an account by the cut-off date.", "Investments that cannot be readily converted to cash (lock-ups, term deposits past the horizon) unless reconciled in as cash equivalents." ], "requiredInputs": [ "Full enumerated account list (bank / brokerage / money-market) with balance, currency, and as-of date.", "Cut-off-date FX rates for every non-reporting-currency account.", "Per-account restricted flag, so the restricted/unrestricted split can be derived from the same source." ], "dataSourcePriority": [ "Bank statements / treasury portal balances at the cut-off date.", "Accounting GL cash balance as a fallback — only after it is reconciled to the bank statements." ], "edgeCases": [ "Multi-currency cash: convert each currency at a stable cut-off rate, then sum — never mix stale rates.", "A forgotten legacy operational account or money-market sweep silently understates the total — checklist-reconcile against the prior board pack.", "Accounts opened or closed mid-period: use the period-end balance, not an average." ], "validationChecks": [ "Total cash must equal finance.total_restricted_cash + finance.total_unrestricted_cash.", "A period-over-period drop materially larger than net burn signals an unreported outflow (deposit, settlement, FX) — surface it as a board note rather than absorbing it.", "Cap-table checksum: capital raised − cumulative net burn should reconcile to total cash within working-capital noise." ], "commonMiscomputations": [ "Reporting a single-currency figure that silently includes foreign accounts at stale FX rates.", "Omitting an account entirely — the most common cause of a misstated total.", "Treating an undrawn credit facility as cash on hand — inflates the survival picture." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_cogs", "slug": "total_cogs", "domain": "finance", "defaultLabel": "Total COGS", "description": "Total cost of revenue for the period — the sum of the COGS lines. Subtracted from total revenue to produce gross profit. Includes only direct delivery costs; operating expenses (R&D, S&M, CS, G&A) sit below the gross-profit line.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "total_cogs = cloud_hosting + third_party_data + customer_support_delivery + payment_transaction_costs + services_delivery_costs + other_cogs.", "whyItMatters": "The direct-cost base that determines gross profit and gross margin.", "interpretationGuidance": "Track as a percentage of total revenue; the inverse is gross margin. Decompose increases into the COGS lines.", "relatedKpiIds": [ "finance.cloud_hosting", "finance.third_party_data", "finance.customer_support_delivery", "finance.payment_transaction_costs", "finance.services_delivery_costs", "finance.other_cogs", "finance.gross_profit" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.total_cs", "slug": "total_cs", "domain": "finance", "defaultLabel": "Total Customer Success", "description": "Total customer-success operating expense for the period — the sum of the CS lines. Shown as its own OpEx section (some companies fold CS into COGS; the default here is OpEx). One of the four OpEx section totals.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "total_cs = cs_payroll + cs_tools_software + other_cs.", "whyItMatters": "Isolates the retention investment so the board can weigh it against NRR.", "interpretationGuidance": "Track against NRR and revenue; classification as OpEx vs COGS is a reporting choice (statementGroup).", "relatedKpiIds": [ "finance.cs_payroll", "finance.cs_tools_software", "finance.other_cs", "finance.total_opex" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.total_ga", "slug": "total_ga", "domain": "finance", "defaultLabel": "Total G&A", "description": "Total general & administrative operating expense for the period — the sum of the G&A lines. One of the four OpEx section totals.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "total_ga = ga_payroll + legal_accounting_professional + office_facilities + software_it + recruiting + travel_entertainment + insurance_compliance + other_ga.", "whyItMatters": "Overhead the board expects to grow sublinearly with revenue.", "interpretationGuidance": "Track G&A as a percentage of revenue; the ratio should compress as the company scales.", "relatedKpiIds": [ "finance.ga_payroll", "finance.legal_accounting_professional", "finance.office_facilities", "finance.software_it", "finance.recruiting", "finance.travel_entertainment", "finance.insurance_compliance", "finance.other_ga", "finance.total_opex" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.total_operational_inflow", "slug": "total_operational_inflow", "domain": "finance", "defaultLabel": "Total Operational Inflow", "description": "Sum of cash actually received from operating activities for the period — customer collections (subscription, services, transactional revenue), refunds claimed back from vendors, and any operating tax credits. Excludes financing activities (debt draws, equity proceeds) and investing activities (asset sales, investment income). This is the numerator-side of the net-burn equation, and the cash-basis counterpart to recognized revenue on the P&L. Common pitfall: companies sometimes book annual SaaS prepayments here as a single-month inflow, masking the underlying monthly run-rate — split lumpy items out or smooth over a trailing 3 months.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of operating-activity cash receipts for the period. Subtract from total_operational_outflow to get the absolute net-burn dollar value (before dividing by months to get the rate).", "whyItMatters": "Inputs the cash-basis revenue side of net burn. A growing inflow at flat-or-falling outflow is the textbook \"earning its runway\" trajectory; the reverse means the company is more dependent on the cash balance than on revenue.", "interpretationGuidance": "Reconcile against recognized revenue from `sales.arr` and bookings — a persistent gap means deferred-revenue or DSO is moving. Watch lumpy enterprise prepayments and isolate them; they distort the trailing-average net burn read.", "relatedKpiIds": [ "finance.total_operational_outflow", "finance.net_burn_rate", "finance.net_working_capital_adjustment", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Cash actually received from operating activities in the period: customer collections across subscription, usage, services, and transactional revenue.", "Operating refunds received back from vendors and operating tax credits/refunds actually received.", "This is the cash-basis counterpart to recognized revenue and the inflow side of the net-burn equation." ], "exclusionRules": [ "Financing inflows: equity raise proceeds, venture-debt or loan drawdowns. Operational inflow is an operating metric.", "Investing inflows: asset sales, and interest/investment income (interest income belongs in finance.interest_income_expense, not operating inflow).", "Recognized-but-uncollected revenue — this line is cash collected, not accrual revenue." ], "requiredInputs": [ "Operating cash-receipts ledger for the period.", "A flagged list of lumpy one-off receipts (large annual prepayments) so they can be smoothed or isolated." ], "dataSourcePriority": [ "Cash-flow-statement operating-activity receipts.", "Bank deposit reconciliation as a fallback, mapped to operating vs financing/investing." ], "edgeCases": [ "An annual SaaS prepayment from a large customer booked as a single-month inflow masks the monthly run-rate — split it out or smooth over a trailing 3 months.", "Refund timing (received this period for a prior-period charge) can distort the trend." ], "validationChecks": [ "Reconcile against recognized revenue (finance.subscription_revenue, sales.arr) ± deferred-revenue / DSO movement; a persistent gap means collection timing is moving.", "finance.total_operational_outflow − operational inflow yields the absolute net-burn dollar value (before dividing by months)." ], "commonMiscomputations": [ "Counting equity or debt proceeds as operational inflow — turns a fundraising month into \"negative burn\" and lies about run-rate.", "Booking recognized (accrual) revenue here instead of cash actually collected." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_operational_outflow", "slug": "total_operational_outflow", "domain": "finance", "defaultLabel": "Total Operational Outflow", "description": "Sum of cash actually paid for operating activities for the period — payroll and benefits, employer taxes, vendor payments (infra, tooling, contractors), sales and marketing spend, rent, professional services, refunds issued. Excludes financing activities (debt repayment, dividend payments) and investing activities (acquisitions, capex). Direct input to gross burn. Common pitfall: capitalized R&D and long-term capex sometimes get bucketed here; if so they distort gross burn. Keep this strictly operating-cash and surface investing/financing outflows separately so the board can see \"ongoing cost base\" vs. \"discretionary capital deployment\".", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of operating-activity cash payments for the period. Equals gross burn × months_in_period when there are no working-capital re-classifications.", "whyItMatters": "The denominator-side of net burn and the basis of gross burn — controlling the structural cost base is the lever most boards can directly act on between fundraises.", "interpretationGuidance": "Decompose by spend category each board cycle (payroll vs. infra vs. GTM) — a sustained shift toward GTM or infra usually signals a strategic decision worth explicit board endorsement. No single industry threshold for \"good\" — interpretation is always against ARR, revenue per FTE, and gross-margin context.", "relatedKpiIds": [ "finance.total_operational_inflow", "finance.gross_burn_rate", "finance.net_burn_rate", "hr.arr_per_fte" ], "calculationPolicy": { "inclusionRules": [ "Cash actually paid for operating activities in the period: payroll, benefits, and employer taxes; vendor payments (infrastructure, tooling, contractors); sales and marketing spend; rent; professional services; refunds issued; operating taxes paid.", "Keep it strictly operating cash — it is the basis of gross burn." ], "exclusionRules": [ "Financing outflows: debt principal repayment, dividends, buybacks.", "Investing outflows: acquisitions, capex, and the cash cost of capitalized software.", "Non-cash items: depreciation & amortization and stock-based compensation are not cash and never belong in operational outflow." ], "requiredInputs": [ "Operating cash payments broken out by spend category (payroll vs infra vs GTM vs G&A).", "A flag for any capitalized or investing item that may have been bucketed into operating payments." ], "dataSourcePriority": [ "Cash-flow-statement operating-activity payments.", "AP and payroll disbursement records as a fallback, classified to operating only." ], "edgeCases": [ "Capitalized R&D or capex mis-bucketed here distorts gross burn — surface investing outflow separately as \"discretionary capital deployment\".", "US employer-tax true-ups (typically Jan/Apr) spike a single month up to 30–50% above run-rate.", "Annual SaaS renewals paid as a lump in one month inflate that month's outflow." ], "validationChecks": [ "Equals finance.gross_burn_rate × months_in_period when there are no working-capital reclassifications.", "Decompose by category each board cycle; a sustained shift toward GTM or infra usually deserves explicit board endorsement." ], "commonMiscomputations": [ "Including capex or M&A cash in operating outflow — overstates the ongoing cost base and gross burn.", "Including non-cash D&A or SBC — outflow must be cash only." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_opex", "slug": "total_opex", "domain": "finance", "defaultLabel": "Total OpEx", "description": "Total operating expense for the period — R&D + Sales & Marketing + Customer Success + G&A. Subtracted from gross profit to produce EBITDA. Excludes COGS (above the gross-profit line) and below-EBITDA items.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "total_opex = total_rnd + total_sm + total_cs + total_ga.", "whyItMatters": "The full operating cost base below gross profit — the lever between gross profit and EBITDA.", "interpretationGuidance": "Track against gross profit: OpEx growing faster than gross profit pushes EBITDA down.", "relatedKpiIds": [ "finance.total_rnd", "finance.total_sm", "finance.total_cs", "finance.total_ga", "finance.ebitda" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.total_restricted_cash", "slug": "total_restricted_cash", "domain": "finance", "defaultLabel": "Restricted Cash", "description": "Cash on the balance sheet that is not available for general operating use because it is contractually pledged or held for a specific purpose — typical examples include landlord lease-deposit escrows, customer-funds collateral, security deposits backing letters of credit, payment-processor reserves, and debt-covenant minimum-balance requirements. Per IFRS and US GAAP balance-sheet presentation, restricted cash must be disclosed separately from unrestricted cash; the board should treat this number as removed from runway. Common pitfall: payment-processor \"reserve\" balances and large customer-deposit floats are often missed when reporting unrestricted cash, inflating apparent runway.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of bank-account balances flagged `restricted: true` in `finance.bank_accounts_list`, plus any restricted balances held in non-bank vehicles (escrow agents, payment-processor reserve accounts).", "whyItMatters": "Excluded from operationally available cash and from the runway calculation — reporting it inside total cash without flagging the restriction overstates runway and can mask a covenant or liquidity issue.", "interpretationGuidance": "A non-trivial restricted balance (say, >5% of total cash — industry folk-wisdom, not citation-grade) usually warrants a footnote on the source of the restriction and any release schedule. Watch for restricted cash that grows faster than the corresponding operating activity (e.g. payment-processor reserves growing faster than GMV) — that often signals a tightening processor relationship.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_unrestricted_cash", "finance.operationally_available_cash", "finance.bank_accounts_list" ], "calculationPolicy": { "inclusionRules": [ "Bank-account balances flagged restricted in finance.bank_accounts_list.", "Contractually pledged or purpose-held cash: landlord lease-deposit escrows, letter-of-credit collateral, security deposits, payment-processor reserves, customer-funds collateral, and debt-covenant minimum-balance requirements.", "Restricted balances held outside bank accounts (escrow agents, processor reserve accounts)." ], "exclusionRules": [ "Unrestricted operating cash that is freely deployable for payroll or vendors.", "Soft internal earmarks (\"set aside for the raise\") that are not contractually restricted — those are still unrestricted and deployable.", "Undrawn facilities or future obligations not yet funded into a restricted account." ], "requiredInputs": [ "Per-account restricted flag plus the source of each restriction (lease, LC, processor, covenant).", "Any scheduled release dates for the restriction." ], "dataSourcePriority": [ "finance.bank_accounts_list restricted flags reconciled to the underlying contracts.", "Legal / contract documents and processor agreements for collateral and reserve terms." ], "edgeCases": [ "Payment-processor reserves that grow faster than GMV — often signal a tightening processor relationship; flag the trend.", "Customer-prepaid balances held in segregated / restricted accounts are NOT deployable.", "A restriction released mid-period reclassifies to unrestricted — disclose the reclassification." ], "validationChecks": [ "Restricted cash must be ≤ finance.total_cash_in_bank.", "finance.total_unrestricted_cash must equal total cash − restricted cash.", "A restricted balance above ~5% of total cash (folk-wisdom, not citation-grade) warrants a footnote on the source and release schedule." ], "commonMiscomputations": [ "Missing processor reserves or large customer-deposit floats — the classic way restricted cash is understated and runway overstated.", "Classifying a soft internal earmark as restricted — understates deployable cash and runway." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "finance.total_revenue", "slug": "total_revenue", "domain": "finance", "defaultLabel": "Total Revenue", "description": "Total recognized revenue for the period — the sum of subscription, usage, services, and other revenue. The P&L revenue subtotal and the denominator for gross margin. Distinct from `sales.total_revenue` (the GTM recognized-revenue metric) and from ARR; this line is the statement total built from the revenue split.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "total_revenue = subscription_revenue + usage_revenue + services_revenue + other_revenue.", "whyItMatters": "The accounting top line and the basis for gross margin and every margin ratio.", "interpretationGuidance": "Compare period-over-period and against budget; decompose movement into the four revenue lines to explain the change.", "relatedKpiIds": [ "finance.subscription_revenue", "finance.usage_revenue", "finance.services_revenue", "finance.other_revenue", "finance.gross_profit", "sales.total_revenue" ], "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "recognized_revenue", "production": "computed" } }, { "rogueId": "finance.total_rnd", "slug": "total_rnd", "domain": "finance", "defaultLabel": "Total R&D", "description": "Total research & development operating expense for the period — the sum of the R&D lines. One of the four OpEx section totals that roll into Total OpEx.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "total_rnd = rd_payroll + product_design_payroll + contractors_outsourcing + rd_tools_software + other_rnd.", "whyItMatters": "The headline R&D investment line the board tracks against revenue and plan.", "interpretationGuidance": "Track as a percentage of revenue and against budget; decompose movement into the R&D lines.", "relatedKpiIds": [ "finance.rd_payroll", "finance.product_design_payroll", "finance.contractors_outsourcing", "finance.rd_tools_software", "finance.other_rnd", "finance.total_opex" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.total_sm", "slug": "total_sm", "domain": "finance", "defaultLabel": "Total Sales & Marketing", "description": "Total sales & marketing operating expense for the period — the sum of the S&M lines (payroll, commissions, marketing, paid media, events, tools, other). One of the four OpEx section totals.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "total_sm = sales_payroll + sales_commissions + marketing_payroll + paid_marketing + events_conferences + sm_tools_software + other_sm.", "whyItMatters": "The headline go-to-market spend line; the numerator behind blended CAC.", "interpretationGuidance": "Track against new ARR/bookings and budget; decompose into the S&M lines to explain change.", "relatedKpiIds": [ "finance.sales_payroll", "finance.sales_commissions", "finance.marketing_payroll", "finance.paid_marketing", "finance.events_conferences", "finance.sm_tools_software", "finance.other_sm", "finance.total_opex" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "finance.total_unrestricted_cash", "slug": "total_unrestricted_cash", "domain": "finance", "defaultLabel": "Unrestricted Cash", "description": "Cash that the company can freely deploy for any operational purpose — total bank balances minus any contractually restricted balances. This is the input most boards actually want when judging runway, because it strips out escrows, security deposits, and processor reserves that cannot be spent on payroll or vendors. The distinction matters more as the company adds enterprise contracts (deposit obligations), debt facilities (covenant balances), and payment processing volume (rolling reserves). Common pitfall: at early stage, restricted cash is often near zero so teams equate this with `finance.total_cash_in_bank` — track them separately from day one to avoid surprise reclassifications later.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "finance.total_cash_in_bank − finance.total_restricted_cash. Equivalent to the sum of bank-account balances flagged `restricted: false` in `finance.bank_accounts_list`.", "whyItMatters": "The right cash number to divide by net burn when computing the spendable runway a board can act on — restricted cash cannot bridge a payroll gap.", "interpretationGuidance": "A meaningful divergence between unrestricted and total cash (industry folk-wisdom: >5–10%) is the trigger to surface a restricted-cash schedule in the board pack. Compare period-over-period — a sudden drop in unrestricted cash that does not match burn usually means a reclassification (e.g. a new lease deposit) rather than spending.", "relatedKpiIds": [ "finance.total_cash_in_bank", "finance.total_restricted_cash", "finance.operationally_available_cash", "finance.runway_months", "finance.bank_accounts_list" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "finance.travel_entertainment", "slug": "travel_entertainment", "domain": "finance", "defaultLabel": "Travel & Entertainment", "description": "Cost of travel, meals, customer travel, and board travel for the period. Rolls up minor items; kept as one readable line.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Travel & entertainment cost for the period.", "whyItMatters": "A discretionary line that is an early lever when tightening burn.", "interpretationGuidance": "Read directionally; large moves usually reflect travel policy or event timing.", "relatedKpiIds": [ "finance.total_ga" ], "calculationPolicy": { "inclusionRules": [ "Travel, lodging, meals, customer travel, and board travel for the period." ], "exclusionRules": [ "Event-linked travel (finance.events_conferences) and relocation (recruiting / the hire's payroll).", "Client entertainment that is actually a marketing program." ], "requiredInputs": [ "Expense-report travel-and-entertainment categorization." ], "validationChecks": [ "Discretionary — an early lever when tightening burn; read directionally; rolls into finance.total_ga." ], "commonMiscomputations": [ "Double-counting event travel already captured in finance.events_conferences." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "finance.usage_revenue", "slug": "usage_revenue", "domain": "finance", "defaultLabel": "Usage / Consumption Revenue", "description": "Recognized revenue tied to usage- or consumption-based pricing for the period (metered API calls, compute, seats-on-demand, overages). Separated from subscription revenue because it scales with customer activity rather than contracted commitments and is typically more volatile period to period.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Recognized usage/consumption-based revenue for the period.", "whyItMatters": "Surfaces how much revenue depends on variable customer activity vs. fixed commitments — a key durability signal.", "interpretationGuidance": "Higher volatility than subscription revenue is normal; large swings should be explained by customer activity, not pricing changes, unless flagged.", "relatedKpiIds": [ "finance.total_revenue", "finance.subscription_revenue" ], "calculationPolicy": { "inclusionRules": [ "Recognized usage- / consumption-based revenue (metered API calls, compute, on-demand seats, overages) earned as consumed in the period." ], "exclusionRules": [ "Fixed contracted subscription fees (finance.subscription_revenue), including committed-use minimums recognized as subscription.", "Estimated usage not yet earned, and cash collected." ], "requiredInputs": [ "Metered usage records reconciled to billing, recognized on a consumption basis." ], "dataSourcePriority": [ "Metering / billing system.", "GL usage-revenue accounts reconciled to metered volume." ], "edgeCases": [ "Usage drawn against a prepaid commitment is recognized as the commitment is consumed.", "Estimated month-end usage is later trued up — disclose the estimate basis.", "Higher volatility than subscription revenue is normal." ], "validationChecks": [ "Large swings should be explained by customer activity, not pricing changes, unless flagged.", "Watch the ratio to total revenue as a durability signal." ], "commonMiscomputations": [ "Booking a committed minimum as usage (or usage as subscription) — distorts the recurring-vs-variable mix.", "Recognizing billed-but-unconsumed prepaid usage upfront." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "recognized_revenue", "production": "primary" } }, { "rogueId": "finance.working_capital_adjustments_list", "slug": "working_capital_adjustments_list", "domain": "finance", "defaultLabel": "Working Capital Adjustments", "description": "Itemized list of working-capital adjustments with explicit sign-prefix driving the additive-vs-subtractive multiplier — e.g. \"+ AR collected: $250k\", \"− Prepaid infra: $80k\", \"+ Deferred revenue: $600k\". The line-item basis for `finance.net_working_capital_adjustment` and its child KPIs (current_asset_adjustments, current_liability_adjustments). The signed-prefix UI convention prevents the most common working-capital reporting bug — sign-flips that double-count or invert the cash effect. Common pitfall: lumping unrelated items into a single \"other working capital\" line loses the diagnostic value; break out the top 3–5 components.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Each row contributes `± amount` based on its sign prefix. Sum of signed amounts equals `finance.net_working_capital_adjustment`. Asset-side rows roll up to `finance.current_asset_adjustments`; liability-side rows roll up to `finance.current_liability_adjustments`.", "whyItMatters": "Makes the working-capital aggregate auditable — the board can see exactly which items moved the number and which direction. Critical at Series A+ when working capital is material.", "interpretationGuidance": "Track the same line items across periods; a previously material line that vanishes from the list usually indicates a hidden reclassification rather than resolution. New material lines deserve a one-line footnote on what happened.", "relatedKpiIds": [ "finance.net_working_capital_adjustment", "finance.current_asset_adjustments", "finance.current_liability_adjustments", "finance.operationally_available_cash" ] }, { "rogueId": "fundraising.assumptions", "slug": "assumptions", "domain": "fundraising", "defaultLabel": "Fundraising Assumptions", "description": "Explicit assumptions underlying the fundraising plan: valuation expectation, lead-investor probability, time-to-close, post-close runway, and what changes if any assumption breaks. Common pitfall: assumptions are made implicitly and only surface in the postmortem. Boards should require this section to be reviewed each update — a board update where assumptions never change suggests they are not being tested, not that they are correct.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Narrative — enumerated assumptions, each ideally with (1) the assumption, (2) the rationale, (3) what changes if it breaks.", "whyItMatters": "Anchors the fundraising plan to falsifiable beliefs. Lets the board pre-agree on what would constitute a \"this is not working, change the plan\" trigger.", "interpretationGuidance": "Assumptions that diverge from `risk_factors` are a signal of inconsistency. Assumptions that have been broken without triggering plan change are the strongest red flag — pair with a board discussion of when to change course.", "relatedKpiIds": [ "fundraising.strategy", "fundraising.risk_factors", "fundraising.target_raise", "fundraising.planned_close_date" ] }, { "rogueId": "fundraising.committed_amount", "slug": "committed_amount", "domain": "fundraising", "defaultLabel": "Committed Amount", "description": "Capital that investors have agreed to invest — including both soft commitments (verbal / handshake / IOI) and hard commitments (signed term sheet or executed subscription docs). Treat this as the round-progress odometer. Common pitfall: soft commitments are notoriously squishy — every published fundraising postmortem (per First Round Review and Bessemer founder essays) warns that founders over-count soft commits. Board-best-practice is to track soft vs hard separately or to define a haircut convention (e.g. 50% of soft) at the start of the round.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of all investor commitments (soft + hard). Define and document the soft-vs-hard convention per round — some companies report only hard commitments to the board, others report a blended number with footnote.", "whyItMatters": "Primary leading indicator for whether the round will close on target and on time. Pacing against `target_raise` and `planned_close_date` tells the board whether intervention is needed.", "interpretationGuidance": "Healthy rounds typically hit 50% committed at the round midpoint and 80%+ before final closing mechanics begin. A committed amount stuck below 30% past the midpoint usually signals a re-pricing or scope-cut conversation with the board.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.total_received", "fundraising.round_completion_pct", "fundraising.investors_in_pipeline", "fundraising.minimum_close_amount" ], "calculationPolicy": { "inclusionRules": [ "Capital investors have AGREED to invest in the current round — both soft commitments (verbal / handshake / IOI) and hard commitments (signed term sheet or executed subscription docs).", "The round-progress odometer: tracked against `target_raise` and `planned_close_date` for pacing." ], "exclusionRules": [ "Cash not yet agreed — pipeline interest that has not produced a commitment (that is `investors_in_pipeline` engagement, not committed capital).", "Not `total_received` — a commitment is a promise; received is cash wired and cleared.", "Not `target_raise` — the target is the ask, committed is progress toward it." ], "requiredInputs": [ "Per-investor commitment amounts.", "Soft-vs-hard flag per commitment, and the documented haircut convention for the round (e.g. 50% of soft).", "Commitment dates (to age soft commits)." ], "dataSourcePriority": [ "Executed subscription docs / signed term sheets for hard commitments.", "The CEO's investor tracker for soft commitments — apply the agreed haircut and footnote the convention." ], "edgeCases": [ "Soft commitments are squishy: every published fundraising postmortem warns founders over-count them. Track soft vs hard separately or apply a documented haircut.", "A soft commit that goes cold: age it out rather than carrying it indefinitely.", "Over-commitment beyond target (oversubscription): record the full committed figure and let allocation decisions reduce it to round size." ], "validationChecks": [ "committed_amount ≥ total_received (you cannot receive more than was committed).", "committed_amount ≤ total_round_size once the round is allocated.", "Healthy pacing: ~50% committed at the round midpoint, 80%+ before final closing mechanics — below 30% past midpoint signals a re-pricing / scope conversation." ], "commonMiscomputations": [ "Counting soft commitments at face value with no haircut — inflates the round-progress odometer.", "Reporting committed as if it were received and extending the runway forecast on capital that has not been wired.", "Including stale or ghosted investor \"interest\" as a commitment." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.convertible_outstanding", "slug": "convertible_outstanding", "domain": "fundraising", "defaultLabel": "Outstanding Convertible Amount", "description": "Total principal value of SAFEs and convertible notes outstanding that have not yet converted to equity. These convert at the next priced round, typically at a discount or valuation cap (per the standard Y Combinator SAFE templates and the National Venture Capital Association convertible-note model). Common pitfall: a SAFE stack quietly accumulating between rounds can convert into 15–25% dilution at the next priced round, surprising founders who modeled \"we only sold 10% in this priced round\" math. Boards should always see the fully-diluted cap table including SAFE conversion.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "Y Combinator Post-Money SAFE (2018+ standard form)", "sourceUrl": "https://www.ycombinator.com/documents", "sectionRef": "Post-Money SAFE — Definitions (Purchase Amount)", "publicationDate": "2018-09-01", "attributionNotice": null, "authorityLevel": "recognized-standard" }, "formula": "Sum of principal outstanding on all unconverted convertible instruments (SAFEs per the Y Combinator post-money SAFE template; convertible notes per the NVCA Model Documents). Pre-conversion — actual dilution depends on the next-round price and the SAFE caps/discounts.", "whyItMatters": "Hidden dilution that hits at the next priced round. A material SAFE stack changes the math on what a \"20% Series A\" actually costs the founders.", "interpretationGuidance": "When `convertible_outstanding` is more than ~10% of the company's next-likely post-money valuation, the board should require a fully-diluted cap-table walk-through at the next priced round modeling exercise. Highest-cap and lowest-cap SAFE conversion paths should both be modeled.", "relatedKpiIds": [ "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.founder_dilution" ], "calculationPolicy": { "inclusionRules": [ "Total PRINCIPAL value of SAFEs and convertible notes outstanding that have NOT yet converted to equity.", "Instruments that convert at the next priced round, typically at a discount or valuation cap (YC post-money SAFE template; NVCA convertible-note model)." ], "exclusionRules": [ "Instruments that have already converted to equity (they are in the cap table as shares now).", "Priced equity rounds — convertibles are a distinct, pre-equity instrument; do not fold them into `total_round_size`.", "Venture debt — that is a senior debt facility, not a convertible equity instrument.", "Accrued note interest unless the company's convention capitalizes it into principal — state the convention." ], "requiredInputs": [ "Per-instrument outstanding principal.", "Per-instrument cap / discount / MFN terms (to model conversion dilution).", "The next-likely priced-round valuation, to estimate conversion dilution." ], "dataSourcePriority": [ "The cap-table system of record (Carta / Pulley) with the convertible ledger.", "Executed SAFE / note documents as a fallback to verify caps and discounts." ], "edgeCases": [ "A SAFE stack accumulating between rounds can convert into 15–25% dilution at the next priced round — model both highest-cap and lowest-cap conversion paths.", "Post-money SAFEs (YC 2018+) fix dilution at the cap regardless of the priced-round price — reconcile against the fully-diluted cap table.", "Pre-money vs post-money SAFEs convert differently — do not assume one form." ], "validationChecks": [ "When `convertible_outstanding` exceeds ~10% of the next-likely post-money, require a fully-diluted cap-table walk-through at the next priced-round modeling exercise.", "Sum of outstanding principal should reconcile to the cap-table convertible ledger." ], "commonMiscomputations": [ "Treating convertibles as equity already in the cap table — understates next-round dilution.", "Folding convertible principal into the priced equity round size or `total_capital_raised` without a footnote.", "Modeling \"we only sold 10% in this priced round\" while ignoring SAFE conversion on top." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.founder_dilution", "slug": "founder_dilution", "domain": "fundraising", "defaultLabel": "Founder Dilution", "description": "Percentage of founders' fully-diluted ownership that is given up in the new round, including any pre-close option-pool top-up (the \"option pool shuffle\" — option-pool expansion taken in the pre-money dilutes existing holders rather than new investors). Common pitfall: founders often quote the \"investor dilution\" (new money / post-money) and forget the option-pool top-up component. The Carta State of Private Markets quarterly reports publish stage-typical dilution ranges that boards should use as a sanity check.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "published", "sourceName": "Carta State of Private Markets Q3 2025", "sourceUrl": "https://carta.com/data/state-of-private-markets-q3-2025/", "sectionRef": "Seed Round Dilution", "publicationDate": "2025-10-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 12, "median": 18, "p75": 24, "unit": "%", "sourceName": "Carta State of Private Markets Q3 2025", "sourceYear": "2025", "higherIsBetter": false }, "formula": "founder_dilution_pct = (founder_shares_pre − founder_shares_post) / founder_shares_pre × 100. Includes both new-money dilution and any pre-close option-pool top-up borne in the pre-money. Per Carta State of Private Markets methodology.", "whyItMatters": "Tracks founder skin-in-the-game over time — sustained ownership matters for long-term motivation and signaling to future investors. Boards balance dilution discipline against capital needs.", "interpretationGuidance": "Per Carta State of Private Markets benchmarks, typical per-round dilution for the priced round (excluding pool top-up) is 18–22% at seed, 18–22% at A, 12–18% at B, 10–15% at C+. Out-of-band dilution either signals weak negotiating position or a strategic priced-up next-round set-up.", "relatedKpiIds": [ "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.total_round_size" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "fundraising.investors_in_pipeline", "slug": "investors_in_pipeline", "domain": "fundraising", "defaultLabel": "Investors in Pipeline", "description": "Count of distinct investors actively engaged in the current round — defined as taken a first meeting and not yet declined or fully committed. Effectively a fundraising-funnel \"qualified leads\" number. Common pitfall: rosy pipelines that include investors who ghosted weeks ago — best practice (echoed across NfX, First Round Review, and Bessemer founder essays) is to age-out any investor with no contact in 14+ days. Track separately from total intros taken and from hard commitments to make the conversion math legible.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of distinct investors in active engagement (intro / first meeting / partner meeting / diligence). Excludes declined, closed, or stale (>14 days no contact) investors.", "whyItMatters": "Healthy round dynamics rest on competitive tension — a thin pipeline means weaker negotiating position on price and terms. Board reads this to gauge whether the CEO needs help with intros.", "interpretationGuidance": "Rule of thumb across stages: ~40–60 first meetings → ~10–15 partner meetings → ~3–5 term sheets → 1 lead. Active pipeline (post first meeting, pre decline) below 8–10 at the round midpoint typically warrants the board opening their networks.", "relatedKpiIds": [ "fundraising.committed_amount", "fundraising.round_status", "fundraising.strategy" ], "calculationPolicy": { "inclusionRules": [ "Count of DISTINCT investors actively engaged in the current round — have taken a first meeting and have not yet declined or fully committed.", "A fundraising-funnel \"qualified leads\" number: intro / first meeting / partner meeting / diligence stages." ], "exclusionRules": [ "Investors who have declined or closed.", "Stale investors — no contact in 14+ days should be aged out.", "Investors who have already fully committed (they have left the pipeline for `committed_amount`).", "Raw intro count / total meetings taken — this is the ACTIVE funnel, not cumulative activity." ], "requiredInputs": [ "Per-investor engagement stage and last-contact date.", "Decline / commit status to remove investors from the active count." ], "dataSourcePriority": [ "The CEO's / Finance investor CRM or fundraising tracker with stage + last-contact fields.", "A manually maintained pipeline sheet as a fallback — apply the 14-day staleness rule explicitly." ], "edgeCases": [ "Rosy pipelines: investors who ghosted weeks ago inflate the count — age out anyone with 14+ days of no contact.", "A single fund with multiple partners engaged counts as one distinct investor.", "Re-engagement after a decline: only re-add if the investor genuinely re-enters diligence." ], "validationChecks": [ "Funnel sanity (rule of thumb): ~40–60 first meetings → ~10–15 partner meetings → ~3–5 term sheets → 1 lead. Active pipeline below ~8–10 at the round midpoint warrants opening the board's networks.", "Pipeline count should be non-increasing for any single investor as they move toward decline / commit (no double-counting across stages)." ], "commonMiscomputations": [ "Counting total intros taken or total meetings instead of currently-active investors.", "Leaving ghosted / stale investors in the count, overstating competitive tension.", "Counting each partner at a multi-partner fund separately." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "fundraising.key_milestones", "slug": "key_milestones", "domain": "fundraising", "defaultLabel": "Key Milestones", "description": "Container handle for the field-array of named fundraising milestones the board should track to the close — each entry tracks milestone name, type (e.g. term-sheet signing, IC presentation, close), target date, status (upcoming / in-progress / completed / at-risk), responsible party, and notes. The \"what has to happen, by when, and who owns it\" surface that turns the round narrative into a tracked plan. Renders via the CollapsibleFormItemCardGallery widget (the reused gallery pattern shared with sales pipeline deals and HR key hires / openings). Common pitfall: milestones carried forward from prior packs without status updates — these should be refreshed each period so the board sees real progress, not a stale wishlist.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — field-array of milestone items (name, type, status, targetDate, responsibleParty, notes). No aggregate calculation; the surface makes individual milestones and their owners visible at the board level.", "whyItMatters": "Converts the round narrative into a tracked plan with owners and dates — the board can see at a glance which milestones are slipping and who to press. Without named-milestone visibility, the board only learns of a stalled round when the close date slips.", "interpretationGuidance": "Watch for milestones that have been \"in-progress\" across multiple quarterly packs without resolving, and for an at-risk or blocked milestone on the critical path to close (term sheet, lead commitment, IC presentation). Pair with `fundraising.round_status` and `fundraising.planned_close_date` — a clean milestone list alongside a slipping close date usually means the milestones are being optimistically maintained.", "relatedKpiIds": [ "fundraising.round_status", "fundraising.planned_close_date", "fundraising.target_raise", "fundraising.committed_amount", "fundraising.risk_factors" ] }, { "rogueId": "fundraising.minimum_close_amount", "slug": "minimum_close_amount", "domain": "fundraising", "defaultLabel": "Minimum Close Amount", "description": "Floor — the smallest amount of committed capital required to legally close the round (often set in the subscription agreement) or the strategically smallest amount management would accept before re-pricing or pausing. Common pitfall: a `target_raise` of $10M and a `minimum_close_amount` of $4M tells a very different story than a target of $10M and a minimum of $9M — boards should always see both. Per common practice (NVCA Model Documents allow flexibility here), the minimum is typically 50–75% of target at seed, 70–90% at A+.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Currency floor — typically defined in the subscription agreement or by management. Distinct from `target_raise` (the ask) and `committed_amount` (in-progress signal). Per NVCA Model Documents convention.", "whyItMatters": "Defines the round's \"this is enough to ship\" line. Pacing relative to the minimum is the worst-case board view; pacing relative to target is the best-case view — both matter.", "interpretationGuidance": "Per common practice: minimum 50–75% of target at seed, 70–90% of target at A+. A minimum-equals-target round signals high commitment to the headline number; a minimum well below target signals optionality for a \"step-down close.\" Triggered minimums (below floor) require management to revise scope and re-baseline runway.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.round_completion_pct", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "The FLOOR — the smallest committed capital required to legally close the round (often set in the subscription agreement) or the smallest amount management would strategically accept before re-pricing or pausing.", "A single management- / document-set figure for the active round, read as the worst-case raise alongside `target_raise`." ], "exclusionRules": [ "Not `target_raise` (the ask) — the minimum is the floor, the target is the aim.", "Not `committed_amount` — the minimum is a fixed threshold, committed is live progress against it.", "Not the minimum VALUATION (`minimum_valuation`) — this is a capital floor, not a price floor." ], "requiredInputs": [ "The subscription-agreement minimum close, or the management-set strategic floor.", "The active-round `target_raise` for the floor-to-target ratio." ], "dataSourcePriority": [ "The subscription agreement / round legal docs.", "The board-approved fundraising plan as a fallback when no legal minimum is set." ], "edgeCases": [ "A $10M target with a $4M minimum tells a very different story than a $10M target with a $9M minimum — always present both.", "Triggered minimum (commitments fall toward the floor): a board-decision event — management must revise scope and re-baseline runway.", "Step-down close: a minimum well below target signals optionality to close small and keep raising." ], "validationChecks": [ "minimum_close_amount ≤ target_raise.", "Per common practice (NVCA allows flexibility): minimum is typically 50–75% of target at seed, 70–90% at A+ — far outside that band warrants a footnote." ], "commonMiscomputations": [ "Confusing the capital floor with the valuation floor (`minimum_valuation`).", "Reporting only the target and omitting the floor — hides the worst-case board view." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.minimum_valuation", "slug": "minimum_valuation", "domain": "fundraising", "defaultLabel": "Minimum Valuation", "description": "The lowest pre-money valuation management would accept to close the current round — the valuation walk-away floor. Distinct from the precise NVCA-defined `pre_money_valuation` (the single negotiated point that actually prices the round): this is the bottom of the acceptable band the team set going in. Common pitfall: teams anchor only on a target valuation and have no pre-agreed floor, so in a soft market they negotiate against themselves with no board-sanctioned line. Pair with `fundraising.target_valuation` to give the board the band, and read both against stage-relative ranges from quarterly Carta / PitchBook reports.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Currency floor — set by management as the valuation walk-away line for the round. Distinct from `pre_money_valuation` (the single negotiated price) and `target_valuation` (the valuation being run to). Typically expressed as pre-money to match `pre_money_valuation`.", "whyItMatters": "Gives the board the worst-case price of the round before negotiations start — the line below which the team should pause, re-scope, or consider a bridge rather than accept a down-round-anchoring price. Without a pre-agreed floor, valuation discipline erodes in a soft market.", "interpretationGuidance": "Read as the bottom of the valuation band alongside `target_valuation`. A minimum well below stage-median pre-money (per quarterly Carta / PitchBook reports) signals the team is bracing for a hard market; a minimum equal to target signals high conviction (or inflexibility). A breached floor (a term sheet below the minimum) is a board-decision event, not a management one.", "relatedKpiIds": [ "fundraising.target_valuation", "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.minimum_close_amount" ], "calculationPolicy": { "inclusionRules": [ "The lowest pre-money valuation management would accept to close the current round — the valuation walk-away FLOOR.", "The bottom anchor of the valuation band the team set going in; typically expressed as pre-money to match `pre_money_valuation`." ], "exclusionRules": [ "Not `pre_money_valuation` (the single realized negotiated price) — this is the pre-agreed floor, not the outcome.", "Not `target_valuation` (the top of the band / the aim).", "Not `minimum_close_amount` — that is a capital floor, this is a price floor." ], "requiredInputs": [ "The management- / board-agreed valuation floor for the round.", "The `target_valuation` to express the full band." ], "dataSourcePriority": [ "The board-approved round plan (where the floor should be set before negotiations).", "Management's pricing model as a fallback — flag if no board-sanctioned floor exists." ], "edgeCases": [ "No pre-agreed floor: teams that anchor only on a target negotiate against themselves in a soft market — the absence of a floor is itself a finding.", "A term sheet below the minimum is a board-decision event, not a management one.", "Minimum equal to target signals high conviction (or inflexibility); a wide band signals the team is bracing for a soft market." ], "validationChecks": [ "minimum_valuation ≤ target_valuation.", "Read against stage-median pre-money (Carta / PitchBook) — a floor well below stage median signals defensive positioning." ], "commonMiscomputations": [ "Confusing the valuation floor with the capital floor (`minimum_close_amount`).", "Reporting the floor as the realized `pre_money_valuation`." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "fundraising.planned_close_date", "slug": "planned_close_date", "domain": "fundraising", "defaultLabel": "Planned Close Date", "description": "Calendar date by which the round is expected to close (final wires received, definitive documents signed). Compared against `finance.runway_months` to detect a fundraising-against-the-clock situation. Common pitfall: planned close dates routinely slip 30–90 days in practice (collected founder postmortems on First Round Review) — boards should ask for both an \"expected\" and a \"no-deal\" date and watch the gap to actual runway exhaustion.", "fieldType": "date", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Calendar date. Not derived — set by management. Compare to today + `finance.runway_months` to surface runway-versus-close risk.", "whyItMatters": "Single most-important fundraising deadline — drives urgency, board cadence, and bridge-financing decisions. Slippage here is the leading indicator that the round is in trouble.", "interpretationGuidance": "When the planned close date is within 2 months of runway exhaustion (i.e. `runway_months` ≤ months_to_planned_close + 2), the board should be in active conversation about bridge financing or scope cuts. A slipping date should be paired with explicit re-baseline of runway.", "relatedKpiIds": [ "fundraising.round_status", "fundraising.committed_amount", "fundraising.target_raise", "finance.runway_months" ] }, { "rogueId": "fundraising.post_money_valuation", "slug": "post_money_valuation", "domain": "fundraising", "defaultLabel": "Post-Money Valuation", "description": "Company valuation immediately after the new round closes, including the new capital raised — the canonical \"valuation\" number quoted in TechCrunch headlines. Per NVCA Model Documents, post-money = pre-money + new money raised. Common pitfall: post-money math gets messy with SAFEs — modern post-money SAFEs (the YC 2018+ form, per the Y Combinator SAFE primer) fix dilution at the SAFE's valuation cap regardless of subsequent priced-round pricing, so the board should always reconcile the headline post-money against the fully-diluted cap table.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "NVCA Model Legal Documents (2024 revision)", "sourceUrl": "https://nvca.org/model-legal-documents/", "sectionRef": "Series A Charter — Post-Money Valuation convention", "publicationDate": "2024-01-01", "attributionNotice": null, "authorityLevel": "recognized-standard" }, "formula": "post_money_valuation = pre_money_valuation + total_round_size. Per NVCA Model Documents. With outstanding post-money SAFEs, reconcile against the fully-diluted cap table — SAFE dilution is fixed at the cap regardless of priced-round price.", "whyItMatters": "The headline number the company carries forward — sets the goalposts for the next round (a down-round means raising at a lower post-money) and the strike-price floor for new option grants.", "interpretationGuidance": "Watch the post-money-to-ARR multiple (or post-money-to-net-burn if pre-revenue): public sources covering 2024–2025 (e.g. SaaS Capital \"Private SaaS Company Valuations\" report, valuation-multiples section; Sapphire / KBCM SaaS Survey, \"valuations\" chapter) show median ARR multiples have compressed materially from 2021 peaks. Pull the current edition for the live range — do not rely on a memorized number — and flag out-of-band multiples as next-round price risk. Where you only have rough heuristics, mark them as \"directional, not citation-grade\" rather than fabricating a precise band.", "relatedKpiIds": [ "fundraising.pre_money_valuation", "fundraising.total_round_size", "fundraising.founder_dilution", "sales.arr", "finance.net_burn_rate" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "fundraising.pre_money_valuation", "slug": "pre_money_valuation", "domain": "fundraising", "defaultLabel": "Pre-Money Valuation", "description": "Company valuation negotiated with investors immediately before the new round closes — the denominator for the new investors' ownership math. Per the NVCA Model Documents, pre-money = post-money − new money raised. Common pitfall: when convertible instruments (SAFEs, notes) are outstanding, the \"headline\" pre-money the CEO quotes and the effective pre-money after conversion can differ materially — the board should always ask for both. Equally important: option-pool top-ups taken pre-close come out of the pre-money share count, diluting founders not investors (the \"option pool shuffle\").", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "published", "sourceName": "NVCA Model Legal Documents (2024 revision)", "sourceUrl": "https://nvca.org/model-legal-documents/", "sectionRef": "Series A Charter — Original Issue Price", "publicationDate": "2024-01-01", "attributionNotice": null, "authorityLevel": "recognized-standard" }, "formula": "pre_money_valuation = post_money_valuation − total_round_size. Per NVCA Model Documents convention. Effective pre-money after SAFE/note conversion can be lower than headline — surface both when convertibles are material.", "whyItMatters": "Sets the price for the round. Drives `founder_dilution`, the option-pool top-up math, and the precedent for the next round (down-rounds are punishing to recover from).", "interpretationGuidance": "Compare to stage-relative ranges from quarterly Carta / PitchBook reports (e.g. seed median has moved $12–18M post-money in 2024–2025). A pre-money below stage median typically signals either harsher terms or a strategic discount; above stage median demands real metric backing.", "relatedKpiIds": [ "fundraising.post_money_valuation", "fundraising.total_round_size", "fundraising.founder_dilution", "fundraising.convertible_outstanding" ], "calculationPolicy": { "inclusionRules": [ "Company valuation negotiated with investors immediately BEFORE the new round closes — the denominator for new investors' ownership math.", "Per NVCA Model Documents: pre_money = post_money − new money raised." ], "exclusionRules": [ "The new round capital itself — adding it gives post-money, not pre-money.", "Not `target_valuation` or `minimum_valuation` (the band the team set going in) — pre-money is the single realized negotiated price.", "Headline pre-money is not effective pre-money when convertibles are outstanding — surface both, but do not conflate them." ], "requiredInputs": [ "The negotiated post-money and round size (pre = post − round), OR the directly negotiated pre-money.", "Fully-diluted pre-round share count, including any pre-close option-pool top-up.", "Outstanding convertible (SAFE / note) terms, to compute effective pre-money after conversion." ], "dataSourcePriority": [ "Executed term sheet (the negotiated price).", "The fully-diluted cap-table model for effective pre-money after SAFE / note conversion." ], "edgeCases": [ "Convertibles outstanding: headline pre-money the CEO quotes and effective pre-money after SAFE / note conversion can differ materially — the board should always ask for both.", "Option-pool shuffle: a pre-close pool top-up comes out of the pre-money share count, diluting founders not investors — include it in the dilution read." ], "validationChecks": [ "pre_money_valuation + total_round_size = post_money_valuation (NVCA identity).", "Compare to stage-relative Carta / PitchBook ranges — a pre-money below stage median signals harsher terms or a strategic discount; above demands real metric backing." ], "commonMiscomputations": [ "Quoting post-money as pre-money (off by the full round size).", "Ignoring outstanding SAFEs / notes so the headline pre-money overstates the effective per-share price.", "Treating the target / minimum valuation band as the realized pre-money before a term sheet exists." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "fundraising.risk_factors", "slug": "risk_factors", "domain": "fundraising", "defaultLabel": "Fundraising Risk Factors", "description": "Named risks that could prevent the round from closing as targeted — market conditions (general venture sentiment, sector-specific freeze), investor-side risk (anchor investor wobble, partner-meeting drop-off), company-side risk (a metric trending wrong direction, customer concentration concern surfaced in diligence), and timing risk (runway versus close date). Common pitfall: optimistic CEOs under-report risk factors. Boards should expect at least 2–3 named risks even in a healthy round — \"no risks\" is itself a risk signal.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Narrative — list of named risks, each ideally with a likelihood / mitigation pair.", "whyItMatters": "Surfaces what could go wrong before it does — boards earn their seat by spotting risks the CEO is too close to see. Also a contract between CEO and board on what to watch.", "interpretationGuidance": "Watch for risks that persist across multiple updates with no mitigation movement — usually a sign the CEO needs board help. A new risk appearing late in the round (post-term-sheet) deserves immediate board attention.", "relatedKpiIds": [ "fundraising.round_status", "fundraising.strategy", "fundraising.assumptions" ] }, { "rogueId": "fundraising.round_completion_pct", "slug": "round_completion_pct", "domain": "fundraising", "defaultLabel": "Round Completion %", "description": "Progress of the round expressed as committed capital divided by target. Read alongside `round_status` and elapsed-time-in-round to detect stalls. Common pitfall: percentage progress is misleading when measured against a shifting `target_raise` — when management lowers the target mid-round, the percentage jumps without any new commitments arriving. The board should always be told when this is a target revision vs. a real progress event.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "round_completion_pct = (committed_amount / target_raise) × 100. When using soft+hard committed, footnote the convention.", "whyItMatters": "Single-number pacing signal — board members glance at it first when scanning a fundraising update. Pairs naturally with elapsed-time-in-round to surface stalls.", "interpretationGuidance": "Rough pacing checkpoints from collected practitioner essays (NfX, Bessemer founder content): 30% by 4–6 weeks in, 60% by week 8–10, 90%+ by week 12. Sustained pacing below these typically signals a need to widen the investor net or revise the target.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.round_status", "fundraising.planned_close_date" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "fundraising.round_status", "slug": "round_status", "domain": "fundraising", "defaultLabel": "Round Status", "description": "Current phase of the active fundraising round on a coarse state machine (e.g. not-started, in-progress, term-sheet, closing, closed). The board reads this to know which playbook applies — pipeline-building, diligence, closing, or post-close communications. Common pitfall: the field drifts when a round stalls or pivots, so treat each phase change as a board-update trigger. The PhasePlaybook widget binds to this enum and surfaces the appropriate phase guidance read-only beside the editor.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Categorical state derived from operational status — no calculation. Typical states: not-started, in-progress, term-sheet, closing, closed, paused.", "whyItMatters": "Anchors every other fundraising number in board context — the same target_raise is read differently mid-pipeline than at closing. Drives which phase playbook the board should be advising on.", "interpretationGuidance": "Treat a phase regression (e.g. term-sheet → in-progress) as a yellow flag and pair it with `risk_factors`. Time spent in any single phase beyond stage-typical norms (6–9 months at seed, 4–6 months at A/B) signals a stalled round.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.planned_close_date", "fundraising.risk_factors" ] }, { "rogueId": "fundraising.strategy", "slug": "strategy", "domain": "fundraising", "defaultLabel": "Fundraising Strategy", "description": "Free-text narrative covering the planned fundraising approach for the current round: target investor types (lead profile, co-investors), timing, sequencing of the conversation, use of proceeds, milestones the round will get the company to, and the alternative scenarios if the primary plan slips. This is the \"what is the CEO actually doing\" section of the fundraising update. Common pitfall: strategy that does not name a target lead investor profile or use-of-proceeds milestone is not strategy — it is intent. Boards should push for specificity here.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Narrative — no calculation. Should cover (1) target investor profile, (2) sequencing / timing plan, (3) use of proceeds, (4) milestones funded, (5) downside scenarios.", "whyItMatters": "Forces the CEO to articulate \"what game we are playing\" — boards offer better help when they understand the strategy, not just the numbers.", "interpretationGuidance": "A strategy that has not changed across consecutive board updates while the round has stalled is a red flag — typically requires a reframing conversation. A strategy that pivots every update is also a red flag — typically requires the board to push for commitment.", "relatedKpiIds": [ "fundraising.round_status", "fundraising.target_raise", "fundraising.investors_in_pipeline", "fundraising.risk_factors", "fundraising.assumptions" ] }, { "rogueId": "fundraising.target_raise", "slug": "target_raise", "domain": "fundraising", "defaultLabel": "Target Raise", "description": "Target gross capital the company intends to raise in the currently active round (the \"ask\"). This is the headline number the CEO walks investors through and the board uses to sanity-check dilution and runway implications. Note the distinction from `total_round_size` (which can include third-party participation beyond the company-led ask) and from `minimum_close_amount` (the floor at which the round can close). Common pitfall: the target is updated mid-process when investor demand or strategy shifts — every change deserves a board note.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Plain currency target — no derivation. Distinct from `total_round_size` (which may include strategic / employee allocations beyond the lead ask) and `minimum_close_amount` (the floor for the round to close).", "whyItMatters": "Defines the contract between management and the board for this round — every downstream KPI (round_completion_pct, founder_dilution, runway extension) is calibrated against it.", "interpretationGuidance": "Compare against stage norms (per Carta / PitchBook quarterly reports): pre-seed $0.5–3M, seed $2–5M, Series A $8–20M, Series B $20–60M. A target significantly above stage norm warrants extra board scrutiny on burn assumptions and investor fit.", "relatedKpiIds": [ "fundraising.committed_amount", "fundraising.total_round_size", "fundraising.minimum_close_amount", "fundraising.round_completion_pct", "fundraising.founder_dilution" ], "calculationPolicy": { "inclusionRules": [ "The headline gross capital the company intends to raise in the currently active round — the \"ask\" the CEO walks investors through.", "A single management-set target figure for one round; gross (pre-fees), in the round's reporting currency." ], "exclusionRules": [ "Not `total_round_size` (the final all-participant round figure used in post-money math) — the target is intent and can move mid-process.", "Not `minimum_close_amount` (the floor at which the round can legally / strategically close) — the target is the aim, not the worst case.", "Not `committed_amount` or `total_received` — those are progress against the target, not the target itself.", "Prior rounds' targets — this is the active round only." ], "requiredInputs": [ "The board-agreed target for the active round.", "Round currency.", "Date the target was last revised (every change deserves a board note)." ], "dataSourcePriority": [ "The board-approved fundraising plan / round kickoff memo.", "The CEO's current investor deck \"ask\" slide as a fallback — reconcile against the board-approved figure." ], "edgeCases": [ "Mid-round target revisions: when demand or strategy shifts, the target moves — flag the change explicitly so `round_completion_pct` is not misread as new progress.", "Target expressed as a range by management: record the point the board is tracking to (typically the midpoint) and footnote the range." ], "validationChecks": [ "target_raise ≥ minimum_close_amount — the ask cannot be below the floor.", "Compare to stage norms (pre-seed $0.5–3M, seed $2–5M, Series A $8–20M per Carta / PitchBook): a target far above stage norm warrants extra burn-assumption scrutiny." ], "commonMiscomputations": [ "Reporting `total_round_size` as the target — the round size is final and feeds valuation math; the target is the moving aim.", "Quoting `committed_amount` as the target once commitments arrive — conflates progress with the goal.", "Silently changing the target and letting completion-% jump without a board note." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.target_valuation", "slug": "target_valuation", "domain": "fundraising", "defaultLabel": "Target Valuation", "description": "The pre-money valuation the current round is being run to land — the valuation \"ask\" that anchors the pitch and the dilution math management is targeting. Distinct from `pre_money_valuation` (the precise NVCA-defined price the round actually closes at, known only once a term sheet is signed): this is the aim, set going in. The board reads the target alongside `fundraising.minimum_valuation` as a valuation BAND — the two together tell a very different story than a single point. Common pitfall: a target valuation set on 2021-vintage multiples in a compressed market; always sanity-check against current stage-relative ranges from quarterly Carta / PitchBook / SaaS Capital reports.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Currency target — the pre-money valuation management is running the round to land. Set going in; distinct from `pre_money_valuation` (the realized price at signing) and `minimum_valuation` (the floor). Typically expressed as pre-money to match `pre_money_valuation`.", "whyItMatters": "Defines the best-case price of the round and the dilution math management is targeting — every downstream economic KPI (`founder_dilution`, option-pool top-up) is calibrated against where the round actually lands relative to this aim.", "interpretationGuidance": "Read as the top of the valuation band alongside `minimum_valuation`. Compare to stage-relative ranges from quarterly Carta / PitchBook / SaaS Capital reports — a target above stage-median pre-money demands real metric backing and raises next-round down-round risk if it cannot be defended. The gap between target and minimum is the team's implicit read on market softness: a wide band signals uncertainty, a tight band signals conviction.", "relatedKpiIds": [ "fundraising.minimum_valuation", "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.total_round_size", "fundraising.founder_dilution" ], "calculationPolicy": { "inclusionRules": [ "The pre-money valuation the current round is being run to land — the valuation \"ask\" that anchors the pitch and the dilution math management is targeting.", "The top anchor of the valuation band, read alongside `minimum_valuation`; typically expressed as pre-money." ], "exclusionRules": [ "Not `pre_money_valuation` (the realized price known only at term-sheet signing) — the target is the aim set going in.", "Not `minimum_valuation` (the floor).", "Not a post-money figure — keep it pre-money to match the band's other anchors." ], "requiredInputs": [ "The management-set valuation the round is being run to.", "The `minimum_valuation` to express the band.", "Current stage-relative valuation comps to sanity-check the target." ], "dataSourcePriority": [ "The board-approved round plan / pricing strategy.", "The investor deck ask as a fallback — reconcile to the board-approved target." ], "edgeCases": [ "A target set on 2021-vintage multiples in a compressed market is a red flag — sanity-check against current Carta / PitchBook / SaaS Capital stage ranges.", "The gap between target and minimum is the team's implicit read on market softness: wide = uncertainty, tight = conviction." ], "validationChecks": [ "target_valuation ≥ minimum_valuation.", "A target above stage-median pre-money demands real metric backing and raises next-round down-round risk if it cannot be defended." ], "commonMiscomputations": [ "Reporting the target as the realized `pre_money_valuation` before a term sheet exists.", "Setting the target on stale (2021-peak) multiples without re-checking the current market." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "fundraising.total_capital_raised", "slug": "total_capital_raised", "domain": "fundraising", "defaultLabel": "Total Capital Raised to Date", "description": "Cumulative gross equity capital raised across all prior rounds (and the current round in-progress). Treated as historical context — investors and board members look at this to gauge capital efficiency (capital raised vs. ARR achieved). Common pitfall: includes all equity but typically excludes convertible debt that has not converted, venture debt principal, and grants — be explicit about what is and is not included when the number is presented. Capital efficiency benchmarks (per KBCM, SaaS Capital, and Bessemer State-of-the-Cloud) compare `total_capital_raised` to current ARR — e.g. \"$30M raised, $10M ARR\" is efficient at A but lean at B+.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of gross equity capital raised across all rounds. Be explicit about inclusion of convertibles and exclusion of venture debt / grants — surface in a footnote.", "whyItMatters": "Tracks capital efficiency over time and frames the company's next-round narrative (\"we raised $X to get to $Y ARR\"). Investors and board members use this for stage-vs-traction sanity-checking.", "interpretationGuidance": "Compare to current ARR for capital efficiency. The right ratio is ARR ÷ capital raised — most early-stage SaaS companies generate noticeably less ARR than they have raised (ratio typically well under 1.0x at Series A, with the gap intentional during growth-spend ramps). The KBCM (now Sapphire / KBCM) Private SaaS Company Survey publishes a \"capital efficiency\" cut for the current vintage; the Bessemer State of the Cloud report covers the same axis qualitatively. Pull the current edition for the live benchmark rather than relying on a memorized number, and tag any heuristic range as \"directional, not citation-grade\" if you cannot cite a specific section.", "relatedKpiIds": [ "fundraising.total_round_size", "fundraising.total_received", "sales.arr", "finance.net_burn_rate" ], "calculationPolicy": { "inclusionRules": [ "CUMULATIVE gross equity capital raised across ALL prior rounds plus the current round in-progress — the all-time historical figure.", "Used to frame capital efficiency (capital raised vs. ARR achieved) and the next-round narrative." ], "exclusionRules": [ "Round-specific amounts (`total_round_size`, `total_received`) — this is cumulative all-time, not the active round.", "Convertible debt that has not converted — typically excluded; be explicit when included.", "Venture debt principal — debt is not equity raised.", "Grants / non-dilutive funding — exclude (or footnote separately)." ], "requiredInputs": [ "Gross equity raised per historical round.", "The current round's equity to date.", "A stated convention for convertibles (included or not) and confirmation debt / grants are excluded.", "Current ARR, for the capital-efficiency ratio." ], "dataSourcePriority": [ "The cap-table system of record (Carta / Pulley) round history.", "Closing documents per round as a fallback to verify gross amounts." ], "edgeCases": [ "Be explicit about what is and is not included (convertibles, debt, grants) — surface the inclusion convention in a footnote each time the number is presented.", "A current round still in-progress: state whether the figure is committed-to-date or received-to-date for the active round.", "Cross-currency historical rounds: normalize to one reporting currency at documented rates." ], "validationChecks": [ "total_capital_raised ≥ any single round's `total_round_size`.", "Capital efficiency = current ARR ÷ total_capital_raised — most early-stage SaaS sits well under 1.0x at Series A; compare to the current KBCM / Sapphire vintage rather than a memorized number." ], "commonMiscomputations": [ "Reporting the latest round size as cumulative capital raised (or vice versa).", "Folding venture debt or grants into the equity total without a footnote.", "Inconsistently including unconverted convertibles across periods so the time series is not comparable." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.total_received", "slug": "total_received", "domain": "fundraising", "defaultLabel": "Total Received", "description": "Cash that has actually been wired and cleared the company's bank account from investors in the current round. This is the cash-in-the-bank version of `committed_amount`. Common pitfall: commitments do not pay the bills — wiring can lag commitments by weeks to months for the second / third closes, and a committed-but-not-received delta of $5M+ can quietly extend the runway forecast incorrectly. Reconcile this against `finance.total_cash_in_bank` increases each period.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of investor wires received and cleared in the current round. Always less-than-or-equal-to `committed_amount`; difference equals \"to-be-wired\" balance.", "whyItMatters": "The only line of capital the company can actually deploy — runway forecasts based on `committed_amount` rather than `total_received` are aspirational, not operational.", "interpretationGuidance": "A widening gap between `committed_amount` and `total_received` past the first close warrants a follow-up — wiring delays beyond 30 days from signature increasingly correlate (per founder postmortems published on First Round Review) with investor regret or strategic shifts.", "relatedKpiIds": [ "fundraising.committed_amount", "fundraising.target_raise", "finance.total_cash_in_bank", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "Cash that has actually been WIRED and CLEARED the company's bank account from investors in the current round.", "The deployable, operational version of the round — the only capital runway forecasts may legitimately rely on." ], "exclusionRules": [ "Committed-but-not-wired capital — `committed_amount` minus `total_received` is the \"to-be-wired\" balance, not received.", "Soft commitments and pipeline interest.", "Prior-round capital already in the bank (reflected in cash balances / `total_capital_raised`, not this round's received)." ], "requiredInputs": [ "Per-investor wires received and cleared in the current round.", "Wire dates (to measure commitment-to-cash lag).", "The current `committed_amount` to compute the outstanding balance." ], "dataSourcePriority": [ "Bank statements / treasury ledger (cleared wires).", "Closing agent / counsel confirmations as a fallback before the bank feed updates." ], "edgeCases": [ "Multiple closes: wiring for the second / third close can lag commitments by weeks to months — report received as of the period, not as of commitment.", "A committed-but-not-received delta of several $M can quietly overstate runway — reconcile received against `finance.total_cash_in_bank` increases each period.", "FX on a cross-border wire: record the cleared reporting-currency amount, not the quoted commitment amount." ], "validationChecks": [ "total_received ≤ committed_amount always.", "Period-over-period increase in `finance.total_cash_in_bank` from financing ≈ total_received for the period (net of fees)." ], "commonMiscomputations": [ "Treating `committed_amount` as received and building operational runway on aspirational capital.", "Counting a signed subscription doc as received before the wire clears." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.total_round_size", "slug": "total_round_size", "domain": "fundraising", "defaultLabel": "Total Round Size", "description": "Total new capital being raised in the current round across all participants — the lead, follow-on investors, employee/strategic allocations, and any side-letter pieces. This is the figure that goes into the post-money math. Common pitfall: companies sometimes confuse `total_round_size` with `target_raise` — the round size is final and used in valuation math, while the target is what management is aiming for and can move during the raise. Boards should expect a specific breakdown by investor when this number is reported.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "published", "sourceName": "NVCA Model Legal Documents (2024 revision)", "sourceUrl": "https://nvca.org/model-legal-documents/", "sectionRef": "Series A Stock Purchase Agreement — Aggregate Investment", "publicationDate": "2024-01-01", "attributionNotice": null, "authorityLevel": "recognized-standard" }, "formula": "Sum of all new-money allocations in the round (lead + follow-on + strategic + employee + side letters). Distinct from `target_raise` (intent) and `committed_amount` (in-progress signal).", "whyItMatters": "Determines the round's post-money valuation and dilution math. Also signals investor concentration risk — a round with 80% from one investor differs structurally from a round with 5 equal participants.", "interpretationGuidance": "Round size noticeably below target typically signals investor demand weakness (consider repricing or scope cut). Round size meaningfully above target signals oversubscription — a healthy signal but raises governance questions on how allocations are decided.", "relatedKpiIds": [ "fundraising.target_raise", "fundraising.committed_amount", "fundraising.pre_money_valuation", "fundraising.post_money_valuation", "fundraising.founder_dilution" ], "calculationPolicy": { "inclusionRules": [ "Total NEW capital raised in the current round across all participants — lead, follow-on investors, employee / strategic allocations, and side-letter pieces.", "The final figure that feeds the post-money valuation and dilution math." ], "exclusionRules": [ "Not `target_raise` (management intent, can move) — the round size is final and used in valuation math.", "Convertible instruments (SAFEs / notes) converting at this round, when tracked separately — be explicit whether the round size is \"new priced money only\" or \"new money plus converting instruments\".", "Venture debt — debt is funding capacity, not part of the equity round size.", "Prior rounds' capital (that is `total_capital_raised`)." ], "requiredInputs": [ "Per-investor new-money allocations for the round (lead + follow-on + strategic + employee + side letters).", "Whether converting SAFEs / notes are folded into the figure (convention).", "Pre-money valuation, to reconcile post-money = pre-money + round size." ], "dataSourcePriority": [ "Executed term sheet / closing allocation schedule.", "The closing cap-table model as a fallback while allocations are still firming." ], "edgeCases": [ "Multiple closes: a first close fixes part of the round size; report cumulative-to-date and footnote that the round is still open.", "Oversubscription: round size can land above target — a healthy signal, but flag the allocation-governance question.", "Concentration: a round that is 80% one investor reads structurally different from 5 equal participants — surface the breakdown." ], "validationChecks": [ "post_money_valuation − pre_money_valuation ≈ total_round_size (NVCA identity) — if it does not reconcile, one of the three is wrong.", "total_round_size ≥ committed_amount ≥ total_received at any point in an open round." ], "commonMiscomputations": [ "Using `target_raise` in the post-money math instead of the final round size.", "Folding venture debt or unconverted SAFEs into the equity round size without a footnote — overstates the priced raise and the dilution denominator." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.venture_debt_available", "slug": "venture_debt_available", "domain": "fundraising", "defaultLabel": "Venture Debt Available", "description": "Undrawn capacity remaining on existing venture debt facilities. Optionality the company can call on quickly without re-pricing. Common pitfall: availability is conditional — most facilities require continued covenant compliance, and an available line can be pulled or frozen by the lender if cash, ARR, or other covenants slip (per the Bessemer venture-debt content and Battery Ventures primer). The board should treat `venture_debt_available` as a soft commitment, not a hard one, until drawn.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "venture_debt_available = total_facility_committed − venture_debt_drawn − amounts no longer drawable (covenant restrictions, time-window expirations).", "whyItMatters": "Strategic optionality — drawable capacity is a buffer for unexpected burn or a bridge to the next round. But it is contingent on staying inside covenants, so the board needs both this number and `venture_debt_covenant_status`.", "interpretationGuidance": "Available capacity of 3–6 months of net burn provides meaningful optionality. Less than ~1 month of burn in availability rarely justifies the facility complexity. Watch for facilities with expiring draw windows — undrawn capacity that vanishes on a calendar date.", "relatedKpiIds": [ "fundraising.venture_debt_drawn", "fundraising.venture_debt_covenant_status", "finance.net_burn_rate", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "Undrawn capacity remaining on existing venture debt facilities — optionality the company can call on without re-pricing.", "available = total facility committed − drawn − amounts no longer drawable (covenant restrictions, expired draw windows)." ], "exclusionRules": [ "Drawn principal (that is `venture_debt_drawn`).", "Capacity no longer drawable due to covenant breach or an expired draw window — exclude it even though the headline facility is larger.", "Equity capital and convertible capacity — this is a debt line, not an equity raise.", "Uncommitted / indicative facility interest a lender has floated but not documented." ], "requiredInputs": [ "Total committed facility size and amount drawn.", "Draw-window expiry dates and any covenant-conditioned draw restrictions.", "Current covenant compliance status.", "Net burn, to express availability in months of runway." ], "dataSourcePriority": [ "The facility agreement (committed size + draw conditions) and current covenant compliance.", "Treasury's facility tracker as a fallback." ], "edgeCases": [ "Availability is CONDITIONAL: most facilities require continued covenant compliance — an available line can be frozen or pulled if cash / ARR covenants slip. Treat it as a soft commitment until drawn.", "Expiring draw windows: undrawn capacity that vanishes on a calendar date — flag the expiry.", "Available capacity of 3–6 months of net burn is meaningful optionality; under ~1 month rarely justifies the facility complexity." ], "validationChecks": [ "venture_debt_available + venture_debt_drawn ≤ total facility committed.", "Pair with `venture_debt_covenant_status` — availability reported without covenant status overstates the usable buffer." ], "commonMiscomputations": [ "Reporting available capacity as a hard, committed source of cash — it is contingent on staying inside covenants.", "Counting capacity behind an expired draw window or a tripped covenant.", "Adding available debt capacity to equity-raise totals." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "fundraising.venture_debt_covenant_status", "slug": "venture_debt_covenant_status", "domain": "fundraising", "defaultLabel": "Venture Debt Covenant Status", "description": "Stoplight state of the venture-debt facility covenants — typically minimum-cash, minimum-ARR or revenue, maximum-burn, customer-concentration, and material-adverse-change clauses (per the standard Bessemer / Battery Ventures venture-debt primers). A covenant trip can freeze the draw line, accelerate repayment, or both. Common pitfall: covenants are not always actively monitored between board meetings — drift between an internal forecast and a covenant threshold can cross the line silently. Boards should require monthly covenant headroom reporting when material debt is drawn.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Stoplight categorical: in-compliance (with headroom) / at-risk (headroom ≤ 1 quarter) / tripped / waived. List the binding covenant and current headroom.", "whyItMatters": "A covenant trip can cascade into a liquidity crisis fast — frozen facility, accelerated repayment, MAC clause triggering. Board catches this only if it is on the dashboard explicitly.", "interpretationGuidance": "Headroom of less than one quarter on the binding covenant is \"at-risk\" — board action required. Headroom of less than one month is a crisis-management situation regardless of stoplight color. Always pair with the binding-covenant name (e.g. \"minimum cash $5M, current $7.2M, headroom = $2.2M\").", "relatedKpiIds": [ "fundraising.venture_debt_drawn", "fundraising.venture_debt_available", "finance.total_cash_in_bank", "finance.net_burn_rate" ] }, { "rogueId": "fundraising.venture_debt_drawn", "slug": "venture_debt_drawn", "domain": "fundraising", "defaultLabel": "Venture Debt Drawn", "description": "Principal currently drawn from venture debt facilities (e.g. Silicon Valley Bank, Hercules Capital, Trinity Capital, Western Alliance, Bridge Bank facilities). Venture debt typically extends runway 6–12 months alongside the equity round — used well, it dilution-efficiently bridges to the next equity event; used poorly, it concentrates default risk into a single covenant covenant trip. Common pitfall: drawn debt creates interest expense and a repayment schedule that compresses runway in 18–24 months even though it extends runway today (per the Battery Ventures venture-debt primer and the Bessemer \"venture debt playbook\" series).", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Sum of principal drawn (and not yet repaid) across all active venture debt facilities. Distinct from `venture_debt_available` (undrawn capacity). Servicing cost = drawn × (rate + fees) — reduces runway.", "whyItMatters": "Drawn debt accelerates cash burn through interest plus principal amortization (typically 24–36 month amortization after a 6–18 month interest-only period). Misjudging the trade-off between dilution avoided and forced repayment is a common venture-backed startup failure mode.", "interpretationGuidance": "Drawn debt above ~30% of unrestricted cash starts to dominate the runway forecast and the covenant exposure. Pair with `venture_debt_covenant_status` and the next-round timeline — if the next equity event is uncertain past the amortization start date, the board should be in active conversation about refinancing.", "relatedKpiIds": [ "fundraising.venture_debt_available", "fundraising.venture_debt_covenant_status", "finance.total_cash_in_bank", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "Principal currently DRAWN (and not yet repaid) from venture debt facilities (e.g. SVB, Hercules, Trinity, Western Alliance, Bridge Bank).", "Debt that creates interest expense and a repayment schedule — funding CAPACITY converted to a liability, not an equity raise." ], "exclusionRules": [ "Undrawn facility capacity (that is `venture_debt_available`).", "Equity capital — venture debt is NOT part of `total_round_size` or `total_capital_raised` (which track equity).", "Convertible instruments — debt does not convert to equity at a priced round the way SAFEs / notes do (absent attached warrants).", "Warrant coverage attached to the facility — track separately as dilution, not as drawn principal." ], "requiredInputs": [ "Per-facility principal drawn and repaid to date.", "Interest rate, fees, and the amortization schedule (interest-only period + amortization start).", "Covenant package, to assess forced-repayment / acceleration risk." ], "dataSourcePriority": [ "The loan / facility agreement and the lender's statement of account.", "Treasury's debt schedule as a fallback — reconcile to the lender statement." ], "edgeCases": [ "Drawn debt EXTENDS runway today but COMPRESSES it in 18–24 months via interest plus principal amortization — model both effects.", "Drawn above ~30% of unrestricted cash starts to dominate the runway forecast and covenant exposure — pair with `venture_debt_covenant_status`.", "A covenant trip can accelerate repayment — model the downside, not just the scheduled amortization." ], "validationChecks": [ "venture_debt_drawn ≤ total facility committed.", "Servicing cost = drawn × (rate + fees) should reconcile to the interest line in `finance.interest_income_expense`.", "Drawn debt must NOT appear in equity-raise KPIs (`total_round_size`, `total_capital_raised`)." ], "commonMiscomputations": [ "Counting drawn venture debt as part of the equity round or cumulative capital raised — it is debt, not an equity raise.", "Treating debt as pure runway extension while ignoring the repayment cliff and interest drag.", "Including undrawn capacity in the drawn figure." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "hr.approved_headcount_budget", "slug": "approved_headcount_budget", "domain": "hr", "defaultLabel": "Approved Headcount Budget", "description": "Board-approved end-of-period headcount target. The contractual reference point against which `hr.total_headcount` and `hr.open_positions` are read — drift means either hiring under plan (typically a growth concern) or over plan (typically a burn-discipline concern). Common pitfall: silent in-year adjustments — boards approve a number, the CEO informally expands or contracts to it, and the variance never gets reconciled. Best practice is to treat changes to this number as board-action items, recorded in `hr.board_actions`.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Plain board-approved end-of-period FTE target. No derivation — set by board resolution as part of the annual or semi-annual budget. Changes require board approval and should be logged in `hr.board_actions`.", "whyItMatters": "The single number that converts strategic intent into operating constraint. Variance against this number drives the budget-vs-actual conversation that anchors most board meetings' HR section.", "interpretationGuidance": "DEPRECATED (#2056) — superseded by `hr.total_headcount` carrying scenario=`budget` (the F1 scenario axis, #2019). The board-approved headcount plan is now the budget scenario of the single canonical headcount KPI, so budget and actual share one definition and one variance view instead of two parallel KPIs. This KPI is hidden from the \"Add KPI\" picker and onboarding but still resolves so existing references keep rendering; prefer `hr.total_headcount` (scenario=budget) for all new budget surfaces. For migration context: pair with `hr.total_headcount` and `hr.headcount_change` for variance reporting — a sustained gap >10% under plan typically signals recruiting capacity issues; sustained over plan signals approval-gate slippage or contractor-conversion that bypassed the budget process (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.total_headcount", "hr.headcount_change", "hr.open_positions", "hr.hiring_plan", "hr.board_actions" ], "calculationPolicy": { "inclusionRules": [ "The board-approved end-of-period FTE target — a plain count set by board resolution as part of the annual or semi-annual budget. No derivation; it is an input, point-in-time as-of the period it governs.", "Use the same FTE-equivalent, employees-only convention as `hr.total_headcount` so plan and actual are directly comparable." ], "exclusionRules": [ "Contractors and open reqs beyond the approved seat count — the budget is an employee-FTE ceiling, consistent with the headcount definition.", "Informal in-year expansions or contractions that never went through a board approval — changes to this number are themselves board-action items (`hr.board_actions`)." ], "requiredInputs": [ "The board resolution / approved operating budget stating the headcount target.", "Any board-approved mid-period revisions, each logged as a board action." ], "dataSourcePriority": [ "Board-approved budget document / resolution of record.", "Finance FP&A headcount plan reconciled to the board number." ], "edgeCases": [ "DEPRECATED (#2056): the board-approved plan is now the `scenario=budget` axis of `hr.total_headcount`, so budget and actual share one definition and one variance view. Populate this legacy KPI only to keep existing references resolving; author all new budget surfaces against `hr.total_headcount` (scenario=budget).", "Mid-year board-approved revision: record the change and its effective date rather than silently overwriting, so the variance history stays auditable." ], "validationChecks": [ "Variance vs `hr.total_headcount` actuals: a sustained gap >10% under plan signals recruiting-capacity issues; sustained over plan signals approval-gate slippage or contractor-conversion that bypassed the budget process.", "Any change to this number should have a corresponding `hr.board_actions` entry — an unexplained change is a process gap." ], "commonMiscomputations": [ "Silently adjusting the approved number to match actuals so variance always reads zero — defeats the budget-vs-actual conversation this KPI exists for.", "Mixing a headcount (people) target with an FTE target, or including contractors, so it cannot be compared like-for-like against `hr.total_headcount`." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.arr_per_fte", "slug": "arr_per_fte", "domain": "hr", "defaultLabel": "ARR per FTE", "description": "Annual Recurring Revenue divided by total FTE-equivalent workforce — the canonical SaaS workforce-productivity ratio anchored to the SaaS Capital Annual Survey methodology (revenue per employee benchmarks). A high-signal denominator for \"are we over- or under-staffed for our revenue scale?\" Common pitfall: choosing different ARR conventions (ending vs average, GAAP-reconciled vs raw) without locking in a board-level standard. Best practice is to pair this with `sales.arr` so the numerator is unambiguous and to disclose whether contractors are included in the FTE denominator.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Capital Annual Survey 2025 (14th Annual)", "sourceUrl": "https://www.saas-capital.com/blog-posts/revenue-per-employee-benchmarks-for-private-saas-companies/", "sectionRef": "Revenue per Employee", "publicationDate": "2025-06-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 100000, "median": 130000, "p75": 175000, "unit": "$", "sourceName": "SaaS Capital Annual Survey 2025 (14th Annual)", "sourceYear": "2025", "higherIsBetter": true }, "formula": "ARR per FTE = `sales.arr` / `hr.total_headcount` (or FTE-equivalent including contractor adjustment from `hr.fte_metrics`). Document the denominator convention in board materials. Per SaaS Capital Annual Survey 2025 methodology (Revenue per Employee).", "whyItMatters": "Investors use this as a quick scalability and operating-leverage proxy — companies with higher ARR/FTE at a given scale typically command premium multiples. Internally, the metric anchors hiring-plan discipline: does each net new FTE earn its keep?", "interpretationGuidance": "SaaS Capital Annual Survey 2025 (§Revenue per Employee) reports private SaaS medians clustering in the $150K–$250K range, with top quartile $250K+ and bottom quartile under $150K (verify exact figures against the cited report — distributions vary by ARR band). Sub-$100K sustained at Series B+ is a board-level efficiency conversation. Reads should be paired with stage and growth rate — high-growth-stage companies tolerate lower ratios for a window in exchange for growth.", "relatedKpiIds": [ "sales.arr", "hr.total_headcount", "hr.fte_metrics", "hr.payroll_run_rate", "operations.rule_of_40" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "production": "computed" } }, { "rogueId": "hr.at_risk_count", "slug": "at_risk_count", "domain": "hr", "defaultLabel": "At-Risk Employees", "description": "Count of employees actively flagged as flight risk by managers, based on engagement signals (skip-level surveys, manager 1:1s, counter-offer activity, tenure-curve risk). A leading indicator that complements the lagging `hr.voluntary_exits` number. Common pitfall: stale flags that never get cleared — at-risk lists tend to drift toward \"every senior IC ever\" without manager discipline. Best practice is a quarterly refresh with explicit add/remove notes and an action attached to each flag.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of currently-flagged active employees on the retention watchlist. Flag criteria are company-defined but typically include: declining 1:1 engagement, missed comp expectations, counter-offer activity, or manager-flagged tenure-curve risk. Convention: flags expire 90 days after entry unless renewed.", "whyItMatters": "Converts manager intuition into a board-readable risk count, and pairs naturally with `hr.retention_initiatives` so the board sees risk and response together. A rising at-risk count without rising retention activity is a yellow flag.", "interpretationGuidance": "Read alongside `hr.voluntary_exits` — at-risk count should lead exits by 1–2 quarters. Concentration in one team or level is more diagnostic than the absolute number. Sustained at-risk count above ~10–15% of headcount typically warrants a targeted retention program (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.voluntary_exits", "hr.voluntary_turnover_rate", "hr.retention_initiatives", "hr.talent_challenges" ], "calculationPolicy": { "inclusionRules": [ "Count of currently-flagged active employees on the retention watchlist as of the snapshot date — a point-in-time read of manager-assessed flight risk.", "Flag criteria are company-defined but typically include declining 1:1 engagement, missed comp expectations, counter-offer activity, or manager-flagged tenure-curve risk.", "Convention: a flag expires 90 days after entry unless a manager explicitly renews it — this keeps the list disciplined." ], "exclusionRules": [ "Stale flags past their 90-day expiry that no manager has renewed — left in, the list drifts toward \"every senior IC ever\" and the count loses meaning.", "Employees on a formal PIP — that is performance management (`hr.performance_watch_count`), a different signal from retention risk.", "Departed employees still flagged in the system." ], "requiredInputs": [ "Current retention-watchlist with entry dates, last-renewal dates, and an action attached to each flag.", "Team / level attribution for the concentration read.", "The company-defined flag criteria and the 90-day expiry convention." ], "dataSourcePriority": [ "Manager / HRBP retention-watchlist of record (refreshed each cycle).", "Skip-level and engagement-survey signals as corroboration." ], "edgeCases": [ "Flag with no attached action: best practice is to require an action per flag; a bare flag should be reviewed rather than counted as managed risk.", "An at-risk employee who moves onto a PIP: they shift to `hr.performance_watch_count` — do not double-count across both watchlists.", "Quarterly refresh: stale flags drop out unless explicitly renewed, so the count can fall purely from list hygiene — note when a drop is hygiene vs genuine de-risking." ], "validationChecks": [ "At-risk count should LEAD `hr.voluntary_exits` by ~1–2 quarters; if exits rise with no prior at-risk build-up, manager flagging is lagging reality.", "Concentration in one team or level is more diagnostic than the absolute number.", "Sustained above ~10–15% of headcount typically warrants a targeted retention program tracked in `hr.retention_initiatives`." ], "commonMiscomputations": [ "Carrying expired flags forward without renewal — inflates the count and turns a leading indicator into noise.", "Conflating PIP employees (performance) with flight-risk employees (retention) — they answer different board questions.", "Counting flags with no owner or action as managed risk." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.avg_days_to_fill", "slug": "avg_days_to_fill", "domain": "hr", "defaultLabel": "Average Days to Fill", "description": "Mean elapsed days between requisition opening (approved and posted) and offer acceptance, averaged across requisitions filled in the period. The headline recruiting-velocity KPI commonly tracked in the SHRM Talent Acquisition Benchmarking Report. Common pitfall: choosing between time-to-fill (req-opened to offer-accepted) and time-to-hire (first-applicant to offer-accepted) without locking the convention — the two can differ by weeks. Best practice is to standardize on time-to-fill (the SHRM benchmark convention) and document any deviation.", "fieldType": "number", "unit": "days", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SHRM Talent Acquisition Benchmarking Report", "sourceUrl": "https://www.shrm.org/topics-tools/research/talent-acquisition-benchmarking-report", "sectionRef": "Time-to-Fill", "publicationDate": "2023-01-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "formula": "Average Days to Fill = Σ(offer-accepted-date − requisition-opened-date) / count of requisitions filled in the period. Convention: time-to-fill per SHRM Talent Acquisition Benchmarking Report — req-opened to offer-accepted, not first-applicant to offer-accepted.", "whyItMatters": "A stretching time-to-fill is one of the earliest leading indicators of either comp-band misfit, role-spec creep, or recruiter capacity exhaustion. Combined with `hr.open_positions`, it projects when promised capacity actually arrives.", "interpretationGuidance": "SHRM Talent Acquisition Benchmarking Report typically reports cross-industry medians around 40–45 days time-to-fill, with technical roles (engineering, data) often longer (60–90+ days). Verify against the most recent SHRM report for the exact figure. A sustained increase of >20% with no role-mix change typically signals a recruiting-pipeline issue (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.open_positions", "hr.hiring_plan", "hr.new_hires", "hr.key_openings", "hr.key_hires" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.board_actions", "slug": "board_actions", "domain": "hr", "defaultLabel": "HR Board Actions", "description": "Explicit list of HR items requiring board attention, approval, or decision in this meeting — executive comp changes, headcount-budget changes, equity-pool top-ups, employment-policy approvals, and any items needing a board resolution. Common pitfall: burying decisions inside other narrative sections — boards consistently miss requests that are not explicitly tagged as \"decision required.\" Best practice is to label each item as approval-required vs awareness-only and give a one-line ask.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "The single most under-served section on most board packs. CEOs often expect their narrative to drive a decision; boards often miss the implicit ask. An explicit \"board actions\" section is a low-cost forcing function for board-level decision hygiene.", "interpretationGuidance": "Each item should be one of: approval-required (specific resolution wording or vote), assistance-required (intro / reference / open-door request), or awareness-only (FYI for governance log). Use `hr.risk_items` for the structured-table version once the board adopts that pattern.", "relatedKpiIds": [ "hr.risk_items", "hr.approved_headcount_budget", "hr.talent_challenges", "hr.retention_initiatives" ] }, { "rogueId": "hr.departments", "slug": "departments", "domain": "hr", "defaultLabel": "Departments", "description": "Field-array of per-department rows — department name, leader status (resolved against `hr.leader_status`), and headcount metrics with stable-count auto-calc — rendered as a drag-sortable table grouped by department. Common pitfall: department boundaries drift over time (Eng+R&D merging, GTM splitting into Sales/Marketing/CS) — when boundaries change, prior-period comparisons need an explicit reconciliation note. This KPI is structural, not numeric — no formula applies.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Shows the org map at a glance — where capacity is allocated, which departments are short-staffed, where leader-vacancies are concentrated. Boards use this to validate the strategy-vs-investment alignment (\"we say we are product-led but R&D is 20% of headcount\").", "interpretationGuidance": "Read with `hr.leader_status` alongside — a department with strong leader and on-plan headcount tells a very different story from one with interim/vacant leader and growing headcount. Material department-shape changes should be called out in `hr.talent_highlights` or `hr.talent_challenges` narrative.", "relatedKpiIds": [ "hr.leader_status", "hr.total_headcount", "hr.key_hires", "hr.key_openings", "hr.executive_commentary" ] }, { "rogueId": "hr.executive_commentary", "slug": "executive_commentary", "domain": "hr", "defaultLabel": "HR Executive Commentary", "description": "Stacked commentary editor with per-section icon and live word count, hosting the four canonical HR narrative slots (talent highlights, talent challenges, hiring plan, retention initiatives) under a single base path — each section persists under `.`. The composite container for the narrative side of the HR scorecard, paired with `hr.departments` and `hr.risk_items` for the structured side. Common pitfall: writing each section in isolation — strong commentary cross-references the numbers (\"voluntary turnover up 4 points QoQ, here is what we are doing\").", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Centralizes the narrative around the HR numbers in one editing surface, with word-count feedback that prevents both under- and over-writing. The structure mirrors how boards expect HR to be presented: positives, concerns, plan, mitigations.", "interpretationGuidance": "Each section should weigh in at roughly the same length (target 80–150 words per section is a reasonable convention) — wildly uneven sections signal the CEO/CHRO is avoiding one of the four. Word-count outliers are an editorial check, not a hard rule.", "relatedKpiIds": [ "hr.talent_highlights", "hr.talent_challenges", "hr.hiring_plan", "hr.retention_initiatives", "hr.departments", "hr.risk_items" ] }, { "rogueId": "hr.fte_metrics", "slug": "fte_metrics", "domain": "hr", "defaultLabel": "FTE Metrics", "description": "Derived triple — effective FTE, cost-per-FTE, and annualized payroll — computed from `hr.payroll_run_rate` + `hr.total_contractors` and a contractor-to-FTE conversion factor. Lets the board see capacity in normalized terms even when the staffing mix shifts. Common pitfall: choosing a contractor-to-FTE factor without explicit board agreement — some companies use 1.0 (1 contractor = 1 FTE for capacity), others use 0.8 (account for ramp / partial-engagement), others use cost-equivalent ratios. Lock the convention.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "effectiveFTE = `hr.total_headcount` + (`hr.total_contractors` × contractorFactor). costPerFTE = `hr.payroll_run_rate` / effectiveFTE. annualizedPayroll = effectiveFTE × costPerFTE. Default contractor factor 0.8 unless the board adopts a different convention.", "whyItMatters": "Normalizes capacity and cost across companies with very different contractor strategies, making `hr.arr_per_fte` and `hr.payroll_as_pct_of_burn` more comparable over time. Surfaces hidden cost inflation when contractor headcount grows faster than employee headcount.", "interpretationGuidance": "Watch the drift between `hr.total_headcount` and effectiveFTE — divergence indicates contractor expansion that may warrant a build-vs-rent conversation. CostPerFTE materially above stage-typical comp benchmarks suggests either a senior-heavy mix or contractor-rate premium creep (industry folk-wisdom, not citation-grade — varies by geography and role mix).", "relatedKpiIds": [ "hr.total_headcount", "hr.total_contractors", "hr.payroll_run_rate", "hr.arr_per_fte", "hr.payroll_as_pct_of_burn" ] }, { "rogueId": "hr.headcount_change", "slug": "headcount_change", "domain": "hr", "defaultLabel": "Net Headcount Change", "description": "Net change in employee headcount during the period — new hires minus (voluntary exits + terminations). The bottom-line growth-or-contraction number on the HR scorecard. Common pitfall: reporting net change without showing the gross-in / gross-out components — boards can't diagnose a flat net number caused by 5 hires and 5 exits the same way they'd diagnose a flat number from zero on each side. Best practice is to surface the four components (new hires, voluntary exits, terminations, net change) together.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Net Headcount Change = `hr.new_hires` − (`hr.voluntary_exits` + `hr.terminations`). Sign convention: positive = growth, negative = contraction. Does not include contractor changes (those flow through `hr.total_contractors`).", "whyItMatters": "Single-number summary of HR's execution in the period and the simplest reconciliation point between this period's `hr.total_headcount` and the prior period's. Variance from `hr.hiring_plan` is the board-conversation trigger.", "interpretationGuidance": "Pair with the gross flows for diagnosis. A small positive net with high gross-in and gross-out tells a churn story; a large positive net during contraction periods raises plan-discipline questions. Compare to `hr.approved_headcount_budget` for budget-vs-actual posture.", "relatedKpiIds": [ "hr.new_hires", "hr.voluntary_exits", "hr.terminations", "hr.total_headcount", "hr.approved_headcount_budget" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.hiring_plan", "slug": "hiring_plan", "domain": "hr", "defaultLabel": "Hiring Plan", "description": "Forward-looking narrative on next-period hiring priorities — target roles, sequence, sourcing strategy, and any unusual asks (executive search, specialized recruiter spend, location flexibility shifts). Anchors the board's understanding of where capacity is heading and what approvals or help are needed. Common pitfall: a stale plan that gets copy-pasted across quarters — the hiring plan should evolve with strategy shifts. Best practice is to lead with the 2–3 highest-priority hires and their justification, then a brief on backfills and bench-builds.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Converts `hr.approved_headcount_budget` (a number) into a board-relevant sequence (a story). Without this, board members lack the context to help with intros, validate strategic-role timing, or push back on questionable role specs.", "interpretationGuidance": "Strong plans name specific roles, target start dates, and what board help would accelerate the hire. Pair with `hr.key_openings` for the structured priority list — narrative here, table there.", "relatedKpiIds": [ "hr.approved_headcount_budget", "hr.open_positions", "hr.key_openings", "hr.avg_days_to_fill", "hr.new_hires" ] }, { "rogueId": "hr.involuntary_turnover_rate", "slug": "involuntary_turnover_rate", "domain": "hr", "defaultLabel": "Involuntary Turnover Rate", "description": "Annualized rate of company-initiated separations as a percentage of average headcount. Complement to `hr.voluntary_turnover_rate`; together they form the total turnover picture per the Mercer US Turnover Survey methodology. Common pitfall: lumping one-time RIFs into the steady-state rate, which makes the trend unreadable. Best practice is to report steady-state involuntary turnover and call out any RIF events separately in `hr.board_actions` with the headcount delta.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "Mercer US Turnover Survey 2025", "sourceUrl": "https://www.imercer.com/articleinsights/workforce-turnover-trends", "sectionRef": "Involuntary Turnover", "publicationDate": "2025-03-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "formula": "Involuntary Turnover Rate (annualized) = (Terminations in period / Average Headcount in period) × (12 / months in period) × 100. Convention: exclude announced RIF events from the steady-state series; report them separately with headcount delta. Per Mercer US Turnover Survey methodology.", "whyItMatters": "A read on performance-management cadence and any active restructuring. Sustained near-zero raises questions about management discipline; sustained-elevated raises questions about hiring quality or strategy thrash.", "interpretationGuidance": "US all-industry total turnover historically clusters in the 18–25% annualized range per Mercer US Turnover Survey 2025 (§Total Turnover); involuntary typically represents 4–8% of that total (verify exact splits against the cited report — distributions vary by industry). Companies with very low involuntary rates (<2% annualized) often have buried under-performers; companies above ~8% steady-state typically have a hiring or onboarding-quality issue (industry folk-wisdom on the upper bound, not citation-grade).", "relatedKpiIds": [ "hr.terminations", "hr.performance_watch_count", "hr.voluntary_turnover_rate", "hr.talent_challenges" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.key_hires", "slug": "key_hires", "domain": "hr", "defaultLabel": "Key Hires", "description": "Field-array of notable individual hires that warrant board-level visibility — typically C-1 executives, director-level functional leaders, and strategic specialist hires. Per-item shape: name, level, role, start status, days-to-fill. Rendered via the T2 collapsible-card gallery pattern. Structural, not numeric — formula does not apply. Common pitfall: listing every hire instead of the strategic few — boards lose signal quickly when this section turns into a directory.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Gives the board context for the headline `hr.new_hires` count — five generalist engineers reads very differently from five senior staff engineers plus a new VP Eng. Boards routinely volunteer reference checks and network help when key hires are surfaced.", "interpretationGuidance": "Keep this list short (typically 3–8 items per board period). Each entry should be defensibly \"board-relevant\" — strategic role, executive level, or a market-significant external hire. Tie related items to `hr.talent_highlights` narrative where additional context is warranted.", "relatedKpiIds": [ "hr.new_hires", "hr.avg_days_to_fill", "hr.talent_highlights", "hr.key_openings", "hr.leader_status" ] }, { "rogueId": "hr.key_openings", "slug": "key_openings", "domain": "hr", "defaultLabel": "Key Openings", "description": "Field-array of priority open roles the board should be aware of and may be able to accelerate — typically C-1 executives, hard-to-fill specialists, and any role open >60 days. Per-item shape: title, department, level, urgency, owner. Rendered via the T2 collapsible-card gallery pattern. Structural, not numeric. Common pitfall: padding the list with every open req — boards add the most value on the 3–8 strategic openings, not on backfilling the next IC.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Turns the scalar `hr.open_positions` count into board-actionable context. Every entry is an opportunity for the board to help with intros, references, or compensation reality-checks. The owner field also surfaces accountability for the search.", "interpretationGuidance": "Items should name the role, the owner (recruiter or hiring manager), days open, and the ask (intros / references / approval for higher comp band). A role open >90 days without a board narrative or escalation usually signals either insufficient executive attention or unrealistic specifications.", "relatedKpiIds": [ "hr.open_positions", "hr.avg_days_to_fill", "hr.hiring_plan", "hr.key_hires", "hr.leader_status", "hr.talent_challenges" ] }, { "rogueId": "hr.leader_status", "slug": "leader_status", "domain": "hr", "defaultLabel": "Leader Status", "description": "Tri-state leader status (permanent / interim / vacant) for each board-tracked department. Permanent shows name+title; interim shows the covering person; vacant shows the gap explicitly. The single most board-relevant org-design signal — an extended interim or vacant status in a strategic function is almost always a board-level concern. Common pitfall: leaving \"interim\" indefinitely as a way to avoid the search-and-hire conversation — boards should set a maximum interim duration and treat overruns as board-action items. Structural KPI; no formula.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Leader-coverage gaps in strategic functions (e.g., engineering, sales, product) are leading indicators of execution risk. Boards routinely under-weight this signal because the headcount number can look healthy while the leadership layer is hollow.", "interpretationGuidance": "Interim status sustained >90 days warrants a board narrative on the search; vacant status in a board-relevant function is a board-action item on day one. Pair with `hr.key_openings` for the structured search-status view and `hr.talent_challenges` for narrative on the search difficulty.", "relatedKpiIds": [ "hr.departments", "hr.key_openings", "hr.talent_challenges", "hr.board_actions" ] }, { "rogueId": "hr.new_hires", "slug": "new_hires", "domain": "hr", "defaultLabel": "New Hires", "description": "Count of employees whose first day fell within the reporting period. The growth-input side of the headcount equation, paired with `hr.voluntary_exits` and `hr.terminations` on the loss side. Common pitfall: counting accepted offers vs actual start dates — these can diverge by weeks (notice period) or fall through entirely (offer rescind, candidate ghosting). The board number should be actual starts, not signed offers; pipeline movement belongs in `hr.hiring_plan` narrative.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of employees whose official start date is within the reporting period. Exclude rehires within 90 days (boomerangs) from this count if the board has adopted that convention; otherwise include and note in `hr.talent_highlights`.", "whyItMatters": "Directly drives `hr.headcount_change` and validates execution against `hr.hiring_plan`. Persistent gaps between hiring-plan targets and actual new hires usually indicate either a pipeline problem or compensation-market mismatch — both board-action triggers.", "interpretationGuidance": "Reconcile against `hr.open_positions` closed in period and against `hr.hiring_plan` targets. A new-hire count materially below plan (e.g. <70% of target for two consecutive periods) typically warrants a board conversation about recruiting capacity, comp band competitiveness, or scope realism (industry folk-wisdom, not citation-grade).", "relatedKpiIds": [ "hr.open_positions", "hr.hiring_plan", "hr.headcount_change", "hr.avg_days_to_fill", "hr.key_hires", "hr.total_headcount" ], "calculationPolicy": { "inclusionRules": [ "Count of employees whose official FIRST DAY (actual start date) falls WITHIN the reporting period — a period-flow count, bounded by the same period start/end the rest of the report uses.", "Count actual starts only: the person showed up and began work in the period.", "If the board has adopted the boomerang convention, exclude rehires within 90 days of a prior exit; otherwise include them and note in `hr.talent_highlights`." ], "exclusionRules": [ "Signed / accepted offers whose start date has not yet arrived — offers can slip by weeks (notice period) or fall through entirely (rescind, ghosting). Pipeline movement belongs in `hr.hiring_plan` narrative, not this count.", "Contractor or agency starts — those move `hr.total_contractors`, not employee hires.", "Internal transfers and promotions — the person was already a head; no net new hire.", "Starts that landed in a prior or later period — respect the period boundary strictly." ], "requiredInputs": [ "New-employee list with official start dates within the period.", "The period start/end boundaries.", "The boomerang (rehire-within-90-days) convention flag if adopted." ], "dataSourcePriority": [ "HRIS onboarding / start-date records.", "Payroll first-paycheck records as a cross-check that the start actually occurred." ], "edgeCases": [ "Offer accepted in one period, start date in the next: count in the period of the actual start, never the offer date.", "Cohort / class start (e.g. a bootcamp or grad intake all starting the same Monday): all count in that period — expect a lumpy spike.", "Rescinded offer or no-show after a recorded start date: reverse out of the count; do not leave a phantom hire." ], "validationChecks": [ "New hires should reconcile against `hr.open_positions` closed in the period and against `hr.hiring_plan` targets.", "Prior headcount + new hires − exits should tie to current `hr.total_headcount` for the period." ], "commonMiscomputations": [ "Counting accepted offers instead of actual starts — overstates hiring and diverges from headcount by the notice-period lag.", "Including internal transfers / promotions as new hires — inflates the growth-input side of the headcount equation.", "Mis-dating cross-boundary starts into the wrong period, breaking the headcount reconciliation." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "hr.open_positions", "slug": "open_positions", "domain": "hr", "defaultLabel": "Open Positions", "description": "Count of board-approved roles that are currently posted and unfilled (requisition open, offer not yet accepted). The leading-edge indicator for upcoming hiring capacity demand. Common pitfall: \"approved\" drift — roles that were verbally green-lit but never went through the approval gate get counted here, inflating the number. The board number should match the approved headcount budget; everything else belongs in narrative as \"pipeline ideas.\"", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of requisitions where status = open AND approval = granted AND no candidate has accepted. Excludes positions filled but not yet started (those belong to `hr.new_hires` in the next period). Excludes role ideas not yet approved.", "whyItMatters": "Quantifies the hiring debt — every open role is unrealized capacity. Combined with `hr.avg_days_to_fill`, it projects when capacity actually arrives. A growing open-position count while time-to-fill stretches is a recruiting-capacity yellow flag.", "interpretationGuidance": "Open positions ÷ approved budget gap = recruiting load. If open positions exceed 15–20% of total headcount sustained over multiple periods, it usually signals either compensation issues, recruiter capacity issues, or unrealistic role specs (industry folk-wisdom, not citation-grade). Tie to `hr.key_openings` for priority-weighted context.", "relatedKpiIds": [ "hr.approved_headcount_budget", "hr.avg_days_to_fill", "hr.hiring_plan", "hr.key_openings", "hr.new_hires" ], "calculationPolicy": { "inclusionRules": [ "Count of requisitions where status = open AND approval = granted AND no candidate has yet accepted — a point-in-time snapshot of unfilled, board-approved roles as of the period-end date.", "The number should tie to the approved headcount plan: every open req traces to a budgeted, approved seat." ], "exclusionRules": [ "Role ideas that were verbally green-lit but never cleared the approval gate — \"approved drift\" inflates the count; those belong in narrative as pipeline ideas.", "Positions already filled but not yet started — the candidate accepted, so the seat is no longer open; it becomes `hr.new_hires` next period.", "Backfills already covered by an accepted offer." ], "requiredInputs": [ "Requisition list at the snapshot date with status, approval state, and candidate-accepted flag.", "The approved headcount plan to confirm each open req is budgeted.", "Priority / criticality tags if the board reads `hr.key_openings`." ], "dataSourcePriority": [ "ATS (Greenhouse / Lever / Ashby) open-requisition report.", "Approved headcount budget / board resolution to validate the approval gate." ], "edgeCases": [ "Offer extended but not yet accepted: still open (candidate has not accepted) — flips out of the count only on acceptance.", "Evergreen / pipeline reqs kept open with no intent to hire imminently: exclude or flag separately so the hiring-debt read is honest.", "A single req approved for multiple identical hires: count the number of seats, not the number of postings." ], "validationChecks": [ "Open positions ÷ approved-budget gap = recruiting load; sustained above ~15–20% of total headcount signals comp, recruiter-capacity, or role-spec issues.", "Open positions closed in a period should reconcile against `hr.new_hires` started in the following period, allowing for `hr.avg_days_to_fill`." ], "commonMiscomputations": [ "Counting unapproved \"wish-list\" roles as open positions — overstates hiring debt and breaks the tie to the approved plan.", "Leaving filled-but-not-started seats in the open count, double-reading them once here and again as next-period hires.", "Counting postings instead of approved seats when one req covers several identical hires." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.payroll_as_pct_of_burn", "slug": "payroll_as_pct_of_burn", "domain": "hr", "defaultLabel": "Payroll as % of Burn", "description": "Monthly fully-loaded payroll cost as a percentage of `finance.gross_burn_rate`. Tells the board what share of cash outflow funds people vs everything else (infra, GTM spend, professional services, facilities). Common pitfall: comparing this ratio across companies without normalizing for stage and capex intensity — a pure-software seed company will run very payroll-heavy; a hardware-or-bio company will not. Best practice is to read this in conjunction with the burn-rate trend, not in isolation.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "HR" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Payroll as % of Burn = (Monthly payroll run rate from `hr.payroll_run_rate` / 12) / `finance.gross_burn_rate` × 100. Use gross burn (not net) so growing revenue does not distort the share. Document any non-cash comp adjustments (e.g., stock-based comp included vs excluded).", "whyItMatters": "Cost-structure shape indicator — pairs naturally with runway math. A rising share without rising headcount can signal comp-band drift; a falling share with rising headcount often signals contractor / GTM expansion. Boards use this for the people-vs-program trade-off conversation.", "interpretationGuidance": "Early-stage pure-software companies often run 60–75% payroll-of-burn (people-heavy by design); later-stage companies with material GTM spend typically run 40–55%; hardware-heavy or bio-tech companies can run lower still (industry folk-wisdom, not citation-grade — varies materially by business model). Sudden drops without a hiring freeze or program-spend spike are usually accounting reclassifications, not real economics.", "relatedKpiIds": [ "hr.payroll_run_rate", "finance.gross_burn_rate", "finance.net_burn_rate", "hr.total_headcount", "hr.arr_per_fte" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "hr.payroll_run_rate", "slug": "payroll_run_rate", "domain": "hr", "defaultLabel": "Payroll Run Rate", "description": "Annualized fully-loaded payroll cost based on current employee compensation — wages plus employer-paid taxes, benefits, and typical equity refresh allocation. Used as the dominant input into `hr.payroll_as_pct_of_burn` and the projection for `hr.fte_metrics`. Common pitfall: reporting base-salary-only and missing employer payroll taxes, benefits, and bonus accrual — this can understate true cost by 15–30%. Document the loading convention (typically wages × 1.20–1.30 for US fully-loaded) and apply consistently.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Payroll Run Rate = Σ(employee fully-loaded annual comp). Fully-loaded ≈ base + bonus + employer taxes (Social Security, Medicare, FUTA, SUTA) + benefits (health, dental, 401k match) + equity refresh accrual. US-typical loading factor 1.20–1.30× base; international varies materially by country.", "whyItMatters": "The single largest line in most operating budgets — drives runway calculus, dilution sensitivity at fundraise, and the unit economics conversation. Visible upward steps without a corresponding revenue or headcount-plan justification are board-action triggers.", "interpretationGuidance": "Trend month-over-month; flag step-changes >5% that are not attributable to net new hires or planned comp cycles. Compare against `hr.approved_headcount_budget` × stage-typical avg comp (industry folk-wisdom, not citation-grade) to surface comp-band drift.", "relatedKpiIds": [ "hr.payroll_as_pct_of_burn", "hr.fte_metrics", "hr.total_headcount", "hr.arr_per_fte", "finance.gross_burn_rate" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "hr.performance_watch_count", "slug": "performance_watch_count", "domain": "hr", "defaultLabel": "Performance Watch", "description": "Count of employees currently on a formal Performance Improvement Plan (PIP) or equivalent performance-bar process. Leading indicator for `hr.terminations` — most PIPs that do not resolve with measurable improvement convert to involuntary exits within one quarter. Common pitfall: confusing PIPs with informal coaching — only employees on a written, time-bound plan with defined exit criteria should be counted here. Informal \"we need to talk\" relationships belong in the at-risk count, not this number.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of active employees on a written, time-bound Performance Improvement Plan with explicit success criteria and an end date (typically 30/60/90 days). Excludes informal coaching relationships and probationary new hires unless the new-hire is on a formal extension PIP.", "whyItMatters": "Leading indicator for `hr.terminations` and a read on management discipline — managers who avoid PIPs accumulate B-players, managers who over-use them are training-out coachable performers. The trend matters more than the snapshot.", "interpretationGuidance": "A sustained PIP count of ~1–3% of headcount typically reflects healthy performance management; near-zero suggests management avoidance; >5% sustained suggests either hiring-quality issues or unrealistic performance bars (industry folk-wisdom, not citation-grade). PIP-to-termination conversion rate (tracked privately) usually settles in the 60–80% range when the program is well-run.", "relatedKpiIds": [ "hr.terminations", "hr.involuntary_turnover_rate", "hr.at_risk_count", "hr.talent_challenges" ], "calculationPolicy": { "inclusionRules": [ "Count of active employees currently on a WRITTEN, time-bound Performance Improvement Plan (PIP) with explicit success criteria and an end date (typically 30 / 60 / 90 days), as of the snapshot date — a point-in-time read.", "Only formal, documented plans count — the leading indicator for `hr.terminations`." ], "exclusionRules": [ "Informal coaching / \"we need to talk\" relationships with no written plan — those are retention/management signals at most (`hr.at_risk_count`), not a PIP.", "Probationary new hires, unless a new hire is on a formal extension PIP with the same written, time-bound structure.", "Employees who have completed or exited a PIP (passed, or already terminated) by the snapshot date." ], "requiredInputs": [ "List of active PIPs with start date, defined end date, and documented success criteria.", "PIP outcome tracking (passed / converted-to-exit) for the conversion-rate read.", "Team / manager attribution." ], "dataSourcePriority": [ "HR case-management / PIP system of record with written plan documents.", "Manager + HRBP confirmation that each plan is formal and time-bound (not informal coaching)." ], "edgeCases": [ "PIP that lapses past its end date with no documented outcome: resolve it (passed or exited) rather than letting it linger in the active count.", "New-hire on a formal extension PIP: counts here; ordinary probation does not.", "PIP-to-termination conversion (privately tracked) typically settles in the 60–80% range when the program is well-run — use it to anticipate `hr.terminations`." ], "validationChecks": [ "PIP count should LEAD `hr.terminations` by roughly a quarter — most unresolved PIPs convert to involuntary exits.", "Sustained ~1–3% of headcount reflects healthy performance management; near-zero suggests management avoidance; >5% sustained suggests hiring-quality or unrealistic-bar issues." ], "commonMiscomputations": [ "Counting informal coaching as PIPs — overstates the leading indicator and blurs it with `hr.at_risk_count`.", "Leaving completed / lapsed PIPs in the active count.", "Including ordinary new-hire probation as a performance watch." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.retention_initiatives", "slug": "retention_initiatives", "domain": "hr", "defaultLabel": "Retention Initiatives", "description": "Narrative on the programs and actions in flight to retain key talent and reduce voluntary turnover — refresh grants, comp-band adjustments, manager training, career-pathing programs, and similar. The response side of the `hr.at_risk_count` and `hr.voluntary_turnover_rate` story. Common pitfall: listing perks (snacks, swag) instead of actions tied to retention drivers. Best practice is to name the initiative, the at-risk population it targets, and the leading-indicator metric you'll watch.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Shows the board that retention risk is being actively managed, not just measured. Initiatives without measurement plans are typically performative — pairing each initiative with a leading-indicator KPI (engagement score, manager 1:1 cadence, refresh-grant acceptance) shows operational rigor.", "interpretationGuidance": "Strong examples: equity refresh program targeting tenure-3+ engineers; manager-effectiveness training tied to attrition-by-manager data; career-laddering for senior ICs. Weak examples: generic culture/perks investments without a specific retention thesis.", "relatedKpiIds": [ "hr.voluntary_turnover_rate", "hr.at_risk_count", "hr.voluntary_exits", "hr.talent_challenges" ] }, { "rogueId": "hr.risk_items", "slug": "risk_items", "domain": "hr", "defaultLabel": "HR Risk Items", "description": "Structured field-array of board-attention items, each with type / department / action / narrative quartet (problem / impact / proposal / ask). Chip color follows boardActionNeeded: approval=red, assistance=yellow, awareness=blue. The structured-table version of `hr.board_actions` — preferred when the board has adopted the formal risk-item pattern. Common pitfall: drift toward vague \"we are working on it\" entries — strong items name a specific action with a date.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Forces explicit categorization of each item (approval / assistance / awareness) so the board cannot accidentally skip a decision item. The color chips make scanning faster than narrative text alone.", "interpretationGuidance": "Red chips (approval) demand a vote or formal resolution this meeting. Yellow chips (assistance) need specific board-member action (intros, references) — name the asks. Blue chips (awareness) are FYI for governance log. A standing meeting with all-blue is well-run; all-red signals a governance backlog.", "relatedKpiIds": [ "hr.board_actions", "hr.talent_challenges", "hr.retention_initiatives", "hr.executive_commentary" ] }, { "rogueId": "hr.talent_challenges", "slug": "talent_challenges", "domain": "hr", "defaultLabel": "Talent Challenges", "description": "Narrative on key hiring difficulties, attrition concerns, comp-market pressure, and market-driven talent risks that the board should weigh in on or be aware of. The \"watch this\" companion to `hr.talent_highlights`. Common pitfall: sanitizing this section to avoid uncomfortable conversations — but talent challenges are precisely where boards add the most value (warm intros, comp benchmarking, executive search). Best practice is to name the specific role, team, or risk and the ask explicitly.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "The mechanism by which the board's network and judgment get applied to talent gaps. Numbers in `hr.voluntary_exits` and `hr.at_risk_count` show the symptom; this section names the cause and the ask.", "interpretationGuidance": "Treat each item as a problem-statement plus ask. Example structure: \"Senior PM role open 90 days; market comp drift +12% over our band; ask: board intros + comp-band re-baseline.\" Vague items signal either insufficient management attention or unwillingness to surface the issue.", "relatedKpiIds": [ "hr.voluntary_exits", "hr.at_risk_count", "hr.open_positions", "hr.avg_days_to_fill", "hr.board_actions", "hr.risk_items" ] }, { "rogueId": "hr.talent_highlights", "slug": "talent_highlights", "domain": "hr", "defaultLabel": "Talent Highlights", "description": "Free-form narrative on notable hires, promotions, internal moves, and other positive organizational developments the board should be aware of. The \"good news\" companion to `hr.talent_challenges`. Common pitfall: listing every internal move and burying the genuinely important signals (key executive hires, strategic team-build milestones). Best practice is 3–5 bulleted items per period, each tied to a board-relevant outcome or risk-it-mitigates rather than a generic celebration.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "whyItMatters": "Gives the board context for the headline numbers — a flat headcount with a major engineering leader hired tells a different story than a flat headcount with no narrative. Also primes board members for warm-intro asks and reference checks.", "interpretationGuidance": "Quality > quantity. Items should answer \"why does the board care?\" — a senior IC promotion to manager matters because it filled a key vacancy; a generic \"we promoted 4 people\" doesn't. Pair each highlight with the role/team it impacts.", "relatedKpiIds": [ "hr.key_hires", "hr.executive_commentary", "hr.talent_challenges", "hr.new_hires" ] }, { "rogueId": "hr.terminations", "slug": "terminations", "domain": "hr", "defaultLabel": "Terminations", "description": "Count of company-initiated employee separations during the period — performance-management exits, layoffs, redundancies, and for-cause terminations. The numerator of `hr.involuntary_turnover_rate` and the inverse of `hr.voluntary_exits` on the attrition page. Common pitfall: bundling layoff events (often one-time, board-known) with normal performance-management churn (steady-state, manager-driven). Best practice is to break out layoffs in `hr.talent_challenges` narrative and reserve this number for the recurring stream.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of company-initiated employee separations within the reporting period — performance terminations, RIFs, role eliminations, and for-cause exits. Excludes voluntary resignations (those are `hr.voluntary_exits`) and contractor-end events.", "whyItMatters": "A direct read on performance-management cadence and any organizational restructuring activity. Spikes correlate with strategy pivots, post-fundraise rebalancing, or recovery from over-hiring — each implies different board narratives.", "interpretationGuidance": "Sustained termination volume above ~1% of headcount per month (excluding announced RIFs) typically signals hiring-quality issues, performance-bar drift, or comp-band misfit (industry folk-wisdom, not citation-grade). One-time RIF events should be reported separately in `hr.board_actions` with the headcount delta noted.", "relatedKpiIds": [ "hr.involuntary_turnover_rate", "hr.performance_watch_count", "hr.headcount_change", "hr.talent_challenges", "hr.board_actions" ], "calculationPolicy": { "inclusionRules": [ "Count of COMPANY-INITIATED employee separations within the reporting period — performance terminations, layoffs / RIFs, role eliminations, and for-cause exits (period-flow, standard period boundary).", "Mirror image of `hr.voluntary_exits`: if the company drove the separation, it counts here." ], "exclusionRules": [ "Employee-initiated resignations and retirements — those are `hr.voluntary_exits`.", "Contractor-end / engagement-expiry events — not employees.", "Announced one-time layoff (RIF) events when the board has adopted the convention of breaking them out separately in `hr.talent_challenges` / `hr.board_actions` — keep this number for the recurring performance-management stream so the trend is not swamped by a single event." ], "requiredInputs": [ "Separation records flagged company-initiated with reason code (performance / RIF / for-cause) and last-day date.", "A separate tally of any announced RIF headcount delta for the period.", "Team / level attribution." ], "dataSourcePriority": [ "HRIS offboarding records with initiator and reason code.", "Board-action / RIF documentation for one-time events that should be reported separately." ], "edgeCases": [ "Layoff event: report the RIF headcount delta separately (board-known, one-time) and reserve this metric for steady-state performance churn — bundling them hides both signals.", "For-cause immediate termination: counts in the period of the last day even with no notice.", "Severance / garden-leave: the separation date for counting is the employment-end date, not the date severance payments stop." ], "validationChecks": [ "Converts to `hr.involuntary_turnover_rate`; the count and rate must share the same separation set.", "Should lag `hr.performance_watch_count` by roughly a quarter when PIPs are converting — a spike with no prior PIP build-up suggests a RIF that belongs in narrative.", "Voluntary + involuntary exits reconcile against the period headcount drop with `hr.new_hires`." ], "commonMiscomputations": [ "Bundling one-time layoff headcount into the recurring termination stream — distorts the performance-management trend the board reads here.", "Classifying a managed-out exit as voluntary, which simultaneously overstates voluntary and understates involuntary turnover.", "Counting contractor-end events as terminations." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "hr.total_contractors", "slug": "total_contractors", "domain": "hr", "defaultLabel": "Total Contractors", "description": "Count of active 1099 contractors, consultants, agencies-of-record, and similar non-employee labor at period end. Tracked separately from `hr.total_headcount` because the cost structure, retention dynamics, and classification risk are different. Common pitfall: under-counting agencies that bill on a project basis without per-head visibility — these often slip out of HR systems and surface only in finance AP detail. A contractor-to-FTE ratio above ~30% sustained typically warrants a classification audit and a deliberate \"build vs rent\" board conversation.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of active non-employee workers (1099 contractors, agency contractors, consultants) with engagement status = active at period end. Convert to FTE-equivalent in `hr.fte_metrics` using a contractor-to-FTE factor (e.g., 0.8) if applying to capacity math.", "whyItMatters": "Hidden capacity and hidden cost — contractors expand effective capacity without going through the headcount-approval gate, but they carry classification risk and tend to convert into permanent cost without explicit board approval. Surfacing the count counters that quiet expansion.", "interpretationGuidance": "Contractor share of total workforce above ~30% sustained signals either a hiring-gate workaround or a deliberate flex-staffing strategy — both warrant a narrative explanation. Under US IRS rules and similar in other jurisdictions, sustained \"contractors\" working full-time under direction risk reclassification (industry folk-wisdom on the 30% threshold, not citation-grade).", "relatedKpiIds": [ "hr.total_headcount", "hr.fte_metrics", "hr.hiring_plan", "hr.payroll_run_rate" ], "calculationPolicy": { "inclusionRules": [ "Count of active non-employee workers — 1099 contractors, consultants, and agencies-of-record — with engagement status = active AS OF the period-end date (point-in-time, same snapshot date as `hr.total_headcount`).", "Count the people actually delivering work, including agency staff billing on a project basis; estimate per-head equivalents for agencies that only bill a lump sum so the count is not silently understated.", "Keep this number strictly parallel to, and separate from, `hr.total_headcount` so the contractor-to-FTE ratio is readable." ], "exclusionRules": [ "W-2 / direct employees — those are `hr.total_headcount`. The whole point of this KPI is to keep the two cost structures and classification-risk profiles distinct.", "One-off vendors and SaaS subscriptions that are not labor (hosting, software, professional fees) — this is a count of contracted PEOPLE, not a spend line.", "Contractors whose engagement ended on or before the snapshot date." ], "requiredInputs": [ "Active contractor / consultant roster at period end with engagement status and, where possible, FTE-equivalent effort.", "Finance AP / vendor ledger to surface agency engagements that never reached the HRIS (the classic blind spot).", "Engagement type (individual 1099 vs agency-of-record) for the classification-risk read." ], "dataSourcePriority": [ "Contractor-management / AP system of record for active engagements.", "Finance AP detail as the catch-all for project-billed agencies invisible to HR systems.", "Department leads as a last-resort reconciliation for embedded contractors." ], "edgeCases": [ "Project-billed agencies with no per-head visibility: estimate the effective head count from the contract scope rather than recording zero — under-counting here defeats the metric.", "Contractor converting to employee mid-period: drop from this count and pick up in `hr.total_headcount` / `hr.new_hires` on the conversion date; never double-count in the same period.", "Full-time, long-tenured \"contractors\" working under company direction: flag for the classification-risk (IRS reclassification) conversation even though they still count here." ], "validationChecks": [ "Contractor share = contractors ÷ (headcount + contractors); sustained above ~30% warrants a narrative on classification risk or a deliberate flex-staffing strategy.", "Reconcile the count against contractor spend in finance — a rising spend with flat count usually means agency heads are uncounted." ], "commonMiscomputations": [ "Under-counting lump-sum agency engagements because they lack per-head records — the metric exists precisely to surface this hidden capacity.", "Sweeping contractors into `hr.total_headcount` (or vice versa) — corrupts both counts and the contractor-ratio read.", "Counting terminated / expired engagements still open in the vendor system as active." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.total_headcount", "slug": "total_headcount", "domain": "hr", "defaultLabel": "Total Headcount", "description": "Total number of employees (W-2 / direct-employment equivalents) across all departments at period end. The base denominator for nearly every other HR ratio — turnover rate, revenue per FTE, payroll as % of burn — so getting the snapshot date and the FTE-vs-headcount convention right matters. CANONICAL HEADCOUNT (#2056): this single KPI carries BOTH the plan and the reported figure via the scenario axis (#2019) — scenario=`budget` is the board-approved headcount plan (formerly the separate, now-deprecated `hr.approved_headcount_budget`), and scenario=`actual` is the reported end-of-period count. Budget-vs-actual variance is read off the two scenarios of this one definition. Common pitfall: mixing headcount (people) with FTE (capacity) — they diverge whenever part-time, contractor, or shared-services arrangements exist. Document the convention (typically \"FTE-equivalent, employees only, end-of-period\") at the board level once and apply consistently.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of active employees at period end. Convention: FTE-equivalent (a 0.5 FTE counts as 0.5), employees only (contractors tracked separately in `hr.total_contractors`). Snapshot is end-of-period unless the board has explicitly adopted an average-headcount convention for ratio math. The budget scenario (scenario=`budget`) holds the board-approved plan for the same definition; actuals (scenario=`actual`) hold the reported count.", "whyItMatters": "The denominator for every HR ratio the board reads — turnover %, revenue/FTE, payroll as % of burn. Drift in this number without a corresponding hiring-plan update is a leading signal of unmanaged growth or quiet attrition.", "interpretationGuidance": "Read budget-vs-actual off this one KPI: scenario=`budget` is the board-approved headcount plan, scenario=`actual` is the reported count (#2056 — this replaces the deprecated `hr.approved_headcount_budget`). A delta above ±5% without a board note typically warrants explanation. Stage norm for SaaS (industry folk-wisdom, not citation-grade): seed 5–15, Series A 20–50, Series B 50–150, Series C 150–400.", "relatedKpiIds": [ "hr.headcount_change", "hr.approved_headcount_budget", "hr.new_hires", "hr.voluntary_exits", "hr.terminations", "hr.total_contractors", "hr.arr_per_fte" ], "calculationPolicy": { "inclusionRules": [ "Count of active W-2 / direct-employment-equivalent employees across all departments, measured AS OF the period-end date (point-in-time snapshot, not an average — unless the board has formally adopted average-headcount for ratio math, in which case state it).", "Convention is FTE-equivalent: a 0.5 FTE counts as 0.5, not 1. Pin this convention once at the board level and apply it identically everywhere headcount feeds a ratio.", "When reading budget-vs-actual, `scenario=budget` holds the board-approved headcount plan and `scenario=actual` holds the reported end-of-period count — both ride this single canonical KPI (#2056)." ], "exclusionRules": [ "Contractors, 1099s, consultants, and agency labor — those live in `hr.total_contractors`. Folding them in is the single most common headcount error and corrupts every downstream ratio.", "Open (unfilled) requisitions — an approved-but-vacant role is `hr.open_positions`, not a head.", "Accepted offers whose start date has not yet landed in the period — they become heads via `hr.new_hires` when they actually start.", "Employees whose last day fell on or before the period-end snapshot date — they have already left the count." ], "requiredInputs": [ "Active-employee roster as of the period-end date with employment type (W-2 vs contractor) and FTE fraction per person.", "The board-adopted convention flag: FTE-equivalent vs raw head, and end-of-period vs average.", "Department / function attribution if the board reads headcount by team." ], "dataSourcePriority": [ "HRIS system of record (Rippling / Gusto / BambooHR / Workday) active-employee report at period close.", "Payroll register as a cross-check on who was actually paid in the period.", "Finance AP / contractor detail to confirm contractors were NOT swept into the employee count." ], "edgeCases": [ "Part-time and job-share arrangements: convert to FTE fraction — two 0.5 FTEs are 1.0, not 2.0, under the FTE convention.", "Employees on unpaid leave / sabbatical: typically still counted as active heads; document the treatment and apply it consistently across periods.", "Acquisition or acqui-hire mid-period: the acquired team joins headcount on their effective start date, not the deal-close date — keep the two distinct.", "Shared-services or PEO-employed staff working full-time under company direction: decide once whether they count as heads or contractors and never flip mid-series." ], "validationChecks": [ "Prior headcount + `hr.new_hires` − (`hr.voluntary_exits` + `hr.terminations`) should reconcile to current headcount within the period; an unexplained gap means a hire/exit was mis-dated or a contractor was swept in.", "Headcount should move in step with `hr.payroll_run_rate`; a headcount jump with flat payroll (or vice versa) flags a counting or classification error.", "A delta above ±5% vs the `scenario=budget` plan without a board note typically warrants explanation." ], "commonMiscomputations": [ "Including contractors in the head count — inflates the denominator and understates every per-FTE productivity and turnover ratio.", "Counting raw heads instead of FTE-equivalent when part-time / job-share arrangements exist — overstates capacity.", "Using a mid-period or average snapshot in one report and end-of-period in another — the two conventions silently disagree and make turnover math unreproducible.", "Counting accepted-but-not-started offers as heads — they belong to next period via `hr.new_hires`." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "hr.voluntary_exits", "slug": "voluntary_exits", "domain": "hr", "defaultLabel": "Voluntary Exits", "description": "Count of employees who resigned during the period (initiated by employee, not the company). The numerator of the `hr.voluntary_turnover_rate` calculation and the headline \"are we losing people\" number boards anchor on. Common pitfall: ambiguous \"mutually agreed\" exits — companies sometimes log managed-out exits as voluntary to keep the visible number low. Define the test: if the employee initiated the conversation and there was no formal performance trigger, it is voluntary; otherwise log as termination.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of employees with employee-initiated separations (resignations, retirements) during the period. Excludes terminations (those go in `hr.terminations`), exclusions for cause, and contractor-end events.", "whyItMatters": "The leading indicator the board reads for retention health and culture risk. Concentration in a single team, level, or tenure cohort is more informative than the absolute number — investigate the pattern, not just the headline.", "interpretationGuidance": "Convert to `hr.voluntary_turnover_rate` (annualized %) for cross-period comparison and benchmarking. Spike triggers: 3+ voluntary exits from one team in a quarter, or any C-1 (executive direct-report) departure — both warrant board narrative in `hr.talent_challenges`.", "relatedKpiIds": [ "hr.voluntary_turnover_rate", "hr.at_risk_count", "hr.retention_initiatives", "hr.talent_challenges", "hr.total_headcount" ], "calculationPolicy": { "inclusionRules": [ "Count of EMPLOYEE-INITIATED separations — resignations and retirements — whose effective last day falls WITHIN the reporting period (period-flow, same period boundary as the rest of the report).", "Classification test: the employee initiated the conversation AND there was no formal performance trigger ⇒ voluntary. Apply the test consistently so the visible number is not gamed." ], "exclusionRules": [ "Company-initiated separations — performance terminations, layoffs/RIFs, for-cause exits — those are `hr.terminations`.", "\"Mutually agreed\" / managed-out exits where the company drove the conversation or a performance process was underway — log these as terminations, not voluntary, even when paperwork reads \"resignation\".", "Contractor-end events — not employees, not in this count.", "Exits dated outside the reporting period." ], "requiredInputs": [ "Separation records with initiator (employee vs company), reason code, and last-day date.", "Performance-process flags to disambiguate managed-out exits from genuine resignations.", "Team / level / tenure attribution for the concentration read." ], "dataSourcePriority": [ "HRIS offboarding records with reason codes.", "Manager / HR exit-interview notes to confirm the voluntary classification on ambiguous cases." ], "edgeCases": [ "Resignation tendered in one period with a last day in the next: count in the period of the effective last day, matching the headcount snapshot.", "Retirement: voluntary by definition (employee-initiated) unless it is a packaged exit tied to a RIF.", "\"Quiet\" managed-out: if a manager steered the exit, classify as termination regardless of how the paperwork reads — otherwise voluntary turnover is understated and involuntary is hidden." ], "validationChecks": [ "Voluntary + involuntary exits should reconcile against the period headcount drop alongside `hr.new_hires`.", "Converts to `hr.voluntary_turnover_rate` (annualized % of average headcount) for benchmarking — the raw count and the rate must use the same exit set.", "Concentration (3+ from one team in a quarter, or any executive direct-report) is more diagnostic than the absolute number — surface the pattern." ], "commonMiscomputations": [ "Logging managed-out / \"mutually agreed\" exits as voluntary to keep the headline retention number low — the single biggest integrity trap on this KPI.", "Mixing contractor-end events into employee voluntary exits.", "Counting by resignation-notice date instead of effective last day, desynchronizing exits from the headcount snapshot." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "hr.voluntary_turnover_rate", "slug": "voluntary_turnover_rate", "domain": "hr", "defaultLabel": "Voluntary Turnover Rate", "description": "Voluntary exits over a trailing period, expressed as an annualized percentage of average headcount — the headline attrition number on the HR scorecard. Anchored to the Mercer US Turnover Survey methodology (Mercer reports voluntary vs involuntary turnover annually). Common pitfall: comparing a single quarter's annualized rate against an annual benchmark — short-window annualization is noisy. Best practice is trailing-12-months for benchmark comparison and trailing-3 or trailing-6 for trend reads. Per #1426: stage-specific industry norms here are folk-wisdom unless tied to a specific Mercer or comparable published cut.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "HR" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "Mercer US Turnover Survey 2025", "sourceUrl": "https://www.imercer.com/articleinsights/workforce-turnover-trends", "sectionRef": "Voluntary Turnover", "publicationDate": "2025-03-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 7, "median": 11, "p75": 17, "unit": "%", "sourceName": "Mercer US Turnover Survey 2025", "sourceYear": "2025", "higherIsBetter": false }, "formula": "Voluntary Turnover Rate (annualized) = (Voluntary Exits in period / Average Headcount in period) × (12 / months in period) × 100. Average headcount = (start headcount + end headcount) / 2 is the simplest acceptable convention; (Σ daily headcount / days in period) is more precise. Per Mercer US Turnover Survey methodology.", "whyItMatters": "The canonical retention KPI investors and boards benchmark against. Tracks the cost of churn — every voluntary exit triggers a replacement-cost cycle (recruiting + onboarding + ramp), commonly estimated at 0.5–2× the role's annual salary depending on level (industry folk-wisdom, not citation-grade).", "interpretationGuidance": "US all-industry voluntary turnover is typically 13–17% annualized per Mercer US Turnover Survey 2025 (§Voluntary Turnover). Tech sector typically runs higher than the all-industry average; engineering and sales roles run highest within tech. Sustained voluntary turnover above ~20% annualized at any stage is a board-action trigger; sustained sub-5% can indicate under-performance management (managers not exiting B-players). Compare trailing-12-month rates, not quarterly snapshots.", "relatedKpiIds": [ "hr.voluntary_exits", "hr.involuntary_turnover_rate", "hr.at_risk_count", "hr.retention_initiatives", "hr.talent_challenges" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "operations.rule_of_40", "slug": "rule_of_40", "domain": "operations", "defaultLabel": "Rule of 40", "description": "Composite SaaS health score that sums the company's revenue growth rate and a profitability proxy (commonly EBITDA margin or free-cash-flow margin) into a single percentage. Originally articulated by Brad Feld in 2015 and codified by the SaaS Metrics Standards Board, the rule frames the growth-vs-profitability tradeoff: a company growing at 60% with a −20% margin scores 40, equal to a company growing at 20% with a +20% margin. The board reads it to sanity-check whether growth is being bought at unhealthy burn or whether margin discipline is constraining growth too far. Common pitfall: which profitability proxy is used materially changes the score (FCF margin is the strictest, EBITDA more flattering, \"operating margin\" inconsistently defined), so pick one and disclose it next to the number.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/rule-of-40", "sectionRef": "Rule of 40", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "benchmark": { "p25": -4, "median": 15, "p75": 31, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "Rule of 40 = revenue_growth_rate (%) + profitability_margin (%). Per SMSB, `revenue_growth_rate` is typically YoY ARR or revenue growth; `profitability_margin` is typically EBITDA margin or FCF margin (disclose which). Both inputs are percentages — the output is also a percentage and can be negative when negative margin overwhelms growth.", "whyItMatters": "Single-number readout of the growth-vs-burn tradeoff. Lets the board compare a high-growth / high-burn company to a slow-growth / profitable one on one axis, and surfaces unhealthy growth (high growth paid for with margin much worse than negative growth-rate offset).", "interpretationGuidance": "Per the rule as originally framed by Brad Feld (2015) and the SaaS Metrics Standards Board, a score at or above 40% is the canonical \"healthy\" threshold for growth-stage SaaS; below 40% signals either growth or margin is under-delivering. Finer stratifications often cited (>50% strong, >60% best-in-class) are industry folk-wisdom, not citation-grade. Always disclose which profitability proxy is used — comparing an EBITDA-margin Rule of 40 to an FCF-margin Rule of 40 is apples-to-oranges and a frequent board-deck error.", "relatedKpiIds": [ "sales.growth_rate_yoy", "sales.gross_margin", "finance.net_burn_rate", "finance.runway_months" ], "calculationPolicy": { "inclusionRules": [ "Sum two percentages: revenue growth rate + profitability margin.", "Growth rate: YoY ARR or YoY recognized-revenue growth (pick one, disclose which — they diverge for sub-scale companies).", "Profitability margin: EBITDA margin OR free-cash-flow margin OR operating margin — pick one, disclose which.", "Both inputs and the output are percentages; the output can be negative." ], "exclusionRules": [ "Do not mix metric bases across the two terms (e.g. ARR-growth + GAAP-operating-margin is acceptable only if both are disclosed; never silently swap proxies between periods).", "Do not annualize a quarterly growth figure by ×4 for this — use a true YoY growth rate." ], "requiredInputs": [ "Revenue (or ARR) growth rate, YoY.", "Profitability margin for the same period.", "Disclosure of WHICH growth basis and WHICH margin proxy were used." ], "dataSourcePriority": [ "`sales.growth_rate_yoy` for the growth term.", "Audited / reviewed financials for the margin term." ], "edgeCases": [ "Margin-proxy choice materially changes the score: FCF margin is strictest, EBITDA more flattering, \"operating margin\" inconsistently defined. The same company can score 35 or 45 depending on the proxy — always disclose.", "Pre-revenue or near-zero-revenue company: Rule of 40 is not meaningful; report N/A rather than a wild number.", "Heavily seasonal business: use trailing-twelve-month figures for both terms so a single quarter does not distort the score.", "One-off items in the margin (litigation settlement, restructuring): present a \"normalized\" Rule of 40 alongside the headline." ], "validationChecks": [ "Rule of 40 = growth% + margin% — recompute and verify against any pre-computed value.", "If the score looks implausibly high (> 80) or low (< −40), check whether the growth rate was QoQ-annualized or whether the margin proxy is mis-signed.", "The growth term should reconcile with `sales.growth_rate_yoy`; the margin term should reconcile with the income statement." ], "commonMiscomputations": [ "Switching the profitability proxy between periods (EBITDA one quarter, FCF the next) — the trend then reflects bookkeeping, not the business.", "Comparing one company's EBITDA-margin Rule of 40 to another's FCF-margin Rule of 40 — apples to oranges; the most frequent board-deck error.", "Using QoQ growth ×4 instead of true YoY growth — overstates the growth term for any company with momentum or seasonality.", "Adding gross margin instead of a profitability margin — gross margin is ~70-80% for SaaS, so the score balloons past 100 and becomes meaningless.", "Sign error on a negative margin — adding +20 instead of −20 flips an unhealthy company into a healthy-looking score." ] }, "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "product.capacity_allocation", "slug": "capacity_allocation", "domain": "product", "defaultLabel": "Capacity Allocation", "description": "Container handle for the structured 5-category engineering-capacity object — total engineers plus the per-bucket split across innovation, maintenance, tech debt, customer support, and sales support (each a percentage), with an optional innovation target. The bespoke product feed card renders this as the capacity-allocation donut the demo design shows. RICHER than the 3-way `product.capacity_allocation_pct` percentage triple — this carries the headcount + the five operating buckets the donut needs. Common pitfall: the five buckets not summing to 100% because a category (e.g. sales support) was omitted.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — { totalEngineers, innovation, maintenance, techDebt, customerSupport, salesSupport, targetInnovation? }. The five percentage buckets sum to 100%; targetInnovation is the aspirational innovation share, not allocated capacity.", "whyItMatters": "Shows where engineering headcount actually goes across all five operating modes — the gap between innovation and its target is the clearest read on whether the company is investing in the future or absorbed by run-the-business work.", "interpretationGuidance": "A large gap between `innovation` and `targetInnovation` (e.g. 32% vs 50%) means run-the-business work is crowding out new capabilities. Read alongside `product.delivery_predictability` — falling innovation with falling predictability is a capacity-crisis signal.", "relatedKpiIds": [ "product.capacity_allocation_pct", "product.innovation_capacity_pct", "product.total_engineers", "product.delivery_predictability" ] }, { "rogueId": "product.capacity_allocation_pct", "slug": "capacity_allocation_pct", "domain": "product", "defaultLabel": "Capacity Allocation", "description": "Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. `innovation_capacity_pct` which is a single percentage for new-capabilities work, and vs. `offensive_roadmap_pct` which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Three-way breakdown: new_features_pct + maintenance_pct + tech_debt_pct = 100%. Measured in the same unit as capacity (eng-weeks, story points, or sprint capacity). Report planned vs actual split — the gap is the operational signal.", "whyItMatters": "Names where engineering hours actually go. The plan-versus-actual gap is one of the highest-signal operational metrics for the board — a persistent 20+ point gap between planned and actual new-feature allocation is the loudest possible flag that the company is under-investing in platform health (the missing hours are going to firefighting).", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: a healthy steady-state split at growth-stage SaaS is roughly 50–70% new features, 15–30% maintenance, 10–20% tech debt. Companies in platform-investment cycles will skew toward maintenance and tech debt. Pair with `innovation_capacity_pct` and `delivery_predictability` — capacity allocation tells you where time goes, predictability tells you whether commitments hold, innovation capacity tells you the available headroom for offense.", "relatedKpiIds": [ "product.innovation_capacity_pct", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.delivery_predictability", "product.total_engineers" ], "calculationPolicy": { "inclusionRules": [ "Three-way breakdown of engineering capacity by WORK TYPE — new_features_pct + maintenance_pct + tech_debt_pct = 100% — over a measurement window (typically a quarter).", "Denominator is total engineering capacity for the window, measured in a single unit (eng-weeks, story points, or sprint capacity).", "Report BOTH the planned and the actual split — the plan-vs-actual gap is the operating signal this KPI exists to surface." ], "exclusionRules": [ "The offensive / defensive / commitments roadmap percentages — that is the separate `product.*_roadmap_pct` partition with a different denominator (roadmap capacity, not all engineering capacity); do not merge the two.", "Capacity outside the engineering org (sales, CS) unless the board capacity definition explicitly includes embedded engineers — pin the boundary once.", "Non-capacity counts (headcount, dollars) — this is a share-of-hours partition." ], "requiredInputs": [ "Engineering time / capacity tracked by work type (new features / maintenance / tech debt) for the window.", "Both the planned split and the actual split.", "The capacity unit and the inclusion boundary of \"engineering capacity\"." ], "dataSourcePriority": [ "Engineering time / issue tracker tagged by work type (the actuals source).", "Sprint / roadmap plan for the planned split.", "Engineering-leadership estimate when actual time is not tracked — flag the lower confidence." ], "edgeCases": [ "A bucket omitted (e.g. customer-support engineering silently folded into maintenance): define the three buckets once and keep them stable, or the split will not sum to 100%.", "Plan reported as actual: require both — reporting only the plan hides the gap this KPI exists to surface.", "An item spanning buckets (a refactor that also ships a feature): split its capacity rather than forcing one bucket." ], "validationChecks": [ "new_features_pct + maintenance_pct + tech_debt_pct must sum to 100% (the three buckets are a mutually-exclusive partition of total engineering capacity) — a sum off 100% means a bucket was omitted or work was double-counted.", "A persistent 20+ point gap between planned and actual new-feature allocation is a loud signal the company is under-investing in platform health (the missing hours go to firefighting).", "This work-type partition is distinct from the `product.*_roadmap_pct` strategic-intent partition — do not expect the two to reconcile to each other." ], "commonMiscomputations": [ "Reporting the planned split as if it were actuals — hides the plan-vs-actual gap that is the whole point.", "Conflating this work-type partition with the offensive / defensive / commitments roadmap-intent partition (different denominator).", "Omitting a bucket (e.g. support engineering) so the three shares do not sum to 100%." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.commitments_roadmap_pct", "slug": "commitments_roadmap_pct", "domain": "product", "defaultLabel": "Commitments Roadmap %", "description": "Share of roadmap capacity allocated to CUSTOMER COMMITMENTS — the third slice of the offensive / defensive / commitments roadmap mix (the slice the bespoke product card needs to complete the roadmap-mix bar). Offensive (`product.offensive_roadmap_pct`) is net-new market expansion, defensive (`product.defensive_roadmap_pct`) is retention/churn-prevention work, and this commitments slice is contractually or relationship-committed deliverables (e.g. enterprise SCIM/audit-log promises). The three should sum to 100%. Common pitfall: commitments work going untracked, so the roadmap looks more offensive than the team actually is.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "commitments_roadmap_pct = customer-committed roadmap capacity ÷ total roadmap capacity × 100. Third slice of the mix: offensive_roadmap_pct + defensive_roadmap_pct + commitments_roadmap_pct = 100%.", "whyItMatters": "Makes contractually-committed roadmap work visible as its own category — a high commitments share means the roadmap is increasingly dictated by sales promises rather than product strategy.", "interpretationGuidance": "Read as the third slice with `product.offensive_roadmap_pct` and `product.defensive_roadmap_pct`. A rising commitments share that crowds out offensive work signals the roadmap is being driven by deal-by-deal promises.", "relatedKpiIds": [ "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.key_initiatives" ], "calculationPolicy": { "inclusionRules": [ "Share of planned roadmap capacity allocated to CUSTOMER COMMITMENTS — contractually or relationship-committed deliverables (e.g. enterprise SCIM / audit-log promises, contractual feature commitments).", "Same denominator (total planned roadmap capacity for the horizon) and unit as the offensive and defensive slices — the third slice that completes the roadmap-mix bar.", "Classify each roadmap item to exactly ONE of the three intent slices." ], "exclusionRules": [ "Net-new market-expansion / differentiation bets the company chose for strategy — `product.offensive_roadmap_pct` (uncommitted strategic work is offensive even if a customer would welcome it).", "Reliability / security / parity / retention work not tied to a specific contractual commitment — `product.defensive_roadmap_pct`.", "Internal delivery commitments to the board / GTM that are not customer-contractual — keep this slice to customer-committed work, or define the boundary explicitly and hold it." ], "requiredInputs": [ "Classified roadmap item list with per-item capacity.", "The register of contractual / relationship commitments driving roadmap items (from sales / CS).", "The horizon definition." ], "dataSourcePriority": [ "Roadmap planning tool with a \"committed\" tag linked to the contract / deal.", "Sales / CS commitment register cross-referenced to roadmap items.", "PM classification when the link is not modeled." ], "edgeCases": [ "A committed deliverable that also serves the broader market: classify by what drove it onto the roadmap (the commitment), but note the dual benefit.", "Commitments work going untracked makes the roadmap look more offensive than it is — surface it as its own slice rather than folding it into offense.", "Re-baselining: recompute all three slices together so they still sum to 100%." ], "validationChecks": [ "offensive + defensive + commitments must sum to ~100% over the fully-classified roadmap — a missing or double-counted commitments slice is the usual reason the bar does not close to 100%.", "A rising commitments share that crowds out offensive work signals the roadmap is increasingly driven by deal-by-deal promises rather than product strategy.", "Do not reconcile against `product.capacity_allocation_pct` — that is the work-type partition, a different denominator." ], "commonMiscomputations": [ "Leaving commitments untracked (folded into offense) so the roadmap looks more strategic than it is — the exact gap this slice exists to close.", "Mixing customer-contractual commitments with internal board / GTM delivery commitments without defining the boundary.", "Letting the three slices fail to sum to 100% because the commitments slice was omitted." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.defensive_roadmap_pct", "slug": "defensive_roadmap_pct", "domain": "product", "defaultLabel": "Revenue Protection %", "description": "Percentage of the planned roadmap allocated to defensive work — platform reliability, security/compliance, scalability rearchitecture, table-stakes parity with competitors, customer-retention features. The complement of `offensive_roadmap_pct`. Common pitfall: defensive work is chronically under-funded (less visible to customers, harder to demo) until a quality-churn or scalability event forces a reactive surge. Boards should treat sustained zero or near-zero defensive allocation in a maturing product as a leading indicator of future quality issues — per the standard product-management argument (Marty Cagan and similar product-leadership writing), a healthy roadmap pays both growth and platform-health rent.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "defensive_roadmap_pct = (roadmap_capacity_allocated_to_defensive_initiatives / total_roadmap_capacity) × 100, where \"defensive\" includes reliability, security, compliance, scalability, parity, retention features, and tech-debt paydown. Complement of `offensive_roadmap_pct` (they sum to ~100% in a fully-classified roadmap).", "whyItMatters": "Names the investment in not-losing alongside the investment in winning. A defensive % that responds to `quality_churn_pct` and `scalability_headroom` trends (rising when those degrade) is a sign of a healthy operating cadence; a defensive % stuck near zero while quality churn rises is a sign the board needs to push for re-prioritization.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 20–40% defensive at growth-stage SaaS with stable platform health; 40–60% during platform-investment cycles; below 15% rarely sustainable in a maturing product. Read alongside `quality_churn_pct` — a defensive ratio that has not increased while quality churn has been rising for 2+ quarters usually warrants a board-level conversation about reprioritization.", "relatedKpiIds": [ "product.offensive_roadmap_pct", "product.innovation_capacity_pct", "product.quality_churn_pct", "product.scalability_headroom", "product.key_initiatives_status" ], "calculationPolicy": { "inclusionRules": [ "Share of planned roadmap capacity allocated to defensive work — platform reliability, security / compliance, scalability rearchitecture, table-stakes parity, customer-retention features, and tech-debt paydown.", "Same denominator (total planned roadmap capacity for the horizon) and same unit as the offensive and commitments slices.", "Classify each roadmap item to exactly ONE of the three intent slices." ], "exclusionRules": [ "Net-new capabilities / market expansion / differentiation — that is `product.offensive_roadmap_pct`.", "Contractually committed deliverables — that is `product.commitments_roadmap_pct`.", "The maintenance / tech-debt share measured against all engineering hours — that is the `product.capacity_allocation_pct` partition, a different denominator." ], "requiredInputs": [ "Classified roadmap item list with per-item capacity.", "The horizon definition.", "The reliability / security / scalability backlog, so defensive work is not under-counted." ], "dataSourcePriority": [ "Roadmap planning tool with strategic-intent tags.", "PM + engineering classification.", "`product.quality_churn_pct` and `product.scalability_headroom` trends as a sanity check on whether defensive funding matches platform health." ], "edgeCases": [ "Defensive work is chronically under-funded (less visible, harder to demo) until a quality or scalability event forces a reactive surge — watch for a near-zero defensive share in a maturing product.", "An item that both hardens the platform and ships a feature: split its capacity across slices.", "Re-baselining: recompute all three slices together so they still sum to 100%." ], "validationChecks": [ "The three roadmap slices (offensive + defensive + commitments) must sum to ~100% — a defensive share that makes the sum drift off 100% means items are unclassified or counted in two slices.", "A defensive share stuck near zero while `product.quality_churn_pct` or `product.scalability_headroom` degrades for 2+ quarters is a re-prioritization flag.", "Do not reconcile against `product.capacity_allocation_pct` — different denominator (work-type vs roadmap-intent)." ], "commonMiscomputations": [ "Under-counting defensive work because it is less visible / demo-able — until a reliability event forces a reactive surge.", "Conflating the roadmap-intent defensive share with the maintenance / tech-debt share of the capacity-allocation partition.", "Leaving backlog unclassified so the slices do not sum to 100%." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.delivery_predictability", "slug": "delivery_predictability", "domain": "product", "defaultLabel": "Delivery Predictability", "description": "Percentage of committed deliverables shipped on or before the originally-promised date within a measurement window (typically a quarter). Surfaces whether the engineering organization can be trusted to hit commitments the company makes externally — to customers in contracts, to the board in quarterly plans, to GTM teams sequencing launches. Common pitfall: gaming. Teams over-deliver by under-promising (predictability climbs while velocity drops) or move the goalposts (re-baseline mid-quarter so \"on-time\" stays high). Boards should ask for \"predictability against original commitment\", not \"against current plan\", and pair with throughput trends.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "Product" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "benchmark": { "p25": 55, "median": 70, "p75": 85, "unit": "%", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "delivery_predictability_pct = (commitments_delivered_on_time / total_commitments) × 100, measured against the originally-promised date (not the most recently re-baselined date). Define \"on time\" explicitly — within the promised week, sprint, or quarter — and apply consistently.", "whyItMatters": "Predictability is the contract between engineering and the rest of the business. When it slips, GTM cannot sequence launches, sales cannot promise dates, and the board cannot trust the quarterly plan. Sustained low predictability is a leading indicator of either capacity mismatch, planning hygiene problems, or accumulated technical debt.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 70–85% predictability is typical for healthy growth-stage engineering organizations; 90%+ usually means sandbagging (commitments are too soft); below 60% means the planning process is broken or capacity is mismatched. Trend matters more than absolute level — a stable 75% is healthier than a 90% sliding to 70% quarter-over-quarter.", "relatedKpiIds": [ "product.key_initiatives_status", "product.capacity_allocation_pct", "product.innovation_capacity_pct", "product.scalability_headroom" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "product.feature_adoption", "slug": "feature_adoption", "domain": "product", "defaultLabel": "Weighted Feature Adoption", "description": "Percentage of customers (weighted by ARR) actively using a defined set of strategic features within a measurement window. The \"ARR-weighted\" framing matters: a feature used by 30% of customers covering 70% of ARR is a different signal than 30% of customers covering 5% of ARR. Common pitfall: defining adoption as \"ever used\" rather than \"actively using\" (returning use in the measurement window) — the first metric only goes up and tells the board nothing. Boards should require an active-use definition (e.g. used in 2 of the last 4 weeks) and a per-feature breakdown for the strategic feature set.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "benchmark": { "p25": 40, "median": 60, "p75": 75, "unit": "%", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "weighted_feature_adoption_pct = Σ (customer_arr × is_actively_using_feature) / Σ (customer_arr) × 100, where \"actively using\" is defined explicitly (e.g. ≥2 sessions in the last 4 weeks, or domain-appropriate usage threshold). Weight by ARR — not by customer count — to surface the strategic-account signal.", "whyItMatters": "Leading indicator of product-market fit for new capabilities. Adoption that does not reach a critical mass of ARR-weighted customers within 2–3 quarters is the strongest signal that the feature is either mis-targeted, mis-priced, or hidden in the UX. Drives roadmap continue-vs-cut decisions.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: for a strategic feature, 30–50% ARR-weighted adoption within 6 months is healthy; below 20% after 6 months usually warrants a retrospective. The product-management literature (Marty Cagan, \"INSPIRED\"; Pendo / Amplitude product-analytics playbooks) consistently emphasizes the active-use definition over cumulative reach, but does not publish citation-grade numeric ranges by company stage. Always pair this with `quality_churn_pct` — high adoption that coincides with rising quality-churn means the feature is shipping pain alongside use.", "relatedKpiIds": [ "product.quality_churn_pct", "product.offensive_roadmap_pct", "product.portfolio_strategy", "sales.arr", "customers.net_revenue_retention" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "product.innovation_capacity_pct", "slug": "innovation_capacity_pct", "domain": "product", "defaultLabel": "Innovation Capacity %", "description": "Percentage of R&D capacity (typically measured in engineering-weeks or story points over a quarter) allocated to net-new capabilities, as opposed to maintenance, bug fixes, internal tooling, or customer-support engineering. The \"available bandwidth for offense\" view. Common pitfall: confusing innovation capacity (input — how much team-time is available for new work) with `offensive_roadmap_pct` (output — what proportion of the planned roadmap is growth-oriented). A team can have 60% innovation capacity allocated entirely to defensive work if the roadmap demands it. Boards should look at both together.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "innovation_capacity_pct = (engineering_capacity_on_new_capabilities / total_engineering_capacity) × 100. Define \"new capabilities\" explicitly — typically excludes bug fixes, performance work, internal tooling, support engineering, and tech-debt paydown. Measured in the same unit as capacity allocation (eng-weeks, story points, or sprint capacity).", "whyItMatters": "Surfaces structural friction. A team with only 20% innovation capacity is being eaten by maintenance and reactive work — the board should be asking why (platform debt, support load, headcount mismatch) before approving new feature commitments.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 50–70% innovation capacity is typical for healthy growth-stage product engineering; below 40% suggests the team is operating in firefighting mode; above 80% suggests under-investment in platform health (will eventually pay back in `quality_churn_pct` and `scalability_headroom` compression). Trend matters most — a steady decline quarter-over-quarter is a leading indicator of accumulating maintenance debt.", "relatedKpiIds": [ "product.capacity_allocation_pct", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.rd_efficiency", "product.delivery_predictability" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "product.key_initiatives", "slug": "key_initiatives", "domain": "product", "defaultLabel": "Key Initiatives", "description": "Container handle for the field-array of strategic product initiatives committed for the current quarter / half — each entry tracks the initiative name, status (on-track / at-risk / blocked / shipped / cut), owner, target date, and a one-line explanation or mitigation plan. The structured, per-initiative companion to the `product.key_initiatives_status` narrative: the narrative gives the execution-pulse story, this gallery makes each initiative individually trackable with its own owner and status. Renders via the CollapsibleFormItemCardGallery widget (the reused gallery pattern shared with sales pipeline deals and HR key hires / openings). Common pitfall: every initiative defaults to \"on-track\" until two weeks before its deadline — require an explicit at-risk state with a mitigation plan, not a re-label at the deadline.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — field-array of initiative items (name, status, owner, targetDate, explanation / mitigation). No aggregate calculation; the surface makes each strategic initiative individually trackable at the board level.", "whyItMatters": "Connects the strategic narrative to delivery reality at the level the board can act on — surfaces where engineering needs unblocking and where commitments are slipping, per named initiative with a named owner. The board's most efficient leverage point on the product organization.", "interpretationGuidance": "Watch for chronic \"at-risk\" items without escalation (the team has accepted slippage and is notifying, not asking for help) and for all-green status alongside a declining `product.delivery_predictability` (status is being optimistically managed). Pair with the `product.key_initiatives_status` narrative — the gallery tracks the items, the narrative explains the pattern.", "relatedKpiIds": [ "product.key_initiatives_status", "product.delivery_predictability", "product.portfolio", "product.offensive_roadmap_pct", "product.capacity_allocation_pct" ] }, { "rogueId": "product.key_initiatives_status", "slug": "key_initiatives_status", "domain": "product", "defaultLabel": "Key Initiatives Status", "description": "Stoplight-plus-narrative status of the strategic product initiatives committed for the current quarter / half — each initiative ideally tagged on-track / at-risk / blocked / shipped, with a one-line explanation. The execution-pulse view that connects strategy intent to delivery reality. Common pitfall: every initiative defaults to \"on track\" until two weeks before the deadline, then turns red — a board that only sees binary green-or-red status without intermediate \"at-risk\" signaling is being managed reactively. Pair with `delivery_predictability` to detect this pattern; require at-risk initiatives to surface a mitigation plan, not just a label.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Narrative — list of named strategic initiatives, each with (1) status (on-track / at-risk / blocked / shipped / cut), (2) one-line explanation, (3) for at-risk and blocked: a mitigation plan or escalation request.", "whyItMatters": "Connects the strategic narrative to delivery reality at the level the board can act on. Surfaces where engineering needs unblocking, where commitments are slipping, and where the strategy needs revision. The board's most efficient leverage point on the product organization.", "interpretationGuidance": "Watch for two patterns: (1) chronic \"at-risk\" without escalation — usually a sign that the team has accepted the slippage and the board is being notified, not asked for help. (2) all-green status alongside declining `delivery_predictability` — usually a sign that the status field is being optimistically managed. The right cadence: at-risk should appear early and resolve via mitigation, not by re-labeling at the deadline.", "relatedKpiIds": [ "product.delivery_predictability", "product.portfolio_strategy", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.capacity_allocation_pct" ] }, { "rogueId": "product.offensive_roadmap_pct", "slug": "offensive_roadmap_pct", "domain": "product", "defaultLabel": "Growth & Differentiation %", "description": "Percentage of the planned roadmap (typically next 1–2 quarters) allocated to offensive bets — net-new capabilities, market expansion, differentiation moats, new monetization. The \"what proportion of the plan is about winning\" view. Common pitfall: counting \"improvements to existing features\" as offensive when the change is really table-stakes parity work. Boards should expect a McKinsey-style horizon framing (Horizon 1 = core, Horizon 2 = adjacent, Horizon 3 = transformational) or an equivalent classification, and apply it consistently. Per the original McKinsey \"Three Horizons\" framing (Baghai/Coley/White, \"The Alchemy of Growth\", 1999), a healthy portfolio funds all three — over-indexing on any one is a strategic risk.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "offensive_roadmap_pct = (roadmap_capacity_allocated_to_offensive_initiatives / total_roadmap_capacity) × 100, where \"offensive\" includes net-new capabilities, market-expansion work, differentiation features, and new monetization. Complement of `defensive_roadmap_pct` (they should sum to ~100% in a fully-classified roadmap).", "whyItMatters": "Encodes the company's strategic posture in one number. Boards use this to check the roadmap against the strategy narrative — a company saying it is \"going on offense\" while showing a 30% offensive roadmap has a story-versus-execution gap worth flagging.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 50–70% offensive in growth-stage companies pursuing market expansion; 30–50% in companies stabilizing a platform; below 30% in turnaround / harden-the-base modes. Pair with `defensive_roadmap_pct` and `innovation_capacity_pct` — strategic offense requires both intent (this metric) and available bandwidth (innovation capacity). The right number is stage-, market-, and strategy-dependent — the trend and the stated rationale matter more than the absolute level.", "relatedKpiIds": [ "product.defensive_roadmap_pct", "product.innovation_capacity_pct", "product.portfolio_strategy", "product.feature_adoption", "product.key_initiatives_status" ], "calculationPolicy": { "inclusionRules": [ "Share of PLANNED roadmap capacity (typically the next 1–2 quarters) allocated to offensive bets — net-new capabilities, market expansion, differentiation moats, new monetization.", "Denominator is total planned roadmap capacity for the same horizon, measured in the same unit as the other two slices (eng-weeks, story points, or sprint capacity).", "Classify each roadmap item to exactly ONE of the three intent slices (offensive / defensive / commitments) so they are mutually exclusive." ], "exclusionRules": [ "Table-stakes parity / reliability / security / scalability work — that is `product.defensive_roadmap_pct`.", "Contractually or relationship-committed deliverables — that is `product.commitments_roadmap_pct`.", "\"Improvements to existing features\" that are really parity work — do not misclassify as offensive.", "The new-features / maintenance / tech-debt work-type split — that is the separate `product.capacity_allocation_pct` partition with a different denominator (all engineering capacity, not roadmap capacity)." ], "requiredInputs": [ "Roadmap item list for the horizon, each classified offensive / defensive / commitments.", "A capacity estimate per item in a single consistent unit.", "The horizon definition (which quarters the plan covers)." ], "dataSourcePriority": [ "Product / roadmap planning tool with per-item capacity and a strategic-intent tag.", "PM + engineering classification when the tool does not tag intent.", "Board strategy narrative as a consistency check on the offensive share." ], "edgeCases": [ "A single item spanning offense and defense (e.g. a re-platform that also ships a new capability): split its capacity across slices rather than forcing one label.", "Re-baselining mid-horizon: recompute all three slices together so they still sum to 100%.", "Unclassified backlog: do not silently drop it from the denominator — classify it or exclude it explicitly." ], "validationChecks": [ "`product.offensive_roadmap_pct` + `product.defensive_roadmap_pct` + `product.commitments_roadmap_pct` must sum to ~100% over a fully-classified roadmap (the three are a mutually-exclusive partition of one denominator) — a sum materially off 100% means items are unclassified or double-counted.", "Check the offensive share against the stated strategy: a company \"going on offense\" while showing a 30% offensive roadmap has a story-vs-execution gap worth flagging.", "This roadmap-intent partition is distinct from the `product.capacity_allocation_pct` work-type partition — do not expect the two to reconcile to each other." ], "commonMiscomputations": [ "Counting parity / table-stakes work as offensive — inflates the growth narrative.", "Mixing the roadmap-intent denominator with the capacity-allocation (new-features / maintenance / tech-debt) denominator.", "Leaving backlog unclassified so the three slices do not sum to 100%." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.portfolio", "slug": "portfolio", "domain": "product", "defaultLabel": "Product Portfolio", "description": "Container handle for the field-array of products in the portfolio — each entry tracks the product name, its portfolio classification (e.g. growth engine / cash cow / innovation bet / sunset candidate, or Horizon 1/2/3), ARR contribution, investment thesis, and lifecycle stage. The structured, per-product companion to the `product.portfolio_strategy` narrative: the narrative tells the story, this gallery makes each product line individually visible and trackable. Renders via the CollapsibleFormItemCardGallery widget (the reused gallery pattern shared with sales pipeline deals and HR key hires / openings). Common pitfall: a portfolio gallery that lists products without an explicit classification or investment thesis per item — that is an inventory, not a portfolio.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — field-array of product items (name, classification, ARR contribution, investment thesis, lifecycle stage). No aggregate calculation; the surface makes each material product line individually visible and classifiable at the board level.", "whyItMatters": "Forces explicit, per-product classification — boards offer better strategic guidance when every material product line is named with its game (growth / cash / option-value / sunset) rather than buried in a single narrative. Surfaces whether the company has a real portfolio or a list of products it happens to ship.", "interpretationGuidance": "Read alongside the `product.portfolio_strategy` narrative and `product.top_product_arr_concentration` — heavy ARR concentration in one item without an explicit diversification thesis on the others is a strategic risk the board should name. A portfolio with every item classified as a \"growth engine\" is a wishlist; expect at least some cash cows and explicit sunset candidates in a maturing company.", "relatedKpiIds": [ "product.portfolio_strategy", "product.top_product_arr_concentration", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "sales.arr" ] }, { "rogueId": "product.portfolio_strategy", "slug": "portfolio_strategy", "domain": "product", "defaultLabel": "Product Portfolio Strategy", "description": "Narrative overview of the product portfolio — which products are growth engines, which are cash cows, which are innovation bets, and which are candidates for sunset. The CEO/CPO articulation of \"what game each product line is playing.\" Frequently structured along the McKinsey Three Horizons framing or the classic BCG growth-share matrix (stars / cash cows / question marks / dogs — per Bruce Henderson's \"The Product Portfolio\", 1970). Common pitfall: the portfolio narrative does not name horizons, life-cycle stages, or sunset candidates — a portfolio described entirely as \"growth engines\" is not a portfolio strategy, it is a wishlist. Boards should push for explicit classification of every material product.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Narrative — no calculation. Should cover (1) classification of each material product (e.g. Horizon 1/2/3 or BCG matrix quadrant), (2) ARR concentration by product, (3) investment thesis per product, (4) any sunset candidates and timing, (5) cross-product synergies or cannibalization risks.", "whyItMatters": "Forces explicit articulation of the multi-product story — boards offer better strategic guidance when they understand which product is being optimized for growth vs cash vs option-value. Reveals whether the company has a portfolio strategy or just a list of products it happens to ship.", "interpretationGuidance": "A portfolio narrative that has not evolved across multiple quarterly updates while the market has shifted is a flag — the strategy is either uncontested or unmonitored. A narrative that pivots every update is also a flag — typically signals over-reactivity. Compare against `top_product_arr_concentration` — heavy concentration without an explicit portfolio-diversification thesis is a strategic risk the board should name.", "relatedKpiIds": [ "product.top_product_arr_concentration", "product.offensive_roadmap_pct", "product.defensive_roadmap_pct", "product.key_initiatives_status", "sales.arr" ] }, { "rogueId": "product.quality_churn_pct", "slug": "quality_churn_pct", "domain": "product", "defaultLabel": "Churn from Quality Issues", "description": "Percentage of customer churn (logo or ARR, define explicitly) where the primary stated reason is product or quality problems — bugs, performance, missing core functionality, reliability incidents. Distinguishes product-driven churn from pricing-driven, competitor-driven, or use-case-fit-driven churn. Common pitfall: relying on free-text exit-survey reasons. Customers commonly cite \"price\" when the underlying issue was reliability or missing features — boards should require both the customer-stated reason and the CSM/Account-Manager-assigned root cause, and watch the gap. The Pendo \"Product-Led Growth Benchmark\" and similar product-analytics publishers cover product-driven churn qualitatively, not as published numeric ranges.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "Product" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "benchmark": { "p25": 5, "median": 10, "p75": 20, "unit": "%", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": false }, "formula": "quality_churn_pct = (churn_attributable_to_quality / total_churn) × 100. Be explicit about whether the numerator and denominator are logo-churn or ARR-churn; the two can diverge sharply if quality issues hit small-customer vs strategic-account differently. Define \"attributable to quality\" explicitly (CSM root-cause assignment is more reliable than customer-stated exit reason).", "whyItMatters": "Isolates the share of revenue loss the R&D organization can directly act on. High and rising quality-churn is the loudest signal that engineering investment should shift from new-feature to platform-hardening. Low quality-churn alongside high overall churn signals the problem is GTM or product-market-fit, not engineering.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: at healthy growth-stage SaaS, quality-driven churn is typically a minority of total churn (under one-third). Quality-churn rising past 40% of total churn is a strong \"harden the platform\" signal — the board should expect a `defensive_roadmap_pct` increase in response. Cross-reference with `scalability_headroom`: a thin headroom paired with rising quality-churn usually means the company is hitting a reliability cliff.", "relatedKpiIds": [ "product.feature_adoption", "product.defensive_roadmap_pct", "product.scalability_headroom", "customers.logo_churn_rate", "customers.gross_revenue_retention" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "product.rd_efficiency", "slug": "rd_efficiency", "domain": "product", "defaultLabel": "R&D Efficiency", "description": "Ratio of net-new ARR generated in a period to R&D spend in the same period — answers \"how much revenue does each R&D dollar produce?\" Distinct from sales-efficiency metrics (Magic Number, CAC payback) which measure sales/marketing productivity. Common pitfall: R&D-driven ARR (new capabilities, expansion features) shows up on a 2–4 quarter lag after the spend — single-period ratios mis-state the relationship. Boards should look at trailing-twelve-month R&D efficiency, not month-over-month, and pair with `innovation_capacity_pct` to understand whether the spend is on growth bets or maintenance.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "benchmark": { "p25": 0.15, "median": 0.27, "p75": 0.4, "unit": "ratio", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "rd_efficiency = net_new_arr_in_period / rd_monthly_spend_in_period. Best computed on a trailing-twelve-month basis to absorb the spend-to-revenue lag. Note: not the same as \"R&D ROI\" (which would deduct R&D cost from revenue); this is a velocity ratio, not a profitability ratio.", "whyItMatters": "Highest-leverage indicator of whether R&D investment is converting into revenue. A persistent decline signals either an over-built team relative to demand, a feature-product fit gap, or accumulated tech debt slowing throughput — each prescribes different board action.", "interpretationGuidance": "No single published benchmark applies across stages and business models. Industry folk-wisdom, not citation-grade: at growth-stage SaaS, $1 of R&D spend producing $1–2 of net-new ARR is healthy; below $0.5 is a flag; above $3 typically signals either underinvestment in R&D (about to hit a velocity wall) or a one-time price-increase boost. Always pair with `quality_churn_pct` — high efficiency with rising quality-churn means the ratio is borrowing from future periods.", "relatedKpiIds": [ "product.rd_monthly_spend", "product.total_engineers", "product.innovation_capacity_pct", "product.quality_churn_pct", "sales.arr" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "product.rd_monthly_spend", "slug": "rd_monthly_spend", "domain": "product", "defaultLabel": "R&D Monthly Spend", "description": "Total monthly cash outflow on research and development — fully-loaded engineering, product, and design payroll plus tooling, infrastructure dedicated to product development, contractors, and direct R&D vendor spend. The \"input\" side of R&D efficiency. Common pitfall: companies report base-payroll R&D and exclude the loaded cost (benefits, stock comp at cash-cost basis, allocated rent, dev tooling), under-reporting true R&D burn by 25–40%. Boards should always ask whether the number is base-payroll, fully-loaded, or GAAP R&D expense — they tell different stories. The KBCM/Sapphire SaaS Survey reports R&D as a percentage of revenue for its company panel — use that as the benchmarking lens.", "fieldType": "currency", "unit": "/month", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "R&D as % of Revenue (capital-allocation section)", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "formula": "Sum of fully-loaded R&D-team payroll + benefits + allocated stock-comp + R&D-dedicated infrastructure + R&D tooling + R&D vendor spend, expressed as a monthly figure. Different from GAAP R&D expense (which capitalizes some software development costs); footnote the convention.", "whyItMatters": "Largest single line of operating spend at most growth-stage SaaS companies — the input that `rd_efficiency` converts into revenue. The board reads this to gauge whether the company is over- or under-investing in product velocity relative to revenue ramp.", "interpretationGuidance": "Compare R&D spend to revenue (or ARR run-rate) to derive R&D-as-% of revenue. Per the KBCM/Sapphire SaaS Survey (latest annual edition — see capital-allocation section), median R&D-as-% of revenue runs ~25–35% at early-growth SaaS and compresses with scale. Out-of-band (e.g. 60%+ at a $20M ARR company) usually signals either heavy platform-investment cycles or under-monetization — flag for context. Always pull the current KBCM/Sapphire edition rather than relying on a memorized range.", "relatedKpiIds": [ "product.rd_efficiency", "product.total_engineers", "product.innovation_capacity_pct", "sales.arr", "finance.net_burn_rate" ], "calculationPolicy": { "inclusionRules": [ "Fully-loaded R&D-team compensation (salary + employer taxes + benefits + cash-basis stock-comp) for engineering, data, QA, DevOps, and the product/design staff building the product, expressed as a monthly figure.", "R&D-dedicated infrastructure and development / CI tooling, plus direct R&D vendor spend and R&D contractors / dev shops.", "Express as a per-month cash outflow: for multi-month source data, divide by the months in the period and state the smoothing window (a trailing-3-month average is common to dampen lumpiness)." ], "exclusionRules": [ "Production cloud / hosting that serves customers — that is COGS (`finance.cloud_hosting`), not R&D infrastructure.", "Sales, marketing, customer-success, and G&A payroll and tooling — only product-building functions count toward R&D.", "GAAP-capitalized software-development labor when the company capitalizes — footnote the convention; capitalized cost is not the cash R&D burn this KPI tracks.", "Non-cash equity expense beyond the cash-cost basis already included — this is a cash view." ], "requiredInputs": [ "Fully-loaded R&D payroll by person / department.", "R&D-dedicated infrastructure + tooling + vendor + contractor spend for the period.", "Period length, to normalize to a monthly figure.", "The reporting convention flag: base-payroll vs fully-loaded vs GAAP-R&D expense." ], "dataSourcePriority": [ "Finance / FP&A general-ledger R&D cost-center roll-up — the authoritative spend source.", "Payroll system grouped by R&D department, plus AP detail for tooling / vendor / contractor spend.", "Engineering-leadership estimate only when GL cost-centers do not cleanly isolate R&D — flag the lower confidence." ], "edgeCases": [ "An engineer split between R&D and customer-support / COGS work: allocate by time, not by whole headcount.", "Capitalized vs expensed development cost: pick one convention (cash R&D burn here) and footnote it; do not mix a capitalized figure into a cash-burn series.", "Lumpy annual tooling / vendor prepayments: amortize across the months they cover rather than spiking a single month." ], "validationChecks": [ "This is the SAME underlying R&D spend as the finance roll-up `finance.total_rnd` (which aggregates `finance.rd_payroll` + `finance.product_design_payroll` + `finance.rd_tools_software` + the R&D share of `finance.contractors_outsourcing`) — `product.rd_monthly_spend` is the product-view, `finance.total_rnd` the finance-view, of one number. Reconcile them to within a small variance and NEVER add the two (or add `rd_monthly_spend` to any `finance.rd_*` component), or R&D spend silently double-counts.", "R&D-as-% of revenue (rd_monthly_spend × period ÷ revenue) should sit in the KBCM/Sapphire band for the stage (~25–35% at early-growth SaaS, compressing with scale); out-of-band is a context flag, not a story.", "Step-changes should map to hiring, comp true-ups, or a tooling purchase — an unexplained jump usually signals a cost-center reclassification." ], "commonMiscomputations": [ "Reporting base payroll instead of fully-loaded cost — under-reports true R&D burn by 25–40%.", "Summing `product.rd_monthly_spend` and `finance.total_rnd` (or its components) as if additive — they are two views of the same spend; this double-counts R&D.", "Folding production cloud-hosting COGS into R&D infrastructure — inflates R&D and understates gross margin.", "Mixing a GAAP-capitalized R&D figure into a cash-burn series — the two diverge by the capitalized-labor amount." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "primary" } }, { "rogueId": "product.scalability_headroom", "slug": "scalability_headroom", "domain": "product", "defaultLabel": "Time to Capacity Limit", "description": "Months of system capacity remaining at the current growth rate before the platform requires major (not incremental) infrastructure investment — typically driven by the binding bottleneck (database, message bus, single-tenant compute ceiling, regional capacity, or compliance-driven re-architecture). Surfaces the \"scale runway\" alongside the financial runway. Common pitfall: a single number hides which bottleneck binds. Boards should require the bottleneck to be named (\"database shard hot-spot binds at ~150K accounts at current growth, ~4 months out\"), not just the headline months — a named bottleneck makes the investment decision concrete.", "fieldType": "number", "unit": "months", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "benchmark": { "p25": 4, "median": 9, "p75": 18, "unit": "months", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": true }, "formula": "Engineering-attested estimate: months_until_binding_bottleneck_at_current_growth_rate. Recompute when growth-rate assumption changes or when capacity work lands. Always surface the binding bottleneck name alongside the months number — `12 months (database write throughput)` not just `12`.", "whyItMatters": "Sequences major infrastructure work against revenue growth. A 6-month scalability headroom against a 9-month financial runway is a foreseeable crisis the board should be addressing now. Pairs naturally with `defensive_roadmap_pct` (which funds the work).", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: 12+ months of headroom is comfortable; 6–12 months means the rearchitecture project should be in flight; under 6 months means the project is critical-path and may already be late. Compare against `finance.runway_months` — financial runway shorter than scalability headroom means the company will hit the cash wall first; the inverse means the company will hit the scale wall first and should be planning the rearchitecture into the current operating plan.", "relatedKpiIds": [ "product.defensive_roadmap_pct", "product.capacity_allocation_pct", "product.quality_churn_pct", "finance.runway_months", "sales.growth_rate_yoy" ], "calculationPolicy": { "inclusionRules": [ "Engineering-attested estimate of the MONTHS of system capacity remaining at the current growth rate before the platform requires MAJOR (not incremental) infrastructure investment.", "Driven by the single binding bottleneck (database shard / write throughput, message bus, single-tenant compute ceiling, regional capacity, compliance-driven re-architecture) — name the bottleneck alongside the months number.", "Keep the growth-rate assumption explicit; recompute when the growth assumption changes or when capacity work lands." ], "exclusionRules": [ "Incremental / auto-scaling capacity the current architecture absorbs without a re-architecture project — that is not the binding constraint this KPI measures.", "Cost headroom or budget runway — this is a technical-capacity horizon, not a financial one (`finance.runway_months`).", "Hypothetical bottlenecks not on the current growth path — surface only the binding one." ], "requiredInputs": [ "The current growth-rate assumption (the denominator of the runway).", "The binding bottleneck and its capacity ceiling at current load.", "Engineering's estimate of months to that ceiling at the stated growth rate." ], "dataSourcePriority": [ "Engineering / infrastructure leadership capacity model and load projections.", "Observability / capacity-monitoring data (saturation trend on the binding resource).", "Prior re-architecture project timelines as a sanity check on the \"major investment\" lead time." ], "edgeCases": [ "Multiple plausible bottlenecks: report the nearest binding one and note the next — do not average them into a blended number.", "A capacity project lands mid-period: recompute the months and re-name the new binding bottleneck.", "Growth-rate assumption change: restate the headroom rather than holding a stale months number." ], "validationChecks": [ "Compare against `finance.runway_months`: financial runway shorter than scalability headroom means the cash wall binds first; the inverse means the scale wall binds first and the rearchitecture belongs in the current operating plan.", "Thin headroom paired with rising `product.quality_churn_pct` usually means the company is already hitting a reliability cliff — cross-check the two.", "A months number with no named binding bottleneck is unverifiable — treat an unnamed estimate as not yet attested." ], "commonMiscomputations": [ "Reporting a headline months number with no named binding bottleneck — makes the investment decision impossible to act on.", "Confusing scalability headroom (technical capacity) with financial runway (`finance.runway_months`) — they answer different questions.", "Holding a stale estimate after the growth-rate assumption or a capacity project changed." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "product.top_product_arr_concentration", "slug": "top_product_arr_concentration", "domain": "product", "defaultLabel": "Top Product ARR Concentration", "description": "Percentage of total ARR contributed by the single largest product line. Diversification-risk indicator at the product level (parallel to customer-concentration risk at the GTM level). Common pitfall: concentration risk is dismissed when the dominant product is performing well — but a one-product company is a one-feature-decision-away from existential risk. Boards should track this number alongside the portfolio narrative; sustained 70%+ concentration in a maturing company should pair with a documented diversification thesis or an explicit decision to remain a single-product company. Frames analogous to customer-concentration discussions in venture diligence (NfX / Bessemer founder essays cover the customer-side; the product-side analogue follows the same logic).", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Product", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "top_product_arr_concentration_pct = (arr_from_largest_product / total_arr) × 100. Define \"product\" explicitly — a SKU, a billable module, or a packaging unit — and hold the definition stable. Surface both the percentage and the named top product.", "whyItMatters": "Quantifies single-point-of-failure risk in the product portfolio. The board reads this alongside `portfolio_strategy` to assess whether the company has a real second product or is effectively still single-SKU. Drives both strategic (build / buy / partner for diversification) and financial (valuation framing) conversations.", "interpretationGuidance": "Industry folk-wisdom, not citation-grade: concentration of 60–80% in the flagship product is common at early-growth multi-product SaaS; sustained 90%+ should be paired with an explicit single-product-strategy thesis or a documented diversification plan. The trend matters most — concentration falling from 95% to 70% over 4–6 quarters signals successful diversification; rising concentration during a multi-product strategy is a flag the secondary products are underperforming.", "relatedKpiIds": [ "product.portfolio_strategy", "product.offensive_roadmap_pct", "sales.arr", "customers.gross_revenue_retention" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "product.total_engineers", "slug": "total_engineers", "domain": "product", "defaultLabel": "Total Engineers", "description": "Headcount of engineers (software, infrastructure, security, data, ML) in the R&D organization, typically including full-time employees plus contractors at a defined FTE-equivalence factor. The \"capacity input\" side of all R&D ratios. Common pitfall: definition drift. Some companies include only software engineers, others include product managers and designers, others include all of R&D plus QA, plus support engineers. Boards should anchor the definition once and hold it stable — otherwise quarter-over-quarter comparisons are noise. Pair with `rd_monthly_spend` to derive fully-loaded cost-per-engineer.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "R&D" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Count of engineering headcount (FTE + contractor FTE-equivalence). Define inclusion explicitly: SWE-only vs SWE+PM+Design vs all-of-R&D-including-QA. Hold the definition stable across quarters; surface the definition in a footnote.", "whyItMatters": "Capacity denominator for every R&D ratio — `rd_efficiency`, ARR-per-engineer, cost-per-engineer, throughput-per-engineer. The board reads this to gauge whether team growth is keeping pace with revenue and product-surface-area growth.", "interpretationGuidance": "No single benchmark; the right number depends on product complexity, business model, and platform vs. point-solution architecture. The SaaS Capital Annual Survey reports revenue-per-employee for its private SaaS panel (see revenue-per-employee section of the latest edition) — pair `total_engineers` with company-wide headcount and ARR to derive both engineer-density (engineers ÷ total headcount) and ARR-per-engineer. Industry folk-wisdom, not citation-grade: engineer density of 25–40% is typical at product-led growth-stage SaaS; lower at sales-led, higher at infrastructure / platform companies.", "relatedKpiIds": [ "product.rd_monthly_spend", "product.rd_efficiency", "product.capacity_allocation_pct", "product.innovation_capacity_pct", "hr.arr_per_fte" ], "calculationPolicy": { "inclusionRules": [ "Count of engineering headcount (software, infrastructure, security, data, ML) in the R&D org AS OF the period-end snapshot date — a point-in-time read.", "Include contractors at a defined FTE-equivalence factor when the board definition includes them; state the factor explicitly.", "Pin the inclusion boundary once (SWE-only vs SWE + PM + Design vs all-of-R&D-including-QA) and hold it stable across quarters; surface the definition in a footnote." ], "exclusionRules": [ "Non-engineering R&D staff (PMs, designers, QA) when the adopted boundary is SWE-only — exclude per the chosen definition, consistently.", "Open (unfilled) engineering requisitions — those are `product.*` hiring plan / `hr.open_positions`, not current capacity.", "Accepted-but-not-started offers — they join the count on their actual start date.", "Engineers whose last day fell on or before the snapshot date." ], "requiredInputs": [ "Engineering roster as of the snapshot date with employment type (FTE vs contractor) and FTE fraction per person.", "The board-adopted inclusion boundary and the contractor FTE-equivalence factor.", "Department / function attribution if the board reads engineer density by team." ], "dataSourcePriority": [ "HRIS active-employee report at period close, filtered to the R&D org.", "Engineering-leadership org chart as a cross-check on the inclusion boundary.", "Payroll / contractor ledger to confirm contractor FTE-equivalents are counted consistently." ], "edgeCases": [ "Part-time / job-share engineers: convert to FTE fraction — two 0.5 FTEs are 1.0, not 2.0.", "A definition change (e.g. starting to include QA): re-baseline the whole series rather than creating a phantom step.", "Contractor-to-employee conversion mid-period: count the person once, on the basis in effect at the snapshot date." ], "validationChecks": [ "Should move in step with the R&D share of `hr.total_headcount`; an engineer count exceeding total R&D headcount means contractors or a wider boundary crept in.", "Pair with `product.rd_monthly_spend` to derive fully-loaded cost-per-engineer — an out-of-band cost-per-engineer flags a counting or spend-classification error.", "Engineer density (engineers ÷ total company headcount) far outside ~25–40% for a product-led SaaS is a context flag, not necessarily an error." ], "commonMiscomputations": [ "Definition drift quarter-over-quarter (SWE-only one period, all-of-R&D the next) — turns the comparison into noise.", "Counting contractors as whole heads instead of FTE-equivalents — overstates capacity.", "Counting open reqs or accepted-but-not-started offers as current engineers." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "sales.arr", "slug": "arr", "domain": "sales", "defaultLabel": "ARR", "description": "Annual Recurring Revenue — the value of all recurring subscription revenue normalized to a one-year run-rate as of the period close. The headline operating metric for a subscription business; every growth and efficiency ratio (NRR, GRR, magic number, CAC payback, Rule of 40) is calibrated against it. Excludes one-time fees, professional services, and non-contractual usage. Common pitfall: confusing ARR (contracted recurring) with revenue (recognized) or with CARR (contracted incl. not-yet-live) — the SMSB standard draws sharp lines between them, and boards expect the same discipline. The KpiVarianceTable widget surfaces forecast / actual / variance / status / future-forecast columns against the same field.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/annual-recurring-revenue", "sectionRef": "ARR", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "ARR = Sum of annualized value of all active recurring subscription contracts at period close. Per SMSB: includes only the recurring portion of contracts that are live (delivered / in production). Excludes one-time fees, professional services, and usage that is not contractually committed. For multi-year contracts, ARR is the contract value divided by the term in years.", "whyItMatters": "Headline operating number that every other SaaS metric calibrates against — growth rate, efficiency ratios (CAC ratio, magic number, Rule of 40), retention math (NRR, GRR), and valuation multiples all read off ARR. Boards use the period-over-period ARR delta as the first-pass health check for the business.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Growth Rate, public-SaaS-comparable private companies in the $5–25M ARR band typically grow ARR 40–60% YoY, falling toward 20–30% by $100M+ ARR; well-below-band growth at any ARR scale is the first thing a board interrogates. Always read ARR alongside Net New ARR (sales.new_business + sales.expansion − sales.churn_arr − sales.downgrades) — flat ARR can mask churn offset by upsell.", "relatedKpiIds": [ "sales.carr", "sales.new_business", "sales.expansion", "sales.churn_arr", "sales.downgrades", "sales.growth_rate_yoy", "sales.starting_arr", "customers.net_revenue_retention", "operations.rule_of_40" ], "calculationPolicy": { "inclusionRules": [ "Recurring revenue from contracts that are live / delivered / in production at the period close.", "Annualized value of multi-year contracts is the contract value divided by the term in years (not first-year ARR, not back-loaded).", "Contractually committed usage minimums count as recurring (the floor, not the expected overage)." ], "exclusionRules": [ "One-time fees: setup, implementation, onboarding, professional services, training — even when invoiced on a recurring cadence.", "Non-committed usage / overage revenue (only contractual minimums count).", "Signed contracts not yet live (those belong in CARR; promote to ARR on go-live).", "Recognized revenue, invoiced revenue, or bookings — ARR is contracted-recurring run-rate, not any of those." ], "requiredInputs": [ "Contract status (live / signed-not-live / churned).", "Contract value (annualized, multi-year divided by term).", "Contract start date and term length (months or years).", "Recurring-vs-one-time flag per line item (or per contract if line items are not modeled)." ], "dataSourcePriority": [ "CRM contract / subscription system with explicit go-live status (Salesforce, HubSpot Subscription Module, Zuora, Chargebee).", "Billing system as a fallback when contract status is not modeled — but verify against the contract data, since billing can run ahead of go-live.", "Spreadsheet exports: only when nothing else exists; flag uncertainty in the output." ], "edgeCases": [ "Partial-month or mid-period starts: prorate or use end-of-period contract value, but be consistent across the time series.", "Contract amendments (price changes, term extensions): re-annualize from the amendment date; do not back-fill prior periods.", "Pauses / suspensions: treat as churn unless contract is held open with go-live SLA — flag the ambiguity in any output.", "Multi-currency: normalize to a single reporting currency at a stable FX rate (period-end or a documented fixed rate); never mix.", "Ramp contracts (escalating annual fees): use the contractually committed annual value for the period, not the average over the ramp." ], "validationChecks": [ "Ending ARR ≈ Starting ARR + New Business + Expansion − Downgrades − Churn ARR — if the waterfall does not reconcile to within 1%, the underlying components are misclassified.", "ARR ≤ total contracted value across all live contracts.", "Year-over-year growth rate sits within the KBCM/Sapphire band for the ARR scale; out-of-band growth in either direction is a calculation red flag, not a story." ], "commonMiscomputations": [ "ARR-vs-CARR confusion: including signed-but-not-yet-live contracts inflates ARR and contradicts the SMSB definition. If unsure, report both ARR and CARR separately and let the reader pick.", "Recognized revenue × 12 or × 4: this is run-rate revenue, not ARR. The two diverge when service revenue is recognized at a different cadence than subscription value.", "MRR × 12 only matches ARR when MRR itself is calculated from contracted recurring (not from invoiced or recognized revenue) — verify upstream.", "Counting expansion or renewal ARR in the \"new business\" line — inflates the acquisition motion and hides a stalled new-logo engine.", "Mixing fiscal-year-end ARR and period-end ARR in the same chart: always pin to one snapshot definition per series." ], "inclusionRulesStructured": [ { "rule": "Include rows whose normalized status is \"live\" (delivered / in production at period close).", "mutability": "invariant", "provenance": "imboard-authored" }, { "rule": "Monthly intervals annualize × 12; annual taken as stated; multi-year = contract value ÷ term in years.", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" } ], "exclusionRulesStructured": [ { "rule": "Exclude rows with current_period_start in the future (signed-not-yet-live belongs in CARR).", "mutability": "invariant", "provenance": "imboard-authored" }, { "rule": "Exclude one-time fees and non-committed usage / overage (only contractual minimums count).", "mutability": "invariant", "provenance": "anchor-derived", "sourceId": "smsb-v1" }, { "rule": "Treatment of \"paused\" / suspended subscriptions.", "mutability": "company-defined", "provenance": "imboard-authored", "default": "excluded" } ], "validationAssertions": [ { "assert": "result >= 0", "severity": "error", "message": "ARR cannot be negative — recurring contracted revenue is a non-negative quantity." } ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "computed" }, "inputContract": { "fields": [ { "name": "contract_status", "type": "enum", "required": true, "description": "Canonical contract lifecycle the metric reasons about.", "values": [ "live", "signed_not_live", "churned" ] }, { "name": "subscription_status", "type": "enum", "required": false, "description": "Raw billing-system status (Stripe-style), normalized onto the inclusion concept.", "values": [ "active", "past_due", "trialing", "canceled", "paused" ], "normalizationMap": { "active": "live", "past_due": "at_risk", "trialing": "excluded", "canceled": "excluded", "paused": "policy" } }, { "name": "billing_interval", "type": "enum", "required": true, "description": "Monthly intervals annualize × 12; annual taken as stated.", "values": [ "month", "year" ] }, { "name": "amount", "type": "currency", "required": true, "description": "Recurring contract amount in the billing interval." }, { "name": "contract_term_months", "type": "number", "required": false, "description": "For multi-year contracts: ARR = contract value ÷ term in years." }, { "name": "current_period_start", "type": "date", "required": true, "description": "Rows with a start date in the future are excluded." } ] }, "dependencies": [ { "kpi": "sales.starting_arr", "edge": "computesFrom" }, { "kpi": "sales.new_business", "edge": "computesFrom" }, { "kpi": "sales.expansion", "edge": "computesFrom" }, { "kpi": "sales.churn_arr", "edge": "computesFrom" }, { "kpi": "sales.carr", "edge": "validatesAgainst" } ] }, { "rogueId": "sales.average_deal_size", "slug": "average_deal_size", "domain": "sales", "defaultLabel": "Average Deal Size", "description": "Mean dollar value across active pipeline opportunities (Pipeline Value / Pipeline Deal Count). Distinct from sales.avg_contract_value (ACV) which measures closed-won deals — average_deal_size is forward-looking pipeline-shape, ACV is realized output. Common pitfall: a few oversized deals materially skew the average — always inspect median_deal_size alongside; a large gap between average and median signals a few mega-deals that drive most of the projected number, which concentrates pipeline risk.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Average Deal Size = Pipeline Value / Pipeline Deal Count. Same value convention (TCV or ACV) as the upstream metrics. Always report alongside Median Deal Size for skew detection.", "whyItMatters": "Forward-looking signal for ACV mix-shift before it appears in closed-won numbers — pipeline-size trending up usually shows up in closed-won-size 1–2 cycles later. Boards use the lead-time to ask \"is this an intentional up-market move or a mix drift to correct?\"", "interpretationGuidance": "Track the spread (average − median) over time: stable, narrow spread = healthy uniform pipeline; widening spread = increasing concentration risk in a few oversized deals (those deals slipping then becomes catastrophic to the period). Average rising faster than median = up-market mix-shift in pipeline.", "relatedKpiIds": [ "sales.median_deal_size", "sales.pipeline_value", "sales.pipeline_deal_count", "sales.avg_contract_value", "sales.closed_won_value" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.avg_contract_value", "slug": "avg_contract_value", "domain": "sales", "defaultLabel": "Average Contract Value", "description": "Average annualized contract value across new-customer deals signed during the period (ACV). Defines where the company plays on the SaaS deal-size spectrum and dictates the operating model — high-ACV businesses tolerate longer sales cycles and direct sales motions; low-ACV businesses must run product-led or inside-sales motions to keep CAC payback short. Common pitfall: blending new and expansion ACV obscures the new-logo deal-size trend that boards actually want to see. Anchored to KBCM/Sapphire SaaS Survey 2024 §Average Contract Value for cross-company benchmarking.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "Average Contract Value", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 25000, "median": 62000, "p75": 100000, "unit": "$", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "Average Contract Value = New Business ARR / New Customers Added (for the same period). For multi-year contracts, use the annualized ACV (TCV / contract term in years), not Total Contract Value (TCV). Restrict to new-logo deals to keep the trend interpretable; track Expansion ACV separately if material.", "whyItMatters": "Sets the cost ceiling for the sales motion — at $5k ACV the company cannot afford a field sales team; at $250k ACV inside sales alone usually leaves money on the table. The board uses ACV trend to validate up-market or down-market strategy bets.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Average Contract Value, segmentation bands: SMB ≤ $5k, Mid-Market $5k–$50k, Enterprise > $50k (often $100k+ for true enterprise). ACV doubling over four quarters is a clear up-market motion — make sure CAC and sales-cycle changes are reflected in plan. Flat ACV with rising volume = scaling the existing motion; rising ACV with flat volume = a deliberate up-market bet that needs explicit board buy-in.", "relatedKpiIds": [ "sales.new_business", "sales.new_customers_added", "sales.median_deal_size", "sales.average_deal_size", "sales.avg_sales_cycle_days", "sales.cac" ], "calculationPolicy": { "inclusionRules": [ "Numerator: `sales.new_business` (annualized new-logo ARR for the period).", "Denominator: `sales.new_customers_added` (count of new logos in the same period, using the same logo unit).", "Result is annualized — for multi-year contracts use annualized contract value, not TCV." ], "exclusionRules": [ "Expansion ARR in the numerator — that produces Expansion ACV, a different metric. Track separately if material.", "Existing customers in the denominator — same reason.", "Pilots / unpaid trials." ], "requiredInputs": [ "New Business ARR for the period.", "New Customers Added for the period (matching logo unit and same period)." ], "dataSourcePriority": [ "Same CRM source as `sales.new_business` and `sales.new_customers_added` — they must come from the same record set." ], "edgeCases": [ "Single very large enterprise deal: pulls ACV up dramatically. Surface alongside median deal size to spot when one mega-deal is masking the underlying distribution.", "Mid-period logo-unit change: ACV becomes meaningless across the boundary. Keep methodology pinned and back-cast on change.", "Multi-year contracts with ramp pricing: use Year 1 annualized value for the numerator (matches the New Business ARR convention)." ], "validationChecks": [ "ACV = New Business ARR / New Customers Added — recompute and verify against any pre-computed value.", "ACV should sit within the segmentation band consistent with the company's ICP (SMB ≤ $5k, Mid-market $5k-50k, Enterprise > $50k). Out-of-band ACV signals up- or down-market drift worth a narrative line." ], "commonMiscomputations": [ "Including expansion ARR in the numerator — produces a \"blended ACV\" that boards mis-read as new-logo ACV.", "Counting customers (denominator) using a different logo unit than ARR (numerator) — e.g. counting billing entities for revenue but parent accounts for logos — produces nonsense.", "Using TCV instead of annualized ACV — overstates by the contract term (e.g. a 3-year deal looks 3x as large).", "Reporting a single-deal-pulled ACV without flagging the outlier — leadership reads it as motion improvement when it's one good deal.", "Computing ACV from median deal size when ACV should use the arithmetic mean — these are different metrics (`sales.median_deal_size` exists for the median)." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "production": "computed" } }, { "rogueId": "sales.avg_sales_cycle_days", "slug": "avg_sales_cycle_days", "domain": "sales", "defaultLabel": "Average Sales Cycle (Days)", "description": "Average number of days from opportunity creation to closed-won status — measured only on won deals (lost deals are tracked separately). The motion-velocity metric — directly determines how much pipeline coverage is needed, how quickly investment in new reps pays back, and how feedback loops on packaging or pricing experiments compound. Common pitfall: blending segment cycles (SMB and Enterprise often differ 5–10×) into a single average hides material trend signals — segment-cut the metric where deal-volume permits.", "fieldType": "number", "unit": "days", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "benchmark": { "p25": 40, "median": 84, "p75": 150, "unit": "days", "sourceName": "imboard Editorial", "sourceYear": "2026", "higherIsBetter": false }, "formula": "Average Sales Cycle (Days) = Σ (close_date − created_date) across closed-won opportunities in period / Count of those opportunities. Restrict to won deals; for cycle-time analysis on lost deals, compute separately.", "whyItMatters": "Determines required pipeline coverage (a 90-day cycle needs ~1 quarter of forward pipeline; a 270-day cycle needs ~3 quarters), and is the leading indicator of ICP fit — strong fit shortens cycles; mismatched fit lengthens them.", "interpretationGuidance": "Typical ranges by ACV band (industry folk-wisdom, not citation-grade): SMB < $5k ACV → 14–45 days; Mid-Market $5k–50k → 45–90 days; Enterprise $50k+ → 90–270 days; Strategic > $250k → 180–365+ days. Cycle lengthening trend over 2+ quarters at constant ACV mix is the canonical \"deals stuck in evaluation\" signal — usually buyer-side decision-process changes (procurement, security review) or competitive friction.", "relatedKpiIds": [ "sales.avg_contract_value", "sales.pipeline_stage_metrics", "sales.pipeline_sales_cycle", "sales.win_rate", "sales.pipeline_value" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.base_currency", "slug": "base_currency", "domain": "sales", "defaultLabel": "Sales Base Currency", "description": "The ISO-4217 currency code (e.g. `USD`) the sales/pipeline feed displays its money metrics in. The bespoke sales and pipeline feed cards read this to choose the currency symbol/format; absent it, they fall back to USD. This is a board-level reporting-currency constant rather than a measured metric. Common pitfall: leaving it unset on a non-USD board — the feed then silently renders USD symbols over non-USD figures.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "A single ISO-4217 currency code. Not a calculation — it is the display/reporting currency the feed formats sales money figures in.", "whyItMatters": "Ensures the sales/pipeline feed renders money in the board's actual reporting currency instead of a silent USD default.", "interpretationGuidance": "Should match the board's reporting currency. If FX conversion is applied upstream, this is the post-conversion display currency, not each deal's original currency.", "relatedKpiIds": [ "sales.arr", "sales.pipeline_value" ] }, { "rogueId": "sales.blended_cac_ratio", "slug": "blended_cac_ratio", "domain": "sales", "defaultLabel": "Blended CAC Ratio", "description": "Total fully-loaded S&M spend in the period divided by the dollars of new CARR generated in the period (new-customer + expansion CARR combined). Per the SMSB standard, the headline efficiency ratio for the full sales-and-marketing motion — answers \"how many cents do we spend on S&M to add one dollar of contracted ARR.\" Common pitfall: blending without separately reporting New CAC Ratio and Expansion CAC Ratio hides which side of the motion is driving efficiency — for a healthy SaaS company expansion CAC is usually 3–5× cheaper per dollar than new-logo CAC.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/blended-cac-ratio", "sectionRef": "Blended CAC Ratio", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "Blended CAC Ratio = Total S&M Spend (period) / (New CARR + Expansion CARR generated in period). Per SMSB §Blended CAC Ratio: spend uses the same fully-loaded definition as CAC; CARR-based denominator (not ARR) reflects committed contract value at the point of sign.", "whyItMatters": "The portfolio-level efficiency number — one ratio that summarizes the full S&M engine. Boards use it to track quarter-over-quarter efficiency improvement as the motion matures.", "interpretationGuidance": "Per SMSB convention, a Blended CAC Ratio < 1.0 means the company is acquiring more contracted ARR than it spends on S&M — capital-efficient growth. 1.0–1.5 is acceptable while the motion is scaling; > 2.0 sustained signals either a motion or pricing problem. Always pair with the New and Expansion CAC Ratio split to localize the issue.", "relatedKpiIds": [ "sales.new_cac_ratio", "sales.expansion_cac_ratio", "sales.cac", "sales.cac_payback_period", "sales.new_business", "sales.expansion", "sales.carr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: total fully-loaded S&M spend for the period (same definition as `sales.cac`).", "Denominator: total new CARR generated in the period — new-customer CARR + expansion CARR combined.", "Use CARR (contracted, including signed-not-yet-live) for the denominator, per SMSB convention — it reflects committed value at the point of sign." ], "exclusionRules": [ "R&D / G&A / COGS from the numerator.", "Renewal CARR from the denominator — renewals are not new selling activity.", "Churn / downgrades — this is a gross-efficiency ratio, not a net one." ], "requiredInputs": [ "Fully-loaded S&M spend for the period.", "New-customer CARR for the period.", "Expansion CARR for the period." ], "dataSourcePriority": [ "Financials for S&M spend; CRM for new + expansion CARR, same period boundary." ], "edgeCases": [ "Sales-cycle lag: same consideration as `sales.cac` — for long cycles, consider lagging S&M and disclose.", "A quarter with near-zero new CARR (e.g. seasonal trough) produces an enormous ratio — annualize or use a trailing window for stability, and disclose." ], "validationChecks": [ "Blended CAC Ratio should sit between New CAC Ratio and Expansion CAC Ratio — it is a weighted blend. If it falls outside that range, the spend allocation or the CARR split is wrong.", "A ratio < 1.0 means more contracted ARR added than S&M spent — capital-efficient. Sustained > 2.0 is a motion/pricing problem." ], "commonMiscomputations": [ "Using ARR instead of CARR in the denominator — understates the denominator by the implementation backlog and overstates the ratio.", "Reporting only the blended number without the New / Expansion split — hides which motion is driving (or dragging) efficiency.", "Including renewal CARR in the denominator — renewals cost almost nothing and artificially deflate the ratio.", "Mixing a CARR denominator with an ARR-based New/Expansion split — the three ratios then fail to reconcile." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.bookings_backlog", "slug": "bookings_backlog", "domain": "sales", "defaultLabel": "Bookings Backlog", "description": "Total value of signed contracts that have not yet been recognized as revenue — future revenue locked into the books. Equivalent to \"remaining performance obligation\" (RPO) in public-SaaS disclosures, though private companies often track only the in-period portion. Board reads this as the visibility horizon: a healthy backlog means recognized revenue is largely already-sold and not dependent on Q-end heroics. Common pitfall: confusing backlog with pipeline — backlog is contractually committed, pipeline is unsigned opportunity. Surface the two on the same dashboard but never sum them.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Bookings Backlog = TCV of all signed customer contracts − Revenue already recognized against those contracts. For a SaaS business, the dominant component is unrecognized subscription value on multi-month / multi-year contracts. Most-comparable public-disclosure equivalent: ASC 606 Remaining Performance Obligation (RPO).", "whyItMatters": "The single best read on next-period revenue predictability — high backlog means the revenue line for the coming quarter is largely contractual, not pipeline-dependent. Boards use it to gauge whether the team is selling for in-quarter close or building durable forward visibility.", "interpretationGuidance": "Backlog at year-end ≥ 1.0× the next year's ARR plan is the \"visible year\" threshold most boards expect at Series B+ subscription companies (industry folk-wisdom — no single published standard; the underlying conventions derive from ASC 606 RPO disclosure norms in public-SaaS filings). Backlog declining as a share of forward plan = visibility eroding; usually demands a sales-cycle or pipeline-coverage drill-down.", "relatedKpiIds": [ "sales.bookings_backlog_total", "sales.total_revenue", "sales.arr", "sales.carr", "sales.pipeline_value", "sales.weighted_forecast" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "bookings", "production": "computed" } }, { "rogueId": "sales.bookings_backlog_changes", "slug": "bookings_backlog_changes", "domain": "sales", "defaultLabel": "Bookings Backlog Changes", "description": "Structured bridge that reconciles opening bookings backlog to closing backlog through the period's new bookings, conversions to revenue, post-contract losses, and value adjustments (starting + new − converted − lost + increases − decreases = ending). The bespoke sales card reads this typed object to show the backlog motion. Distinct from the editor's `sales.bookings_backlog_total` FlowSubform container — this is the typed `IBookingsBacklog` the feed card consumes. Common pitfall: an ending value that does not reconcile because conversions to recognized revenue were not netted out.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — { startingBackLogValue, newBookingValue, bookingsConvertedToRevenue, lostBookingsPostContract, backlogValueIncreases, backlogValueDecreases, endingBackLogValue, netChange, netChangePercent }. Identity: starting + new − converted − lost + increases − decreases = ending.", "whyItMatters": "Makes signed-but-not-yet-recognized revenue auditable — a growing backlog is forward revenue visibility; a shrinking one (conversions outpacing new bookings) is an early top-of-funnel warning.", "interpretationGuidance": "When conversions consistently exceed new bookings, the backlog erodes and future recognized revenue will soften. Disproportionate post-contract losses signal delivery or scoping problems.", "relatedKpiIds": [ "sales.bookings_backlog_total", "sales.bookings_backlog", "sales.arr" ] }, { "rogueId": "sales.bookings_backlog_total", "slug": "bookings_backlog_total", "domain": "sales", "defaultLabel": "Bookings Backlog Total", "description": "Total dollar value of all signed contracts that have not yet been recognized as revenue — the visibility window into future revenue at a point in time. Closely related to sales.bookings_backlog; this entry serves as the FlowSubform `start` slot for the per-period bookings-backlog flow (open + new bookings − recognized − cancellations = close). Common pitfall: omitting cancellations from the flow leaves a phantom backlog that overstates future revenue visibility — every backlog flow needs an explicit cancellation line even when zero.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Bookings Backlog Total at period close = Σ TCV of all signed contracts − Σ revenue recognized to date against those contracts. Equivalent to ASC 606 RPO. The per-period flow: opening backlog + new bookings (TCV signed in period) − revenue recognized in period − cancellations = closing backlog.", "whyItMatters": "Quantifies how much of forward revenue is already contracted — high ratios of backlog to forward plan = high revenue predictability. Boards use it to assess whether the business has visibility or is running quarter-to-quarter on pipeline conversion.", "interpretationGuidance": "Backlog at year-end ≥ 1.0× next-year ARR plan is the conventional \"visible year\" benchmark for Series B+ subscription companies (industry folk-wisdom — anchored to public-SaaS RPO disclosure norms but not a published cross-company threshold). Track the cancellation share of the flow — rising cancellations as a % of opening backlog signal contract instability.", "relatedKpiIds": [ "sales.bookings_backlog", "sales.total_revenue", "sales.arr", "sales.carr", "sales.new_business" ], "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "bookings", "production": "computed" } }, { "rogueId": "sales.cac", "slug": "cac", "domain": "sales", "defaultLabel": "Customer Acquisition Cost", "description": "Fully-loaded sales-and-marketing (S&M) expense incurred to acquire one new customer during the period. Per the SMSB standard, the CAC numerator includes salaries + commissions + benefits + travel + marketing programs + tooling — i.e. all S&M costs, not just direct-attribution paid acquisition. The denominator is new logos, not deals. Common pitfall: omitting fully-loaded comp (especially BDR/SDR base salary and CS-team cost-of-sale where they participate in expansion) understates CAC and inflates every downstream efficiency metric. The board cares about CAC alongside CAC Payback and the CAC Ratio family — single-number CAC is a building block, not a verdict.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/customer-acquisition-cost", "sectionRef": "CAC", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "CAC = Total fully-loaded S&M expense for the period / New Customers Added in the period. Per SMSB §CAC: numerator includes all S&M spend (compensation, benefits, programs, tooling, allocated overhead); denominator counts net-new logos only (not expansion deals).", "whyItMatters": "The cost side of the customer-unit economics ledger — paired with ACV and gross margin, determines whether each customer is a profitable transaction over a reasonable horizon. Boards read CAC alongside payback period before debating S&M investment levels.", "interpretationGuidance": "Absolute CAC values vary by ACV band — what matters is the ratio CAC / first-year-ARR (= New CAC Ratio) and CAC Payback. Per public SaaS comps, healthy CAC payback is < 24 months gross-margin-adjusted; > 36 months usually means the acquisition motion is either too expensive or the contract terms too short.", "relatedKpiIds": [ "sales.cac_payback_period", "sales.new_cac_ratio", "sales.blended_cac_ratio", "sales.expansion_cac_ratio", "sales.new_business", "sales.new_customers_added" ], "calculationPolicy": { "inclusionRules": [ "Numerator: total fully-loaded S&M expense for the period — all sales + marketing compensation (base, commission, benefits), marketing programs, sales/marketing tooling, travel, allocated S&M overhead.", "Denominator: count of net-new logos acquired in the same period (`sales.new_customers_added`).", "Result is a per-customer dollar figure." ], "exclusionRules": [ "R&D, G&A, and COGS — CAC is S&M-only.", "Expansion-attributed S&M / CS cost — that belongs in `sales.expansion_cac_ratio`. If AEs do both, allocate by a documented rule.", "Expansion deals in the denominator — count new logos only.", "Stock-based compensation if the company reports cash CAC (disclose which basis is used)." ], "requiredInputs": [ "Fully-loaded S&M expense for the period.", "New logos acquired in the same period.", "If AEs split new vs expansion: the documented allocation rule (e.g. fraction of OTE tied to new-business quota)." ], "dataSourcePriority": [ "Audited or reviewed financials for S&M expense.", "CRM for new-logo count, matched to the same period boundary." ], "edgeCases": [ "CAC-lag: S&M spent this quarter often acquires customers next quarter. For long sales cycles, consider a trailing-spend window (e.g. lag S&M by the average sales-cycle length) and disclose the method.", "Founder-led sales with no formal S&M line: impute a market-rate cost or flag CAC as not-yet-meaningful — never report a near-zero CAC.", "Marketing brand spend that benefits future periods: include it in the period spent; do not capitalize it." ], "validationChecks": [ "CAC is positive.", "CAC ÷ first-year ACV ≈ New CAC Ratio — cross-check the two.", "CAC at a > $5M ARR company that comes out implausibly low (e.g. < $1k for a $30k-ACV product) almost always means S&M is not fully loaded." ], "commonMiscomputations": [ "Omitting fully-loaded comp — especially SDR/BDR base salary, sales-ops, and sales-engineering — understates CAC and inflates every downstream efficiency metric.", "Counting expansion deals in the denominator — makes the new-logo motion look cheaper than it is.", "Using only paid-media spend (\"ad CAC\") and calling it CAC — ignores the much larger people cost.", "Period mismatch: S&M from one period, new logos from another. For long cycles this is defensible only if explicitly lag-adjusted and disclosed.", "Dividing by deal count instead of distinct new logos — multi-deal customers inflate the denominator and understate CAC." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "cash", "production": "computed" } }, { "rogueId": "sales.cac_payback_period", "slug": "cac_payback_period", "domain": "sales", "defaultLabel": "CAC Payback Period", "description": "Number of months required for the gross profit generated from a new customer's ARR to recover the fully-loaded S&M spend used to acquire them. The single most decision-useful efficiency metric at the board level — it directly connects acquisition cost, ACV, and gross margin into one \"how long until we break even on this customer\" answer. Per the SMSB standard, the calculation must use gross-margin-adjusted ARR in the denominator (not raw ARR) to be cross-company comparable. Common pitfall: using raw ARR understates payback by ~25–30 percentage points and breaks comparability with peer benchmarks.", "fieldType": "number", "unit": "months", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/cac-payback-period", "sectionRef": "CAC Payback Period", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "CAC Payback (months) = Total fully-loaded S&M spend (period) / (Monthly New ARR × Gross Margin %). Both numerator and denominator are period aggregates — the numerator is total S&M spend for the period, NOT per-customer CAC (pairing per-customer cost with aggregate new ARR is a dimensional error that yields months-per-customer). The denominator is gross-margin-adjusted total monthly new ARR. Per SMSB §CAC Payback Period: the gross-margin adjustment makes the metric comparable across companies with different cost structures.", "whyItMatters": "The decision-relevant single number for \"is the acquisition motion working\" — sub-24 months signals capital-efficient growth; > 36 months means each dollar of S&M is locking up cash for too long to justify scaling spend.", "interpretationGuidance": "Per the SaaS-investor convention reflected in KBCM/Sapphire SaaS Survey 2024 benchmarking: < 24 months gross-margin-adjusted payback is healthy; 24–36 months is acceptable for early-stage / up-market motions; > 36 months requires either an explicit path to compress (motion change) or a strategic rationale (e.g. multi-year deferred-revenue contracts with strong retention).", "relatedKpiIds": [ "sales.cac", "sales.new_cac_ratio", "sales.blended_cac_ratio", "sales.gross_margin", "sales.new_business", "sales.arr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: total fully-loaded S&M spend for the period — all S&M compensation (base, commissions, benefits), marketing programs, tooling, allocated overhead. This is the period aggregate, NOT per-customer CAC.", "Denominator: new-customer ARR only (from `sales.new_business`), gross-margin-adjusted, normalized to a monthly figure — also a period aggregate, so it pairs dimensionally with the aggregate numerator.", "Gross margin uses the company-reported gross margin % for the same period." ], "exclusionRules": [ "Expansion ARR in the denominator (use `sales.expansion_cac_ratio` for that motion separately).", "Renewal ARR in the denominator (renewals are not acquisition).", "Non-S&M costs in the numerator (do not include R&D, G&A, or COGS — those belong in unit economics, not in CAC).", "Revenue (recognized) in place of ARR — payback is a contracted-recurring metric." ], "requiredInputs": [ "Fully-loaded S&M spend for the period (CAC numerator).", "New-customer ARR signed in the same period.", "Gross margin % for the same period.", "Period length so monthly conversion is explicit (annual → ÷12, quarterly → ÷3)." ], "dataSourcePriority": [ "Audited or reviewed financials for S&M spend and gross margin.", "CRM-derived new-business ARR for the same period (matched to the same start/end dates as the S&M figure)." ], "edgeCases": [ "Period mismatch (S&M from Q1, new ARR from Q2): pick a single period and recompute both; otherwise the ratio is meaningless.", "Founder-led sales (no formal S&M line): impute a market-rate AE/marketing cost or flag the metric as not-yet-meaningful — do not report a zero-CAC payback.", "Customer-success cost participating in expansion: include the share attributable to acquisition (typically zero); do NOT pull CS into new-customer CAC.", "Negative gross margin (early-stage with heavy hosting cost): the formula breaks; report payback as N/A and flag the underlying GM problem.", "Multi-year contracts: use first-year ARR only in the denominator — payback is a year-one cash-recovery metric." ], "validationChecks": [ "Result is in months and positive; payback < 6 months at >$5M ARR usually means the numerator is missing fully-loaded comp.", "Sanity-check against `sales.new_cac_ratio`: payback ≈ (CAC ratio × 12) / gross margin %.", "Compare to KBCM/Sapphire band for the ARR scale; an out-of-band result is more likely a calculation error than a true outlier." ], "commonMiscomputations": [ "Pairing per-customer CAC (the `sales.cac` value) with aggregate Monthly New ARR — a dimensional mismatch that yields months-per-customer, not months. The numerator and denominator must both be period aggregates: total S&M spend over total monthly new ARR.", "Dropping the gross-margin adjustment (total S&M / Monthly New ARR, without × Gross Margin %) — overstates efficiency by ~25–30 percentage points and breaks comparability with peer benchmarks.", "Using total net new ARR (including expansion) in the denominator — makes acquisition look artificially efficient and obscures whether new-logo motion is working.", "Using annual new ARR directly without monthly normalization — produces a payback ~12× off (number reads as years instead of months, or vice versa).", "Omitting fully-loaded S&M (esp. SDR base pay, sales ops, tooling, marketing programs) — common in early-stage models; understates CAC and breaks peer comparability.", "Using bookings or invoiced revenue in place of new ARR — they recognize at different cadences and produce different payback numbers.", "Period mismatch between numerator and denominator (S&M and ARR from different periods) — most common when carrying numbers across a fiscal-year boundary." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.carr", "slug": "carr", "domain": "sales", "defaultLabel": "CARR", "description": "Contracted Annual Recurring Revenue — recognized MRR × 12 plus the annualized value of contracts that are signed but not yet live (i.e. implementation, ramp, deferred-start). Per the SMSB standard, CARR sits between ARR (live only) and pipeline (unsigned) on the revenue-certainty spectrum: contractually committed but not yet delivered. Boards reading CARR > ARR gap can quantify the in-flight implementation backlog and the leading indicator of next-period ARR. Common pitfall: counting verbal commitments or LOIs as CARR — only signed contracts qualify under the SMSB definition.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/contracted-annual-recurring-revenue", "sectionRef": "CARR", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "CARR = ARR (live, recognized contracts annualized) + Annualized value of signed contracts not yet in production. Per SMSB §CARR: requires a signed contract; excludes verbal commitments, letters of intent, and pipeline. The (CARR − ARR) gap = in-flight ARR awaiting go-live.", "whyItMatters": "A leading indicator that ARR alone misses — if CARR is growing faster than ARR, an implementation backlog is building and ARR will accelerate as those contracts go live. Boards use the CARR-to-ARR ratio to interrogate the implementation engine.", "interpretationGuidance": "A CARR / ARR ratio of 1.00 means everything signed is already live (no implementation backlog); 1.10–1.20 is typical for enterprise SaaS with multi-month implementation timelines; > 1.30 may signal either an implementation bottleneck (operational risk) or a deliberate backlog-build before a known activation event (intentional). Always cross-reference with the implementation team's capacity plan.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.blended_cac_ratio", "sales.new_cac_ratio", "sales.bookings_backlog_total" ], "calculationPolicy": { "inclusionRules": [ "ARR (live, recognized contracts annualized) plus the annualized value of signed contracts not yet in production.", "Requires a signed contract — same recurring-contract definition as ARR; CARR uses the same multi-year handling (contract value divided by term in years)." ], "exclusionRules": [ "Verbal commitments, letters of intent, qualified pipeline — these are pipeline, not CARR.", "One-time fees and non-committed usage (same exclusions as ARR).", "Cancelled contracts even if recently signed." ], "requiredInputs": [ "Live ARR figure for the same period close.", "List of signed contracts with `not yet live` status and their annualized contract value.", "Signed-date and expected go-live-date per pending contract (used in edge-case handling)." ], "dataSourcePriority": [ "CRM contract module with explicit `signed but not live` status (Salesforce opportunity stage + go-live field).", "Manual signed-contract log when CRM does not model the implementation backlog." ], "edgeCases": [ "Contracts signed but with conditional or rolling go-live dates: include in CARR only if the contract is unconditional.", "Long implementation cycles (> 6 months): include but flag separately; boards may want to see ARR + near-term CARR + far-term CARR.", "Contracts with deferred-start clauses: include from signature date, not from intended start." ], "validationChecks": [ "CARR ≥ ARR always; if not, the underlying classifications are wrong.", "(CARR − ARR) should equal the sum of `signed-not-live` contract annualized values." ], "commonMiscomputations": [ "Reporting CARR as if it were ARR — this is the single most common source of board-deck inflation; always show the (CARR − ARR) gap explicitly.", "Including pipeline / LOIs / verbal commitments — those are not contracted and do not qualify.", "Failing to migrate a CARR contract to ARR on go-live — leaves it double-counted or stranded; reconcile each period." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "dateBasis": "signed", "production": "computed" }, "dependencies": [ { "kpi": "sales.arr", "edge": "computesFrom" }, { "kpi": "sales.bookings_backlog_total", "edge": "computesFrom" } ] }, { "rogueId": "sales.churn_arr", "slug": "churn_arr", "domain": "sales", "defaultLabel": "Churned ARR", "description": "Annualized recurring revenue lost during the period from customers who fully cancelled — terminating their contract or letting it lapse without renewal. The \"leak\" line of the ARR waterfall and the denominator of Gross Revenue Retention. Distinct from Downgrade ARR (sales.downgrades) which captures contractions where the customer stays. Common pitfall: lumping mid-term cancellations with non-renewals masks two very different retention failures — surface them separately when material. The KpiVarianceTable widget tracks period forecast vs actual; a widening miss against forecast is the earliest signal of a retention problem.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "recommended", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Churned ARR = Sum of ARR from contracts that terminated during the period (cancelled mid-term or not renewed at the end of term) attributable to customers whose ARR with the company drops to zero. Excludes contractions where the customer remains (those land in Downgrade ARR).", "whyItMatters": "Direct read on Gross Revenue Retention (GRR) — the floor of the retention math, since downgrades and churn cannot be offset by upsell in GRR. A board can tolerate slow new-logo growth if churn is low, but cannot tolerate high churn at any growth rate — it compounds against valuation.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Gross Revenue Retention, top-quartile SaaS companies hold GRR ≥ 90% (enterprise-segment) or ≥ 85% (SMB-segment); GRR below 80% in either segment usually means the product or onboarding has a structural problem, not a sales-execution one. Pair this line with the Customers domain to identify whether churn concentrates in a particular segment or cohort.", "relatedKpiIds": [ "sales.arr", "sales.downgrades", "sales.expansion", "customers.gross_revenue_retention", "customers.net_revenue_retention", "customers.logo_retention_rate", "customers.logo_churn_rate" ], "calculationPolicy": { "inclusionRules": [ "Annualized ARR of contracts that terminated during the period such that the customer's total ARR with the company drops to zero.", "Both mid-term cancellations and non-renewals count.", "Use the customer's ARR at the most recent live period close as the churned amount (don't pro-rate the partial period of service)." ], "exclusionRules": [ "Contractions where the customer remains (seat reductions, tier downgrades) — those are `sales.downgrades`.", "New-logo failures (customer signed but never went live and was refunded) — these were never ARR and don't belong in churn.", "Pause / suspension if the contract is still open with a defined return SLA — flag separately as \"paused ARR\" rather than churned." ], "requiredInputs": [ "Customer-level ARR snapshot at period start.", "Customer-level termination dates and cancellation reason codes if available.", "Distinction between mid-term cancellation and non-renewal (these are often surfaced separately on board packs)." ], "dataSourcePriority": [ "Customer-level ARR ledger with churn events.", "CRM opportunity / renewal stages as a fallback." ], "edgeCases": [ "Customer terminates one product but keeps another: the per-customer ARR delta is negative but non-zero — that goes in `sales.downgrades`, NOT churn.", "Customer is acquired by another company and the contract is novated to the acquirer: typically count as retention, not churn (account identity transfers).", "Bankruptcy / non-payment write-offs: count as churn from the date the contract is voided.", "Mid-term cancellation with a non-cancellable balance still due: still count as churn from the cancellation effective date; the unpaid balance is an AR issue, not an ARR one." ], "validationChecks": [ "Churned ARR ≥ 0 always.", "GRR = (Starting ARR − Churned − Downgrades) / Starting ARR. Bounded at 100% — recompute if violated.", "Per-customer churned amount ≤ that customer's period-start ARR." ], "commonMiscomputations": [ "Lumping downgrades and churn into a single \"churn\" number — masks the contraction-vs-cancellation signal that the waterfall exists to reveal.", "Counting customers who never went live (refunded new logos) as churn — they were never ARR.", "Using cancellation-request date instead of contract-end date for the period attribution — produces phantom churn in the request quarter and missing churn in the actual cancellation quarter.", "Treating \"paused\" customers as churned (or vice versa) — pick a convention and apply it; mid-stream policy changes corrupt the trend.", "Forgetting to remove the customer from the starting-cohort base for the next period — produces double-counting in the next quarter's retention math." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "period_close", "production": "primary" }, "dependencies": [ { "kpi": "customers.churn_risks", "edge": "narrates" }, { "kpi": "customers.percent_arr_at_risk", "edge": "contextualizes" } ] }, { "rogueId": "sales.closed_lost_count", "slug": "closed_lost_count", "domain": "sales", "defaultLabel": "Deals Lost", "description": "Count of opportunities that transitioned to closed-lost during the period — the volume side of pipeline disqualification. The other half of the win rate denominator; without tracking it explicitly you cannot compute or benchmark win rate. Common pitfall: stale \"open\" deals that should be marked lost are left open, inflating pipeline value while suppressing the lost count — a hygiene problem that compounds because next-period coverage looks fine while win rates silently degrade. Every CRM hygiene policy should specify a max-age before deals auto-flag for lost-or-update review.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Lost Count = Count of distinct opportunities whose stage transitioned to closed-lost during the period. Excludes \"no decision\" / paused opportunities (which should have a separate stage); excludes disqualified-pre-pipeline opportunities.", "whyItMatters": "Denominator input for win rate and direct read on pipeline hygiene. Cluster analysis of loss reasons feeds product / pricing / positioning decisions that boards expect to see referenced in strategic_context.", "interpretationGuidance": "Track loss-reason distribution quarter-over-quarter — concentration in \"price\" usually points to packaging; concentration in \"feature gap\" feeds product roadmap; concentration in \"no decision\" usually means lead-qualification is too loose. Pair count with value to spot mix-shift (e.g. losing more small deals while winning the large ones is a different motion problem than the inverse).", "relatedKpiIds": [ "sales.closed_lost_value", "sales.closed_won_count", "sales.win_rate", "sales.competitive_alerts", "sales.pipeline_risk_factors" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct opportunities whose stage transitioned to closed-lost during the period." ], "exclusionRules": [ "\"No decision\" / paused opportunities — those belong in a separate stage, not in lost.", "Disqualified-pre-pipeline opportunities (never bona-fide pipeline).", "Closed-won opportunities (see `sales.closed_won_count`)." ], "requiredInputs": [ "Opportunities with close date, final stage, and loss-reason code if available.", "A stage convention that separates lost from no-decision / paused." ], "dataSourcePriority": [ "CRM closed-lost report with loss-reason codes.", "Rev-ops export as a fallback." ], "edgeCases": [ "Stale \"open\" deals that should be lost are left open — this suppresses the lost count while inflating pipeline value; enforce a max-age lost-or-update review.", "\"No decision\" lumped into lost — artificially depresses win rate; bucket it separately." ], "validationChecks": [ "Count is a non-negative integer.", "Denominator input for win rate alongside `sales.closed_won_count`.", "Pair the count with `sales.closed_lost_value` to detect mix-shift (losing many small deals vs a few large ones)." ], "commonMiscomputations": [ "Counting no-decision / paused outcomes as lost — distorts win rate.", "Leaving stale deals open instead of marking them lost — silent win-rate degradation that compounds across periods." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.closed_lost_value", "slug": "closed_lost_value", "domain": "sales", "defaultLabel": "Deals Lost Value", "description": "Total dollar value of opportunities closed-lost during the period — the opportunity-cost view on the pipeline motion. Useful for sizing the \"what we missed\" gap and prioritizing post-mortem efforts on the highest-value losses. Common pitfall: post-mortems on small lost deals waste time relative to insight; tier the post-mortem cadence by value (e.g. every loss above the 80th-percentile deal size gets a written debrief). Boards expect the largest 2–3 losses to be explained explicitly in commentary.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Lost Value = Σ (deal_value) across opportunities that transitioned to closed-lost in the period. Use the same value convention (TCV vs ACV) as Closed-Won Value for consistency.", "whyItMatters": "Quantifies the realized opportunity cost — useful for justifying packaging changes, ICP refinement, or product investment that would have closed specific tier-1 losses. Drives loss-reason prioritization.", "interpretationGuidance": "Loss-Value / Won-Value (= loss share of total close events) — at steady state usually 30–60% depending on motion type (inbound-heavy motions have higher win rates and lower loss values; outbound motions have lower win rates and higher loss values). Spiking loss-value with stable won-value usually indicates competitive friction or pricing pressure on enterprise deals specifically.", "relatedKpiIds": [ "sales.closed_lost_count", "sales.closed_won_value", "sales.win_rate", "sales.average_deal_size", "sales.competitive_alerts" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across opportunities that transitioned to closed-lost in the period — the opportunity-cost view on the pipeline motion.", "Use the same value convention (TCV vs ACV) as `sales.closed_won_value`." ], "exclusionRules": [ "\"No decision\" / paused opportunities (separate stage).", "Closed-won value (see `sales.closed_won_value`).", "Disqualified-pre-pipeline opportunities." ], "requiredInputs": [ "Closed-lost opportunities with deal_value and close date.", "A value convention consistent with `sales.closed_won_value`." ], "dataSourcePriority": [ "CRM closed-lost report for the period.", "Rev-ops export as a fallback." ], "edgeCases": [ "Same value convention as won — a mismatched TCV / ACV choice breaks the loss-share ratio.", "Tier post-mortems by value; the largest 2–3 losses should be explained explicitly in commentary." ], "validationChecks": [ "closed_lost_value ≥ 0.", "Loss share = closed_lost_value / `sales.closed_won_value` — at steady state usually 30–60% depending on motion type; spiking loss value with stable won value signals competitive or pricing pressure on enterprise deals." ], "commonMiscomputations": [ "Using a different value convention than `sales.closed_won_value` — the loss-vs-won comparison becomes meaningless.", "Including no-decision / paused deal value in the lost total." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.closed_won_count", "slug": "closed_won_count", "domain": "sales", "defaultLabel": "Deals Won", "description": "Count of opportunities that reached closed-won status during the period — the volume side of the period's sales output. Paired with closed_won_value gives the period's average won-deal size, a critical mix-shift indicator. Common pitfall: counting opportunity stage transitions rather than discrete deal closes (re-opened deals inflate the count). Boards read the trend over 4+ quarters to detect motion-volume stability — sharp drops while pipeline holds usually mean late-stage conversion has broken.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Won Count = Count of distinct opportunities whose stage transitioned to closed-won during the period. Each opportunity counted at most once even if multiple stage transitions occur.", "whyItMatters": "The most direct sales-execution volume signal — separates \"we sold lots of small things\" from \"we sold a few big things\" when paired with deal-size lines. Inputs win rate and ASP analysis.", "interpretationGuidance": "Read alongside closed_won_value: rising count + rising value = healthy scale; rising count + falling value = down-market mix shift (often unintentional); falling count + rising value = up-market success or a coverage problem; both falling = execution issue requiring intervention.", "relatedKpiIds": [ "sales.closed_won_value", "sales.closed_lost_count", "sales.win_rate", "sales.average_deal_size", "sales.new_customers_added" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct opportunities whose stage transitioned to closed-won during the period.", "Each opportunity counted at most once even if it had multiple stage transitions (e.g. re-opened then re-won)." ], "exclusionRules": [ "Stage transitions that are not genuine closes (a re-opened deal counted a second time).", "Closed-lost opportunities (see `sales.closed_lost_count`).", "Expansion / renewal bookings not tracked as discrete won opportunities — be consistent with how `sales.closed_won_value` is built." ], "requiredInputs": [ "Opportunities with close date and final stage.", "Period boundaries." ], "dataSourcePriority": [ "CRM closed-won report for the period.", "Rev-ops export as a fallback." ], "edgeCases": [ "Re-opened-then-re-won deals: count once.", "Multi-product single opportunity vs split opportunities: hold the counting unit constant with `sales.pipeline_deal_count`." ], "validationChecks": [ "Count is a non-negative integer.", "Win rate = closed_won_count / (closed_won_count + `sales.closed_lost_count`) × 100 — this is the count-basis numerator and denominator input.", "`sales.closed_won_value` / closed_won_count = realized average won-deal size; cross-check against `sales.avg_contract_value`." ], "commonMiscomputations": [ "Counting opportunity stage transitions rather than discrete deal closes — re-opened deals inflate the count.", "Omitting `sales.closed_lost_count` (or mixing won and lost) so win rate cannot be computed." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.closed_won_value", "slug": "closed_won_value", "domain": "sales", "defaultLabel": "Deals Won Value", "description": "Total dollar value of all opportunities closed-won during the period — the period's realized bookings from the pipeline motion. Reconciles to (sales.new_business + sales.expansion) when split by deal type. Common pitfall: reporting TCV (total contract value) here when the rest of the dashboard uses ACV — pick one and apply it consistently across closed_won_value, weighted_forecast, and pipeline_value, or the dashboard math stops reconciling.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Closed-Won Value = Σ (deal_value) across opportunities that transitioned to closed-won in the period. The \"deal_value\" convention (TCV vs ACV) must match the pipeline-tracking convention for the math to reconcile.", "whyItMatters": "Realized bookings — the period's actual sales output. Sum across periods should reconcile to total new-customer + expansion CARR additions; gaps indicate either revenue-recognition policy or stage-data-quality issues.", "interpretationGuidance": "Closed-Won Value / Quota gives the period's attainment percentage — > 100% is over-plan, 80–100% is the typical \"acceptable\" band, < 80% triggers the post-mortem cycle. Read alongside Win Rate to identify whether misses are pipeline-driven (low value but normal win rate) or execution-driven (normal value, depressed win rate).", "relatedKpiIds": [ "sales.closed_won_count", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.win_rate", "sales.new_business" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across opportunities that transitioned to closed-won in the period — the realized bookings from the pipeline motion.", "Use ONE value convention (TCV or ACV) and apply it consistently with `sales.pipeline_value` and `sales.weighted_forecast`." ], "exclusionRules": [ "Closed-lost value (see `sales.closed_lost_value`).", "Recognized or invoiced revenue — closed-won value is bookings (signed), NOT earned revenue (`sales.total_revenue`) and NOT an annualized run-rate (`sales.arr`).", "Re-opened-then-re-won double counts." ], "requiredInputs": [ "Closed-won opportunities with deal_value and close date.", "The value convention (TCV vs ACV) in force." ], "dataSourcePriority": [ "CRM closed-won report for the period.", "Finance bookings ledger as a cross-check." ], "edgeCases": [ "TCV-vs-ACV: pick one — reporting TCV here while the rest of the dashboard is ACV breaks reconciliation.", "Multi-year deals: the convention decides whether the full TCV or the annualized value lands on this line.", "When split by deal type, closed-won value reconciles to `sales.new_business` + `sales.expansion` (the live-ARR subset). Cross-reference those already-hardened ARR-movement lines; do NOT restate their waterfall here." ], "validationChecks": [ "closed_won_value ≥ 0.", "Sum across periods reconciles to total new-customer + expansion CARR additions; persistent gaps indicate revenue-recognition policy or stage-data-quality issues.", "closed_won_value / quota = the period attainment percentage." ], "commonMiscomputations": [ "Reporting TCV here while using ACV elsewhere — breaks the dashboard math.", "Conflating closed-won bookings with recognized revenue (`sales.total_revenue`) or with the ARR run-rate (`sales.arr`).", "Double-counting re-opened / re-won deals.", "Duplicating the ARR-movement waterfall (`sales.new_business` / `sales.expansion`) on this line instead of cross-referencing it." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "bookings", "production": "primary" } }, { "rogueId": "sales.competitive_alerts", "slug": "competitive_alerts", "domain": "sales", "defaultLabel": "Competitive Alerts", "description": "Narrative read on competitive dynamics affecting the sales motion — material wins / losses to specific competitors, observed pricing or packaging moves in the market, new entrants, M&A in the competitive set. Boards use this surface to bring outside intelligence (their other portfolio companies, advisors) to bear on the competitive picture. Common pitfall: listing competitor names without quantifying how often they show up in deal cycles — a \"Competitor X is being aggressive\" entry without \"we saw them in 8 of 20 active deals last quarter, up from 3 of 18\" is too vague to act on.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: per-competitor sub-sections covering deal-frequency observed, win/loss split when statistically meaningful, and any observed pricing / packaging moves.", "whyItMatters": "Competitive intelligence is the most under-shared information in board packs and the most useful for cross-portfolio learning — boards can validate or refute observations from other companies they sit on.", "interpretationGuidance": "Track entries quarter-over-quarter: a competitor whose mention frequency rises consistently is a leading indicator of market positioning erosion. Pair with sales.win_rate trend cut by competitor when possible.", "relatedKpiIds": [ "sales.win_rate", "sales.closed_lost_count", "sales.closed_lost_value", "sales.key_concerns", "sales.strategic_context" ] }, { "rogueId": "sales.deals_summary", "slug": "deals_summary", "domain": "sales", "defaultLabel": "Deals Summary (Won / Lost)", "description": "Container handle for the period's notable deals split into WON and LOST arrays — each deal carries name, account, amount, owner, deal type, source, and competitor, plus a win reason + close date (won) or a loss reason (lost). The bespoke sales feed card renders this as the \"Notable Deals\" won/lost breakdown the demo design shows. This is RICHER than the flat `sales.pipeline_key_deals` editor gallery (which has no won/lost split, reason, or close date). Common pitfall: carrying the same list forward each quarter — refresh to the actual period's closes.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — { wonDeals: IWonDeal[], lostDeals: ILostDeal[] }. Won deals carry winReason + closeDate; lost deals carry lossReason. No aggregate calculation; the surface makes specific outcomes visible at the board level.", "whyItMatters": "Turns the quarter's win/loss outcomes into board-readable narrative — why deals were won (superior product / service) and lost (features / price / competitor) is the qualitative signal raw pipeline numbers miss.", "interpretationGuidance": "Cluster the loss reasons: repeated `features` losses signal a product gap; repeated `price` losses signal a packaging/positioning gap. Pair with `sales.pipeline_key_deals` for the still-open top deals.", "relatedKpiIds": [ "sales.pipeline_key_deals", "sales.closed_won_value", "sales.closed_lost_value" ] }, { "rogueId": "sales.downgrades", "slug": "downgrades", "domain": "sales", "defaultLabel": "Downgrade ARR", "description": "Annualized recurring revenue lost from existing customers who reduced spend mid-term or at renewal (seat reductions, tier downgrades, removed modules) — without leaving entirely. The \"contraction\" line of the ARR waterfall, distinct from full churn. Often a more sensitive leading indicator than churn because customers tend to contract before they cancel. Common pitfall: lumping downgrades into churn obscures the early-warning signal — boards looking only at logo churn miss the slow-bleed pattern. Surfaces in the KpiVarianceTable widget alongside expansion and churn so the net-retention math is auditable.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Downgrade ARR = Sum across existing customers of (ARR at period start − ARR at period close) for the subset where the delta is positive AND the customer's ARR did not drop to zero. Customers whose ARR drops to zero count in Churned ARR instead.", "whyItMatters": "Earliest leading indicator of retention risk — customers usually contract before they cancel, so a rising downgrade line predicts churn 1–2 quarters out. Inputs NRR (subtracts from expansion) and CCO/CS comp models that gate on Net Retention.", "interpretationGuidance": "Downgrade ARR rising as a share of expansion ARR over 2+ quarters is the canonical leading signal of a renewal-cycle problem. There is no widely-published cross-company benchmark for downgrade rates as a standalone — read it in context of NRR (industry folk-wisdom: a healthy SaaS company with NRR ≥ 110% typically has downgrade ARR ≤ 3% of starting ARR per period).", "relatedKpiIds": [ "sales.expansion", "sales.churn_arr", "sales.arr", "customers.net_revenue_retention", "customers.gross_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "Sum across existing customers of (period-start ARR − period-end ARR) where the delta is positive AND the customer's ARR did not drop to zero.", "Includes seat reductions, tier downgrades, removed modules/products, and renewal-time contractions." ], "exclusionRules": [ "Customers whose ARR dropped to zero — those are full churn (`sales.churn_arr`), not downgrades.", "New-logo deals and expansions — positive-delta customers do not appear here.", "Contractual price decreases that were pre-agreed in the original contract (rare, but disclose if present)." ], "requiredInputs": [ "Customer-level ARR snapshot at period start.", "Customer-level ARR snapshot at period end.", "Per-customer churn flag (to separate full churn from contraction)." ], "dataSourcePriority": [ "Customer-level ARR ledger (same source as expansion / churn / NRR).", "CRM contract changelog as a fallback." ], "edgeCases": [ "Customer downgrades one product and expands another in the same period: net the per-customer delta; if negative, it counts here; if positive, it counts in expansion.", "Renewal at a lower price after a discount expires: count the reduction as a downgrade.", "Customer contracts to zero: that is churn, not a downgrade — even though it \"feels\" like the extreme downgrade." ], "validationChecks": [ "Downgrade ARR ≥ 0 always.", "NRR = (Starting ARR + Expansion − Downgrades − Churn) / Starting ARR — downgrades and churn together must reconcile the waterfall.", "Per-customer downgrade ≤ that customer's period-start ARR." ], "commonMiscomputations": [ "Lumping downgrades into churn — destroys the leading-indicator signal; customers usually contract 1-2 quarters before they cancel.", "Counting a contract-to-zero as a downgrade — it is churn; mixing the two corrupts both GRR and the churn line.", "Netting downgrades against same-customer expansion and reporting only the net — both gross lines are needed for the waterfall.", "Missing renewal-time downgrades because the system only captures mid-term amendments — renewal contractions are the larger share for most SaaS." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "period_close", "production": "primary" } }, { "rogueId": "sales.expansion", "slug": "expansion", "domain": "sales", "defaultLabel": "Expansion ARR", "description": "Annualized recurring revenue added during the period from existing customers — through upsell (more seats / higher tier), cross-sell (additional products), or price increases. The \"farm\" line of the ARR waterfall. Boards read this as the leading indicator that product-market fit has translated into product-account fit and that the post-sale motion is creating compound growth. Common pitfall: classifying contractual price-step-ups (CPI escalators baked into the original contract) as expansion overstates new selling motion. Expansion CAC Ratio and Net Revenue Retention are derived from this number.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Expansion ARR = (ARR from existing customers at period close) − (ARR from those same customers at period start) for the subset where the delta is positive. Excludes downgrades (tracked separately) and excludes new-logo bookings. Pre-contracted CPI escalators may or may not be treated as expansion — pick one convention per the company and apply it consistently.", "whyItMatters": "A high expansion line is the single best predictor of capital-efficient compounding growth — the SaaS playbook depends on existing customers expanding faster than new ones churn. Drives NRR, which is the metric public-market investors weight most heavily on the retention side of the model.", "interpretationGuidance": "Expansion ARR ≥ Churned + Downgrade ARR means NRR ≥ 100% (the \"leaky bucket gets refilled by upsell\" condition). Per KBCM/Sapphire SaaS Survey 2024 §Net Revenue Retention, median NRR is roughly 105–110% for $5M+ ARR SaaS — below 100% is a yellow flag at any stage; above 120% signals a category-leading account-expansion motion.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.churn_arr", "sales.downgrades", "sales.expansion_cac_ratio", "customers.net_revenue_retention", "customers.gross_revenue_retention" ], "calculationPolicy": { "inclusionRules": [ "Sum of (end-of-period ARR − start-of-period ARR) per customer, restricted to existing customers and to the subset where the delta is positive.", "Includes upsell (more seats, more capacity), cross-sell (additional products/modules), tier upgrades, and discretionary price increases negotiated mid-term.", "Disclose handling of contractual CPI escalators baked into the original contract — pick a convention (count or don't) and apply consistently." ], "exclusionRules": [ "New-logo ARR — those are in `sales.new_business`.", "Customers who started the period with zero ARR (they're new logos, not expansions, even if they upgraded the same period).", "Negative deltas (downgrades) — those go in `sales.downgrades`.", "Renewals at the same price — those are retention, not expansion." ], "requiredInputs": [ "Customer-level ARR snapshot at period start.", "Customer-level ARR snapshot at period end.", "Convention flag: are contractual CPI escalators counted as expansion?" ], "dataSourcePriority": [ "Customer-level ARR ledger keyed by stable account ID (same source as NRR/GRR).", "CRM contract changelog as a fallback when the ledger isn't available." ], "edgeCases": [ "Customer who upgraded AND downgraded different products in the same period: net the per-customer delta; if positive, count in expansion (only).", "Mid-period contract amendment: take the period-end ARR vs period-start ARR for the customer; don't double-book intermediate changes.", "Account mergers (parent acquires sub-customer): treat the consolidated entity as the new cohort; don't count the consolidation as expansion.", "Price-pack upgrade (Pro→Enterprise) at renewal: count the delta as expansion, not as renewal." ], "validationChecks": [ "Expansion ARR ≥ 0 always.", "Per-customer expansion ≤ their period-end ARR (you can't expand by more than the customer pays).", "Sum of all expansion line items reconciles to the aggregate expansion number within 1%." ], "commonMiscomputations": [ "Counting price-step-ups that were pre-contracted (CPI escalators) as expansion — inflates the selling-motion narrative without any actual sales activity.", "Including new-logo upsells (customer signed Tier 1 then upgraded to Tier 2 in the same period) as expansion — they're part of the new-logo motion.", "Netting downgrades against expansion at the customer level and reporting the net as \"expansion\" — they're different lines for a reason.", "Cohort drift: counting expansion from customers who weren't in the starting-period cohort. The cohort must be closed at period start.", "Counting renewal value as expansion — renewal at the same price is retention, not expansion." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "primary" } }, { "rogueId": "sales.expansion_cac_ratio", "slug": "expansion_cac_ratio", "domain": "sales", "defaultLabel": "Expansion CAC Ratio", "description": "Fully-loaded S&M plus Customer Success expense attributable to expansion divided by expansion CARR generated in the period. Per SMSB, the efficiency read on the upsell / cross-sell / land-and-expand motion. Distinct from the new-logo CAC ratio because the cost base often includes CSMs whose primary metric is retention but whose secondary metric is expansion — boards expect to see that allocation called out. Common pitfall: excluding CS comp entirely understates the true cost of expansion; including all of CS overstates it. The SMSB standard prescribes a documented allocation rule (typically tied to expansion-quota OTE share).", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/expansion-cac-ratio", "sectionRef": "Expansion CAC Ratio", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "Expansion CAC Ratio = (S&M + CS spend allocated to expansion in period) / (Expansion CARR generated in period). Per SMSB §Expansion CAC Ratio: allocation rule for cross-functional comp (typically split by quota share of OTE) must be documented and consistent.", "whyItMatters": "Validates the financial logic of \"expansion is cheaper than acquisition\" — when this is healthy, the company should bias growth investment toward post-sale; when it inverts (Expansion CAC ≥ New CAC), the expansion motion is broken and acquisition is the only available lever.", "interpretationGuidance": "Per SMSB convention, healthy Expansion CAC Ratio is typically 3–5× cheaper than New CAC Ratio — i.e. 0.2–0.5 when New CAC Ratio is ~1.5. Expansion CAC Ratio > 1.0 is a yellow flag (expansion costs as much as it earns); inversion vs New CAC Ratio is a red flag warranting a CS / sales-team org review.", "relatedKpiIds": [ "sales.blended_cac_ratio", "sales.new_cac_ratio", "sales.expansion", "customers.net_revenue_retention", "sales.carr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: S&M + Customer Success spend allocated to the expansion motion (upsell / cross-sell / land-and-expand).", "Denominator: expansion CARR generated in the period.", "CS comp is partly in scope: include the share of CSM cost attributable to expansion (typically the fraction of OTE tied to an expansion quota), per a documented rule." ], "exclusionRules": [ "New-logo S&M spend from the numerator (goes in `sales.new_cac_ratio`).", "The retention-only share of CS comp — CSMs whose comp is purely tied to renewal/retention, not expansion.", "New-customer CARR and renewal CARR from the denominator." ], "requiredInputs": [ "S&M + CS spend allocated to expansion.", "Expansion CARR for the period.", "The documented allocation rule for cross-functional (CS) comp." ], "dataSourcePriority": [ "Financials + documented CS/S&M allocation model.", "CRM for expansion CARR." ], "edgeCases": [ "CS team with no expansion quota at all: expansion is AE-driven; CS comp share is ~0 and the numerator is AE-expansion-comp only.", "Product-led expansion (self-serve upgrades, no human touch): the numerator may be near-zero — Expansion CAC Ratio approaches zero, which is correct and worth calling out as a strength.", "Allocation-rule change: re-state prior periods." ], "validationChecks": [ "Expansion CAC Ratio should be materially lower than New CAC Ratio — healthy SaaS expansion is typically 3–5× cheaper per dollar (≈ 0.2–0.5 when New CAC Ratio ≈ 1.5).", "Expansion CAC Ratio ≥ New CAC Ratio is a red flag — the expansion motion is broken; investigate before reporting it as a number without commentary.", "Blended CAC Ratio must sit between New and Expansion CAC Ratio." ], "commonMiscomputations": [ "Excluding CS comp entirely — understates the true cost of expansion, makes the motion look free.", "Including ALL of CS comp — overstates it; most CS comp is retention, not expansion. Use the documented allocation.", "Using ARR instead of CARR in the denominator.", "Reporting Expansion CAC Ratio in isolation — it is only meaningful next to New CAC Ratio (the comparison IS the insight)." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.focus_areas", "slug": "focus_areas", "domain": "sales", "defaultLabel": "Sales Focus Areas", "description": "Forward-looking narrative naming the next-period (typically next-quarter) sales priorities — segment bets, pipeline-coverage actions, hiring focuses, enablement themes, ICP refinements. The \"what we're changing or doubling-down on\" surface, complementing strategic_context (which is past-tense) and key_concerns (which is present-tense). Common pitfall: listing too many focus areas (3 is the practical maximum a team can actually execute against; 7+ means everything is a priority, i.e. nothing is). Boards use this to track promise-vs-delivery quarter over quarter.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3 numbered priorities, each with a one-line statement and a measurable next-period success criterion.", "whyItMatters": "Creates accountability across periods — the board can ask \"you said X was the focus last quarter, what happened?\" Without an explicit list, every quarter looks like a fresh strategy reset.", "interpretationGuidance": "Focus areas should reappear (with progress) for 2–3 quarters before retiring — single-quarter focus shifts are usually a thrash signal. Track which focuses produce measurable KPI delta vs which produce only activity reports.", "relatedKpiIds": [ "sales.strategic_context", "sales.key_concerns", "sales.pipeline_assumptions", "sales.win_rate", "sales.cac_payback_period" ] }, { "rogueId": "sales.gross_margin", "slug": "gross_margin", "domain": "sales", "defaultLabel": "Gross Margin", "description": "Recognized revenue minus cost of goods sold (COGS), divided by recognized revenue, expressed as a percentage. The single best read on whether the business model can ever generate operating leverage — a low gross margin caps every downstream efficiency metric (CAC payback, LTV/CAC, Rule of 40). For SaaS, COGS includes hosting, third-party software, customer support, and customer-success cost-of-service. Common pitfall: omitting customer success from COGS inflates the margin and breaks comparability with peer benchmarks. Anchored to KBCM/Sapphire SaaS Survey 2024 §Gross Margin.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "Gross Margin", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 65, "median": 72, "p75": 81, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "Gross Margin = ((Recognized Revenue − COGS) / Recognized Revenue) × 100. COGS for a SaaS business: cloud / hosting infrastructure, third-party data and APIs called for delivery, customer support, customer success cost-of-service, and any directly-attributable delivery personnel. Excludes R&D, S&M, and G&A.", "whyItMatters": "Caps every long-term efficiency metric — Rule of 40, LTV/CAC, CAC payback all run off contribution margin which derives from gross margin. Board uses it to verify the unit economics are real before debating S&M investment levels.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §Gross Margin, healthy SaaS gross margin is 70–80%; > 80% is best-in-class infrastructure leverage; < 65% usually signals heavy services revenue or inefficient COGS (often customer-success scaling linearly with customer count). Sub-70% companies must show a credible path to 70%+ by next funding milestone or face valuation pressure.", "relatedKpiIds": [ "sales.total_revenue", "sales.arr", "sales.cac_payback_period", "operations.rule_of_40", "sales.growth_rate_yoy" ], "calculationPolicy": { "inclusionRules": [ "Numerator: Recognized Revenue (period) − COGS (period).", "COGS for SaaS includes: cloud/hosting/infrastructure, third-party APIs/data called for product delivery, payment-processing fees, customer support, customer-success cost-of-service, directly-attributable delivery personnel, software included with the product.", "Denominator: Recognized Revenue for the same period.", "Result is a percentage; format consistently (rounded to one decimal, or as the company's investor-letter standard)." ], "exclusionRules": [ "R&D, S&M, G&A — those are below the gross-margin line and belong in operating expenses.", "Stock-based compensation expense — exclude from COGS (separately disclose adjusted GM if non-GAAP).", "One-off implementation services revenue if reported in a separate revenue line with its own services-COGS." ], "requiredInputs": [ "Period Recognized Revenue (`sales.total_revenue` or income-statement total revenue).", "Period COGS, broken out by component (hosting, support, CS cost-of-service, payment-processing, third-party delivery costs).", "Methodology disclosure: cash vs accrual basis; GAAP vs adjusted (SBC-excluded)." ], "dataSourcePriority": [ "Audited or reviewed income statement.", "Internal management P&L with documented adjustments." ], "edgeCases": [ "High services-revenue mix (professional services > 15% of total revenue): break out product GM vs services GM. Blended GM hides whether the product GM is healthy.", "Customer-success cost-of-service: include in COGS for SaaS comparability. The single most common omission that inflates GM by 5–10 percentage points.", "Pure usage-based metering with variable infra cost: include the variable infra cost in COGS for each unit delivered.", "Hosting credits from cloud providers: net against hosting COGS, but disclose the credit period (it ends and COGS spikes)." ], "validationChecks": [ "Gross Margin should sit in 60–85% range for healthy SaaS. Below 60% requires either a services-heavy explanation or a credible path to 70%+.", "GM × Revenue = Gross Profit — recompute and cross-check.", "Trend should be smooth at steady state; > 5-percentage-point swings quarter-over-quarter usually indicate either a one-off COGS event or a revenue-mix shift worth narrative." ], "commonMiscomputations": [ "Omitting customer success from COGS — inflates GM by ~5–10 points and breaks peer comparability with KBCM/Sapphire benchmarks.", "Computing GM from ARR (not Recognized Revenue) while still using period-COGS — produces a number that is neither GM nor anything else meaningful.", "Including S&M or R&D in COGS — drops GM far below true unit economics.", "Counting SBC as a cash COGS — overstates COGS by 5–15% depending on equity comp intensity. Disclose adjusted GM if SBC-excluded is the headline.", "Mixing GAAP and non-GAAP GM across periods of the same trend chart — distorts comparability.", "Hiding cloud credits as a permanent COGS reduction — when the credit period ends, GM \"drops\" without any business change." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.growth_rate_yoy", "slug": "growth_rate_yoy", "domain": "sales", "defaultLabel": "Growth Rate (YoY)", "description": "Year-over-year percentage growth in ARR (or recognized revenue, if explicitly anchored) — comparing the current period to the equivalent period 12 months prior. The single most-watched investor metric and the largest single driver of SaaS valuation multiples. Common pitfall: comparing to the prior quarter (QoQ) and reporting it as \"growth rate\" — boards and investors mean YoY unless explicitly noted otherwise. Anchored to KBCM/Sapphire SaaS Survey 2024 §YoY ARR Growth for cross-company benchmarking.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "published", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceUrl": "https://www.cfodesk.co.il/wp-content/uploads/2024/10/2024_kbcm_sapphire_saas_survey.pdf", "sectionRef": "YoY ARR Growth", "publicationDate": "2024-09-01", "attributionNotice": null, "authorityLevel": "industry-benchmark" }, "benchmark": { "p25": 12, "median": 19, "p75": 27, "unit": "%", "sourceName": "KBCM/Sapphire SaaS Survey 2024 (15th Annual)", "sourceYear": "2024", "higherIsBetter": true }, "formula": "YoY Growth Rate = ((ARR at period close − ARR 12 months prior) / ARR 12 months prior) × 100. State the underlying metric explicitly (ARR vs Recognized Revenue) — they diverge meaningfully for sub-scale businesses. For quarters, use end-of-quarter ARR vs end-of-same-quarter-prior-year.", "whyItMatters": "Direct input to public-comparable valuation multiples (EV / NTM ARR multiples are sliced by growth band). Boards use it to triangulate stage-appropriate pace and to flag deceleration early.", "interpretationGuidance": "Per KBCM/Sapphire SaaS Survey 2024 §YoY ARR Growth, median private-SaaS growth bands by ARR scale: $5–10M ARR median ~55–70%, $10–25M ARR ~40–55%, $25–50M ARR ~35–45%, $50M+ ARR ~25–35%. Growth decelerating > 30 percentage points YoY at any ARR scale is the most actionable board warning signal — usually requires either pipeline-coverage diagnosis or product-investment reallocation.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.expansion", "sales.churn_arr", "operations.rule_of_40", "sales.gross_margin" ], "calculationPolicy": { "inclusionRules": [ "Numerator: ARR at period close (or Recognized Revenue at period close if explicitly anchored on revenue) minus the same metric exactly 12 months prior.", "Denominator: the same metric 12 months prior.", "For quarterly reporting, use end-of-quarter ARR vs end-of-same-quarter-prior-year (not start-of-period).", "State the underlying metric explicitly in any output (\"ARR YoY growth\" or \"Revenue YoY growth\") — they diverge for sub-scale businesses." ], "exclusionRules": [ "Quarter-over-quarter (QoQ) growth — that's a different metric. \"Growth rate\" without qualifier means YoY by convention.", "Monthly growth annualized via compounding — that's \"run-rate growth\", not YoY.", "Inorganic ARR additions (acquisitions) — disclose separately as \"ARR growth excluding M&A\" alongside the headline." ], "requiredInputs": [ "Period-close ARR (or Recognized Revenue) for the current period.", "Period-close ARR (or Recognized Revenue) exactly 12 months prior.", "Acquisition / divestiture log within the trailing 12 months." ], "dataSourcePriority": [ "Audited or reviewed period-close balances.", "Internal closed-period ARR snapshots maintained for board reporting." ], "edgeCases": [ "Acquisition mid-year: show two numbers — headline YoY (including acquired ARR from the acquisition date) and organic YoY (excluding). Boards read both.", "Currency moves on multi-currency revenue: hold FX flat at one rate across both endpoints when revenue is multi-currency. Constant-currency growth is the comparable number.", "Very small base 12 months prior (< $1M ARR): growth rate becomes mathematically unstable; report carefully or use absolute deltas alongside.", "Calendar-shift (53-week years, fiscal-year change): pin the comparable period or disclose the adjustment." ], "validationChecks": [ "Result is a percentage; can be negative (decline) but rarely > 200% for sub-scale companies in a single year.", "Sit within stage-typical KBCM/Sapphire band for ARR scale — out-of-band growth (especially declines) requires investigation, not narration.", "Cross-check ARR and Revenue growth rates: if they diverge by > 30 percentage points, ask why — usually a contract-mix shift or billing-policy change." ], "commonMiscomputations": [ "Computing QoQ growth and labeling it \"growth rate\" — investors interpret unqualified growth rate as YoY.", "Mixing ARR for numerator and Recognized Revenue for denominator (or vice versa) — produces a meaningless ratio.", "Including acquired ARR in the headline growth rate without flagging the inorganic contribution — investors see \"rocket growth\" that is mostly M&A.", "Using start-of-period vs end-of-period inconsistently (period-start one year vs period-end the other) — produces a 1-period offset that distorts the rate.", "Annualizing a monthly delta and reporting it as YoY — overstates dramatically for any company with seasonality.", "Computing growth on a metric that itself changed definition mid-trend (e.g. swapped MRR×12 to true contracted ARR) — usually inflates the growth rate by the methodology change." ] }, "metricBasis": { "timeBasis": "trailing_window", "production": "computed" } }, { "rogueId": "sales.key_concerns", "slug": "key_concerns", "domain": "sales", "defaultLabel": "Sales Key Concerns", "description": "Free-text narrative of the critical issues, pipeline risks, or blockers in the sales motion that require board attention this period. Distinct from sales.pipeline_risk_factors (which is forecast-specific) — this is the full-stack sales-org concerns list including hiring, comp, churn-cluster patterns, large-deal slippage, and competitive losses. Common pitfall: under-reporting concerns because the team wants to show progress — boards explicitly invite this surface so they can help, and a board pack with no concerns surfaces is itself a yellow flag (either the team is hiding something or not introspecting deeply enough).", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–7 bulleted concerns, each one sentence framing the issue + one sentence on what is being done.", "whyItMatters": "Lets the board pre-load the discussion topics that need their judgment or network — the most leveraged use of board time. Absent this surface, the conversation drifts to whatever board members notice in the numbers, which is rarely the highest-leverage issue.", "interpretationGuidance": "A healthy entry names specific deals or accounts, quantifies the at-risk amount where possible, and links to follow-up KPIs. Vague concerns (\"market is choppy\") consume board time without producing action; ask the team to either quantify or remove.", "relatedKpiIds": [ "sales.strategic_context", "sales.pipeline_risk_factors", "sales.competitive_alerts", "sales.focus_areas", "sales.churn_arr", "sales.downgrades" ] }, { "rogueId": "sales.median_deal_size", "slug": "median_deal_size", "domain": "sales", "defaultLabel": "Median Deal Size", "description": "Median dollar value across active pipeline opportunities — the typical deal in the pipeline, robust against the few-big-deals skew that distorts the average. The honest read on the \"core motion\" deal-size; if the team is winning a few oversized deals but the median is shrinking, the underlying motion is degrading even though the topline numbers look fine. Common pitfall: omitting median in dashboards in favor of just the average lets concentration risk hide. A best-practice board pack always shows both.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Median Deal Size = 50th-percentile deal_value across active pipeline opportunities. Same value convention (TCV vs ACV) as upstream metrics; same active-pipeline stage filter as average_deal_size.", "whyItMatters": "The most honest read on the typical motion — distinguishes \"we have a real scalable motion\" (high median) from \"we have a few oversized deals carrying everything else\" (low median, high average).", "interpretationGuidance": "When median deal size is stable while average deal size rises, the pipeline is becoming more skewed (a few mega-deals) — concentration risk. When median rises with average, the entire motion is shifting up-market. When median shrinks while average stays flat, deal-size compression is happening in the core motion (usually competitive pricing pressure).", "relatedKpiIds": [ "sales.average_deal_size", "sales.pipeline_value", "sales.pipeline_deal_count", "sales.avg_contract_value" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.new_business", "slug": "new_business", "domain": "sales", "defaultLabel": "New Business ARR", "description": "Annualized recurring revenue booked from net-new logos (first-time customers) during the period. This is the \"hunt\" line of the ARR waterfall — the output of the new-customer acquisition motion, distinct from expansion (existing-customer upsell) and from churn / downgrades. Common pitfall: counting renewals or expansion deals as new business inflates the new-logo conversion engine and hides a stalled acquisition motion. The KpiVarianceTable widget shows period forecast vs actual; downstream views compare it to S&M spend to derive new-business CAC and CAC payback.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "New Business ARR = Sum of ARR contracts signed during the period by customers who had zero prior ARR with the company. Excludes expansion, renewals, and reactivations. Aligns with the SMSB definition of new-logo ARR and pairs 1:1 with sales.new_customers_added for ASP analysis.", "whyItMatters": "Direct read on the health of the new-customer acquisition engine — separates \"are we winning new logos\" from \"are existing customers expanding.\" Inputs the New CAC Ratio and CAC Payback calculations the board uses to judge sales efficiency.", "interpretationGuidance": "New Business ARR running below plan for two consecutive quarters is the classic early-stage growth-stall signal — usually upstream pipeline coverage or win-rate problems. New Business as a share of total Net New ARR should be 60–80% pre-Series B and trends down to 40–60% post-Series B as expansion picks up (industry folk-wisdom, not citation-grade — verify against KBCM/Sapphire 2024 segmentation tables for the company stage band).", "relatedKpiIds": [ "sales.arr", "sales.new_customers_added", "sales.avg_contract_value", "sales.expansion", "sales.cac", "sales.new_cac_ratio", "sales.cac_payback_period" ], "calculationPolicy": { "inclusionRules": [ "Annualized contract value of net-new logos signed during the period (customers with zero prior ARR with the company).", "Multi-year contracts: use annualized value (TCV / term in years), not first-year billing.", "Same recurring-revenue definition as ARR: live / delivered subscription value only." ], "exclusionRules": [ "Expansion deals from existing customers — those belong in `sales.expansion`.", "Renewals of existing customers — those are retention, not new business.", "Reactivated customers who previously churned: classify per company policy, but be consistent and disclose. Some firms count reactivations as new business, others as recovery.", "Bookings (signed but not yet live) — those are CARR. New Business is the live-ARR subset." ], "requiredInputs": [ "CRM customer table with first-active-contract-date per account.", "Contract value annualized per account.", "Period boundaries (start/end dates)." ], "dataSourcePriority": [ "CRM with explicit \"first-time customer\" flag or stable customer-since field.", "Manual classification from CFO/Rev-Ops when CRM customer-since isn't reliable." ], "edgeCases": [ "Account splits / parent-child relationships: count by the same logo-unit used elsewhere in the waterfall (typically parent organization).", "Customers who signed late in the period but went live in the next: defer to the period when ARR turns live (matches ARR semantics) — unless the company explicitly uses booking-date.", "Pilots that convert to paid: count from the first paid contract, not the pilot start." ], "validationChecks": [ "New Business ARR + Expansion − Churned − Downgrades = Net New ARR. The waterfall must reconcile to the ARR delta within 1%.", "New Business should pair 1:1 with `sales.new_customers_added` — count and dollars track together; a large divergence indicates a logo-counting or classification error." ], "commonMiscomputations": [ "Counting renewals as new business — most common error; inflates the new-logo motion narrative and breaks every downstream CAC ratio.", "Counting expansion deals from existing customers — same effect; also doubles up against the expansion line.", "Using bookings instead of live ARR — overstates by the implementation backlog (often 10-25% of new bookings).", "Logo-unit drift: parent-org-counted one quarter, sub-account-counted the next — produces phantom new-logo growth.", "Late-period signing counted in the wrong period when the live-vs-signing convention isn't pinned." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "primary" } }, { "rogueId": "sales.new_cac_ratio", "slug": "new_cac_ratio", "domain": "sales", "defaultLabel": "New CAC Ratio", "description": "S&M expense attributable to new-customer acquisition divided by the new-customer CARR generated in the period. Per SMSB, the cleanest read on the new-logo acquisition engine's efficiency — strips out the expansion motion which has materially different unit economics. Common pitfall: failing to split AE comp time correctly between new and expansion activities — when the same AE owns both motions, an allocation rule (often the % of OTE tied to new-vs-expansion quota) is required and must be applied consistently quarter-over-quarter.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales", "Finance" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "published", "sourceName": "SaaS Metrics Standards Board", "sourceUrl": "https://www.saasmetricsboard.com/new-cac-ratio", "sectionRef": "New CAC Ratio", "publicationDate": "2023-01-01", "attributionNotice": "Metric definitions reference standards published by the SaaS Metrics Standards Board (saasmetricsboard.com). imboard is not affiliated with, endorsed by, or a member of SMSB.", "authorityLevel": "self-declared-coalition" }, "formula": "New CAC Ratio = (S&M spend allocated to new-customer acquisition in period) / (New-customer CARR generated in period). Per SMSB §New CAC Ratio: spend allocation must follow a documented rule (e.g. fraction of S&M headcount tied to new-business quota) applied consistently.", "whyItMatters": "Isolates the new-logo engine — when blended CAC Ratio is moving, this is the first line of split-out diagnosis. Boards use it to evaluate whether to invest more in acquisition or shift weight toward expansion.", "interpretationGuidance": "Per SMSB convention, New CAC Ratio of 1.0–2.0 is the typical mid-stage SaaS band; > 2.5 sustained signals the new-logo motion is structurally expensive (often a fit problem with target segment). Should be ≥ Blended CAC Ratio (new-logo is always more expensive than expansion); if New CAC Ratio < Blended, the spend allocation between new and expansion is mis-tagged.", "relatedKpiIds": [ "sales.blended_cac_ratio", "sales.expansion_cac_ratio", "sales.cac", "sales.cac_payback_period", "sales.new_business", "sales.carr" ], "calculationPolicy": { "inclusionRules": [ "Numerator: S&M spend allocated specifically to new-customer acquisition.", "Denominator: new-customer CARR generated in the period.", "When AEs run both new and expansion motions, allocate their comp by a documented rule — typically the fraction of OTE tied to new-business quota." ], "exclusionRules": [ "Expansion-attributed S&M / CS spend from the numerator (goes in `sales.expansion_cac_ratio`).", "Expansion CARR from the denominator.", "Renewal CARR from the denominator." ], "requiredInputs": [ "S&M spend allocated to new acquisition.", "New-customer CARR for the period.", "The documented new-vs-expansion allocation rule, applied consistently across periods." ], "dataSourcePriority": [ "Financials + a documented allocation model for split-role comp.", "CRM for new-customer CARR." ], "edgeCases": [ "Pure new-logo sales team (no split roles): allocation is trivial — all of that team's comp is in the numerator.", "Marketing spend that supports both new and expansion: allocate by the same documented rule; do not dump all of marketing into new-logo.", "Allocation-rule change between periods: re-state prior periods on the new rule, or the trend is broken." ], "validationChecks": [ "New CAC Ratio should be ≥ Blended CAC Ratio — new-logo acquisition is always more expensive per dollar than expansion. If New < Blended, the spend allocation between new and expansion is mis-tagged.", "New CAC Ratio of 1.0–2.0 is the typical mid-stage band; sustained > 2.5 signals a structurally expensive new-logo motion." ], "commonMiscomputations": [ "No allocation rule for split-role AEs — all AE comp lands in new-logo, overstating New CAC Ratio and understating Expansion CAC Ratio.", "Allocation rule that drifts quarter to quarter — produces a trend that reflects bookkeeping, not the motion.", "Using ARR instead of CARR — same understatement as the blended ratio.", "New CAC Ratio computed < Blended CAC Ratio and shipped without catching it — a guaranteed sign of an allocation error." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "computed" } }, { "rogueId": "sales.new_customers_added", "slug": "new_customers_added", "domain": "sales", "defaultLabel": "New Customers Added", "description": "Count of net-new logo customers signed during the period (a customer is a discrete buying entity — typically an account, not a seat). Paired with sales.new_business gives Average Selling Price (ASP) — a primary input to ICP / segment-fit conversations. Early-stage boards read the logo count as a sanity check on top-of-funnel and PMF before ARR-density grows enough to matter. Common pitfall: counting expansion deals or new contracts from existing customers as \"new\" inflates the acquisition signal — the count must match the same \"first-time customer\" criterion as New Business ARR.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "New Customers Added = Count of distinct customer entities whose first-ever active contract started during the period. Must apply the same logo-counting unit (account / parent-org / billing entity) consistently across periods so the trend is comparable.", "whyItMatters": "Logo count is the most direct read on acquisition-motion volume before contract-value mix dominates the ARR view. Early-stage boards read it before ARR; growth-stage boards pair it with ASP to spot segment drift (e.g. up-market mix-shift where logo count falls while ARR rises).", "interpretationGuidance": "Read alongside New Business ARR to derive ASP (= New Business ARR / New Customers Added). A rising ASP with falling logo count signals up-market drift (often intentional). Stable ASP with falling logo count signals a top-of-funnel problem. Falling ASP with stable logo count usually means discounting pressure — investigate competitive dynamics.", "relatedKpiIds": [ "sales.new_business", "sales.avg_contract_value", "sales.cac", "sales.pipeline_deal_count", "sales.closed_won_count", "sales.win_rate" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct customer entities whose first-ever active contract started during the period.", "Use a consistent logo unit (typically parent account / billing entity) across periods." ], "exclusionRules": [ "Expansion deals to existing customers — even if a new product or new line of business is added.", "Renewals or reactivations of previously-churned customers — those are separately tracked.", "Pilots / free trials — until the first paid contract starts.", "Sub-accounts under an existing parent (when parent-level is the unit) — should not double-count." ], "requiredInputs": [ "CRM customer table with stable customer-since field.", "Definition of \"logo unit\" (parent account vs sub-account vs billing entity) — pin one and apply consistently." ], "dataSourcePriority": [ "CRM with explicit customer-since field per logo unit.", "Billing system with first-billed-date as a fallback." ], "edgeCases": [ "Customer signs in period N but goes live in period N+1: pick a convention (signing-date vs go-live-date) and apply consistently with `sales.new_business`. Mismatched conventions break ASP calculations.", "Reactivated former customers: pin a policy (\"count as new\" or \"count as recovery\") and apply consistently. Most boards prefer separate reporting.", "Parent-child shifts: if the logo unit changes mid-year (e.g. multi-subsidiary deal becomes a single parent contract), don't treat the consolidation as a logo gain or loss." ], "validationChecks": [ "Count is a positive integer.", "New Customers Added × ACV ≈ New Business ARR within ~1% rounding — material divergence means the two metrics use different logo definitions.", "Trend should be smooth at steady state; large step-functions usually indicate a CRM data-cleanup or logo-unit change, not a real-world event." ], "commonMiscomputations": [ "Counting expansion deals or sub-account adds as \"new customers\" — inflates the acquisition signal.", "Logo-unit inconsistency across periods (parent in Q1, billing-entity in Q2) — produces phantom growth or shrinkage.", "Using signing-date here but go-live-date for New Business ARR — ASP becomes nonsense.", "Counting trial conversions twice (once when trial started, once when paid contract began).", "Including customers in the count whose contract never went live (lost-to-implementation churn happens before live-ARR but after counting)." ] }, "metricBasis": { "timeBasis": "period_flow", "dateBasis": "go_live", "production": "primary" } }, { "rogueId": "sales.new_opps_added_value", "slug": "new_opps_added_value", "domain": "sales", "defaultLabel": "New Opportunities Added", "description": "Total dollar value of new opportunities entering the pipeline during the period — the top-of-funnel inflow line in the pipeline flow. The single best read on the marketing-and-SDR engine's output. Common pitfall: counting inflated, un-qualified opportunities (e.g. every demo request) overstates the engine's output; restrict to opportunities that pass a defined qualification stage (typically SQL or higher) before counting. Boards expect this number to track forward quota — a quarter's top-of-funnel should be ~1× the same quarter's quota for a normal sales-cycle business.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "New Opportunities Added (Value) = Σ deal_value across opportunities that entered the pipeline during the period (using the same qualification-stage floor and value convention as upstream metrics). Excludes deals re-opened from closed-lost (those should be tracked separately to avoid double-counting top-of-funnel).", "whyItMatters": "Marketing/SDR output measured in dollars — directly determines whether future periods will have sufficient pipeline coverage. Trending down with stable conversion = future-period miss baked in 1–2 cycles out.", "interpretationGuidance": "New opportunities added should run ~1× of the comparable-period quota at steady state (i.e. the period's top-of-funnel feeds roughly the same period's closes via the sales cycle). Sustained sub-quota top-of-funnel for 2+ quarters is the canonical signal to invest in marketing or SDR capacity.", "relatedKpiIds": [ "sales.pipeline_value", "sales.opening_pipeline_value", "sales.pipeline_deal_count", "sales.pipeline_flow", "sales.win_rate" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across opportunities that ENTERED the pipeline during the period — the top-of-funnel inflow line in the pipeline flow.", "Use the same qualification-stage floor (typically SQL or higher) and the same value convention as the upstream pipeline metrics." ], "exclusionRules": [ "Deals re-opened from closed-lost — track those separately to avoid double-counting top-of-funnel.", "Opportunities below the qualification floor (raw demo requests, unqualified inbound).", "Value already counted in the opening pipeline — only net-new entrants this period count." ], "requiredInputs": [ "Opportunity entry / creation dates and deal_value.", "The qualification-stage floor and value convention.", "Comparable-period quota for the benchmark read." ], "dataSourcePriority": [ "CRM opportunity-created report for the period.", "Marketing / SDR attribution system as a cross-check on engine output." ], "edgeCases": [ "Re-opened closed-lost deals: exclude or track separately so the engine output is not double-counted.", "A mega-deal entering pipeline skews the inflow — inspect alongside the count of new opportunities.", "Deals created late in the period: attribute by entry date, consistently." ], "validationChecks": [ "This is the inflow term of the pipeline-flow identity: opening + new_opps_added − `sales.closed_won_value` − `sales.closed_lost_value` − scrubs = closing pipeline (see `sales.opening_pipeline_value`). The flow must reconcile to the penny.", "New opportunities added ≈ 1× comparable-period quota at steady state; sustained sub-quota top-of-funnel for 2+ quarters is the canonical future-miss signal." ], "commonMiscomputations": [ "Counting un-qualified opportunities (every demo request) — overstates the marketing / SDR engine output.", "Counting re-opened closed-lost deals as new top-of-funnel — double-counts pipeline generation.", "Using a different value or stage-floor convention than the rest of the pipeline flow so the reconciliation breaks." ] }, "metricBasis": { "timeBasis": "period_flow", "production": "primary" } }, { "rogueId": "sales.opening_pipeline_value", "slug": "opening_pipeline_value", "domain": "sales", "defaultLabel": "Opening Pipeline Value", "description": "Total pipeline value at the start of the period — the baseline against which the period's pipeline flow (+ new opportunities − won − lost = closing) reconciles. Equal to the prior period's closing pipeline by construction. Surfaces in sales.pipeline_flow as the `start` slot. Common pitfall: restating opening pipeline to retroactively \"clean up\" stale deals masks the hygiene problem rather than addressing it; cleanup should happen via explicit \"old-deal scrub\" lines in the flow, not by editing the opening baseline.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Opening Pipeline Value = Total pipeline value snapshot at period open = prior period's closing pipeline. Identity: opening + new_opps_added − closed_won_value − closed_lost_value − scrubs = closing pipeline.", "whyItMatters": "Without an explicit opening line, the pipeline flow has no anchor and the additions / removals cannot be audited. Boards expect the flow to reconcile to the penny period-over-period.", "interpretationGuidance": "Compare opening pipeline to the period's quota — opening pipeline coverage (opening / quota) is a stronger leading indicator than current pipeline (which has had time for in-period additions). Coverage < 1.5× quota at period open is usually a warning that the period requires above-average in-period generation to land.", "relatedKpiIds": [ "sales.pipeline_value", "sales.new_opps_added_value", "sales.closed_won_value", "sales.closed_lost_value", "sales.pipeline_flow" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.pipeline_assumptions", "slug": "pipeline_assumptions", "domain": "sales", "defaultLabel": "Pipeline Assumptions", "description": "Narrative documenting the key assumptions underlying the pipeline forecast — conversion rates by stage, expected sales-cycle length, segment-mix expectations, and any deal-specific dependencies (e.g. \"we assume Acme renews their POC by end of month and signs the upgrade in Q3\"). Common pitfall: leaving assumptions implicit makes the forecast non-falsifiable — if you don't list the assumptions, you can't identify which one broke when the forecast misses. Renders side-by-side with sales.pipeline_risk_factors in the TwoColumnTextarea widget (sales.pipeline_context_notes container).", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–6 bullet assumptions, each one stating the assumed value/rate and the implication if it diverges (e.g. \"Assumed Q3 win-rate of 28%; each 5pp miss = $X off forecast\").", "whyItMatters": "Makes the forecast falsifiable and post-mortem-able — without an assumptions list, missed quarters get attributed to vague \"execution\" rather than specific assumption failures the next plan should correct.", "interpretationGuidance": "After-the-fact review: which assumptions held and which broke? An assumption that consistently breaks (e.g. \"Q4 always slips\") is a planning-process problem, not an execution problem. Strong commentary names 1–2 assumptions explicitly and provides the sensitivity (\"if conversion holds at 32%, forecast holds; below 28% we are $X short\").", "relatedKpiIds": [ "sales.pipeline_risk_factors", "sales.pipeline_context_notes", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.win_rate" ] }, { "rogueId": "sales.pipeline_context_notes", "slug": "pipeline_context_notes", "domain": "sales", "defaultLabel": "Pipeline Context Notes", "description": "Container handle for the side-by-side contextual notes — pairs sales.pipeline_assumptions (left slot) with sales.pipeline_risk_factors (right slot) in the TwoColumnTextarea widget. Visually positions the \"what we're assuming\" narrative directly next to the \"what could break those assumptions\" narrative, forcing the team to write them in concert (rather than as two independent surfaces that drift apart over quarters). Common pitfall: writing assumptions without their corresponding risks (or vice versa) means the forecast is incomplete — every assumption should pair to a risk factor that captures the failure mode.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — two-slot composite. Left slot = sales.pipeline_assumptions, right slot = sales.pipeline_risk_factors. No additional content; the value of the container is purely the side-by-side rendering, which structurally encourages assumptions and risks to be written together.", "whyItMatters": "Forces a discipline that significantly improves forecast quality — assumption / risk pairs are more useful than either alone because each risk has a sensitivity (how much the forecast moves if the corresponding assumption breaks).", "interpretationGuidance": "Well-constructed pairs read like \"Assume win rate of 28% in Q3 → Risk: Win rate has dropped below 25% in months with competitive entry.\" A board reading the surface should be able to identify every risk's sensitivity by cross-referencing to the assumption.", "relatedKpiIds": [ "sales.pipeline_assumptions", "sales.pipeline_risk_factors", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.key_concerns" ] }, { "rogueId": "sales.pipeline_deal_count", "slug": "pipeline_deal_count", "domain": "sales", "defaultLabel": "Pipeline Deal Count", "description": "Total number of active opportunities in the pipeline (open stages only — excludes closed-won and closed-lost). The volume side of pipeline coverage; paired with pipeline_value gives the average deal size and the deal-count vs deal-size ratio that characterizes the motion shape. Common pitfall: counting non-bona-fide opportunities (orphaned trials, demo requests that never converted to a real evaluation) inflates the number — apply a stage-floor cutoff (e.g. SQL or higher) so the count reflects committed evaluation activity.", "fieldType": "number", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Pipeline Deal Count = Count of opportunities currently in any open stage (qualification through proposal / negotiation). Applies the same stage-floor convention quarter-over-quarter so trend is comparable.", "whyItMatters": "Volume-side health of the funnel — when value rises with falling count, deal sizes are growing (often deliberate up-market motion); when count falls without value compensation, top-of-funnel is the problem.", "interpretationGuidance": "Read alongside average_deal_size and median_deal_size to characterize the motion shape: many small deals (high count / low size) implies a velocity / inside-sales motion; few large deals (low count / high size) implies an enterprise motion; mismatch between intended motion and observed shape is a strategic signal.", "relatedKpiIds": [ "sales.pipeline_value", "sales.average_deal_size", "sales.median_deal_size", "sales.win_rate", "sales.pipeline_stage_metrics" ], "calculationPolicy": { "inclusionRules": [ "Count of distinct opportunities currently in any open stage (qualification through proposal / negotiation) — a point-in-time count.", "Apply a stage-floor (typically SQL or higher) so the count reflects committed evaluation activity, held constant across periods." ], "exclusionRules": [ "Closed-won and closed-lost opportunities.", "Non-bona-fide opportunities below the stage floor (orphaned trials, unconverted demo requests).", "Splitting one multi-product opportunity into several deals — count the opportunity once (hold the counting unit constant)." ], "requiredInputs": [ "Open opportunities with stage at the snapshot date.", "The stage-floor convention." ], "dataSourcePriority": [ "CRM pipeline report at the snapshot date.", "Rev-ops export as a fallback — verify stage hygiene." ], "edgeCases": [ "Stale open deals inflate the count just as they inflate pipeline value — apply the same max-age hygiene rule.", "Parent / child or multi-product opportunities: pick a counting unit (opportunity vs account) and hold it constant with `sales.pipeline_value`." ], "validationChecks": [ "Count is a non-negative integer.", "Identity: `sales.pipeline_value` / pipeline_deal_count = `sales.average_deal_size` — sanity-check the three together.", "Trend should be smooth at steady state; step-changes usually mean a CRM cleanup or stage-floor change, not real-world motion." ], "commonMiscomputations": [ "Counting sub-floor opportunities (every demo request) — inflates the funnel.", "Stage-floor drift across periods — produces phantom count growth / shrinkage.", "Counting closed-won or closed-lost deals in the open-pipeline count." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "sales.pipeline_flow", "slug": "pipeline_flow", "domain": "sales", "defaultLabel": "Pipeline Flow", "description": "Container handle for the additive / subtractive pipeline-flow bridge — reconciles opening pipeline to closing pipeline through the period's adds, wins, and losses (opening + new_opps − closed_won − closed_lost = closing) with dual count + value columns. Renders via the FlowSubform widget. The audit trail of the pipeline motion — without this, period-over-period pipeline changes are unexplained. Common pitfall: a \"scrub\" line (deals reclassified from open to lost mid-period) is needed to keep the math reconciling when CRM hygiene happens; without it the flow appears not to balance and trust in the underlying numbers erodes.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — start/end slots with dual (count + value) columns. Identity that must hold: opening_pipeline_value + new_opps_added_value − closed_won_value − closed_lost_value − scrubs = closing pipeline_value. Same identity holds on the count side using deal counts. Any gap surfaces a data-quality issue worth root-causing before next period.", "whyItMatters": "Makes the period's pipeline changes auditable line-by-line — boards can immediately see whether closing pipeline shrank because deals closed (good) or because deals were lost / scrubbed (bad). Without the flow, only the net change is visible and the underlying motion is opaque.", "interpretationGuidance": "A healthy flow shows new_opps_added ≈ (closed_won + closed_lost) at steady state (top-of-funnel replacing what closes). When new_opps_added consistently lags closes, the closing pipeline shrinks period-over-period — future quarters will run into coverage stress. Disproportionate scrubs (large negative reclassifications) signal a CRM hygiene problem that's been suppressed.", "relatedKpiIds": [ "sales.opening_pipeline_value", "sales.new_opps_added_value", "sales.closed_won_value", "sales.closed_lost_value", "sales.pipeline_value", "sales.pipeline_deal_count" ] }, { "rogueId": "sales.pipeline_key_deals", "slug": "pipeline_key_deals", "domain": "sales", "defaultLabel": "Pipeline Key Deals", "description": "Container handle for the field-array of key in-flight deals — each entry tracks deal name, current stage, dollar value, and confidence/commit status. Renders via the CollapsibleFormItemCardGallery widget (a reused gallery pattern shared with HR keyHires / keyOpenings). The \"named deals the board should know about\" surface — typically the top 5–10 deals by value or strategic importance. Common pitfall: a static list that doesn't reflect the current quarter — these should be refreshed each period to reflect actual top-of-mind deals, not carried forward from prior packs.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — field-array of items (name, stage, value, confidence). No aggregate calculation; the surface's purpose is to make individual deals visible at the board level. Sum of values across the items typically represents a meaningful share (≥ 25%) of the period's quarterly forecast.", "whyItMatters": "Concentrates board attention on the specific deals whose outcomes will determine the quarter — sales leaders often have valuable context (executive relationships, partnership levers) that only the board can deploy. Without named-deal visibility, board help on big deals happens reactively.", "interpretationGuidance": "If the top 5 deals represent > 60% of the weighted forecast, the quarter is concentration-risky — any single slip is catastrophic. A healthy distribution has the top 5 below 50% of forecast. Track deal-mention persistence across quarters: deals that have appeared 2–3 quarters in a row at \"high commit\" without closing usually have a structural issue that's been missed.", "relatedKpiIds": [ "sales.pipeline_value", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.average_deal_size", "sales.median_deal_size", "sales.win_rate" ] }, { "rogueId": "sales.pipeline_quarterly_forecasts", "slug": "pipeline_quarterly_forecasts", "domain": "sales", "defaultLabel": "Pipeline Quarterly Forecasts", "description": "Container handle for the addable per-quarter forecast rows — each row tracks quarter, totalPipelineValue, weightedPipelineValue, expectedCloses (committed forecast), and dealCount. Rendered via the AddableQuarterlyForecastTable widget. Provides the multi-quarter forward visibility view the board reviews to validate the next 2–4 quarters of revenue, not just the current quarter. Common pitfall: filling in only the current quarter and treating future quarters as \"we'll figure it out\" — multi-quarter forecasting forces honest top-of-funnel planning for the periods beyond the immediate one.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — addable rows of (quarter, totalPipelineValue, weightedPipelineValue, expectedCloses, dealCount). Per-row: totalPipelineValue = same as sales.pipeline_value for that quarter; weightedPipelineValue = same as sales.weighted_forecast; expectedCloses = same as sales.quarterly_forecast; dealCount = pipeline deal count attributed to that close period.", "whyItMatters": "Forward-quarter coverage view — the board needs to see whether next-quarter and next-next-quarter pipelines look credible, not just current. Many revenue misses are visible 2 quarters out if the multi-quarter pipeline view is honest; without this surface, the only data point is \"current quarter looks ok.\"", "interpretationGuidance": "Next-quarter pipeline coverage should be ≥ 2× quota at the start of current quarter (giving the cycle time to fill in). A pattern of pipeline shrinking quarter-by-quarter from current to current+3 = top-of-funnel capacity gap that demands investment now (3+ months before the affected revenue period).", "relatedKpiIds": [ "sales.pipeline_value", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.pipeline_deal_count", "sales.new_opps_added_value" ] }, { "rogueId": "sales.pipeline_risk_factors", "slug": "pipeline_risk_factors", "domain": "sales", "defaultLabel": "Pipeline Risk Factors", "description": "Narrative listing the material risks to pipeline conversion or deal timing — specific deal slips, segment headwinds, budget freezes, competitive entry, ICP-fit misses on late-stage deals. Distinct from sales.key_concerns (which covers the whole sales motion) — this is specifically about the forecast / pipeline conversion math. Common pitfall: vague risks (\"market is choppy\") aren't actionable; a useful entry quantifies the at-risk dollar amount and names specific deals or segments. Renders side-by-side with sales.pipeline_assumptions in the TwoColumnTextarea widget.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–5 bulleted risks, each quantified ($X at risk if Y materializes) and time-bound (in-quarter vs structural).", "whyItMatters": "Surfaces the forecast tail risk early enough for the board to engage — large-deal slip risks often have customer-side levers (CEO outreach, partnership offer) that only the board can pull. Without this surface those interventions happen reactively at quarter-end.", "interpretationGuidance": "Quantified risks (with dollar amounts) are actionable; un-quantified ones consume meeting time without producing decisions. Boards typically ask the team to rank the top 3 risks by expected loss and confirm mitigation owners — a healthy entry pre-empts this.", "relatedKpiIds": [ "sales.pipeline_assumptions", "sales.pipeline_context_notes", "sales.weighted_forecast", "sales.quarterly_forecast", "sales.key_concerns", "sales.competitive_alerts" ] }, { "rogueId": "sales.pipeline_sales_cycle", "slug": "pipeline_sales_cycle", "domain": "sales", "defaultLabel": "Sales Cycle Quarter-to-Quarter", "description": "Container handle for the three-section quarter-over-quarter compare object that tracks average days-to-close trend (lastQuarter / thisQuarter / improvement). Renders via the QuarterToQuarterImprovementGrid widget with three slots. The \"is the motion getting faster or slower\" diagnostic — cycle length trend is one of the most reliable leading indicators of ICP fit and packaging quality. Common pitfall: comparing without controlling for deal-size mix — if up-market mix is shifting, a flat cycle is actually an improvement (because up-market cycles are inherently longer). Note the mix context in commentary if material.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "recommended", "seriesC": "recommended", "public": "recommended" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — three-slot composite. lastQuarter and thisQuarter slots = average sales cycle in days (sales.avg_sales_cycle_days for that period). improvement = (lastQuarter − thisQuarter) / lastQuarter × 100 (positive = cycle compressed = better). When deal-size mix changes materially, the slots should be ACV-segmented separately and the improvement read per segment.", "whyItMatters": "Cycle compression compounds dramatically — a 20% reduction in cycle time roughly translates to a 20% capacity increase for the same headcount. Cycle expansion does the inverse and usually predicts future-period coverage stress.", "interpretationGuidance": "Cycle compression of 10%+ QoQ at constant ACV mix is a strong signal that ICP / pricing / sales-process changes are working. Expansion of 20%+ at constant mix is the canonical \"something is broken in the buyer journey\" signal — usually procurement, security, or competitive friction worth a stage-by-stage diagnosis.", "relatedKpiIds": [ "sales.avg_sales_cycle_days", "sales.pipeline_stage_metrics", "sales.avg_contract_value", "sales.win_rate", "sales.pipeline_value" ] }, { "rogueId": "sales.pipeline_stage_metrics", "slug": "pipeline_stage_metrics", "domain": "sales", "defaultLabel": "Pipeline Stage Metrics", "description": "Container handle for the per-stage pipeline metrics grid — for each pipeline stage (qualification, discovery, evaluation, proposal, negotiation, closing) tracks dealCount, totalValue, closingProbability, winRateFromStage, and avgTimeToClose. The most diagnostic surface in the pipeline view: where deals are bunching, which stage is the bottleneck, where conversion math is breaking. Rendered via the StageMetricsGrid widget seeded from PipelineStageValues. Common pitfall: trusting unchanged stage probabilities even as the deal mix shifts — re-calibrate the per-stage close rates quarterly against actuals or the weighted forecast drifts unreliably.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Container — no scalar calculation. Per-stage rows: dealCount and totalValue are direct sums; closingProbability is the empirical historical close rate from that stage; winRateFromStage is the historical win rate of opportunities that reached that stage; avgTimeToClose is the average days from stage entry to close-won. Closing probabilities should be back-tested against actuals every 1–2 quarters and updated explicitly.", "whyItMatters": "Localizes pipeline problems to specific stages — flat pipeline value with a stage-2 buildup means lead-qualification is too loose; stage-5 stall means closing-skill or pricing-objection issues. Without this surface, the weighted forecast is opaque.", "interpretationGuidance": "Look for stage where deal count is bunching disproportionately — that is the current bottleneck. Compare win-rate-from-stage at the entry stage (top of funnel) vs late stages: large gaps imply the team is investing time on low-probability deals. The avgTimeToClose by stage should monotonically decrease (later stage = closer to close); if not, stage definitions are likely misaligned with actual buyer behavior.", "relatedKpiIds": [ "sales.pipeline_value", "sales.pipeline_deal_count", "sales.weighted_forecast", "sales.win_rate", "sales.avg_sales_cycle_days", "sales.pipeline_sales_cycle" ] }, { "rogueId": "sales.pipeline_value", "slug": "pipeline_value", "domain": "sales", "defaultLabel": "Pipeline Value", "description": "Sum of the dollar value of all active deals currently in the sales pipeline — unweighted (raw deal-value sum, not probability-weighted). Boards read this as the top-of-funnel sufficiency check: if pipeline coverage (pipeline value / forecast) drops below the historic conversion-rate-implied threshold, the forecast is at risk. Common pitfall: confusing pipeline value with weighted forecast — the unweighted number always exceeds the weighted, often by 3–5× depending on the stage mix. Always report both and the implied conversion ratio.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Pipeline Value = Σ (deal_value) across all open opportunities in stages between qualification and signature (excludes closed-won and closed-lost). No probability weighting — for that, see sales.weighted_forecast.", "whyItMatters": "The capacity number for the forecast — without sufficient pipeline value, the forecast is structurally unachievable regardless of close-rate execution. Coverage ratio (pipeline / quota) is the first read on whether the team can hit the period.", "interpretationGuidance": "Typical SaaS pipeline-coverage benchmark is 3× quota for the current quarter and 4–5× for the next quarter (industry folk-wisdom — varies meaningfully by historical win rate; the right multiple is 1 / historical-win-rate, not a fixed number). Coverage below the historic-conversion-implied threshold is the canonical \"you will miss\" signal.", "relatedKpiIds": [ "sales.weighted_forecast", "sales.pipeline_deal_count", "sales.average_deal_size", "sales.win_rate", "sales.quarterly_forecast", "sales.pipeline_stage_metrics" ], "calculationPolicy": { "inclusionRules": [ "Σ deal_value across all open opportunities in stages between qualification and signature — a point-in-time snapshot of the live pipeline.", "Unweighted: raw deal-value sum, NO probability weighting (for the probability-weighted number see `sales.weighted_forecast`).", "Apply a consistent stage-floor (typically SQL or higher) and the same value convention (TCV vs ACV) used across the other pipeline metrics." ], "exclusionRules": [ "Closed-won and closed-lost opportunities — those have left the pipeline (see `sales.closed_won_value` / `sales.closed_lost_value`).", "Probability-weighting of any kind — that is `sales.weighted_forecast`.", "Non-bona-fide opportunities below the stage floor (orphaned trials, demo requests that never became a real evaluation)." ], "requiredInputs": [ "Open opportunities with stage and deal_value at the snapshot date.", "The stage-floor and value (TCV / ACV) conventions.", "The current / next-period quota for the coverage read." ], "dataSourcePriority": [ "CRM pipeline report (Salesforce / HubSpot) at the snapshot date.", "Rev-ops pipeline export as a fallback — verify stage hygiene first." ], "edgeCases": [ "Stale \"open\" deals that should be closed-lost inflate pipeline value; enforce a max-age auto-flag so coverage is not overstated.", "A few oversized mega-deals can dominate the sum — inspect alongside `sales.average_deal_size` / median for concentration risk.", "Mid-stage re-scoping: use the current deal_value, consistently across the series." ], "validationChecks": [ "Pipeline value ≥ weighted forecast always (unweighted exceeds weighted, often 3–5× by stage mix) — if not, the weighting is wrong.", "Coverage ratio (pipeline value / quota) should be read against 1 / historical-win-rate, not a fixed 3× folk number; coverage below the historic-conversion-implied threshold is the canonical \"you will miss\" signal.", "Identity: pipeline_value = `sales.pipeline_deal_count` × `sales.average_deal_size`." ], "commonMiscomputations": [ "Reporting the weighted forecast as pipeline value (or vice versa) — the unweighted-vs-weighted distinction is the entire point of the two lines.", "Counting closed deals or sub-floor junk opportunities — overstates coverage.", "Switching the TCV / ACV convention between pipeline_value, `sales.closed_won_value`, and `sales.weighted_forecast` so the dashboard math stops reconciling." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "sales.quarterly_forecast", "slug": "quarterly_forecast", "domain": "sales", "defaultLabel": "Quarterly Forecast", "description": "The team's expected closed-won dollars for the current quarter — usually a sales-leader judgment call informed by weighted forecast but adjusted for deal-by-deal commit confidence. Distinct from weighted_forecast (which is mechanical, stage × probability). Boards read both: a quarterly_forecast materially below weighted_forecast means the team has explicit negative judgment on specific big deals; above it means they're calling deals stronger than the stage probabilities suggest. Common pitfall: anchoring the call to plan rather than reality — boards quickly learn to discount \"we will hit plan\" forecasts and reward calibrated commit-vs-actual track records.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Quarterly Forecast = Sales leadership's committed call on closed-won dollars for the current quarter. Convention: blends weighted forecast (mechanical) with deal-by-deal judgment overlays (commit / best-case adjustments). Typically reported as a single point estimate; some teams report commit / forecast / best-case ranges.", "whyItMatters": "The number the board commits against — quarter-end attainment vs this number is the primary execution scorecard. Track forecast-accuracy (forecast vs actual) over time to calibrate trust in the call.", "interpretationGuidance": "Forecast attainment within ±5% over 4+ quarters = well-calibrated forecast and a leader the board can rely on. Persistent over-shoot = sandbagging (rebase quota); persistent under-shoot = forecasting / qualification problem worth a methodology change. The drift between weighted forecast and quarterly forecast is itself a signal — large gaps demand explicit explanation.", "relatedKpiIds": [ "sales.weighted_forecast", "sales.pipeline_value", "sales.closed_won_value", "sales.win_rate", "sales.pipeline_quarterly_forecasts" ], "calculationPolicy": { "inclusionRules": [ "Sales leadership's committed call on closed-won dollars for the current quarter — a point-in-time judgment number.", "Blends the mechanical weighted forecast with deal-by-deal commit / best-case judgment overlays.", "State the reporting convention explicitly (single point estimate vs commit / forecast / best-case range)." ], "exclusionRules": [ "The mechanical stage × probability number itself — that is `sales.weighted_forecast`; the quarterly forecast is judgment-adjusted, not mechanical.", "Unweighted pipeline capacity — `sales.pipeline_value`.", "Plan / quota — the forecast is a reality call, not the plan number." ], "requiredInputs": [ "`sales.weighted_forecast` as the mechanical anchor.", "Deal-by-deal commit-confidence overlays from the sales team.", "Current-quarter boundaries and quota for the attainment read." ], "dataSourcePriority": [ "Forecast-call system / CRM forecast categories (commit / best-case).", "Sales-leadership judgment captured in the weekly forecast review." ], "edgeCases": [ "Forecast materially below weighted forecast = explicit negative judgment on specific big deals; above it = calling deals stronger than the stage probabilities — both demand an explicit explanation.", "Anchoring the call to plan rather than reality — boards quickly discount \"we will hit plan\" forecasts and reward calibrated commit-vs-actual track records." ], "validationChecks": [ "Track forecast accuracy (forecast vs actual `sales.closed_won_value`) over 4+ quarters: within ±5% = well-calibrated; persistent over-shoot = sandbagging; persistent under-shoot = a forecasting / qualification problem.", "The drift between `sales.weighted_forecast` and quarterly_forecast is itself a signal — large gaps require commentary." ], "commonMiscomputations": [ "Reporting the mechanical weighted forecast as the quarterly forecast (or vice versa) — they are different numbers by construction.", "Anchoring the call to plan / quota rather than to deal-by-deal reality.", "Comparing attainment against pipeline value instead of against the committed forecast." ] }, "metricBasis": { "timeBasis": "point_in_time", "production": "primary" } }, { "rogueId": "sales.starting_arr", "slug": "starting_arr", "domain": "sales", "defaultLabel": "Starting ARR", "description": "Opening ARR at the beginning of the period — the baseline against which the period's ARR waterfall (new + expansion − downgrades − churn) reconciles to ending ARR. Equal to the prior period's closing ARR by construction. The FlowSubform widget binds starting_arr as the `start` slot of the ARR-bridge flow, and the ending position is computed as start + Σ(deltas). Common pitfall: restating starting_arr mid-period to \"fix\" a prior-period reporting error breaks the period-over-period audit trail; corrections should land as a separate restatement note, not by editing the opening balance.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance", "Sales" ], "stageRelevance": { "preSeed": "core", "seed": "core", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Starting ARR = ARR snapshot at period open = the prior period's closing ARR. Identity that must hold: starting_arr + new_business + expansion − downgrades − churn_arr = ending ARR (sales.arr at period close). Reconcile any gap as a \"data quality\" line and root-cause it before next period.", "whyItMatters": "The anchor of the ARR waterfall — without an explicit starting point, the period's net-new ARR cannot be audited. Boards expect the waterfall to reconcile to the penny, period over period.", "interpretationGuidance": "If starting_arr ≠ prior-period ending ARR, there is either a restatement or a data issue — surface it explicitly. Beyond that the value itself is descriptive, not interpretive; the interpretive work happens on the delta lines.", "relatedKpiIds": [ "sales.arr", "sales.new_business", "sales.expansion", "sales.churn_arr", "sales.downgrades" ], "calculationPolicy": { "inclusionRules": [ "ARR snapshot at the exact open of the period.", "By identity, equals the prior period's closing ARR (`sales.arr` at prior period close)." ], "exclusionRules": [ "Any in-period activity (new business, expansion, churn, downgrades) — Starting ARR is the opening balance only.", "Restatement corrections — never edit the opening balance to fix a prior error; land corrections as an explicit restatement line." ], "requiredInputs": [ "Prior period's closing ARR." ], "dataSourcePriority": [ "Prior period's board-reported closing ARR (the audited / agreed number)." ], "edgeCases": [ "First period a company tracks ARR: Starting ARR is whatever the historical ARR was at that open; if unknown, disclose as \"first tracked period — opening balance estimated.\"", "Restatement of a prior period: Starting ARR for the current period uses the RESTATED prior close, with the restatement disclosed. Do not silently absorb it.", "Acquisition that closed exactly at period open: decide whether acquired ARR is in the opening balance or appears as an in-period inorganic line, and disclose." ], "validationChecks": [ "Starting ARR === prior period closing ARR. Any inequality is a restatement or a data error — never let it pass silently.", "Starting ARR + New Business + Expansion − Downgrades − Churn === Ending ARR. The waterfall must reconcile to the penny." ], "commonMiscomputations": [ "Restating Starting ARR mid-stream to \"fix\" a prior reporting error — breaks the period-over-period audit trail; corrections belong in a restatement note.", "Using current-period ARR as the starting balance (off-by-one-period error) — the whole waterfall then fails to reconcile.", "Letting Starting ARR drift from prior closing ARR because the two are computed by different teams from different snapshots.", "Folding acquired ARR into Starting ARR without disclosure — masks how much of \"growth\" was inorganic." ] }, "metricBasis": { "timeBasis": "point_in_time", "moneyBasis": "contracted_arr", "dateBasis": "go_live", "production": "computed" } }, { "rogueId": "sales.strategic_context", "slug": "strategic_context", "domain": "sales", "defaultLabel": "Sales Strategic Context", "description": "Executive-summary narrative for the sales section of the board pack — the CRO/CEO's one-screen synthesis of overall sales performance, market dynamics, and the story behind the quarter's numbers. Categorical state derived from operational reporting — no calculation. Renders via ExecutiveCommentary widget as multi-section tabbed prose with per-section word counts. Common pitfall: writing it as a numbers-recap repeats what the KPI table already shows; the goal is the connective tissue — why the numbers moved, what changed in the market, what the next 90 days look like. Boards read this first when scanning the deck.", "fieldType": "text", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Free-text narrative — no calculation. Convention: 3–5 sentences per section across overall performance, market dynamics, and forward outlook. The ExecutiveCommentary widget enforces a soft word-count target per section.", "whyItMatters": "Provides the interpretive frame that turns the raw KPI table into a story the board can debate. Without it, board members default to their own (often wrong) interpretation of the numbers.", "interpretationGuidance": "A well-written entry calls out one or two surprises and links them to actionable next steps; a poorly-written entry just narrates the KPIs back. If the prose only describes what the numbers show, treat it as missing context — push back during pre-read.", "relatedKpiIds": [ "sales.key_concerns", "sales.focus_areas", "sales.competitive_alerts", "sales.arr", "sales.growth_rate_yoy" ] }, { "rogueId": "sales.total_revenue", "slug": "total_revenue", "domain": "sales", "defaultLabel": "Recognized Revenue", "description": "Total revenue recognized under the company's accounting standard (ASC 606 / IFRS 15) during the period — distinct from billings (what was invoiced) and from ARR (an annualized run-rate snapshot). The income-statement top line and the basis for GAAP reporting. Common pitfall: confusing recognized revenue with ARR — for a company with mid-year contract starts, ARR exit will exceed recognized revenue for that year; the gap shrinks as the cohort matures. Boards reviewing a recognition-heavy investor pack should always see ARR alongside revenue to avoid mis-pricing growth.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "preSeed", "seed", "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Finance" ], "stageRelevance": { "preSeed": "recommended", "seed": "recommended", "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Recognized Revenue = Sum of revenue earned during the period under ASC 606 (or IFRS 15). For subscription contracts, recognized ratably over the contract term; for usage / professional services, recognized as delivered. Distinct from bookings (signed contracts) and billings (invoiced amounts). Public-reporting companies should reconcile this line to the income statement.", "whyItMatters": "The audited top line that anchors every GAAP-based valuation multiple, debt covenant, and tax filing. Boards need it to track the path to profitability (revenue − cost), which subscription ARR alone cannot show.", "interpretationGuidance": "For an early subscription business, recognized revenue typically lags ARR by 20–40% on an annual basis depending on contract-start distribution within the year; the gap shrinks at steady state. A material divergence between recognized-revenue growth and ARR growth in the same period usually signals either a billing-policy change or a contract-mix shift (e.g. shift to upfront-billed multi-year).", "relatedKpiIds": [ "sales.arr", "sales.carr", "sales.bookings_backlog", "sales.bookings_backlog_total", "sales.gross_margin", "sales.growth_rate_yoy" ], "calculationPolicy": { "inclusionRules": [ "Revenue earned during the period under the company's accounting standard (ASC 606 / IFRS 15): subscription value recognized ratably over the contract term, usage / overage recognized as consumed, professional services recognized as delivered.", "All income-statement revenue lines for the period — subscription, usage, AND one-time services — because this is the GAAP top line, not a recurring-only run-rate.", "Public-reporting companies: reconcile this figure to the income-statement revenue line." ], "exclusionRules": [ "Bookings (signed contract value not yet earned) and billings (invoiced amounts) — recognized revenue is neither.", "ARR / run-rate snapshots — `sales.arr` is an annualized point-in-time contracted run-rate, NOT period-earned revenue. Keep the two distinct (see edge cases + miscomputations).", "Deferred revenue still on the balance sheet (invoiced-but-unearned) until it is actually earned." ], "requiredInputs": [ "Period revenue split by recognition category (subscription ratable, usage-as-consumed, services-as-delivered).", "Contract start dates and terms (to drive ratable subscription recognition).", "Period boundaries." ], "dataSourcePriority": [ "Audited / reviewed income statement (or the revenue sub-ledger that rolls up to it).", "Billing + revenue-recognition system (Zuora / Chargebee RevRec, NetSuite) when the close is not yet final.", "Spreadsheet revenue schedules only as a last resort — flag uncertainty in the output." ], "edgeCases": [ "Mid-year contract starts: recognized revenue for the year lags exit ARR by 20–40% depending on start-date distribution; the gap shrinks as the cohort matures.", "Multi-year upfront-billed contracts: recognize ratably regardless of the billing schedule — cash and recognized revenue diverge in that period.", "Multi-currency: convert each revenue stream on the period recognition-rate convention; never mix rates within a series." ], "validationChecks": [ "Recognized revenue ≤ cumulative billings to date (absent unbilled / accrued revenue) — a material breach signals a recognition-schedule error.", "Recognized-revenue growth and ARR growth in the same period should move together; a large divergence flags a billing-policy change or contract-mix shift (e.g. shift to upfront-billed multi-year), not a story.", "Sum of the monthly recognized-revenue numbers reconciles to the period total within rounding." ], "commonMiscomputations": [ "Reporting ARR — or MRR × 12, or run-rate revenue × the period count — as recognized revenue. ARR is a contracted run-rate snapshot; for mid-year starts it exceeds recognized revenue, so the swap overstates the GAAP top line. See `sales.arr`.", "Reporting billings or bookings as revenue — invoiced / signed is not earned.", "Dropping one-time services from the GAAP top line (or, conversely, folding them into a \"recurring revenue\" figure) — recognized revenue is ALL earned revenue; recurring-only belongs in `sales.arr`.", "Mixing cash receipts with recognized revenue on upfront-billed contracts — collapses the rev-rec schedule that this line exists to honor." ] }, "metricBasis": { "timeBasis": "period_flow", "moneyBasis": "recognized_revenue", "production": "primary" } }, { "rogueId": "sales.weighted_forecast", "slug": "weighted_forecast", "domain": "sales", "defaultLabel": "Weighted Pipeline Forecast", "description": "Total pipeline value with each deal multiplied by its stage-based close probability — the canonical probabilistic forecast number. More forecasting-useful than raw pipeline value because it accounts for the conversion-likelihood mix across stages (early-stage deals weighted ~10–25%, mid-stage ~40–60%, late-stage ~70–90%). Common pitfall: using globally-flat probabilities (e.g. always 50%) instead of stage-specific calibrated ones — a reliable weighted forecast requires the stage probabilities to be back-tested against actual close rates from prior periods.", "fieldType": "currency", "unit": null, "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "recommended", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Weighted Forecast = Σ (deal_value × stage_close_probability) across all open opportunities. Stage probabilities should be the empirical historical close rate by stage for the comparable cohort (segment / motion / quarter-of-year mix), not arbitrary fractions.", "whyItMatters": "The single most-cited number in the weekly forecast call — the team's probabilistic answer to \"what will we close.\" Boards compare it to commit and quota to assess delivery risk.", "interpretationGuidance": "Weighted forecast trending up while pipeline value is flat usually means deals are advancing through stages (good); trending flat while pipeline grows usually means new deals are entering early stages but not advancing (top-of-funnel-only growth — yellow flag). A weighted forecast meaningfully below quota mid-quarter is the canonical \"you will miss without intervention\" signal.", "relatedKpiIds": [ "sales.pipeline_value", "sales.quarterly_forecast", "sales.pipeline_stage_metrics", "sales.win_rate", "sales.closed_won_value" ], "metricBasis": { "timeBasis": "point_in_time", "production": "computed" } }, { "rogueId": "sales.win_rate", "slug": "win_rate", "domain": "sales", "defaultLabel": "Win Rate", "description": "Percentage of closed opportunities that resulted in closed-won (vs closed-lost) during the period. The single best read on bottom-of-funnel execution and the most direct input to pipeline-coverage math (required coverage = 1 / win rate). Common pitfall: computing win rate without disqualifying \"no decision\" outcomes inflates losses and depresses the rate artificially; the SaaS norm is to either bucket no-decisions separately or track a two-rate view (raw win rate vs ICP-fit win rate excluding no-decisions). Stage-segment cuts (SMB vs Enterprise) usually differ 2×–4× and should be reported separately when volume permits.", "fieldType": "percentage", "unit": "%", "maturity": "general", "suggestedForStages": [ "seriesA", "seriesB", "seriesC", "public" ], "defaultOwningFunctions": [ "Sales" ], "stageRelevance": { "seriesA": "core", "seriesB": "core", "seriesC": "core", "public": "core" }, "definitionSource": { "tier": "editorial", "sourceName": "imboard Editorial", "sourceUrl": null, "sectionRef": null, "publicationDate": "2026-04-01", "attributionNotice": null, "authorityLevel": "imboard-editorial" }, "formula": "Win Rate = (Closed-Won Count / (Closed-Won Count + Closed-Lost Count)) × 100. Excludes \"no decision\" / paused opportunities (track separately). Compute on count basis for execution analysis; compute on value basis (Won Value / (Won Value + Lost Value)) for dollar-weighted view.", "whyItMatters": "Reciprocal of required pipeline coverage — a 25% win rate requires 4× pipeline coverage to hit quota. Drives capacity planning, quota setting, and the pipeline-coverage commit conversation.", "interpretationGuidance": "Typical SaaS win rates (industry folk-wisdom, not citation-grade): inbound-heavy SMB motions 25–40%, mid-market 15–25%, enterprise / outbound-heavy 10–20%. Sharp drops (≥ 10pp over 2 quarters) at constant motion mix is the canonical \"competitive entry\" or \"ICP drift\" signal — investigate loss-reason distribution before changing tactics.", "relatedKpiIds": [ "sales.closed_won_count", "sales.closed_lost_count", "sales.closed_won_value", "sales.closed_lost_value", "sales.pipeline_value", "sales.pipeline_stage_metrics", "sales.competitive_alerts" ], "metricBasis": { "timeBasis": "period_flow", "production": "computed" } } ] }