Digital Financial Reporting

A study (A Comparison of XBRL Filings to Corporate 10-Ks - Evidence from the Voluntary Filing Program) finds what they call serious errors in XBRL filings to the SEC Voluntary Filing Program (VFP).

Here is the abstract of the research paper:

The SEC has mandated a phase-in of XBRL filings beginning June 2009 for accelerated filers. Although companies have limited legal liability for initial filings, registrants may suffer reputational and other risks should the filings include errors. To assess the likelihood of material errors, we evaluate the accuracy of XBRL filings for 22 companies participating in the SEC.s voluntary filing program in 2006. Results of a comparison of XBRL filings to Forms 10-K reveal multiple errors in signage, amounts, labeling, and classification. These errors are serious because since XBRL data is computer-readable, users will not visually recognize the errors, especially when using XBRL analysis software. Although XBRL software and taxonomy have improved since 2006, the potential for some errors remains. The SEC, registrants, and accountants need to take note of the complexities of XBRL tagging and identify solutions (e.g., assurance, training) to ensure successful adoption.

 The general types of error discovered and reported in this study includes:

• Missing elements and amounts
• Incorrect amounts
• Sign flips (i.e. reported as a positive when it should be a negative value as an example)
• Duplication of items
• Incorrect classifications
• Incorrect tagging (labeling)

The VFP did not really do a lot in the way of validating submissions.  Nor did the SEC seem to crack down on people whose submissions contained errors.  This probably will not be the case for the real filing companies make to the SEC.  I would suspect that significantly more robust processes will be wrapped around "real" submissions.

Further, the AICPA has issued a statement of position (SOP 09-1) titled Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data.  This guidance did not exist during the time that these VFP filings were made.  It does now.  This will contribute to improving the quality of the filings, at least if CPAs are involved in the process as they need to follow this guidance.  While the SOP does not tell you how to create a good XBRL instance, it does help to define "good" by pointing out the things which are not good.

Anyone responsible for creating XBRL instances, whether for SEC filings or any other types of XBRL instances, would benefit from reading this paper.  It helps you understand the types of things to look for when reviewing an XBRL instance of any type.

Shipping containers have been used as an example of the benefits of standards, helping people to understand why the XBRL standard is a good thing. There is another analogy relating to shipping containers which can be brought to bear in explaining why application profiles are a very good thing.

Let's look at the shipping container from a different perspective. First of all, there really is not just one standard shipping container. There are, in fact, a number of different size and shapes of standard shipping containers. I live in Tacoma, Washington and I see the container ships go into and out of the port which was home to Sealand, an early user of shipping containers. I figure that perhaps there are between 20 and maybe 50 different sizes and shapes of shipping containers). The exact number is hard to determine, but the primary thing to realize is that it is not one standard size; and that it is also the case that each different shipping container is not a unique size and shape (i.e. there are not infinite sizes and shapes).

Now, take a look at XBRL. Today, the way XBRL taxonomies are being created, each XBRL taxonomy is created using a somewhat different architecture. IFRS, US GAAP, EDINET, COREP, FINREP, FDIC, The Netherlands Taxonomy project, the Australian SBR project, (I could go on) all have different architectures! This would be like every shipping container being constructed to be constructed of a different size and shape. How could that possible be a good thing???  In fact, now the IFRS, US GAAP, and EDINET are trying to undo or converge their different architectures.

Why are the architectures for each of these XBRL taxonomies different? XBRL is a general purpose specification. XBRL can be used for lots of different things, XBRL was built to be flexible, to be a general purpose tool. People have referred to XBRL as a "Swiss Army knife". As such, no one would ever use every feature of XBRL within one system. You pick and choose your approach, you pick different pieces of XBRL, don't use other pieces, and you create an what amounts to an architecture approach to creating your XBRL taxonomy.

Each different XBRL taxonomy implementation picks different pieces, parts, and approaches of XBRL to use in expressing their XBRL taxonomy. All of the different approaches (US GAAP, IFRS, COREP, and so forth…) are 100 percent XBRL compliant, but each is different. This causes two things. First, interoperability between each XBRL taxonomy is harder to achieve. This is not to say that each XBRL taxonomy really needs to be interoperable, they don't; but if you do need to make them interoperate, just being XBRL is not enough to achieve the interoperability. For example, now the FDIC and SEC have two different XBRL taxonomies which financial institutions which have to report to both must use.

The second thing which occurs is that each implementer of XBRL has to figure out pretty much the same things for their specific implementation, repeating the same effort over, and over, and over. Or another way of saying this, why would it be a bad thing to simply copy someone else's XBRL taxonomy if the architecture is both good and meets your needs?

Application profiles are a common approach to of solving this sort of problem and it has a side benefit to boot: it makes XBRL easier to use. XBRL is complex to use because you cannot make the general specification simple. You can make parts, or subsets, simpler to use. Remember that XML is basically an application profile of SGML (Standard General Markup Language). It is vastly easier to build an XML parser than it is to build a fully compliant SGML parser. XML is taking off, SGML has a niche but never received broad adoption.

I believe that a number of application profiles will be created and that will be the implementation patterns for XBRL. No one will use just general XBRL. Everyone will use a subset of the more general XBRL specification. Each XBRL taxonomy today uses different pieces and parts within their XBRL taxonomy architecture. In effect, each XBRL taxonomy is, today, its own unique application profile.

There are already groups working together to create application profiles for XBRL implementations. XBRL Global Ledger is basically an application profile. The US GAAP Taxonomy is an application profile (see the architecture document, page 4, section 1.4); it even calls itself such within its architecture documentation. XBRLS is an application profile. There are a number of governments around the world starting to talk about Standardized Business Reporting (SBR) as an application profile or approach for governments to implement XBRL in a consistent manner.

However, most of these application profiles are not documented formally enough to be as useful as they can. None of them work "out of the box". There are no software applications leveraging the application profiles to make a business user's life in making use of XBRL easier. But I believe that soon, there will be. Once business users realize the practical nature of using application profiles to make their life easier they will gladly give up a small amount of flexibility in order to gain significant reductions in implementation complexity, implementation cost, and ease of use.

XBRL International has published a document which can shed a tremendous amount of information on XBRL, XBRL taxonomies, and XBRL instances if one is interested in this sort of thing.  The document is the Comparison Framework for EDINET, IFRS, and US GAAP XBRL Taxonomies.

What the TCF (taxonomy comparison framework) is trying to achieve is best understood from the executive summary of the document which says:

The effort to provide a comprehensive comparison framework is a deliverable of the Interoperable Taxonomy Architecture project (ITA). The ITA is a joint initiative between the US SEC, the Japan FSA, the European Commission and the IASC Foundation XBRL team, and aims to converge the XBRL architectures of three taxonomies: EDINET, IFRS and US GAAP. In the project's first stage, the three respective taxonomy developers agreed to develop a comprehensive framework which would provide a basis for comparison of the three taxonomy architectures. The result was the Taxonomy Comparison Framework (TCF). The ITA project assumed a scope of analysis limited to financial reporting in capital markets. Although XBRL taxonomies are often used in other reporting scenarios (for example bank regulation, statistical reporting or tax reporting) such usage of XBRL taxonomies was out of scope of the ITA and thus is not analysed in the TCF.

There are two specific things which I am personally interested in relating to this document.

The first item of interest is the possibility of creating one global framework for financial reporting.  As a CPA, I personally believe that one framework which makes us of IFRS (International Financial Reporting Standards) and XBRL would be a very good thing.  The next 10 years will tell if the the business community and in particular those who participate in the financial reporting supply chain have the resolve to make this a reality.  I would be the first to admit that I don't have a full understanding of the issues involved in creating one globally used framework.  However, I do believe that such a framework would be a very good thing.  Further, I hope that the US does not hold this effort back.  Technically, creating such a framework is very possible from what I see looking at IFRS and XBRL.  I think this all boils down to the will to do it.

The second item of interest is the need to actually do a comparison of the different architectures of these three financial reporting XBRL taxonomies.  After all, all are XBRL.  All are for financial reporting. They should all interoperate because they are XBRL.  Right?  Well, no.  This is something that many people still don't seem to get about XBRL.  People need to understand this about XBRL, otherwise they will make big mistakes in implementing XBRL.  This is not a problem with XBRL, it is a reality of what XBRL is.  XBRL is a general purpose specification.  It is quite flexible, it was constructed to be flexible for a reason.  Business reporting is a broad category, a broad set of use cases.  Think about this.  Take a look at the comparison of the three taxonomies.  The question that I have is how to avoid having to do such comparisons in the first place.  Another way of saying this is how is interoperabilty maximized?  I think I am seeing how to do this.  Look for a blog entry in the near future which talks about how XBRL is similar to shipping containers.  It may seem odd, but there is something to be learned about building XBRL taxonomies from those big metal boxes used to transport goods on ships.  Look for it.

The EDGAR Filer Manual can be found on this page.  This page in particular is the manual, see chapter 6 for information about filing XBRL with the SEC.

The CFA Institute published a white paper titled eXtensible Business Reporting Language: A Guide for Investors.  The paper is worth reading, it has a good executive summary.  It also outlines five guiding principles which the CFA Institute believes how XBRL should be used in financial reporting.  These are those five principles:

1. Disclosure neutrality
2. Limited extensibility
3. Global initiative
4. Open source
5. Regulator cooperation

There are a lot of things I personally like about their five principles.  There are some things I don't personally like.  The BEST thing about there principles is that they are written down and it seems they will guide how the CFA Institutes pushes on XBRL and how XBRL is implemented for financial reporting.

But I do have a question.  Where are the white papers for the preparer community (perhaps published by FEI), the public accounting profession (perhaps published by the AICPA in the US, or maybe the Big 4 audit firms), the software vendors (maybe the software vendors who are members of XBRL International can do this), and anyone else who wants to "push" on XBRL and how it will be used within financial reporting?

Seems to me like it is in the interest of a number of communities who are involved in financial reporting and care about this  and that they should start communicating where they want things to go and start pushing in that direction.  If they don't, how XBRL is used in financial reporting might not be what they desire.

I hear people complain that XBRL is too heavily influenced by CPAs.  I also hear CPAs communicate different views of how to best use XBRL.

Or heck!  Nothing prevents me from getting together with other CPAs I know and making our views known.