This prototype Excel application demonstrates the power of cross business system interaction which is enabled by the XBRL technical syntax and by clear business semantics. This PDF will walk you through using the Excel prototype. Be aware that the Excel workbook contains macros and you might need to adjust your security settings to make this work on your computer.
You can try the application and/or read through the PDF to see what this protytpe application does.
You can understand the point that I am trying to make here by asking yourself two fundamental questions.
- How much does Microsoft Word understand financial statements?
- Why do you have to use so many different things which do not interact with one another when creating a financial statement?
Perhaps these seem like odd questions. Let's look at the first question relating to how much Microsoft Word, the software application which is used to create 85% of all financial statements as I understand it, understands financial statements. Of course the answer is that Word has ZERO understanding of financial statements.
The way a financial statement is created in Word is that someone which has a tremendous amount of understanding about financial statements uses their skills and the word processing features which Word does grasp to create a financial statement. There may be others involved which type information, cut and paste, or whatever; but fundamentally someone with financial reporting domain expertise interacts with a software application which excels at word processing and presentation of information, but knows nothing about financial reporting.
Why is that?
Well, others are asking the same question. That is what model-based reporting is all about. Call it structured authoring which is what was used in the SGML and XML authoring worlds, call it model-based reporting; personally I prefer the term semantic structured authoring or semantic model-based reporting.
I will get to how you can do this in a future blog post. But for now just consider the possibility of a software applicaiton which does understand financial reporting. Why would that not be a good thing?
Now for the second question: Why do you have to interact with so many different pieces when creating a financial statement and none of the pieces interact with the other pieces. For instance:
- You have your Word application, but that does not understand the computations in your financial statement and in fact, it does not even have a calculator built in, but you have hundreds of computations which you need to make sure are correct. So you get out that 10 key.
- You need to look up something from the financial reporting standards issued by the FASB. The FASB brand spanking new codification does not interact with Word, separate application. Or, say you don't even like reading the FASBs but rather prefer Wiley's US GAAP Guide. That does not interact with Word either. No problem, cut and paste what you need and reformat it.
- Accounting Trends and Techniques published by the AICPA is a wonderful tool, as I understand it one of the best selling products of the AICPA. But that does not interact with Word either, other than that same technique of cut and paste.
- The disclosure checklist which you complete to be sure you created your financial correctly, or perhaps your auditors complete, or maybe you use the AICPA checklist; that does not interact with Word either.
- Then there are all those Excel spreadsheets which have information which eventually end up in that Word document. You can get Excel and Word to hook up some times if you work at it, but add one row to that spreadsheet! We have all been there.
- Take the financial for last period and crate a pro forma for the next period. Macros can work to automate this, but not that great. More cut and paste.
OK, so maybe I am wrong here, perhaps there is not a whole lot of accounting skill which goes into creating a financial statement, it seems to primary skill one needs is how to cut, paste, and reformat things between the multiple business systems which are needed to create a financial statement.
What does all of this have to do with my Excel prototype? Well, just know that there is a better way. The key is metadata. Metadata can help a software application understand the semantics of a financial statement or business report from many other business domains. Look at what is driving that Excel prototype, metadata.
Can metadata drive a semantic model-based financial statement creation application? I think we will have the answer to that question within a few short years, perhaps less. How will this impact domain experts? We shall see.