How regulators evaluate XBRL platforms

Buying regulatory reporting technology is a decision that outlives the people who make it. Procurement runs for years. The platform runs for a decade or more. The taxonomies it was built around change underneath it the whole time.

So the evaluation criteria matter more than the vendor list. Here are the ones we see separating good decisions from expensive ones.

Start with the data model, not the feature list

XBRL is a reporting standard from 2003. It solved a real problem: filings a machine can read. But supervision is moving towards granular, API-first data collection, where authorities pull the data they need rather than receive documents about it.

The question to ask any platform: is XBRL one format it speaks, or is it the product itself? If the entire system assumes a document standard, the move to granular collection eventually means replacing the platform. If the system owns the data model and treats XBRL as an output, that move is an iteration.

What does a taxonomy change cost?

Taxonomies are not static. Frameworks update, fields change, new obligations arrive. Over a decade, the cost of change dwarfs the cost of purchase.

Ask specifically: when a taxonomy updates, who does the work, how long does it take, and what does it cost? If the answer involves a vendor release cycle measured in quarters, that is the real price of the platform.

Who owns the validation rules?

Validation is where supervisory judgement lives. If the rules sit inside a proprietary engine, your team works around a black box: raising tickets to change logic they cannot see.

The alternative is validation logic that lives in your repositories, versioned and auditable, changed by your team on your schedule. For an authority that answers publicly for its decisions, auditability of the rules is not a nice-to-have.

Time to production, honestly measured

The UK National Audit Office found five major government digital programmes running a combined 29 years late, with more than £3bn of cost increases.

Those two facts are connected. When delivery takes years, manual process fills the gap. Ask vendors for the honest number: not time to contract, but time to the first filing flowing in production. Then ask what evidence sits behind it.

Total cost per filing

Licence fees are the visible cost. The rest arrives later: per-filing charges, per-entity charges, integration fees, change requests, renewal uplifts. Model the ten-year cost per filing, not the year-one licence.

The exit question

The most revealing question in any evaluation: how do we leave? If leaving means a full replatform, every future negotiation starts from weakness. If the system, its data model and its rules sit in your repositories, leaving is a decision rather than a programme.

The arriving question matters as much. Before you commit, ask the new platform to read the taxonomy you already publish, replay your recent filings and show you a rule-by-rule parity report against what your current system said. If it cannot do that in a week, the migration risk is yours (how a switch in a week works). If you are running a tender, send us the RFP.

What good looks like

A platform that speaks XBRL fluently today and is not welded to it. Validation rules your team owns. Taxonomy changes in days, not release cycles. Production in months. Code in your repositories from day one.

If the platform uses AI, hold it to the same standard as a rule: each AI check tested on your own cases before it runs, retested when the model changes, and every finding traceable to the data and rule behind it (what AI you can audit looks like).

That is the standard we build to. You can read about the SupTech we ship and how Line4.Reporting handles XBRL and structured filings.