In order to better understand how to verify an SEC XBRL financial filing, or really any digital financial report for that matter, I put together a mind map using VUE which shows all of these semantic objects, the properties of these semantic objects, and the relations between these semantic objects and shows all this information visually.
You can see these semantic objects, their properties, and their relations to one another here in this PDF. (If you want the VUE file, contact me.)
That PDF may seem a little overwhelming to business users, but here is what it means and why this information is important:
- Easier to use software. Look closely at the terms used in that PDF. Contrast those terms to the terms in this PDF which provides a partial overview(XBRL has WAY, WAY more goodies that I am showing) of the XBRL technical syntax. Which terms are easier to understand? Today, pretty much ever software vendor implemented their software for working with business reports along the lines of the XBRL technical syntax rather than financial reporting semantics. That is why software is so difficult for business users to make use of. This will change when software vendors start building financial report creation tools which export XBRL, rather than XBRL technical syntax editors.
- Easier to understand SEC XBRL financial filings. Today it is extremely challenging for an accountant who creates an SEC XBRL financial filing to be sure they have done so correctly (expressing a true and fair representation of their entities financial information); it is even more challenging for management of that company to understand what they are signing off on; and third party verification of this information is challenging because the accountants performing this work have the same issues as the accountants who have created the information in the first place - they really don't understand XBRL or how it works. Understanding the semantic objects, their properties, and their relation to other semantic objects will help accountants, who have to create and sign off that this information is expressed correctly, a "true and fair representation of the reporting entities financial information."
- Higher quality SEC XBRL public company information. Today the quality of all that SEC XBRL public company is not what it needs to be for robust, reliable, easy to use analysis software to do anything particularly useful with all that expensive information. That will change. As accountants, managers, and auditors understand the information (see previous bullet) the information they report will make more sense and will be more useful.
- XBRL will become useful to accountants. Once accountants realize how XBRL makes it easier to create financial reports (I know this is hard to see or believe given the state of things today) because computers can help them in that process; they will use totally different processes for creating their financial reports. "Bolting on" XBRL to the end of an existing process, how does that make anything better, faster, or cheaper?
- Verification tasks/steps for an SEC XBRL financial filing will become clearer and easier. Few people that I talk to are happy with the guidance provided by the AICPA Statement of Position 09-1 for verifying an SEC XBRL financial filing. A paper points out issues with SOP 09-1. The data quality of those filings shows that the SOP needs improving. Neither the SOP nor the paper points out exactly what one needs to do to verify an SEC XBRL financial filing. That PDF above with the semantic objects, their properties, and their relations provides a definitive, finite list of all the things which need to be verified. Those are all the important aspects of an SEC XBRL financial filing which need to be correct, complete, consistent, and accurate; something that the SOP and the paper agree are needed for proper verification. Given the right easy to use software, which enables the proper understanding by accountants and managers, which will lead to higher quality SEC XBRL financial filings because the verification tasks/steps are possible for accountants to effectively execute.
Basically, XBRL will become useful when it disapears into the background and accountants can be sure they are expressing their financial information correctly, completely, consistently, accurately, with fidelity, and with integrity. Focusing on semantics makes this possible.
It is only a matter of time before some smart software vendor figure out how to make their software serve accountants rather than force accountants to struggle with the XBRL technical syntax. How long before you think this kind of software will appear?