Digital Financial Reporting

The Basic Comparison, SEC XBRL Filing exampleshows issues relating to comparing SEC XBRL filings. If you understand how to read the XBRL instances and XBRL taxonomies or if you dig into the Measure Relations and Fact Groups (Fact Tables), comparability issues jump out at you.

Now granted, the issues will be better seen within a software application actually trying to do a comparison; but I cannot show such an application currently.

Don't be fooled by the simplicity of this example.  It is simple, but it is not simplistic.  The information in the XBRL taxonomy and XBRL instance is concise, but it serves its purpose.

For example, imagine that you want to compare the accounting policies of these three basic SEC XBRL type filings.  How would you do this?  First off, you might try and find the extended link which contains the accounting policies, using that to grab all the accounting policies.  Well, that will not work.  EFM rules state that company extensions cannot use extended links from the US GAAP Taxonomy.  There is an extended link, but each filer needs to create their own extended link. Look closely at the Measure Relations of the ABC Company, XYZ Company, and QQQ Company and you will see what I mean. So, you cannot use extended links for comparisons at all.

OK, the next level down in the taxonomy after the extended link is the [Table].  Just grab the Accounting Policies [Table], use that as the basis for comparison.  This is a great idea, but that will not work either.  The reason is that there is no Accounting Policies [Table] in the US GAAP Taxonomy.  Now, I created one in these three example filings, but although they have the same name, they are from different namespaces (abc:, xyz:, qqq:); they are not the same and will not be seen as the same by software applications.  Another way to understand this is to look at the Nonmonetary Transactions, by Type [Table]. Now that [Table] is comparable as (a) it does exist in the US GAAP Taxonomy, and (b) each filer used that [Table].  A rather simple program can be written to get that [Table], all the concepts in that [Table] (as that is clearly defined in the definition linkbase) and you have your comparison.

But you don't have that [Table] to use.  You may think that you do because in this example you could ignore the namespace prefix but then you would be missing the point here.  Although I named the elements the same in each taxonomy, there is nothing which will ensure that SEC XBRL filers will do this in their filings.  So, perhaps there is some concept that everyone uses in their taxonomy, use that and the presentation relations to find all the accounting policies.  If you go look at real SEC XBRL filings you will see that that will not work.

The bottom line here is that there is no dependable way to do a comparison of accounting policies.  You could spend time and money creating a pretty good software algorithm, but why not make the problem go away so you don't have to spend the time and money to write that algorithm.  Just add an Accounting Policies [Table], require that everyone use that [Table], then compatibility can be easy.  Same deal for other portions of the taxonomy.  This is not to say that everything needs to be required, but base areas such as the accounting policies seem to be something everyone should really have.  Same for the balance sheet, income statement, cash flow statement, other specific disclosures, and other areas.  What might be contained in those [Table]s may be different, but the place to look in each SEC XBRL filing would be the same.  How else would comparability be achieved?

This is just one example, there are many other clues in this basic example.  As is said, the proof will be in the pudding: in actual and useful comparability.  Where the comparability will exist is a decision for the financial reporting domain.  But clearly there should be some comparability at some level.

Have a look at the Basic Comparison example and see what you come up with.  Or even better, load these three simple SEC XBRL filings into your favorite comparison tool and see what you come up with.

To me this blog is a bit like a lab notebook you would keep in science. I endeavor to figure things out, test things, see how things are working and take notes making those notes available on this blog.

As a CPA, I am interested how technologies like XBRL will impact financial reporting. As a business person I am also interested in how XBRL will impact general business reporting.

Over the last three years I have put a lot of focus on the US GAAP XBRL Taxonomy, SEC XBRL filings, and figuring out what it might take make cross business system information exchange work for the average business user. I have many, many posts on my blog relating to this.

In this blog post, what I am doing is going back through my lab book, examining my prior posts, consolidating that information, and trying to better understand the bigger picture and how the pieces of the puzzle fit together. I have summarized my thinking here:  http://www.xbrlsite.com/US-GAAP/.

You can read through that if you wish. I have provided links to details and you can drill into those details should you have that desire.  In the rest of this post, I am trying to make sense of these details, trying to figure out how the future might play out.

Vision

The vision I have is for financial reporting and other types of business reporting to work as elegantly and be as well integrated as an iPhone, iTunes, iPad, iPhoto, iMac.  If you have ever created an iBook you probably understand what I mean. While not perfect, Apple has done a marvelous job of hiding the technology from users while exposing useful functionality.  I would describe how this works as elegant. That is the world I want to work in and do financial reporting.

Imagine external reporting, internal reporting, ad hoc reporting, audit schedules which support the information, analysis of the information, all integrated.  Minimum of re-keying of information, technology helps the process where it can, humans do what they need to do.

Roadblocks

The way I tend to achieve things is to understand where I am going, figure out what is in the way, and eliminate all the things that are in the way and then you end up where you desire to be. What roadblocks exist which need to be removed for my vision to exist? 

• Software: Well first, to make this vision work we need software. Pretty much every piece of software which touches a financial report (or other business report for the bigger use vision) has to be able to exchange information with ever other piece of software. For this to happen, software vendors need to figure out where to cooperate/collaborate and where to compete.
• Standards: The software vendors are going to need to agree on the standards, things like XBRL but XBRL is not enough, which enable this interoperability. This HL7 video (slide 4) points out that for the business benefits of interoperability to occur you need three types of interoperability: technical, semantic, and process.
• Protocols: You can have standards, but within the processes or workflow there needs to be agreed upon protocols. Think about the steps of making a hotel reservation. That is a protocol. Calling the hotel, seeing what is available, getting prices, providing your credit card to hold the room, obtaining a confirmation number.  Similarly protocols are needed in the processes of business reporting.
• Motivation: Why would the average business person want to achieve this vision? Business benefit. Why would a software vendor desire to achieve this vision.  Business benefit. Why would an auditor want to achieve this vision? Business benefit. The business benefit is being seen and will be better seen as more software which shows the vision becomes available. But what would motivate a software vendor to support a standard? Big Business Intelligence (BI) vendors such as Oracle, SAP, IBM, Microsoft. Well, Oracle, SAP, and IBM already support XBRL. Others do also.  But, do they support it enough? Do they have the right standards and protocols?

Interoperability is not rocket science.  Or, heck, actually it is.  The more I dig into all this stuff, the more complex I realize this vision is. But we have plenty of rocket scientists, or rather IT experts, to make this work. If they can make the OSI model work, I figure these IT people can make interoperability of business systems work.

Levels of Interoperability

How much interoperability is enough interoperability? I looked at the paths I saw towards XBRL adoption in the past. This is another take at articulating the spectrum of possibilities of adoption of XBRL:

• Proprietary systems, little interoperability: There are lots of different approaches to implementing XBRL and there are many missing puzzle pieces. There are some benefits to software vendors because of this such as customer lock in to their proprietary systems; but little benefit to business users.  We, in fact, already have this today. There is nothing that XBRL does that a proprietary software solution cannot do.
• US financial reporting system, good interoperability: For, say, the SEC to be successful, comparability between information in the SEC XBRL database needs to be achieved. The SEC seems well down that path. The SEC has the hardest use case of XBRL that I have ever come across.  They use extensibility heavily, the domain is complex, the stakes are high, US GAAP is appropriate for paper-based reporting but needs changes to maximize what XBRL can provide.  Once the SEC use case is figured out by software vendors, the FASB, the SEC, and other parties; what prevents those software vendors from using what they have learned from making the SEC system work and applying those techniques in other US business domains? Nothing really. A de facto set of standards and protocols could be created between the SEC implementation and other implementations of XBRL. This seems highly likely, particularly if the financial reporting domain uses US GAAP.
• Global financial reporting system, good interoperability: What prevents the US SEC implementation from being copied globally? Well, if software exists and that software can be modified to support not just the SEC implementation of XBRL but other similar implementations; software can be leveraged across different implementations.  The SEC seems to be past the point of no return.  I cannot see major changes happening any time soon.  I do see the possibility of the SEC going to inline XBRL (sometimes called iXBRL). If the US adopts IFRS or if the SEC allows IFRS and a lot of US companies adopt IFRS, this could improve the chances of one global financial reporting standard used globally.
• Global business reporting system based on global financial reporting system: What if global use of XBRL is achieve in the financial reporting domain, and then because the benefits are seen and motivation for other domains rises, and then those other business domains simply leverage the approach financial reporting has used to make XBRL work in that domain.  That way, the same financial reporting software applications can be used in other business domains.

Is financial reporting's adoption of XBRL a done deal?

While I don't think that use of XBRL for all financial reporting is a done deal quite yet, it seems to me that we are getting closer and closer to that point. I think that I would be ready to declare victory if the SEC is happy with XBRL, the SEC filers are happy with XBRL, and analysts/investors making use of the SEC XBRL filing information are happy XBRL. Since there is a lot of investment being poured into software for SEC XBRL filings, it seems to me that turning back now is out of the question. While there are some rough edges to be polished, I really think the financial reporting domain will continue to be a leader in using XBRL.  Will other financial reporting domains use XBRL? Likely.  Will financial reporting's use of XBRL inspire other business domains? That is harder to say.

Continuing on with my endeavor to better understand XBRL as used in financial reporting, I have put together a Basic Example of an SEC XBRL Filingwhich is both compliant with the SEC XBRL rules and leverages the Business Reporting Logical Model.

What I am working toward is creating a Comprehensive Example-type modelof an SEC XBRL filing.

The truth is that the US GAAP Taxonomy inspired a lot of what went into the Business Reporting Logical Model. The Basic Example contains Hierarchy, Roll Up, Roll Forward, and a Compound Fact information models. Each of these information models is quite common in the US GAAP Taxonomy.  It is not surprising that the information models in the Business Reporting Logical Model map to the US GAAP Taxonomy; they actually come from the US GAAP Taxonomy.

If you are interested in taking a look at the Basic Example of an SEC XBRL Filing, follow the link above and just work from the top of the page to the bottom.

Why would you be interested in this Basic Example of an SEC XBRL Filing?

• To help you get good renderings in the SEC previewer and in the interactive data rendering in the EDGAR system.
• To help you train business users to create proper XBRL.  The Basic Example condenses the entire US GAAP Taxonomy into a hand full of meta patterns.  These meta patterns help hide the complexities of the XBRL syntax from business users. The example is simple, but it covers 90+ percent of what you would ever run up against in creating SEC XBRL filings.  If you can create this example, you can move to the next "level" of XBRL expertise.  If you cannot create this Basic Example, your foundation is not solid.  This example helps build the right foundation.
• This example is a great use case to test software.  The example is small enough to be able to be created in a short period of time, yet it has enough complexity to exercise software applications. Rather than use a software vendor's canned demos, ask software vendors to model this basic information in an XBRL taxonomy and XBRL instance.  It will help you see how that software will work.
• For professors teaching XBRL in their accounting classes, this is a good, solid example which will help your students get their heads around XBRL.

The meta patterns, business use cases, comprehensive example, and comparison exampleare coming for US GAAP Taxonomy and SEC XBRL filings. While the Business Reporting Logical Model Examples are quite useful, many people cannot make the leap from those examples to how the same ideas can be applied to using the US GAAP Taxonomy and creating SEC XBRL filings.