Standard specifications for XBRL attributes (“harmonization topics”):
Convenor: Katrin Heinze katrin.heinze@bundesbank.de
- Functional XBRL expert: Thierry Declerck (DFKI)
- Technical XBRL expert: Roland Hommes (Rhocon)
- Volunteer: Anna-Maria Weber (Bundesbank)
- Volunteer: Ignacio Santos (Bank of Spain)
See the complete set of documents
Objective: Standardize the “harmonization topics” for Financial Supervision and Analysis.
This CWA will provide a first draft standard laying down clear requirements for the precision, decimal, scale, percentages, common dimensions (breakdowns as currency, country, or others), XBRL notation/conventions, best practices, error handling, etc. to be used to be conformant to the standard XBRL taxonomy.
Topics, not standardised by XBRL but which need standardisation (list non-exhaustive):
- Decimals, precision, scale, percentages, …At present, several topics are not standardised in financial reporting to European Supervisors:
- Decimals: number of digits, comma, dot
- Precision; an XBRL attribute in order to report how precise numbers should be; by not having a standard on this, validation errors arise on non-material differences
- Scale: some authorities require reporting in 1000 euro, other in euro.
- Percentage: a percentage can be reported in many ways, e.g. 12, 0.12 or 0,12
- Currency conversion rates are not yet used in the CEBS XBRL reporting. Common practice is the reporting of conversion rates with up to six significant digits, following the standard on Euro conversion rule for irrevocable rates.
- XBRL works with unitRef attributes to be reported in an instance. According to XBRL rules monetary items must have a unit of measure from the ISO 4217 namespace of currencies. The unit “pure” could be used for dimensionless numeric items like percentages or rates. For comparability reasons, this topics needs to be standardised across taxonomies.
- Threshold/tolerance margin: The reporting frameworks FINREP and COREP contain a substantial number of cross-linked cells, be it direct links or links via breakdowns or subtotals. A reporting institution often sources such data from multiple systems, which can cause small rounding differences for cross-linked cells. In such case, exact matching of numbers takes a lot of unnecessary time; this can be solved by including thresholds and tolerance margin mechanisms in the package.
- Reporting institution identification: At present, identification of institutions is not uniform across Europe. Hence, the same financial institution has to cope with different identification mechanisms for each national supervisor.
We want to address this topic in a broader view through the harmonisation effort on “Business Registers”, see below under “improve interoperability of company data”. - Nil, null, zero and blank values: Not all financial institutions (must) submit all reportable cells; this needs standardisation through the appropriate us of nil, null, zero or blank values.
- Non-numeric items: definition and values. Some elements in the framework are string based, with or without patterns, etc.
- Report type (Solo, Consolidated, other options)
- Audit status
- ID and tagging of cells and (sub)totals
- Metadata container with administrative data, feedback parameters and digital signature. An XBRL instance document should be self-containing, which means that all required information is included in the document. Nevertheless, still a number of elements are not included in taxonomies and shouldn’t because they don’t belong to the data model of the framework (The new release of the framework must foresee a standard mechanism to include these metadata). Therefore, in most cases, this information is included in metadata which is structured around the instance document, such as (two examples of common practise):
- Strict nomenclature on file name. The file name then includes codes to facilitate the processing of the instance.
- Including the XBRL root node as child node in another XML structure which contains other child nodes with administrative data.
- Character codification (UTF-8 or others): Several codifications are possible.