Why is XBRL What it is?
To many observers, the XBRL standard seems sort of strange. But there was actually a method to what might appear to be madness.
First, let me address the issue of "complexity". Some call XBRL complex. Financial reporting using US GAAP and IFRS has complexities. XBRL had to address the needs of US GAAP and IFRS and other such financial reporting schemes, which have complexities. As such, there is a lot to the XBRL technical standard which must meet those complex use cases. One of the primary areas of complexity is extensibility.
Financial reports are not, and should not, be forms. The Financial Accounting Standards Board (FASB) which publishes US GAAP and the International Accountings Standards Board (IASB) who is behind IFRS or International Financial Reporting Standards consciously provide specific flexibility to economic entities creating financial reports using these two financial reporting schemes. The ability for an economic entity to modify their report model within specific boundaries is a "feature", not a bug.
Does that mean extract information from such reports is a bit more challenging? Yes it does. It means that software applications need to understand that flexibility and be able to adapt to how US GAAP and IFRS financial reports are actually created.
And so, that is why some people tend to criticize XBRL as being "complex"; the XBRL technical specification was consciously constructed to meet the needs of US GAAP and IFRS based financial reporting. That is where XBRL's complexity comes from.
When XBRL was first created back in 2000, RDF was not a published standard of the W3C. The architects of XBRL contemplated using RDF, but since it was not a published standard at the time that really could not happen. The architects of XBRL also contemplated creating everything from scratch but ruled that out. As a bit of a compromise, the architects tried to leverage what they could from the W3C and found that XML, XML Names, XML Base, XML Schema (parts 1 and 2), XPointer, and XLink provided something that could be leveraged.
Frankly, I think the architects of XBRL made a good call. While I would admit that there tends to be a lot of "overhead" from using many different technical standards, those technical standards are solid, they get the job done, and there is a lot of software that helps you avoid technical syntax mistakes.
What I have been able to do is abstract away the technical syntax by focusing on a logical model and working with the logical artifact of XBRL-based reports rather than the technical artifacts. The following graphic helps a reader understand the primitive XBRL technical artifacts and reconcile those to the primitive logical artifacts of my Seattle Method:
There is plenty of material for understanding the XBRL technical syntax. Here is an Very Basic XBRL Primer you might find useful. A more comprehensive explanation of the XBRL technical syntax can be found in The XBRL Book: Simple, Precise, Technical which is now in it's sixth edition.
XBRL is effectively a technical syntax for representing a knowledge graph. Financial reports are sophisticated knowledge graphs. Other business reports are effectively knowledge graphs also. There is a lot that can be learned about knowledge graphs by studying XBRL-based financial reports.
XBRL will typically not be implemented internally by any enterprise. Rather, other technical formats will be used and then that format will be converted into XBRL if needed.
Additional Information:
Comments
Post a Comment