Best Practices on Data Definitions
From XBRLWiki
| Revision as of 14:36, 14 January 2009 (edit) Javi.mora (Talk | contribs) ← Previous diff |
Revision as of 15:07, 14 January 2009 (edit) Iboixo (Talk | contribs) Next diff → |
||
| Line 1: | Line 1: | ||
| [[Image:Corep_finrep_logo.gif]] | [[Image:Corep_finrep_logo.gif]] | ||
| <br/><br/> | <br/><br/> | ||
| - | Contribution dated 2008-03-06 | + | Contribution dated 2009-01-14 |
| <br/><br/> | <br/><br/> | ||
Revision as of 15:07, 14 January 2009
Contribution dated 2009-01-14
Discussion on the use of the precision and decimal attributes
Contents |
Discussion on the use of the precision and decimal attributes
Definition
XBRL Specification states that in the case of numerical values it is necessary to specify either a decimals or precision attribute so they must not occur together on the same fact element. The CEBS XBRL Network recommends the use of the decimals attribute instead of precision for numerical values in instance documents based on COREP or FINREP taxonomies. The integer value of the decimals attribute defines the number of decimal places to which the value may be considered accurate. It answers the question on how many digits the banking supervisor can trust because the value might be a result of rounding or truncation.
XBRL 2.1 Specification example:
| decimals="2" | The value of the numeric fact is known to be correct to 2 decimal places. | If a value of 10 is reported than the value can range between 9.995 and 10.005 |
| decimals="-2" | The value of the numeric fact is known to be correct to –2 decimal places, i.e. all digits to the left of the hundreds digit are accurate. | If a value of 2002000 is reported than the value can range between 2001950 and 2002050 |
XBRL parsers rely on the decimals attribute to process the rounding of fact values. While consuming instance data, numbers with the desired degree of precision can be produced by the financial regulator. This mechanism is important when aggregated values
must match with the sum of its child item values depending on the rounded number of decimals. For rounding differences that cannot be preclude, each financial regulator defines thresholds for minor rounding variations.
Most financial regulators predefined the accuracy of the data to be reported, ie. in thousand or million. To ease the composition of the data for the reporting institut, the unrounded values of the database can be put into the fact and the decimals attribute defines how the value should be rounded.
The rounding is being done while consuming the data by the financial regulator.
The table below shows how the decimals might be set:
| in thousand | decimals="-3" |
| in million | decimals="-6" |
| accurate value | decimals="INF" or decimals="2" |
| percent | decimals="2" |
Business case
Multinational financial institutions underlying different supervisors must comply with the requirements set in different countries. Often these requirements differ. Regarding the reported values some countries ask for numbers expressed in thousands or millions but some require precise numbers expressed together with cents (or their equivalent). The accuracy of required numbers impacts the validation of these numbers on reporting gates of the supervisors. Especially for multinational financial institutions which use the same set of numbers to report to different supervisors it can lead to issues.
XBRL Perspective on the Business case
The issue mostly concerns the calculation linkbase not being able to calculate properly numbers with a given value of the decimal attribute.
Example below uses two supervisors (1 and 2) and a multinational bank reporting to both of them.
Elements A=B+C+D are modelled in the core taxonomy.
Supervisor 1 imposes use of decimals=”2” and supervisor 2 imposes use of decimals=”-3”.
Multinational bank has following data in their system:
A=4000,00
B=1300,00
C=1300,00
D=1400,00
and reports these numbers to both supervisors.
The validation for supervisor 1 (decimals=”2”) will conduct a calculation for 1300+1300+1400=4000 and produce result “valid”.
The validation for supervisor 2 (decimals=”-3”) will conduct a calculation for 1000+1000+1000=4000 and produce result “not valid”. The instance document will be not accepted at the gate. To be accepted this multinational bank has to change one of the numbers.
For example it would require the bank to change the data from the system (which can be reported without issues to supervisor 1) to:
A=4000,00
B=1000,00
C=1000,00
D=2000,00
for supervisor 2. This leads to another issue if a bank is allowed to report two different set of numbers to two supervisors.
XBRL Best Practice Perspective
Agreeing on a certain value of the decimals attribute and establishing this as a best practice for COREP and FINREP network will help financial institutions deal with creating instance documents. From the current perspective the greater common nominator required by the European supervisors is decimals=”2”. The established common practice could use this value.
An alternative to the use of decimals=”2” would be decimals=”INF” accepting for calculations the values with accuracy as reported. This can however lead to later problems in the databases of supervisors where certain accuracy is allowed (by the field/record definition). If a financial institutions reports numbers with for example 10 digits after comma (1999,3333333333) and the validation engine rounds/truncates the number in the ETL process the inconsistency in calculation will be still in place.
The background for the reporting of values in thousand and millions is historical and with regard to paper-based reports. Most of the reporting in Europe is actually being done electronically, so there is no need to ease the filling of reports by requesting only the main parts of an amount. As explained above, reporting accurate values reduces the complexity of rounding. Another argument for more precise amounts is the definition of rounding thresholds for calculations. Most of the European supervisors use variable thresholds. Sometimes also depending on the number of items included in the calculation or depending on the rounding definition (thousands, millions). Depending on the grade of accuracy of the amounts, smaller thresholds can be defined to adjust the rounding differences.
