Did you know that on average, creating an XBRL-based report is about logically organizing on average 11 facts correctly for all on average 125 parts in a financial report and making sure none of those 125 parts is logically inconsistent with or logically contradicts any other report part, preferably using effecient and effective automated processes that leverage Lean Six Sigma philosophies and techniques.
Do you realize that the average fact set of an XBRL-based digital financial report has 11 facts. This is skewed a little because a little over half of the fact sets are [Text Block]s. The information below is for a set of 6,023 XBRL-based financial reports submitted to the SEC by public companies:
Of the 754,430 fact sets there are:
If you want to have a look at some fact sets, see: US GAAP | IFRS.
There are over 20 different software applications that can represent this information correctly about 99.24% of the time. On average, about 89.1% of reports can get at least all of the high-level financial information right. There are six software vendors that consistently get all high-level financial information 97% correct.
There are three software vendors that I am testing to make sure they process 10 different fact set patterns to make sure they do so consistently. After they get all of those 10 correct, then we expand to four different reporting scheme profiles, including both IFRS and US GAAP, to be sure those are all processed consistently.
Once they can process an XBRL-based report correctly, then we focus on creating an XBRL-based financial report correctly. The we test their ability to evaluate the report.
My personal view is the the transition from traditional raw XBRL to Inline XBRL is going to allow for the creation of XBRL-based reports to be partitioned into two distinct tasks: modeling the report correctly and mapping the model into an XHTML presentation layer. This transition will cause a positive leap in information quality.