As I have mentioned on a number of occasions, the XBRL International Taxonomy Architecture Working Group is working to create a business reporting and financial reporting logical model. I am part of that working group. It is my hope that XBRL International will make modifications to the next version of the Financial Reporting Taxonomy Architecture (FRTA) to address:
- interoperability issues between financial reporting taxonomies (i.e. why is the SEC, IASCF, EDINET having to reconcile their taxonomy architectures, the Interoperable Taxonomy Architecture Group),
- XBRL usability issues (i.e. XBRL is too hard for business users to use such as for SEC XBRL filings),
- system implementation issues (i.e. why can't the FDIC and the SEC XBRL implementations work together; why does the SEC have to write 400+ rules to implement XBRL within their system; why don't vendors agree on SEC XBRL error messages)
- software creation issues (i.e. why is it so hard for software vendors to create XBRL software which business users can actually use)
- taxonomy extension issues (i.e. why are SEC XBRL company extensions so inconsistent)
This blog post looks into possible future scenarios of XBRL adoption, taking the realities of the list above into consideration.
What more details about these sorts of issues and how to solve them? If so, you are in luck. I created what I am calling a straw man implementation of the business reporting and financial reporting logical models in order to both show the problems and why they are problems, and to show a solution to the issues outlined above. The straw man implemention also proves the issues are all solvable, showing specifically how to solve them.
Straw Man Implementation
Here is information about my straw man implementation:
- Overview: This is a good starting point, it provides an overview.
- Semantics to XBRL Syntax Mapping: This maps the logical model semantics to its XBRL syntax in my implementation.
- Processing Model: This shows the processing model or steps in working with the business reports.
I do realize that this is a lot of information. All this information is the first step in doing what I want to do. The next step is to take this detailed information and summarize it down to its essence in order to show business users why the efforts of the XBRL International Taxonomy Architecture Working Group to create this logical model are a good thing and why a global standard is better than the proprietary solutions to the XBRL issues (which I mentioned in this blog post) which will be created should XBRL International not address these issues.
As I see it, this is the future of XBRL, be it via a global standard (my preferred option) or proprietary solutions (if nothing is done).
Take a look at this information and let me know what you think.