Digital Financial Reporting

Most people look at XBRL as simply a means of exchanging information.  For example, in the US public companies exchange information with the SEC using the XBRL format. Others around the world are doing the same. Most of these companies use XBRL because they have to.

But XBRL will enable more than an ability to exchange information.  In fact, the exchange of information is really only a by product of the structured nature of XBRL. As I point out in my book XBRL for Dummies (page 12), XBRL is:

A means of modeling the meaning of business information in a form comprehendible by computer applications.

It is the structured nature of the informationexpressed in XBRL which is the key.  This enables the effective information exchange between business systems. But the structuring of the information causes something else to be structured: metadata.  Looking closely at the US GAAP Taxonomy will reveal that the metadata of financial reporting is articulated in a taxonomy which can be used by a computer software application. That metadata, along with other metadata, will enable software developers to create interesting new software.

As I pointed out in a previous blog post, Microsoft Word is used to create 85% of all financial statements yet Word knows nothing about financial reporting.

Looking at three diagrams will help you understand why this structured metadata and the structured nature of XBRL will enable this interesting new software.

Software today

When a financial statement is created today using Microsoft Word, a highly skilled domain expert has to structure that information into the form of a financial statement within Word.  That highly skilled person has extensive domain knowledge.  They might use some light weight computer algorithms (macros) to assist in the process, but it is mostly a highly skilled domain expert, perhaps with someone else doing the actual typing of information, which hammers out the financial statement.

Then, because the information in the financial statement is unstructured, to reuse the information another domain expert with extensive domain knowledge "cuts and pastes" that financial information into a spreadsheet analysis model or perhaps some other software.

This diagram shows this process: (A) create information, (B) the unstructured information is read by humans or (C) cut and pasted into spreadsheet models, which (D) leads to actionable information, or information which "supports action", information you can do something with. 

Rather than "cutting and pasting" the information you could do what Edgar Online has been doing for years which is creating parsing routines which minimize the need for "cut and paste" and use software algorithms to parse the information.  Edgar Online parses SEC HTML and SGML filings and then makes the information available to those that use the information, for example analysts.

A key point to realize here is that these parsing routines are driven by domain metadata. It is those computer understandable algorithms and metadata which allows a computer to recognize that, say, a piece of information is a specific balance sheet line item.  Rather than the human "cut and paste" by a highly skilled domain expert, it is a computer algorithm and metadata created by highly skilled domain experts and software developers which puts the information where you want it. The key thing to not here is how the domain knowledge moved around a bit. 

Semantic, Structured, Model-based Authoring

What if we moved this metadata and some of these algorithms to the creation end of the financial statement creation, rather than the reuse end?  That is what semantic, structured, model-based authoring is all about. The unstructured form and the need to parse the unstructured form into some more useful structured form is totally eliminated because the information is structured in the first place.

How does this happen? Magic? Voodoo? Artificial intelligence? Nope, it happens because of the metadata.  Computers may not be able to do everything for the user who wants to create a financial statement, but there is an incredible amount that a computer can, and will, do.  Human effort is reduced by the algorithms and metadata, costs are saved.  Having a highly skilled domain expert doing cut and paste operations is a waste of their skills.  Using a 10 key to verify that the numbers in the financial statement add up is not only a waste of skill, but humans get tired and make mistakes.  Computers don't get tired.  These repetitive, simple, time consuming tasks can be taken over by computer software leaving the highly skilled domain experts to focus on things like judgment; things a computer will never have.

Metadata

What is the only thing better than metadata?  More metadata. Metadata can take various forms such as business rules, for example:

• Assertions: For example asserting that the balance sheet balances or Assets = Liabilities + Equity.
• Computations: For example, calculating things, such as Total Property, Plant and Equipment = Land + Buildings + Fixtures + IT Equipment + Other Property, Plant, and Equipment.
• Process-oriented rules:  For example, the disclosure checklist commonly used to create a financial statement which might have a rule, "If Property, Plant, and Equipment exists, then a Property, Plant and Equipment policies and disclosures must exist."
• Regulations: Another type of rule is a regulation which must be complied with, such as "The following is the set of ten things that must be reported if you have Property, Plant and Equipment on your balance sheet: deprecation method by class, useful life by class, amount under capital leases by class . . ." and so on.  Many people refer to these as reportability rules.
• Instructions or documentation: Rules can document relations or provide instructions, such as "Cash flow types must be either operating, financing, or investing.

Another type of metadata is relations.  For example, how one concept is related to another concept.

The US GAAP Taxonomy itself is metadata, it defines concepts and relations between concepts used in financial reporting.

Other metadata is the conceptual framework of US GAAP itself. Not all this metadata will be, or even has to be, expressed using XBRL.  It only needs to be understandable to a computer.  Who will create this metadata? Humans who have domain knowledge.

It is this metadata which articulates the semantics which today exist in books and other forms not understandable by computers. It is the semantics which will drive the software. It is the model-based nature, which is really more metadata, which enables this new approach to authoring.

The world is already going down this path. Many software companies started down this path long before XBRL even existed. Many tools already exist for specialized tasks, but they are very expensive.

XBRL International held a webinar which explained the UML model they are creating for XBRL, referred to as the XBRL Abstract Model.  You can watch this 1 hour 34 minute video on YouTube here.

For those serious about understanding XBRL, this video is worth investing in. As stated in the webinar, XBRL International is trying to create two models:

• Primary model: Models semantics.
• Secondary model: Maps modeled semantics to the XBRL technical syntax.

One of the most useful aspects of this video are the very, very good questions which were asked.  The webinar stated that a public working draft of this model would perhaps be available in October.

The semantic model which I have created can be found here. My model, which would fit into the model I saw in the webinar, is more focused on financial reporting and tends to be at a higher level than the model created by XBRL International.

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.

1. How much does Microsoft Word understand financial statements?
2. 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.

One of the most frustrating things in my life is getting a treeview control to do what I want in Excel.  Treeview controls seem very illogical to me in VBA.  Now, in VB.Net this is a different story, they make far more sense.

And because of all the trees or hierarchies you have to deal with when working with XBRL, this adds to the frustration.

I can point to two resources which help semi-technical people trying to work with treeviews:

• This is an article which explains the fundamentals of using a treeview control.
• This is an Excel workbook which has a treeview control in it. Someone gave me this code seven or eight years ago and I have used it over, and over, and over.  I modified it slightly to make it easier to use, but it is good code which can be reverse engineered.
• ADDED: Someone sent me this great tutorial on using the treeview control in Micorosoft Access.
• ADDED: Another person sent me this set of tips which is also very helpful.
• ADDED: Another good reference http://mytreeviewblog.blogspot.com/
• ADDED: MSDN http://msdn.microsoft.com/en-us/library/aa443492(VS.60).aspx

If you run across any documentation which explains working with treeview controls in non-technical terms I would really like to have that documentation.