Methodology & trust
How we score vendors, where we surface uncertainty, how fresh the data is, and when the Copilot declines to answer.
Cascading process priorities — process × maturity × sub-requirements
EPM is not one-size-fits-all. A buyer evaluating consolidation against a buyer evaluating workforce planning is in two different markets, and a buyer who needs basic close maturity has very different fit than one who needs advanced Pillar Two-ready tax provisioning. We capture that in three orthogonal axes:
Pick from 10 EPM processes
Planning / Forecasting, Consolidation, Close / Reconciliation, Reporting / Disclosure, ESG / Sustainability, Tax Provisioning, Cost Allocations, Sales Performance, Supply Chain / S&OP, Treasury. Multi-select — most buyers pick 2–4. Mark one as primary.
Basic, Standard, or Advanced — per process
Defines what "good enough" looks like. Vendor below requested maturity for ANY chosen process is eliminated from the shortlist (hard cap). Maturity definitions are process-specific: Standard close means automated reconciliations, Standard planning means rolling forecasts.
Universal + industry-overlay sub-reqs, weighted by importance
Per-process detail (intercompany eliminations, transfer pricing, CSRD reporting, etc.) flagged as Must / Important / Nice. Drives a weighted nudge that surfaces specialists when Must items align with vendor strength, and demotes generalists that are weak in a Must area.
Sub-requirement visibility cascades from your scope: legal-entity count, reporting-currency count, and geographic footprint. A single-entity buyer doesn't see consolidation-only items; a single-country buyer doesn't see country-by-country reporting.
The cascading inputs work alongside the legacy 5-dimension composite (described below). Process priorities drive the maturity hard cap and a bidirectional ±12 importance nudge; the 5-dimension composite still does the heavy lifting on capability depth, ICP fit, ERP compatibility, use-case alignment, and risk.
Source: shared/lib/taxonomy/processes.ts and shared/lib/shortlist-engine/process-priorities.ts.
Five weighted dimensions, one composite fit score
Every vendor is scored 0-100 against your buyer profile across five dimensions. The weights are documented analyst priors — set from published evaluations, practitioner interviews, and vendor evidence, and held deliberately stable. They have not yet been calibrated against post-launch buyer outcomes; as real selection data accumulates, any re-tune is logged with a before/after harness run rather than changed silently. The table below is rendered directly from the scoring engine's own weight constants, so it cannot drift from what the code does.
| Dimension | Weight | What it measures |
|---|---|---|
| Capability | 45% | Strength and depth in the domains your goals imply (FP&A, Close, Consolidation, Reporting, Workforce). The dominant weight — what the tool can actually do. |
| ICP fit | 25% | Organizational fit by revenue band and segment — catches over/under-build mismatches. |
| Use-case depth | 10% | Specific use-case coverage (rolling forecasts, close workflow, intercompany, etc.). |
| ERP compatibility | 10% | Source-system integration depth. Weighted deliberately moderate: a genuine integration blocker is enforced as a hard cap on the composite, not through this weight. |
| Risk & viability | 10% | Financial, acquisition, and implementation risk. Swings a few points — separates close calls. |
Weights sum to 100% and render live from shared/lib/shortlist-engine/weights.ts.
35 EPM, FP&A, and Close vendors
We cover the vendors CFOs and controllers actually shortlist — not a long tail of adjacent tools. If a vendor you're evaluating isn't listed, email us; new coverage is prioritized by reader demand.
2,200+ analyst-curated data points
Every claim maps to a structured field in the vendor dataset, and each data point is labeled verified, reported, or estimated so you can see exactly what is sourced. Customer-reference, risk, vertical-fit, implementation, and ecosystem claims carry cited sources; analyst assessments (verdicts, feature and pricing notes) are labeled analyst-curated. The table below unpacks where the 2,200+ figure comes from.
| Category | Count | Structure |
|---|---|---|
| Profile attributes | 630 | 35 vendors × 18 fields |
| Sub-capability scores | ~1,120 | 35 vendors × 4 domains × ~8 sub-capabilities |
| ERP integration features | ~350 | 35 vendors × ~10 ERP integrations with feature matrices |
| References & flags | ~100 | Customer references, differentiators, risk flags |
| Total | ~2,200 | Every row analyst-curated; sourced sections carry citations |
Every answer ships with its own uncertainty envelope
Scores, timelines, and costs are estimates — not quotes. Each module surfaces an uncertainty level (low, moderate, high), the assumptions driving the estimate, and the sensitivity to profile changes.
Direct vendor match on capability, ICP, and ERP. High-confidence composite.
Partial coverage or inferred fit. Score is directional — verify one or two claims in the dossier.
Sparse data, thin references, or novel scenario. Treat as a hypothesis and pressure-test in discovery.
Where the data comes from and how often it refreshes
Vendor records combine public disclosures (product docs, G2, earnings calls), practitioner interviews, and analyst briefings. Each attribute carries a_sourcesarray so you can see who said what and when.
Cite or decline — the Copilot will not guess
The Copilot is grounded on the vendor dataset. When you ask a question that the data supports, it returns an answer with inline citations. When the data is thin or contradictory, it declines, tells you why, and opens a data-gap ticket so the answer gets better the next time someone asks.
Found a gap, an error, or a vendor we should add?
The whole point is that this gets more accurate as operators like you push back. Send corrections, sources, or missing vendors to the team.