| Goal "A" |
Human readable rendering |
PDF
|
This is what a human can read. The PDF file was created by applying a style sheet to the XBRL Instance to create XSL-FO which is sent to an open source FO processor which then generates PDF. Rendering XBRL is not particularly challenging, although it is not very effecient if you have to create a style sheet for each XBRL instance. These one-to-one renderings also don't provide you with "interactive data". For more information relating to how to make XBRL "interactive", see here. |
The simple example is what a report looks like today. It may not look like it, but this simple report has all the characteristics of an SEC filing other than the "block text". This simple report focuses on specific issues. Reports are verified today by having an accountant read the report using a 10 key to add up the numbers to be sure everything "ticks and ties". This takes a lot of time no matter how careful one might be, errors can occur. |
| Goal "B" |
Computer readable document (XBRL instance file) |
XBRL Instance
|
This is what a COMPUTER can read. A computer reading and using XBRL is not particularly challenging either. Although to minimize human involvement, one needs to be explicit about the information contained within an XBRL instance. Being explicit is one of the things necessary (not the only thing) to make the information interactive. For more information see the discussion on datacubes on this web page. |
A report of the future; but you still need humans to be able to read this. Not all processes can be automated. Further, not all human involvment can be removed from automated processes. Humans will need to make use of information being exchanged, particularly if there are exceptions. |
|
| 1 |
XBRL syntax validation |
XBRL Validation
|
Ensures that the XBRL syntax is correctly expressed. These days, XBRL syntax validation is not particularly challenging. This publically available validation report provided by XBRL Cloud shows XBRL validation for every SEC filing. See the columns "Errors", "Inconsistencies", "Warnings" and "Best Practices". This includes (or should include) FRTA and FRIS validation. |
Business users could not care the least about this, however they MUST have valid XBRL to create interoperability. |
| 2 |
XBRL Calculations validation (basic business rules) |
XBRL Calculations
|
Computations must add up. The "Inconsistencies" column of the same validation report above shows inconsistencies in SEC filings. XBRL Calculations allows for the validation of some (but not all) calculations. There is no reason to every have calculation inconsistencies in XBRL instances. If things do add up, XBRL calculations validation should show them to add up. If they don't add up, then why were XBRL calculations expressed and provided in the XBRL taxonomy? If things should not add up, simply remove the XBRL calculation links. |
XBRL Calculations only works if the facts are in the same contexts. For example, you cannot validate a movements (roll forward). This is why additional validation is necessary. Clearly ALL the numbers need to add up, not just the ones XBRL calculations can validate. Further, XBRL calcuations can only support addition and subtraction. |
| 3 |
Business rules (expressed by XBRL Formula) |
XBRL Formula
|
Business rules can be expressed using XBRL Formulas. XBRL Formulas does not have the same constraint that XBRL calculations has relating to computing across context or supporting only addition and subtraction. The US GAAP Taxonomy has what is called a "[Roll Forward]". There are quite a few of these and all need XBRL Formulas to automate the validation of these relations. Or, you could use humans to perform this validation, but this takes way more time, costs more money, and is more error prone than an automated validation process. |
XBRL Calculations cannot express all these rules, but if the numbers do have relations, those relations certainly can be expressed. If they can be expressed, then automated processes can be used to verify that the rules are being followed. This is a substantial benefit to both creators of business reports and consumers of the information within a business report. Also, because XBRL Formulas is a global standard with cross software application support, the same set of business rules can be exchanged between the creator and consumer of the business information. XBRL Formulas is not application specific. For more information on business rules see my blog. |
| 4 |
Information model validation |
Information Model Validation
|
If your information model is not modeled correctly (i.e. the taxonomy is not created correctly) bad things will happen. For example, see these errors which are caused by inconsistent taxonomy extensions to the [Table] style of the US GAAP Taxonomy in SEC filings. |
This is particularly true if extension to the taxonomy is allowed. If XBRL extensibility is used, this can lead to poor comparability between XBRL instances. Take a look at this early version of information model validation which has lots of errors. (This information model validation was provided by XBRL Cloud) For more information relating to what an information model is, see my blog. |
| 5 |
System specific validation |
System specific validation
|
Each system has to build system specific rules to the extent that those rules are needed but not provided by XBRL. Different rules used by different systems can cause interoperability issues between systems. For example, consider the differences between the US GAAP Taxonomy, the IFRS Taxonomy and the EDINET Taxonomy which are documented here. |
For example, one such rule is how to structure the entity scheme and identifier of the SEC (i.e. the CIK number). This SEC test suite articulates those rules for the SEC EDGAR system. |