Digital Financial Reporting

The XBRL International Standards Board (XSB) published a document summarizing six strategic initiatives which they say will help prepare XBRL for the future. I agree. This is a summary of those six strategic initiatives.

1. Create an abstract model. An abstract model provides a conceptual framework for understanding XBRL and gives developers a strong foundation for implementing XBRL solutions.
2. Produce training materials. High-quality training materials lend support to developers and those new to XBRL.
3. Define standard API signatures. API signatures assist developers with their implementation of XBRL solutions.
4. Reorganise existing specification. A reorganisation of the XBRL specification will make the specification easier to understand.
5. Enhance data comparability. Data comparability widens the applicability of XBRL data across project and international boundaries.
6. Develop application profiles. Application profiles reduce the scope of XBRL implementations by breaking up the XBRL specification into components.

This document and the strategic initiatives are a great piece of work by the XBRL International Standards Board. It is my view that the initiatives summarized in this document are critical for XBRL. Several of the strategic initiatives are absolutely necessary for XBRL to move to the next level in its evolution.

The two key pieces are number 1 (Create an abstract model) and 6 (Develop application profiles). This will lead to number 5 (Enhance data comparability).

Since I learned about the notion of an application profile and logical model from my work on the team which created the US GAAP Taxonomy Architectureand the result of that work which was a paper Rene van Egmond and I put together in 2008, XBRLS: How a Simpler XBRL Can Make a Better XBRL, I have been pushing the idea of using a logical model above XBRL's syntax and application profiles to make using XBRL easier for business users.

Work with the XBRL Taxonomy Arhitecture Working Group resulted in a draft Business Reporting Logical Model and Financial Reporting Logical Model.  I created a straw man implementation of those two models. I have further expanded on that straw man implementation creating a set of meta patterns, business use cases, comprehensive examples, and comparison examples to help prove those two  logical models and better understand these ideas.  You can find summaries of this information here.

Taking this to the next level, I have applied these models to SEC XBRL filings and the US GAAP Taxonomy.  You can find summaries of this information here: Meta patterns, basic example, basic comparison.

Both of those sets of resources are helpful in understanding the business benefits of an abstract logical model and an application profile.

While I am not a software architect, I don't know exactly how to document an application profile.  I do understand a little better how a logical model can be expressed using UML (Unified Modeling Language) or RDF/OWL. I do understand from my detailed work with XBRL over the past 11 or so years that application profiles and logical models which will hide the XBRL syntax which will cause fundamental changes to how business reporting applications which generate XBRL will be created. These changes will result in an order of magnitude improvement is usability of this software for business users.

So kudos to the XBRL International Standards Board for taking this important step. This step moves us significantly closer to the possibility broad use of XBRL by business professionals. I would point out that it was the XBRL International Standards Board, not the XBRL International Best Practices Board which issued this strategic initiative. What that means to me is that these logical models and application profiles will have more teeth to them: standards, not best practices.  Time will tell for sure how all this will play out, but I see the strategic initiatives as a big step in the right direction.

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.

The US GAAP Taxonomy Architecture (and the current draft) has a term called a Compact Pattern Declaration (CPD).

Section 1.3 (Logical Model) of the US GAAP Taxonomy Architecture states:

Disciplined Extensions– The architecture internally enforces design rules to ensure that the base taxonomy from which others will need to extend is internally consistent. It is beyond the scope of the architecture to create a formal expression of extension rules to facilitate "disciplined" or "channeled" or "managed" extensions within systems that use it. We encourage systems that make use of the architecture to build such formal expressions for use within their systems. The Compact Patterns Declarations (CPD) is an example of such formalized expressions for the purpose of managing extension by filers.

Section 3.4 (Consistency and Comparability) of the US GAAP Taxonomy Architecture states (the emphasis is mine):

Systems which implement version 1.0 are expected to provide mechanisms for providing discipline around the extension of the base taxonomies. One example of providing such discipline or "channeling" or "management" of extensions is the compact pattern declaration (CPD). The CPD is a formal XML representation of a pattern [PATTERNS] that allows software to help a user follow exactly the same pattern and rules that were used to construct version 1.0 itself.

The US GAAP Taxonomy Architecture refers to two documents above and in Section 7 (References) in the architecture: UGT Compact Patterns Declarations (CPD) Module and [Patterns] or the UGT Patterns Guide (also called the USFRTF Patterns Guide).  These documents explain the patterns within the US GAAP Taxonomy.

There are two other places which show the sorts of things systems which implement the US GAAP Taxonomy are expected to do.  Section 4.5 of the US GAAP Taxonomy Architecture, Implementation of Tables, explains the [Table] is constructed within the US GAAP Taxonomy and how systems which use the US GAAP Taxonomy are expected to extend the taxonomy, such as SEC XBRL filings.

Another place to see how this can be implemented is by what XBRL Cloud.  You can see these rules here on this page and you can see the validation of these rules, as suggested by the US GAAP Taxonomy Architecture, here on XBRL Cloud's EDGAR Dashboard.  XBRL Cloud calls this an information model, rather than a Compact Pattern Declaration.  But it is the same thing.

The Business Reporting Logical Model also uses the term information model.  That logical model was basically created using ideas first created by the architects of the US GAAP Taxonomy. Those ideas were expanded on by the ITA Interoperable Taxonomy Architecture Group which was made up of the US SEC, IASCF, Japan FSA, and European Commission.

For years I had worked to build sample XBRL taxonomies and XBRL instances, I called these "patterns". You can see the history of that work here. I ultimately realized, partly from participation on the US GAAP Taxonomy Architecture Working Group, of which I was a member, that the patterns needed to be further condensed, this is what the Compact Pattern Declarations which expressed an information model were.  Now I refer to these as meta patterns.

For years I had been making a mistake about how I looked at those patterns or meta patterns and the information models they expressed. I realized this mistake when the FINREP taxonomy released their taxonomy without a presentation linkbase.

Business information is not random, it has patterns. There is not an infinite number of patterns within business information, there is some fininte amount. Here are some patterns which are hard to dispute, most of these are instantiated within the US GAAP Taxonomy:

• Hierarchy: A Hierarchy is an information model where there are relations between facts but the relations do not involve computations.  For example, accounting policies is a Hierarchy.
• Roll Up: A Roll Up is an information model which expresses relations where there is a simple computation between concepts. A Roll Up relation is basically A = B + C + n; where "n" is any number of concepts.
• Roll Forward: A Roll Forward is an information model which expresses a relation where a BASE (beginning + additions - subtractions = ending) type of relation exists.  Basically, a Roll Forward is a reconciliation between two instants in time. An example of a Roll Forward is the cash flow statement or a movement analysis for property, plant and equipment.
• Adjustment: An Adjustment is an information model which is similar to a Roll Forward in that it is a reconciliation; however the dimension or axis which is moving in the relation is the financial report's report date. An example of an Adjustment is the reconciliation of an originally stated balance to a restated balance for an accounting prior period adjustment.
• Variance: A Variance is an information model which is a computation between two different reporting scenarios such as actual and budget.  For example, the difference between the actual and budgeted values for the concept Sales.
• Other Relation: An Other Relations is an information model and is what amounts to a Hierarchy with business rules attached to the concept within the Hierarchy. An example would be the computation of weighted average common shares and earnings per share. These are computations too complicated for XBRL calculations to handle, but they are computations which exist.

The point here is that it is not XBRL which all of a sudden introduced the ideas of the information model.  Information models have always existed but we, as humans, understood what those were and we never really communicated at that level; it is pretty basic and we business users get those relations. But computers are dumb.  We need to break down business reporting so that we can explain the moving pieces to a computer application.  That is what meta patterns and an information model does.

The US GAAP Taxonomy and the filers who use the US GAAP Taxonomy for SEC XBRL filings don't have different information models for "Roll Up" or "Roll Forward", or whatever.  They are the same.  So, the US GAAP Taxonomy and the SEC filers who extend that taxonomy should be using the same information models.

Finally, the information model is not defined by the XBRL presentation linkbase, it is explained by the model itself, what the XBRL looks like.  A computer application can figure this out.  You can help a human understand that information model by articulating it within the XBRL presentation linkbase, like the US GAAP Taxonomy does, for example recall section 4.5 Implementation of Tables as discussed above.  But if you do express it in the presentation linkbase, you need to keep it consistent with the other underlying XBRL which really is what describes the real information model.  Eventually, perhaps the US GAAP Taxonomy will do like FINREP and not even provide a presentation linkbase because a computer can auto generate it based on the underlying information model.  But today, the US GAAP Taxonomy and the SEC require the presentation linkbase, therefore you need to keep it consistent with the underlying XBRL information model which is used to express your business information.

The document Modeling Financial Information Using XBRL (DRAFT) is available on the index page of the samples and examples I have been creating. That document summarizes the many, many samples and examples which I have been putting together to help me see if the Business Information Logical Model works as I would like it to work.

Lots of people seem to be struggling with the symptoms of how XBRL is being used today. This material strives to solve the problems, not fight the symptoms.  The symptoms will go away once the problem is solved. Also, keep in mind that if you are trying to figure out how to get XBRL into your existing processes, realize that another way to approach things is to try and understand how XBRL can make your current processes more effective and effecient.

I wish I could say that this information is helpful to the average business user. It probably is not and most will not choose to make their way through it. I cannot write that material that I want to write until software applications change their approach to working with XBRL. The material is quite helpful to business users who are early adopters of XBRL and will endeavor to wade through the material.  The material will help these curious business users begin to ask good questions. Those good questions will begin to impact all the moving pieces which impact business reporting where XBRL is being used as an output.

For those leaders in the accounting profession who do have the intellectual curriousity to dig in and try and figure out how to best make XBRL serve financial reporting and other areas of accounting, I think there is a lot there to help you. For example, when having software vendors demo their analysis software, use the comparison example's three XBRL instances rather than the scripted demos of software vendors.  Understanding the material in that document will turn you into an educated, informed buyer.

Most accountants aren't really that up on the issues relating to working with XBRL. All that will change when legal liability associated with filed XBRL kicks in.  Further, the SEC has already said publicly that it's intension is to not continue to supplement the HTML or SGML filings with XBRL, but to make the HTML and SGML go away.  When this happens, accountants will look at the XBRL differently.

Do you really want to wait until the last minute, when legal liability kicks in and XBRL is the only document you are filing with the SEC?

There are more and more accountants realizing that financial reporting using XBRL is a foregone conclusion. We still have many, many details to work out; how to "tame the XBRL beast". The information in Modeling Financial Information Using XBRL can help us get the software tools, proper XBRL taxonomies, and other infrastructure we need and get to the point that we want to use XBRL because it actually makes the process of financial reporting more effective and efficient than the current process which has been with us for hundreds of years.

If you feel so inclined, roll up your sleeves and dig in.  If not, don't worry; your competitors are.