Digital Financial Reporting

There is a base set of criteria which must be satisfied in order to make use of information reported in SEC XBRL financial filings. Satisfying these criteria does not mean that all the reported information is useful. Or, said another way, these base criteria are not sufficient.  However, this base criteria is necessary.

All of these base criteria, in my personal opinion, can and should be verified to be true before the SEC even accepts an XBRL-based financial filing.  Every one of these base criteria is automatable.

These base criteria were determined from analysis of 7160 SEC financial filings, all of which were 10-K filings.  The analysis is summarized in the document Summary of Analysis of SEC XBRL Financial Filings.

The majority of SEC XBRL financial filers satisfy each category of these base criteria. Less SEC XBRL financial filings satisfy all criteria.  The SEC clearly does not use its inbound validation to detect these base criteria for if they did, these issues would not exist in the submitted filings.  The issues would be detected using automated processes, flagged as issues, reported to an SEC filer attempting to submit a filing, and then would force the SEC filer to correct the issue before being able to submit their financial information.

This is how the FDIC XBRL-based system works.

The closest thing that I have seen in the market which satisfies the detection of these base criteria so that the can be identified and corrected is XBRL Cloud's EDGAR Dashboard.  However, that commercially available tool does not cover all the base criteria.

You have to give the accountants creating these SEC XBRL financial filings credit for doing as good a job as they are doing using manual verification processes.  But manual verification is time consuming, expensive, and it lets errors fall through the cracks.  For digital financial reporting to be deemed to work, there cannot be cracks.

So, what are the base criteria?  Here you go:

Click for a larger image

Here is a list which explains the criteria, where SEC XBRL financial filings are today based on my analysis, an example to help you understand why the criteria must be satisfied, and other information to help you understand why the criteria must be satisfied.

• Automated XBRL Technical Syntax Validation Errors:  99.9% of all SEC XBRL financial filings already satisfy this criteria so this is not worth discussing in detail, it works.  What causes the .1% shortfall is inconsistent XBRL implementations by software vendors. Fundamentally, if software cannot read the XBRL technical syntax without error, the information is somewhere between unusable to unreliable. The good news?  This works very well.
• Automated EDGAR Filer Manual (EFM) Errors: 86.1% of all SEC XBRL filers pass the EFM validation rules.  Why not 100%?  Well, that is because different interpretations of the EFM rules by software vendors, including the SEC.  The good news is that from what I can see, most of the automated EFM validation rules relate to improperly formatted HTML within [Text Block]s.
• Automated US GAAP Taxonomy Architecture Model Structure Errors: 97.9% of all SEC XBRL financial filings properly distinguish and properly organize [Table]s, [Axis], [Member]s, [Line Items], [Abstract]s and Concepts. A small number do not. This is a problem because if a [Member] is placed within a set of [Line Items]; how should that be interpreted by software using the information?
• Balance sheet date of current period identifiable: 97.2% of all SEC XBRL financial filings have the correct relationship between the balance sheet date, the fiscal year focus, the dei:DocumentPeriodEndDate and the context of the required context.  If these dates are incorrect or inconsistent, it is not possible to figure out what the date of the current balance sheet is.  Software might be able to figure it out, but they can guess incorrectly.  A specific example will help understand this.  In this filing, note the fiscal year focus (which says 2011) in the document information, the context of the document information (which says 2012), the document period end date concept (which says 2011), and the balance sheet date (which says 2012). Again, software can guess but because it is a guess, they could get it wrong. 
• Root reporting entity is discoverable: 99.2% of SEC XBRL financial filings provide an easily detectable root reporting entity as required by the EFM. A few don't. Here is an example. Go look at the balance sheet and notice that there are multiple balance sheets and the reporting entity balance sheet cannot be detected. If you cannot detect the one legal entity or one scenario you should be using, you have to venture a guess.  If you have to guess, you can guess wrong.  Besides, if you don't have to guess with 99.2%, why can't the other .8% just get with the program?
• Fundamental accounting concepts identifiable/distinguishable and relations are intact: 98% of SEC XBRL financial filings report fundamental concepts and have the same relations between those concepts.  For example, "Assets = Current assets + Noncurrent assets".  It does not matter whether a filer explicitly reported one of these fundamental concepts or not, if software cannot sort this out, bad things happen when trying to use the information.  Here is more information on what these fundamental concepts and relations are.  Hard to disagree with those. Don't agree with my list?  Fine, modify the list.  But again, if this cannot be sorted out the information is not usable.
• Primary financial statement computations proven to be intact: 79.1% of SEC XBRL financial filers provide the business rules which prove that their balance sheets, income statements, or cash flow statements add up (roll up) correctly.  But 20.9% don't.  As a result, many times that 20.9% reverse the polarity of a reported number.  For example they report (1000) when they should have reported 1000.  Easy enough to fix.  Just provide the XBRL calculations which the SEC requires anyway.
• No detectable accounting or reporting anomalies found to exist: I don't have a reliable number for this criteria.  I have the number on a test-by-test bases and I have 26 tests.  But this is really a wild card.  The list of tests will grow, and grow, and grow.  As the number of tests grow, accounting anomalies will be identified, corrected, and information will be more usable. There will be thousands of tests like this, I am clearly only scratching the surface.  Here is an example; If an SEC filing reports current assets but you cannot find current liabilities, how trustworthy is the information?  Now you can say that if current liabilities is zero and not reported, that is not an anomaly.  Well, I would say two things.  First, if it is zero it is "not reported", it is zero and should be reported as zero.  That will keep software from doing the wrong things.  Second, most people who have this error report "us-gaap:Liabilities" when they should have reported "us-gaap:LiabilitiesCurrent".  That is a problem.

While I have not characterize these base criteria as data quality logic or business logic; all are based on logic.  This is not really a matter of opinion.  In fact, this cannot be a matter of opinion and also be called usable digital financial information.

All one needs to do is write a software application, prove that they can successfully use this information and refute what I am pointing out.  Until someone can justify otherwise, and I would love to be wrong about this, each one of these base criteria leads to unsafe and unpredictable interpretation of the information.  And I am not talking about creating a guessing game, a game which different software vendors would implement in different ways and then we get one financial statement with two different meanings depending on which software application you use.  This information should be reliable, predictable, and easy to safely grab.

Unsafe, unreliable, unpredictable cannot exist and the SEC XBRL-based financial information considered appropriately usable.

How hard is it to create automated software routines to detect these base issues?  Well, I did it.  Therefore it cannot be considered that hard.

Business rules can be grouped into two broad categories: data quality logic related and business logic related.  Of course, your first question might be "What the heck is a business rule?"  A business rule, as defined by the Business Rules Group in their Business Rules Manifesto is:

Business rule: A formal and implementable expression of some user requirement.

In their Decision Model, Knowledge Partners International points out the important difference between data quality logic and business logic:

• Data quality logic: is the logic used against data elements to determine if they meet various data quality dimensions such as completeness, reasonableness, etc.
• Business logic: is the logic that uses data elements as conditions leading to business-oriented (not data-validation-oriented) conclusions such as compliance, eligibility, etc.

I have turned my analysis of SEC XBRL financial filings from the primary financial statements to the disclosures. I picked a somewhat common disclosure to take a look at: long-term debt. As an accountant I understand that not every reporting entity has long-term debt.  But if a reporting entity does have long-term debt, then specific disclosures are required.  Further, because of the way the SEC EFM says XBRL-based financial reports need to be created, I would expect them to look a certain way.

This is a summary of what I found from my set of 7160 financial filings (all 10-Ks): 

• 1,571 filings, which is about 22%, contained something that indicated that they had long-term debt.  Typically this would be the line item "Long-term debt" reported on their balance sheet.
• Of that total, 469 reporting entities provided BOTH a detectable long-term debt maturities disclosure and a detectible break down of their debt instruments.  That is about 30% of reporting entities.  I would expect 100% of reporting entities which have long-term debt on their balance sheet to provide both of these disclosures.  I would assume that these disclosures exist, I just need to make my detection algorithms more sophisticated.
• Of the 1,571 filings, there were 1,553 filings, which is 88% which provided a "Debt Instruments [Table]" (using the report element us-gaap:DebtInstrumentTable).  On that [Table], 1,170 or 75% had a "Long-term Debt Type [Axis]", 1,103 or 71% used a "Debt Instrument [Axis]" and 772 or 50% used both of these [Axis].
• 996 or 64% of the reporting entities who had long-term debt provided the [Text Block] provided in the US GAAP XBRL Taxonomy "Schedule Of Maturities Of Long-Term Debt [Table Text Block].  The rest did not.
• Of the 1,553 which provided that "Debt Instruments [Table]"; only 779 about 50% provided the "Schedule Of Debt Instruments [Text Block]".

Those are only some of the things I observed relating to long-term debt in the SEC XBRL financial filings which I am analyzing.  I don't know if these are data quality logic anomalies or business logic anomalies.  They seem like data quality logic anomalies to me.

I mean, if someone provides a "Debt Instruments [Table]" which is the details of debt instruments it would be logical to expect that the "Schedule Of Debt Instruments [Text Block]" should be located also because the EFM requires both levels of information.  Particularly since this is true for 50% of SEC XBRL financial filers.

What do you think?

I would not go as far as saying that it is a RoboCop, but I do have a rudimentary accounting analysis software agent up and running against SEC XBRL financial filings.  I am not trying to fight fraud or discover accounting shenanigans; I am simply trying to help accountants understand financial reporting and digital financial reporting best practices. I am also trying to understand how to construct quality XBRL taxonomies and what business rules are necessary to make a system work effectively.

Below is a summary of my results of my first query.  The question I was trying to answer was to see how many SEC XBRL financial filings provided a future minimum lease payments under capital leases disclosure, see what balance sheet line items they provided, and see whether I could find both a text block level disclosure and a detailed disclosure.  Here is a summary of my results:

In addition to the software agent which looks through the details of the filings, I have some other software which helps me analyze the filings.  I put together this document of a summary of that analysis for this specific disclosure. I can do this sort of analysis for any financial report disclosure.

Again, while what I have created is fairly rudimentary, I think it does help people see some of the types of things one can do with a digital financial report using automated processes which could only be done manually using typical reports which are only readable by humans.

Prototype theory is something I picked up when I read David Wenberger's very insightful book, Everything is Miscellaneous.

The book has two key points.

• That every classification scheme ever devised inherently reflects the biases of those that constructed the classification system.
• The role metadata plays in allowing you to create your own custom classification system so you can have the view of something that you want.

Several years ago I summarized what I learned about prototype theory into this document, Understanding Prototype Theory and How it Can be Useful in Analyzing and Creating SEC XBRL Filings. The document also pulls information together about Concept Learning and Prototype and Exemplar Theory of Concepts.  If you are working with SEC XBRL financial filings, trust me...this information is incredibly helpful.

A fundamental problem of the US GAAP XBRL Taxonomy, in my view and in the view of many others that I talk to, is that it was (a) admittedly designed to be a "pick list", (b) the pieces are too big, and (c) the pieces which people generally work with are not physically identified.

This is what I mean, this is one section of the US GAAP XBRL Taxonomy (2011 Version), Debt. (That is an older version but there is not really much of a change in the 2013 version in terms of its organization.  I am using the older version because I remodeled the 2011 version, you will see why in a minute.)

If you look at that section of the US GAAP XBRL Taxonomy, you can clearly see that it can be categorized by it network which identifies it as "460000 - Debt". That network can be differentiated from every other network by the title and identifier of the network.

But, tell me what is in that network?  Or rather, you can read it and tell me what is in it.  But have a computer tell you what is in that network.  It cannot.  Why? A computer cannot identify what is in that network because it cannot identify the pieces which make up the network because the organization is inconsistent.  You can identify sum pieces, for example each of the [Table]s.  But, because not everything is in a [Table] and there is not really any other way to latch on to a specific piece because the representation is inconsistent, a computer cannot identify "the pieces".

Contrast the US GAAP XBRL Taxonomy representation to my remodeled version of exactly that same information. Note that everything in that remodeling is represented within a [Table].  I used US GAAP XBRL Taxonomy [Table]s where they existed, and where they did not exist I created a [Table].

But SEC XBRL filers don't use the information in the US GAAP XBRL Taxonomy at the [Table] level.  Look how big many of those [Table]s are.  Consider, say, the "Long-term debt maturities" disclosure which is a very common disclosure provided by SEC XBRL Financial filers which tends to look like this:

The above example of how long-term debt is disclosed. How do I know? Because I analyzed SEC XBRL financial disclosures, see this analysis of Long-term Debt Maturitieswhich I created for another project I am doing, and that is how the US GAAP XBRL Taxonomy is used generally by filers. This analysis has even more information on how small these disclosures really are.

So, if you look closely at my reorganization of the US GAAP Taxonomy you will see two things: (1) If you look within each [Table], you can see that the pieces are at the level SEC filers tend to use the information and each of those pieces is identifiable and (2) each one of those pieces follow a defined accounting concept arrangement pattern which I have made explicit.

This is what you should be looking at:

So now, because I have specifically identified each of the pieces of the US GAAP XBRL Taxonomy and I know that SEC filers create filings at that level, I can put the two things together and identify every report component of ever SEC XBRL financial filing.

How?  Well, consider this little XML file. That is a fragment of this larger file to make reading the file easier.

Click for a larger image

So, I have prototypes for EVERY piece of the commercial and industrial companies portion of the US GAAP XBRL Taxonomy.  I got them by reorganizing the taxonomy into a useful form, each disclosure.  Those disclosures match what SEC XBRL financial filers are disclosing.  I have exactly the same XML representation for every SEC XBRL financial filing.  I use the prototypes to identify the SEC XBRL financial filing report components, and the SEC XBRL financial filings to help me create prototypes.

Why do I go through all this effort? Well, that is how I do this:

• I can query SEC XBRL financial filings and grab the exact disclosure that I want.
• I can view individual report components within one filing or across SEC filings.

A proper organization of the US GAAP XBRL Taxonomy is very useful for all sorts of things!

When I originally started using prototype theory, I thought that what I was trying to do is convince the FASB and the SEC to provide specific "handles" on every disclosure so that I would not need to go through all this effort.  But I think that I have convinced myself that those handles are not necessary.

My idea was for the FASB to provide a specific [Table] for every disclosure so each disclosure could be identified easily by anyone using SEC XBRL financial filings. They already provide [Table]s for some things, the idea is simply to provide a [Table] for everything.  Why is this possible?  Disclosures don't change.  The presentation of disclosures can be fiddled with by SEC filers, but what they can disclose cannot.  Look at the long-term debt maturities again.  What is disclosed does not change significantly, it is "the law".  There is some variability, but not much.  Now, this is not the case for EVERY disclosure, for example qualitative disclosures have more variability. However, qualitative disclosures are not random; patterns do exist.

But while providing specific identifiers for each disclosure is possible and may even be desirable and even a good practice for those creating taxonomies; it is not necessary.  The fact that I can get to whatever disclosure I want using prototype theory is proof of that.

While those SEC XBRL financial filings are far from perfect and not really good enough for automated reuse of the information by financial analysts and investors; that financial statement database is a literal treasure trove of value to professional accountants. And I don't mean just external accounting managers of public companies.  I mean the hundreds of thousands of CPAs who create private company financial statements.

There is already one commercial application that I am aware of which makes use of the XBRL-based database of public company financial reports: GAAPWatch which was created by XBRL Cloud. I tried GAAPWatch and even created some videos which shows the sorts of things you can do with GAAPWatch.

I created a tool which is based on the same web service as GAAPWatch. I took that tool which was origionally created for analyzing the quality of the XBRL-based financial information and tweaked it a little bit and now I have an incredible research tool. To do queries, I cached some other information locally on my computer so that I could search through individual digital financial reports using some techniques which I created.

Similar to GAAPWatch, I can view the pieces of a financial report and get to those individual pieces by searching on the characteristics of reporting entities or by searching for specific disclosures contained within a financial report.

But what I can also do is search for individual facts which are reported in a financial report and find filers who reported those facts, see how and where they were reported, compare and contrast how different reporting entities provided those disclosures, and compare the relationships between reported facts. Those queries are done against the locally cached information to make the queries run significantly faster.

So here are some fairly rudimentary examples that I think provides insight to the possibilities which are available right now. (This ZIP file contains Excel spreadsheets which has the information I pulled from the set of SEC financial filings I am working with.)

• Say you wanted to see how environmental site loss contingencies were being disclosed. First, you would have to find reporting entities which had such disclosures.  Then you have to find the disclosure within the report.  Then you can read through the disclosures and see how specific filers approached the disclosure.  My query discovered 120 such disclosures and the specific location within the report which contained the disclosure.  Press a button, and I can see the disclosure in my application.
• Suppose you wanted to see the relationship between having the line item "Income tax expense (benefit)" on the statement of operations and having an income tax policy provided or whether it is more common to provide the reconciliation between statutory tax rates and the effective tax rates using percentages or amounts.
• Imagine that you wanted to understand the specific sorts of things which are disclosed in the nature of operations for reporting entities who operated within a specific industry.

Research can be done during the process of creating financial report disclosures where, say, private companies can leverage the high-quality financial disclosures within financial reports submitted to the SEC.

The closest thing that I can think of which exists today which is similar is what used to be called Accounting Trends and Techniques which was renamed U.S. GAAP Financial Statements - Best Practices in Presentation and Disclosure which is published by the AICPA.  The benefits of using the SEC XBRL financial filings is that

• the entire process of creating the resource can be 100% automated
• you can have a different version of this disclosure research resource for specific industries as the marginal cost is so low because of the automation
• you don't need to limit the resource to 500 reporting entities or some specific subset of disclosures because it is just as easy to grab information from every reporting entity

But the ability to search through specific reported facts and other information goes far, far beyond what the AICPA's product provides. Eventually software vendors who make software for the creation of financial reports will realize the utility of having this research information directly within software applications used for creating financial reports.  The software vendors will also realize that any aspects of the tools such as the disclosure guides used to jog your memory to make sure you did not miss a disclosure can be automated.  And obiously software can watch over external financial reporting managers to make sure they did not make other mistakes such as computations which don't add up correctly.

Besides making the human readable copies of financial reports better, all those SEC XBRL financial filings will help the general quality of XBRL also improve.

(Here is a video of the application I used to get this information.)