Prior-Quarter ACV
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. — Customers KPI, I'mBoard-authored (editorial tier).
I'mBoard-authored (editorial tier)
No public third-party standard anchors this KPI yet, so I'mBoard authors and maintains the definition — transparently labeled as editorial tier. See the ontology methodology for the published vs editorial tier system and the back-attribution workstream.
Rogue ID: customers.prior_quarter_acv
Type: Currency
Domain: Customers
Definition
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.
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.Why it matters
Lets the board read ACV direction at a glance — the single most useful framing of an ACV number is its own trajectory.
How to interpret
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.
Calculation policy
How an AI agent should compute this KPI from messy company data. Free-text rules consumed at reasoning time — not a deterministic DSL. The most common ways to get this wrong are listed under Common miscomputations.
Inclusion rules
- The
customers.avg_contract_valuevalue 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.
Exclusion rules
- 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).
Required inputs
- The prior period's reported ACV (the agreed board number).
- Confirmation that the prior population / logo-unit definition matches the current period.
Data-source priority
- 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.
Edge cases
- 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.
Validation checks
acv_trend ≈ (avg_contract_value − prior_quarter_acv) ÷ prior_quarter_acv.- Equals the prior period's reported
avg_contract_valuewhen the population definition is unchanged.
Common miscomputations
- 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.
Related KPIs
customers.avg_contract_valuecustomers.acv_trend_pctcustomers.total_customers
Source
I'mBoard editorial — authored and maintained by I'mBoard, first published 2026-04-01. No third-party standard is cited for this KPI; when one emerges, the definition is back-attributed and promoted to the published tier (a minor version bump). Read the ontology methodology for the published vs editorial tier system, attribution rules, and dispute process.
Stage relevance
| Company stage | Priority |
|---|---|
| Pre-Seed | Core |
| Seed | Core |
| Series A | Core |
| Series B | Core |
| Series C+ | Core |
| Public | Core |
Suggested for stages: Pre-Seed, Seed, Series A, Series B, Series C+, Public.
Default owning functions
- Sales
- Finance
Machine-readable
- This KPI as JSON:
/api/ontology/customers/prior_quarter_acv.json - All Customers KPIs:
/api/ontology/customers.json - Full catalog:
/api/ontology/index.json
% ARR at Risk
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. — Customers KPI, I'mBoard-authored (editorial tier).
Prior-Quarter Concentration
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. — Customers KPI, I'mBoard-authored (editorial tier).