Digital Financial Reporting

There is a new web service available which allows access to SEC XBRL financial filings without any knowledge of XBRL.  The web service, offered by XBRL Cloud, has a 30 day free trial so you can see what it does and is priced at $9.95 per month.

I have been using this web service during it's alpha and beta phase.  I have put together some sample code for accountants and analysts who might want to make use of this web service to pull information into Excel. (You will need to sign up for the free trial to use these samples.)

• General sample code: This is numerous general examples of navigating the web service to grab information and put that information into an Excel spreadsheet.
• Taxonomy comparison tool: This is a very basic Excel taxonomy comparison tool.

I have some other samples in Microsoft Access that I will eventually make available.  Here is a screen shot of the taxonomy comparison tool:

Taxonomy comparison tool screenshot

The web site has some very interesting characteristics which may not be evident just by looking at it.  Here is a summary of the things that I find particularly useful:

1. Metadata: There is lots and lots of metadata which provides easy ways to organize information. For example, the following information is available for entities: CIK, Entity Registrant Name, SIC Code, SIC Description, Industry Sector, Ticker Symbol, IRS Tax ID, Subindustry, Entity Type, Is Entity a Trust, Is Entity Developing Stage, Is Entity Going Concern, Entity Filer Category.
2. Links: Links, links, everywhere.  You have links to the actual SEC filing page for every filing, links to the XBRL Cloud Viewer, etc.
3. Components: All the filings are available by component of the filing.  You don't have to use the entire filing, just the piece you need.
4. Disclosures identified: This is a particularly useful piece of metadata.  All of the primary financial statement components (i.e. BalanceSheet, IncomeStatement, CashFlowStatement) are identified for you.  Many of the disclosure components are likewise identified.  Not all, but this is a very, very good start.
5. Various information views with drill down by component: For every component you can view the rendering, the SEC viewer view, the model structure, and the fact table.  You can imbed HTML versions of the renderings into your application.  Every HTML form allows you to "drill down" into the report elements and/or fact tables which make up the component.
6. Component perspective: You can query information by component.  For example, "Give me all the balance sheets" or "Give me all the long-term debt maturities disclosures".  You REALLY need to check this out.  This is a game changer in terms of working with financial reports.
7. XML: All this is in XML so you can read what you need and have the flexibility to do what you want.  Basically, you can build your own interface.

There is a lot more, those are only the highlights. You can experience all this stuff for yourself by trying the free 30 day trial and playing with the sample applications.  Excel users will be thrilled.

SEC XBRL financial reports are 96.6% accurate for a select set of 51 fundamental accounting concepts.

In my prior post I stated that I had an accuracy rate of 95% for SEC XBRL financial information for a select set of 51 information points that I was going after.  These 51 information points are fundamental accounting concepts which every financial filing has whether they are reported or not. For example, if comprehensive income is not reported, that means that comprehensive income is the same as net income and that other comprehensive income must be zero.  Why?  Because:

Comprehensive income = net income + other comprehensive income

These fundamental accounting concepts have very precise definitions and very precise relations which are not changeable.  Accountants have no discretion here.  These are the rules.  Check any intermediate accounting text book or the acconting rules.  But even better proof is that over 90% of SEC XBRL financial filings follow these rules.  Here is my proof:

If you look at that graphic you will see that for the 21 tests that I have, for 20 of those tests about 90% or more SEC XBRL financial filings pass the test.  Only one test, IS3, falls below that threshold.  More about that later.

If you do a little calculation which you can follow on that graphic, you can see that I am now up to 96.6% accuracy.

Further, I am understanding exactly why information from an SEC XBRL financial filing is incorrect.  I can look at the information from any SEC XBRL financial filing, look at that filing by going to the XBRL Cloud Viewer, and see why the filing is not passing the test.  I use that information to either (a) adjust my algorithm, (b) adjust my test, or (c) confirm that there is, in fact, an error.

Here is a screen shot of the interface I created to perform this work (click on the image to see a larger image):

Here is a link to the Adobe filing within the XBRL Cloud viewer.

Now I will be the first to admit that I have taken the "happy path" through this information.  I am looking at only 10-K filings, not all the various forms reporting entities file.  I am looking at only the current balance sheet date and the year-to-date information, not all the information for all periods provided in a filing.  I am not looking at all the different entity breakdowns provided, only at the consolidated entity or the parent holding company which is the "root" reporting entity.  I am ignoring the minority of reporting entities which don't provide a balance sheet, but rather provide a statement of net assets.  I am not considering certain discretions which accountants do have, such as including the exchange gains (losses) in the roll forward of cash (which a handful of reporting entities do, which is allowed per US GAAP) rather than within net cash flow like most reporting entities do.  Yes, a happy path.  But, all those other things are just additional use cases of the exact same fundamental approach I am using.

The relations for the balance sheet and cash flow statement are very straight forward and even non-accountants can grasp that those probably make sense: "Assets = Current assets + Noncurrent assets" is easy to understand.  Even the income statement is not that challenging for most of its areas.

The one place where I am having difficulty in computing the fundamental accounting relations correctly using the technique which I am using is all the stuff which is included within "Operating Income (Loss)".  There are exactly five reasons for this difficulty:

1. Discovery of the root reporting entity for a small number of filers (about 54)
2. Significant variability in the concept used by SEC filers to report revenues.
3. Lack of clear totals for the sub categories which make up operating income (loss).
4. Filers crossing categories of fundamental concepts (for example, including the total of one category within another category).
5. Inappropriate extension of these high-level concepts.

The list of SEC filers who pass all of my tests has grown from 294 to 584. That is less than 1% of all filers. Not that great.  However; it is a start and it proves that it is in fact possible to pass all my tests.

My next step is to get this entire process repeated by someone else to see if they get the same results that I obtained.  Also, I would like to figure out how solid that number of 96.6% really is.  If it is correct, the day that "reuse" of all this financial information has arrived or will arrive very soon.  Understanding what information is correct actually serves two purposes: (a) knowing that the information that you are reusing is correct and (b) information about what error needs to be fixed to make a filers information correct and reusable.

There are many, many other things which I have learned during the process of figuring this stuff out.  Stay tuned to my blog for additional information.

In my last blog post I discussed some enhanced information verification capabilities that I created.  I pointed out that for 21 tests, in 17 of those tests over 90% of SEC filers passed the test.

Something occurred to me.  I know exactly which information points failed.  I know the total number of filers I am analyzing (7,160).  I know the total number of information points I am looking for (51).  I added a column to my spreadsheet which calculated the information points which FAILED, that number is 16,421.

Some quick, back of the envelope math and I get a 95% pass rate for the 51 information points I am looking at.  Here is my calculation:

• Total number of failed tests: 16,421
• Total number of filings where NO information was found because no root reporting entity was discovered (54 entities X 51 information points): 2,754
• Total BAD information points (16,421 + 2,754): 19,175
• Total information points (7,160 filings X 51 information points): 365,160
• Percent of BAD information points (19,175 / 365,160): 5%
• Percent of GOOD information points ((365,160 - 19,175) / 365,160): 95%

Keep in mind that I am NOT using an XBRL processor to grab this information and that I am looking for very specific pieces of information and I am either finding the information successfully or calling this an error.  My tests are very aggressive.

What is the error rate in information manually created by data aggregators?  Generally, any manual process has about a 2% error rate.  So there is a difference between the 95% good information rate that I see and the perhaps 98% good information rate of data aggregators.

This is very encouraging.  I would suspect that the error rate in SEC information will eventually get into the range of .01%.  This is a very real possibility given a high-quality conformance suite of tests and forcing SEC XBRL filings through a set of agreed upon rules during the inbound submission of the information.

Don't know whether this 95% good informatoin rate can be projected onto all information within a filing including disclosures.  Likely not.  Filers have more experience with the primary financial statements than with disclosures.

When a professional accountant creates a financial report, one expects that financial report will add up correctly, will be created in compliance with accepted accounting rules, and will otherwise follow all the rules generally employed when creating a financial report.  And when these reports are created in the medium of paper, accountants generally do a very good job complying with the rules.  In particular, any accountant who works for an entity who reports to the SEC are among the best professional accountants there are.

When a professional accountant creates a financial report which is subsequently formatted using XBRL or when a professional accountant performs agreed upon procedures related to such an XBRL formatted financial report to be sure it is correctly created one would likely expect that the XBRL formatted report correctly articulates the financial information contained within that report.

I have personally been looking at SEC XBRL financial filings for many years in order to better understand SEC XBRL financial filings in particular and digital financial reporting in general.  In November 2009, I was happy when I found one SEC XBRL financial filing which would pass a battery of tests which I put together.  By March 2010, I was able to find 92 SEC XBRL filings which passed that battery of tests.  By September 2011, there were now 5151 SEC XBRL filings which passed that somewhat tuned battery of tests. And finally by March 2013, vast majority of the 7191 SEC XBRL financial filings I looked at passed a better tuned battery of tests.  Another thing which changed is that I don't need to do any of this testing any longer as commercial software is available to run these tests.  See the XBRL Cloud Edgar Dashboard.

However, most of those tests related to getting the representation of an SEC XBRL financial report correct.  There were about 9 accounting related tests to see if basic things such as "Assets" and "Net Income" and "Net Cash Flows" were reported, but the tests were rather basic.

Well, I now have approximately 50 fundamental accounting concept related tests and another 21 or so tests of the relations between these fundamental accounting concepts.  Click on the graphic below to see the results of these tests:

If you look in the "Percent" column you will see that of the 21 relationship tests, for 17 of the tests more than 90% of SEC XBRL financial filings pass the tests.  That is very good evidence that the test is a good test.

(Note that the column "No root entity" removes 54 SEC filings where I cannot get to any information using my processes, see why here.)

However, it could be that more SEC filers pass these tests or that the test needs to be modified to allow for situations which are not allowed for by the tests.  For example, it could be the case that someone would come to me and say that there are situations where Assets does not equal Liabilities and Equity.  They would point out the case where, for example, a filer uses "Net assets".  In fact, I don't take into account this exact situation.  I know my test set needs adjustment for this situation.  No problem, that would make my percentages go up and further support the notion that these fundamental accounting concepts and the relations between these concepts exist.

Does anyone pass ALL the tests?  Good question.  And the answer is yes, these 294 SEC XBRL financial filings pass all 21 tests.

I have a new wiki, Fundamental Accounting Concepts, which summarizes the concepts and the relations between the fundamental accounting concepts.  These relations don't change.  A US GAAP Taxonomy element cannot exist (or rather should not exist) in more than one category.  More on that later.

And while not every US GAAP financial statement reports all of this information that does not mean that the notion of that fundamental concept does not apply to a financial statement.  For example, if a reporting entity does not have equity method investments, then it will not have income (loss) from equity method investments.  That value is zero for that filing. Why is this important?  Comparison between financial reports.  EVERY financial report fits into this model other than reports which are explicitly excluded because they contain things which are rare.  For example, that is why I do not include net assets in my representation.  It is rare.  Need that representation?  No problem, it can be created.  I have just not created it as of yet.

Creating these XBRL-based financial reports is challenging particularly since the tools we have to work with today are not what they need to be.  How do we get SEC XBRL filings to follow these rules so there is even a chance that reuse of the information is possible?  Well, the SEC could enforce these sorts of rules via inbound verification when an SEC filing is submitted.  The FDIC does this, in fact they eliminated 18,000 mathematical errors on the first day they turned on the switch to the XBRL-based system they went live with in 2005. (See the bottom of this blog post)

Software vendors could also implement rules such as these within their software.  Some already are, for example XBRL Cloud. There are others.  Having software watch over the creation of SEC XBRL filings will reduce the number of time filers do something like use the inappropriate concept "us-gaap:AssetsNoncurrent" (like they did in this filing) to express "Total assets".  Now, they subsequently fixed that mistake in this filing. (Look at the report element name used for the balance sheet line item "Total assets" in both filings to see what I am talking about.)

Why do I think this is a new era?  Well, do you think that there are only 50 fundamental accounting concepts and 21 relationships?  This is the tip of the iceberg.  Eventually, software applications will help accountants do things like use a concept in one category within a totally inappropriate category and many, many other helpful things.  Like this idea?  Tell your software vendor.

Until software performs these tasks and/or SEC inbound verification does not except filings with these sorts of errors, XBRL master craftsmen need to watch out for these sorts of errors.  Otherwise Robocop may call you on the carpet.  These sorts of tests may end up being covered by the SEC accounting quality model.

"Knowledge as a service" is the vision of Epistematica.  Great vision. 

This company is also the first use of the term "semantic financial reporting" that I have heard. Semantic financial reporting is far better than the term I use which is "digital financial reporting".

I believe we are both talking about the same thing: guidance-based, model-oriented, semantic structured authoring of financial reports. 

The reports are not created using tools which know nothing of financial reports or financial reporting such as Microsoft Word or Microsoft Excel.  Semantic financial reports are created using "smart applications" which do understand financial reporting.  That may seem odd, but that is precisely what the semantic web is all about.

Software understanding the semantics of some domain is not voodoo or magic. It is all about metadata. Ontologies, like the financial report ontology, which express key "things" and important relations between those things which make up a financial report literally guide a user of that software to achieving some desired goal such as creating a financial report.

Ontologies express knowledge in the form of metadata which a software application can understand and use.  To see this you need both the software that understands the metadata and the metadata itself.

I predict that we will see the metadata and software which can understand and use this metadata for financial reporting within a year. Disclosure management software is a big step in this direction. Then accountants will get what XBRL is really all about.

Knowledge is part of a spectrum or hierarchy: (I synthesized these definitions from many other definitions)

• Data is the most basic level; discrete facts or observations, but unorganized and unprocessed and therefore has no real meaning or value because it has no context; for example, "10,000" is data.
• Information adds context; information is data in context, it has meaning; for example, "Sales for ABC Company for 2012 is $10,000 is information.
• Knowledge adds how to use it; knowledge is a framework for evaluating and interpreting information which makes use of experience, values, expert insight, intuition with the goal of evaluating and incorporating new experiences and information; for example, the sales for every public company organized in useful ways is knowledge.
• Wisdom adds when to use knowledge; wisdom relates to knowing why and doing something useful; wisdom = knowledge + experience; for example, exercising judgment to sell your shares of some stock because the sales relative to the sales of other public companies and relative to other numbers on a financial statement is wisdom.

The end game is now knowledge, it is wisdom.  Data, information, and knowledge are building blocks.  But it takes experience to to know what to do with that knowledge to have wisdom.

That is what I think.  What do you think?