XBRL taxonomy — what it is and why filings fail
XBRL is not a file format you can “export to” — it is a dictionary, and your filing has to speak the exact edition in force. A taxonomy expresses the data items, business concepts, relations and validation rules of a reporting framework in machine-readable form. Get the edition wrong and the file is rejected before anyone reads a number, which is why version control is the single most valuable discipline in a reporting function.
1. What a taxonomy actually fixes
For the European Banking Authority’s frameworks, the taxonomy expresses in a technical format the data items, business concepts, relations and validation rules already described by the data point model, and is primarily intended for the transmission of data between competent authorities and the EBA. Three consequences follow for a firm’s own pipeline:
- Concepts are identified, not named. A cell is a combination of a metric and a set of dimensions, so two visually similar cells in different templates can be the same data point — or entirely different ones.
- Structure travels with the data. The relations between concepts are part of the taxonomy, which is what lets a receiving system check consistency automatically.
- Validation is embedded. The rules are part of the framework rather than a separate quality-assurance step bolted on afterwards.
2. Taxonomy and data point model
| Data point model | XBRL taxonomy | |
|---|---|---|
| What it is | A structured representation of the data — business concepts, their relations and validation rules | That model rendered in a technical, machine-readable format |
| Audience | Analysts and IT designing a reporting solution | Systems transmitting and receiving the data |
| Used for | Understanding and mapping | Producing and validating the instance document |
Read in that order, the pair makes sense: the model is the meaning, the taxonomy is the encoding. Teams that map straight to the taxonomy without reading the model tend to produce files that validate and still say the wrong thing.
3. Working with editions
Three habits separate reporting functions that ship cleanly from those that firefight:
- Pin the edition per submission. Record which framework version and taxonomy edition produced each file, alongside the file itself. Without that, a later query about a historical figure cannot be answered reliably.
- Track applicability per module. A release specifies module-level applicability dates rather than one date for everything, so the correct edition can differ between two returns due in the same week.
- Rehearse the change, don’t discover it. Framework releases are published in advance precisely so mapping changes can be made before the first affected reference date.
FAQ
Is XBRL the same as XML?
XBRL is built on XML, but the useful part is the taxonomy — the dictionary of concepts, dimensions, relations and rules that gives the tags meaning. Producing well-formed XML is not the same as producing a valid filing.
Do we need the taxonomy if our vendor handles it?
You need to know which edition was used for each submission, because that is what makes a historical figure reproducible and a rejection diagnosable.
Why did our file fail with no obvious error?
The most common structural cause is a superseded taxonomy edition or a module whose applicability date has moved. Check the edition and the module applicability before checking the numbers.
Related: The data point model · Validation rules · What is supervisory reporting
