Digital Financial Reporting

Many accountants and auditors find the process of verifying that SEC XBRL financial filings are correct rather challenging.  I certainly understand this being a CPA and ex-auditor and having struggled for years trying to make sure the XBRL I was creating was correct with either no software or early XBRL software tools which were quite technical in nature and rather hard to use.

While software applications for enabling such verification of SEC XBRL financial filings is still rather immature, the software is in fact maturing and verification processes and techniques used in the past are less appropriate today.

A big part of the challenge of making sure your SEC XBRL financial filings is correct is your fundamental philosophy. First off, what exactly does "correct" mean?  I define correct as:

• HTML and XBRL convey the same message
• Integrity: each piece is correct and all the pieces fit together
• Clear and appropriate business meaning/semantics
• Consistency with peers
• Consistency between current and prior periods
• Justifiable extension concepts
• Appropriate rendering
• Usable by analysts

The second challenge is to understand how do you know that everything is correct? Everything which should be there is there, nothing which should not be there is included, and everything which is stated is accurate?

The first tip, forget about the XBRL technical syntax.

Forget about XBRL Technical Syntax

Should the XBRL technical syntax of your filing be correct? Absolutely.  If your software application cannot do this for you so you don't have to worry about it then you likely need better software.

Should your ampersands within an XBRL footnote be double escaped? Of course you ask, "What is this guy talking about?" That is precisely my point.  The Edgar Filing Manual (EFM) says that you need to double escape your ampersands.  Are you going to check for that? Of course not.  Software should not let you NOT comply with that rule.  Verifying these sorts of things can be 100% automated within software, business users need not deal with this.  Besides, the SEC will not accept incorrect XBRL technical syntax, their submission validation process makes sure this is the case.

Another reason you should forget about XBRL technical syntax is this: Can you actually read XBRL technical syntax? Should you be able to? Some people can.  More people think they can but really cannot. Here you go, give it a try:

Here is exactly the same information rendered as an Excel spreadsheet, I call this a fact table:

A fact table shows all the facts and all the characteristics of each reported fact.  Did I change the meaning of the information by moving it from the XBRL syntax to the Excel syntax? Certainly not. Which is easier to read, the XBRL or the Excel?  Notice that there is no syntax information at all in  the Excel such as the context ID.  Clearly you need additional information such as the units and decimal information for numeric values, but the point here is that it is the semantics which are important, not the syntax.

Taking this one step further, here is exactly the same information which was shown in the Excel fact table shown again, this time rendered within an XBRL viewer (in this case XBRL Cloud's XBRL viewer application):

"What do you mean, same information?", you ask. Yes, it is the same information. The information from the Excel table, the fact table, contains the business semantics, the characteristics of the facts being communicated by the SEC XBRl financial filing.  All the rendering application does is the same thing that an Excel pivot table does, it renderings the information into a form which is consumable by business users.

If you look at the business meaning of information contained in an XBRL instance, it might look like the Excel fact table shown above or it might look like the more human friendly rendering. In fact you could and should have both views. Both the fact table and the rendering communicate the same information, but the different forms help you achieve different things. Does how the information is rendered change the business meaning of the information? Certainly not.

I think that while you would probably acknowledge that some software applications are better than others at helping the user to see the business meaning, it is not the case that whether information is rendered in the form of a fact table or in a more human readable form; rendering the information does not change the business meaning.

Reasons Why Syntax Doesn't Matter

I think it would be easy to agree that taking information which is in the XBRL format and putting that information into some other syntax such as Excel spreadsheet, a database, some other form of XML does NOT change the meaning of the information. In fact, it certainly should not because that is a fundamental characteristic of XBRL; the ability to exchange the information between different business systems.

So while the syntax changes when the information contained in an XBRL instance and taxonomy moves from the form of an XBRL instance, into Excel and/or into the form of a database application or some other format; the meaning of the information (the semantics of the information) does not change.

Further, there are different ways to express exactly the same business meaning using the XBRL syntax. 

Consider, for example, that the SEC has rules relating to expressing, which reported information relates to the legal entity "consolidated entity".  In essence, the EFM states that unless you state otherwise, the legal entity is assumed to be the "consolidated entity".  The EFM states something to the affect that by creating an [Axis] and a [Member] for that [Axis], the information expressed in an XBRL instance and its XBRL taxonomy relates to the "consolidated entity".  You use the [Axis] "dei:LegalEntityAxis" and the [Member] "dei:EntityDomain".  Or, you could also NOT physically provide any legal entity [Axis] nor the [Member] (i.e. you do not create a [Table]).  Therefore, no legal entity [Axis] is provided and therefore the legal entity is assumed to be or implied to be the consolidated entity. 

In essence, you can either explicitly state the legal entity or you can imply the legal entity per the SEC EFM rules. 

Does your choice of which approach you use, using or not using the XBRL syntax of a [Table], impact the meaning of the information?  I think that you would agree that it clearly does NOT impact the meaning of your information. Here is an example of what I am talking about, Dow Chemical Company does NOT use a [Table] and Apple DOES use a [Table] to express exactly the same information:

• Dow Chemical Company: SEC Viewer | Taxonomy
• Apple: SEC Viewer | Taxonomy

But wait, there is more! You can take the explicit versus implicit representation of the legal entity one step further. 

In the XBRL syntax, or more accurately the XBRL Dimensions syntax, there is the notion of a "dimension default".  If the dimension default is indicated in an XBRL taxonomy; that dimension would physically not exist within the context for that fact within an XBRL instance. So, does the business semantics of the information change between the options you choose to use the "dimension default" or not use the "dimension default"?  Clearly not. 

Now, under SEC reporting rules, you are always required to use a dimension default.  However, if you do use the dimension default that dimension and the default value of that dimension (a [Domain] or a [Member]) do not physically exist within the context of the XBRL instance.  Does the fact that the syntax rules of XBRL which states that the [Axis] and [Member] in our case the legal entity axis and the value "consolidated entity" expressed using "dei:LegalEntityAxis" and "dei:EntityDomain", but in this case not physically there because of the technical rules of the XBRL syntax; does this change the business meaning of the information?  Clearly not.

Focus on Business Semantics

When you review an SEC XBRL financial filing, do you care that any of the following core financial semantics (meaning) is appropriately articulated:

• Balance sheet reports assets
• Balance sheet reports liabilities and equity
• Balance sheet reports equity
• Balance sheet balances
• Balance sheet foots
• Cash flow statement reports net cash flow
• Net cash flow foots
• Income statement reports net income (loss)
• Income statement foots
• If a classified balance sheet is presented, the balance sheet reports current assets and current liabilities

Now we are talking! This is both understandable to an accountant and/or auditor who is checking to be sure the information is properly articulated and it is also part of the characteristics of a quality SEC XBRL financial filing. And this is just the tip of the iceberg.  Every aspect of an SEC XBRL financial filing can be evaluated in the same way: does it exist, does it foot, does it cross cast, is it the correct concept, are all the pieces correct, do the pieces tie together properly, etc.

Bottom Line

Clearly it is important for the XBRL technical syntax to be correct. Software applications can automatically check to be sure that your escaped XHTML has property double escaped those ampersands. And your software should not bother you with these details, of which there are thousands and thousands.

Accountants and auditors need not consider the XBRL technical syntax when trying to determine if an SEC XBRL financial filing is correct for two primary reasons:

1. You don't understand the XBRL technical syntax, you likely never will understand the XBRL technical syntax, and you never really needed to understand the XBRL technical syntax in the first place.  You will likely always be using the information contained within an XBRL instance and XBRL taxonomy from within some software application built for business users. The software will put the information into a form which allows you to be sure the information is articulated correctly.
2. It is far more effective and efficient to review information in a form which is easy for you to use and understand.  It is the business semantics which you care about, not the XBRL technical syntax. Focusing on the XBRL technical syntax is a waste of time and money.

If your software does not both properly hide the unimportant XBRL technical syntax from you and expose the imporant business meaning of information to you in a form what is useful to you, then start looking for better software.

In a prior blog post I pointed out that creating a financial statement is a collaboration between many parties which exist both within your organization and some of which are external to your organization.

In this blog post I want to point out that there is a workflow which exists when creating a financial statement. Here is a very simplified workflow: create, review, approve, submit.

Clearly one can dig deeper into the many, many details of the workflow of creating a financial statement. The point here though is to simply point out that one should be thinking about workflow when considering software for creating SEC XBRL financial filings.

Further, workflow can be determined by the fundamental approach one chooses for getting their SEC XBRL financial filing created. Popular categories of approaches (which are covered in chapter 11 of XBRL for Dummies) include:

• Bolt on: You basically "bolt on" another process for generating the XBRL to an existing process of creating the Word and HTML versions of your SEC filing. Typically one might purchase an additional software product to generate your XBRL output.
• Out source: Outsourcing is really somewhat of a bolt on approach except that rather than purchasing software which adds the additional needed functionality of generating XBRL, you out source the entire process.
• Integrated: Integrating the creation of the Word, HTML, and XBRL formats into one process is another approach to getting that XBRL generated.  This generally involves purchasing new software which offers XBRL generation or updating to a new version of an existing software product which you use which offers the feature of XBRL output.
• "Roll your own" solution: A type of integrated approach is for you to "roll your own" solution by either creating internal systems which generate XBRL or somehow enhancing the functionality of a third party software product which you use. For example, this article discusses United Technologies use of XBRL.

If you were around when the PC was first introduced, you will recall that initially PCs had a character-based interface.  Think "DOS". That all changed with the introduction of the graphical user interface by Apple on its first Mac. Not everyone believed that the graphical user interface provided an improvement over the DOS character based interface.  But Apple proved the graphical user interface and the user interface paradigm shifted.

A similar paradigm shift will occur with SEC XBRL financial filing software.  If you really consider workflow; the common approaches used today where someone bolts on an additional process or outsourcing the process of generating the required XBRL does little to improve the overall financial statement creation process.  That is why accountants see little value in XBRL today.

When work flow is considered and appropriate software is created the value accountants will see from XBRL and what XBRL enables will change.  When will this change take place? In my view the change is already occurring slowly but surely. The pace will become more rapid over next year, I predict.

Further, I predict that accountants will be using XBRL enabled semantic, structured, model-based authoring software products for creating financial statements whether they need to submit XBRL to some regulator or bank, or not. Why? Because the workflow enabled by technologies such as XBRL will enable more effecient and effective processes.

The creation of an external financial statement is a collaboration between multiple parties. This collaboration is both inter- and intra-organization. The graphic below shows many of the parties which collaborate to create an external financial statement.

Before the internet existed, many of the means of collaboration we take for granted today were either simply impossible or cost prohibitive for all but the largest organizations. As such, collaboration could be considered "efficient" by pre-internet standards. However, by today's standards with the capabilities enabled because of the internet, those same efficient looking processes seem quite inefficient.

Before the internet collaboration with external parties took the form of the postal service, the fax, couriers, etc. Even collaboration with internal parties required these types of resources. Today, we all know that this is different and that anything which is in a digital form or can be put into a digital form can be anywhere on the planet in milliseconds.

But, if you look at the process of creating an external financial statement, how efficient is it? This how Ventana Research describes the process in their white paper Selecting the Right XBRL Solution (2008, page 5): 

All larger companies keep the text and numbers that go into their external reports in multiple enterprise systems and a large number of spreadsheets (usually Microsoft Excel) and text documents created with word processing software (such as Microsoft Word) scattered around on individual hard drives and multiple network directories. People cobble together filings from a large number of text files and spreadsheets in a highly manual, time-consuming and error-prone process.

Gartner tells a similar story in their research report XBRL Will Enhance Corporate Disclosure and Corporate Performance Management (April 23, 2008):

For example, it is estimated that the average Fortune 1000 company used more than 800 spreadsheets to prepare its financial statements for regulatory reporting.

And that describes the internal collaborative process. One would anticipate that the method of collaborating with external participants in this process is similar or likely even worse.

Is there a better way?

The primary objective of XBRL is to enable one business system to exchange information with another business system without the involvement of the IT department. The IT department can exchange information between systems with one hand tied behind their back. But when you get the IT department involved, costs go up.  Plus, without standards the costs go up because all you can build is point solutions which allows interoperability between two systems.  Standards, like XBRL, offer general interoperability.

Are we there yet with XBRL? Not quite, but getting closer.  Today business system interoperability is easier because of standards such as XBRL.  But, you still need that IT department to help out.  Proof of this is the high number of SEC XBRL filers who out source this task.

But in the future there will be better business system interoperability, achieving the interoperability will be easier, and not only will the internal collaboration be easier; but collaboration with external parties will likewise be easier.  Costs will be reduced.  Applying a "bolt on" process, even if that bolt on process is out sourced, simply adds more work.

In a future post I will like at some of the specific types of collaborations involved in external financial reporting and how XBRL and other technologies can enable significant improvements in not only efficiency but also in effectiveness.

So stay tuned!

Inspired by what I had mentioned about linking directly to a component of an SEC XBRL filing (as opposed to having to get the entire filing), a statement made to me by a CPA about how it would be nice if I connected two things together, and some information provided to me by the SEC in response to a question I posed to ask-oid@sec.gov; I created this prototype mashup.

The mashup is similar to several things I already had so it literally only took me two hours to create.  The first puzzle piece was this list of the taxonomiesfor the top 100 SEC XBRL filers by total assets. That is useful, but it leaves a lot to be desired in terms of what I was trying to achieve which is allow a CPA to quickly browse through SEC XBRL an see how others expressed their financial information in XBRL.

The second thing I did was this set of what I call exemplars which allows you to look at information for the same 100 SEC filers as above, but this time, it breaks the pieces of the filings into components; thus letting you focus on one specific component and browse through that by filer.  For example, you could browse through the document information or the balance sheet or the income statement.

The obvious thing which is missing from that exemplar viewer is the actual rendering of the financial report.  If you had that, plus the taxonomy you can really look at SEC XBRL filings in a very helpful way. So when someone showed me that Rivet CrossView Preview, what I saw was this. That was good, it makes it easier to browse SEC filings faster than you can at the SEC web site; but my first question was could I go directly to a component of one filing.  Someone kindly pointed out that I could do that, and then this was the view I was able to have, linking directly to the Exxon income statement.

http://crossview.rivetsoftware.com/financial/Default.aspx?cik=0000034088&accession=0001193125-11-209772&rfile=R2.htm&query=EXXON+MOBIL+CORP

So my next question was: Could I generate the URL from my software, allowing me to autogenerate the links to this information.

Well, I know everything in that URL (the CIK, the accession number, the company name) EXCEPT for that funky "R2.htm".  I new what it was, if you go to this link you can see these pages. But how do you figure out those page numbers?

Well, I looked at the pages and noticed that the pages correlated to the networks in a filing.  So, I tried that and sure enough I was pretty successful predicting which network was in which of those "R" whatever HTML pages.

And that is how I created that mashup of my taxonomy information for one network and the corresponding rendering, complements of the SEC!  Pretty slick.

But, what I noticed is that (a) I cannot be sure this is reliable, in fact it is not reliable. I have some glitch in my algorithm.  If you go to filing #9 (AMERIPRISE FINANCIAL INC) you can see that I have the wrong file for the network I wanted to grab.  My metadata is fine, I point to the correct balance sheet network (i.e. my taxonomy relations are fine).  So, for this reason this approach may not be reliable.  Also, I noticed some filings which have like 60 or so networks and there are only R files which go up to R42.htm.  Not sure what the deal is with that.

Also, if you use those files, you will notice that the handy little pop up with the concept name, references, and other detailed information does not work.

I do believe that you can see how useful this functionality is.  This will help me create this Accounting Trends and Techniquestype functionally for SEC XBRL financial filings.  Do you think something like that would be useful with both the taxonomy relations, the viewer rendering, and all this information usableinto an application which generates XBRL? Let me know.

Someone pointed out an incredibly useful feature of a tool.  If you click on this link, it will take you directly to the income statement of the June 30, 2011 10-Q of Exxon.

That is similar to a feature in another tool which will take you directly to a concept within a taxonomy.  For example, if you click on this link it takes to you to the concept "Cash and Cash Equivalents, Period Increase (Decrease)"in the US GAAP Taxonomy.

I have always tried to build my web pages in that manner.  For example, if you click on this link it will take you to a rendering of the Exxon taxonomy.

The really interesting thing is the ability to string all of this information together, say in some sort of mashup, which provides new information.

What neither of those links really does is make it easy to generate from a computer software application the URLs which you need.  The reason you would want to do this is that you can avoid having to manually create links.