Digital Financial Reporting

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?

This is my first draft of an articulation of all the properties of the financial report semantic objects.  (I think I am saying this correctly).  I used an approach which was used when I was working on the XBRL International Taxonomy Architecture working group; I did this using VUE (Visual Understanding Environment).  It is not UML, but it is UML-ish.  I am no expert at this but I think this is getting pretty close to where it needs to be.

Basically, what I did was leverage the business reporting logical model created and change it, expressing it in terms of the Financial Report Semantics and Dynamics Theory and my implementation of the SEC XBRL financial filing logical model.  You can get more information of both of those here on my blog.

More to come...comments welcomed.

I mentioned this a while back with GoAnimate and Scratch.  But this is WAY cooler!

AppBaker lets you build your own iPhone application and from what I read on their web site; building iPad software is soon to come.

I learned recently that there is actually a name for this sort of thing, end-user computing. Another term which describes this area is knowledge-based engineering.  Here is a definition of knowledge-based engineering:

KBE (knowledge-based engineering) can be defined as engineering on the basis of electronic knowledge models. Such knowledge models are the result of knowledge modeling that uses knowledge representation techniques to create the computer interpretable models.

Another way I have put this in the past is that XBRL has a "shape". Unlike native XML where you can go in any direction, XBRL provides "lines" that you have to stay within.  Now, if you look at XBRL from a technical syntax perspective this notion is still applicable but if you add a logical model layer on top of the XBRL technical syntax things get much more interesting.  Why?  Because while the XBRL technical syntax is too hard for business users to work with, the logical model significantly easy to work with.

My vision is that financial reporting would work a lot like TurboTax which is an easy to use interface for creating tax returns; except that "TurboFinancialReporting" would be different in that the user can "change the forms".  What I mean by that is that while TurboTax is easy enough to use, it can only be used for filling out US Tax Forms.  But what if you exposed the taxonomy (i.e. metadata) to the user and allowed the user to edit that metadata?  They remove the US Tax Form metadata, pop in the US GAAP Taxonomy metadata, and then you can create a financial report rather than a tax return.

Now, this may be too much of a leap for most people to make but from what I am seeing, I predect that this sort of application will exist within two years, maybe sooner.

Why would such an application, a "TurboFinancialReporting" application, be better than current approaches to creating financial reports?  Here is why:

• With current approaches such as Microsoft Word, how much does the software application understand about financial reporting?  Zero. But TurboFinancialReporting does understand financial reporting.
• With current approaches such as Microsoft Word, the software cannot help you be sure that the numbers add up correctly.  But TurboFinancialReporting can be sure that information adds up correctly and is otherwise complete, correct, consistent, accurate, has fidelity, and has integrity.
• Reuse of the information is possible by analysts, regulators, or others without rekeying the information.
• Basically many things can be better, cheaper, and faster.

And you don't even need to exchange information using the XBRL global standard format to derive value from this new approach to financial reporting which I call digital financial reporting.  But, you can and likely will.

Finally, this same approach which is being proven by the SEC's use of XBRL for financial reporting of public companies can be used for many other types of business reporting.  Just think of XBRL as a payload of numbers and text which a business user can create and maintain by themselves, without the IT department or any programmer ever getting involved.  Somewhat of a "semantic spreadsheet".