Recognizing the Benefits of and Path to Semantic Interoperability
Seven years ago I could not tell you the difference between syntax and semantics. I now understand the difference thanks to countless conversations, lots of reading, and years of trying to figure out how to make XBRL work to serve my needs.
If you are an accountant or an auditor why should you care about semantics? The reason is because the capabilities which XBRL has to express business semantics using a global standard technical syntax, the existence of business standards such as International Financial Reporting Standards (IFRS) and US Generally Accepted Accounting Principles (US GAAP), and the adoption of XBRL by the US SEC and other regulators around the world will change financial reporting.
You likely don't believe me if you don't understand the difference between syntax and semantics or you don't understand that it takes three things to achieve business system interoperability: technical interoperability (i.e. syntax), semantic interoperability, and process interoperability. If you do understand the difference between syntax and semantics, you might not believe me because creating an SEC XBRL filing is so utterly expensive and challenging that it is hard for you to believe that XBRL would ever provide any real value. This is justifiable. Or, you may find it hard to believe that XBRL could be useful because the expensive to create SEC XBRL filings are not all that useful for analysis and certainly don't yet live up to the SEC's promise that XBRL will improve transparency and the general utility of all that public company information they make available via their EDGAR system. If none of those reasons to not believe me are good enough, you can always fall back on the rational that I, being the so called "father of XBRL" is nothing but an XBRL zealot whose opinions are biased. Granted, the appearance of independence is just as bad as an actual lack of independence.
There are plenty of reasons to believe that XBRL is not capable of delivering any real utility. And I could provide all the evidence in the world that a business user could, in fact, make use of XBRL and a new digital model-based paradigm of financial reporting will emerge, disrupting current financial reporting practices not just in the US, but globally. What if all IBM, Oracle, and SAP are right and the last mile of finance will change? What if improved collaboration and workflow tools were created.
What if:
- SEC no longer requires HTML, all filings are to be in the XBRL format: Already, many regulators require only XBRL to be submitted including the Federal Deposit Insurance Corporation and the Bank of Belgium. Why does it make sense to report both XBRL and HTML and have to make sure both versions of the information agree?
- Public companies report to financial institutions using XBRL: What if reporting using XBRL could be make easier, so easy that the cost drops significantly and software leverages semantics and guides business users in the process of creating financial reports and the process becomes better, faster, and cheaper?
- Federal, state, and local governments around the world adopt model-based digital financial reporting: Already two countries, the Netherlands and Australia, have made major investments in what has become called standardized business reporting (SBR). Their goal is to reduce the cost for both those who report and government.
- Model-based digital reporting is adopted for not only financial reporting use cases where it is cutting its teeth; but also for general business reporting use cases: There really is no difference between financial information and non-financial information, both are numbers and text.
If you have been paying attention to my blog you will see that I have not been very shy about commenting on how well the XBRL which is being used for SEC XBRL based financial reporting is working. I have invested all that effort into looking at these SEC XBRL financial filings because I realize that the SEC is the toughest use case which XBRL will ever encounter: the reports are big and complex and extension is allowed. I have used this opportunity to both figure out if XBRL can work and how to use XBRL correctly. All that I have come up with is encapsulated in the phrase: semantic model-based structured authoring.
I can tell you based on my assessment of SEC XBRL financial filings that not only can semantic model-based structured authoring of financial reports work, but it will displace the current practices of using unstructured authoring tools and systems and that there are many software vendors and others placing bets on this approach.
It is my assessment as a certified public accountant with 29 years of experience relating to financial reporting and business reporting that, if implemented correctly, XBRL can make things better, faster, and cheaper. I thought this back in 1998 when I brought this idea to the American Institute of Certified Public Accountants (AICPA), I began to doubt it when we actually struggled to create what became XBRL because of all the challenges, but because of the evidence provided by the SEC's implementation of XBRL I can see not only that XBRL can work, but also how to make it work.
Sticking my neck out, I will go as far as predicting that the first three bullet points above will come to pass within 10 years, maybe sooner. The fourth bullet point is still up in the air, the best hope that I see is for a de facto standard approach to implementing XBRL based on the SEC's implementation. Agreeing on a de facto standard is likely the path of least resistance as I see it.
The biggest benefit that XBRL provides is not the exchange or analysis of the information provided. I know of at least three software products which were taking a structured approach to creating financial information before XBRL even existed. Structured authoring has its advantages. Add to that the US GAAP and IFRS XBRL taxonomies, structured authoring becomes even more compelling. Add to that the investment made by software vendors and the successful interoperability which has existed since about 2003 at the XBRL technical syntax level. Add to that the core financial reporting semantics which the SEC XBRL financial filings show. Add to that the investment software vendors have made in SEC XBRL financial filings creation and the competition between software vendors in the market.
Call me an XBRL zealot if you like...but what if I am right? What if the predictions in my first three bullet points above do come to pass. What will that mean for financial reporting?
What do you think? Before you venture a guess, please take the time to understand the fundamental differences between syntax and semantics.
This document summarizes my evidence that XBRL can be made to work, but is not necessarily the appropriate technical implementation approach: Modeling Business Information Using XBRL. (Or get to it via this location on my blog.)
Reader Comments