Digital Financial Reporting

I have updated the set of metapatterns I have been maintaining for years. Also, upon the recommendation of others I am going to start referring to these as "accounting arrangement patterns" or "line item arrangement patterns" because that is a more precise term.

The biggest change is that I corrected the XBRL Formula namespaces and schema locations.  These are now confirmed to work consistently per the UBmatrix, Arelle, XBRL Cloud, and TrueNorth XBRL processors. (see here for more information about interoperability.)

Users of XBRL will soon be realizing that they need XBRL Formula, in particular SEC XBRL financial filers.  The XBRL Formula examples of these metapatterns make understanding how to create these business rules a bit easier.

OK, so here are a bunch of ideas which I am trying to fit together.  These seem to be very, very related. Seems like all this stuff needs to be synthesized together somehow:

• Ontology: An ontology is a representation of something that exists in reality.  An ontology deals with questions concerning what entities exist or can be said to exist, and how such entities can be grouped, related within a hierarchy, and subdivided according to similarities and differences.
• Knowledge base: A knowledge base is an information repository that provides a means for information to be collected, organized, shared, searched and utilized. It can be either machine-readable or intended for human use.
• Business rules engine: A business rules engine is a software system that executes one or more business rules in a runtime production environment. The rules might come from legal regulation ("An employee can be fired for any reason or no reason but not for an illegal reason"), company policy ("All customers that spend more than $100 at one time will receive a 10% discount"), or other sources. A business rule system enables these company policies and other operational decisions to be defined, tested, executed and maintained separately from application code.
• TBox: A TBox is a "terminological component", a conceptualization associated with a set of facts, known as an ABox.
• ABox: an ABox is an "assertion component", a fact associated with a terminological vocabulary within a knowledge base.
• Differential Diagnosis: A differential diagnosis is a systematic diagnostic method used to identify the presence of an entity where multiple alternatives are possible, and may also refer to any of the included candidate alternatives. This method is essentially a process of elimination or at least of obtaining information that shrinks the "probabilities" of candidate conditions to negligible levels.

As I understand it:

• A knowledge base is an ontology + assertions.  A knowledge base is an ABox.
• Off-the-shelf software does this "stuff" above.  However, there is little software which uses global standards to build useful things.  For example, a company called LogicNets provides a software application that lets you build "logical nets", or a decision tree or process node,  (here is a video) which seems to allow you to use some type of knowledge base or rules (that seems to be what a logic net is).  So, there seems to be off-the-shelf software which allows you to build systems using knowledge bases.
• Network theory and graph theory seem to be part of this equation.

There seems to be an entire alphabet soup of global standard technologies which are being created, building on top of RDF and OWL related to knowledge bases, business rules, etc:

• SPARQL: A language for querying RDF. http://www.w3.org/TR/rdf-sparql-query/
• SWRL: A Semantic Web Rule Language Combining OWL and RuleML. http://www.w3.org/Submission/SWRL/
• RIF: An XML language for expressing rules which computers can execute. http://www.w3.org/2005/rules/wiki/RIF_FAQ
• SPIN: SPARQL Inferencing Notation (SPIN). SPIN is a SPARQL-based rule and constraint language for the Semantic Web. SPIN is also a mechanism to represent reusable SPARQL queries as templates and to define new SPARQL functions with a web-friendly syntax. http://www.w3.org/Submission/spin-overview/

And, oh yeah, throw XBRL into this equation.

What seems to draw all these things together is the desire for meaningful information exchange.  There are proprietary ways of doing these things and there are global standard ways of doing them.  Clearly global standard ways seem preferable to me and the effort being put forth to create these standards seems to support my preference. It seems that there is a high risk these days of choosing the wrong technology because many of these things are so new and things seem to be moving rather fast.

The following is a post I made to an XBRL news list which walks you through, step-by-step, extracting financial facts from SEC XBRL financial filings from public companies.  The explaination provides a "happy path" which eliminates details to make the explaination easier.  Extracting any fact works in this same manner, it just involves additional details. Use this prototype to work through this process if you desire. You can turn the debugger on and step through the process as it unfolds. Basically, extracting other information is a variation of this same process.

STEP 1: You need to know WHERE the information is (i.e. what companies, what filings).

The first thing you need to do is have a list of companies or know the list of companies you want to pull information for and which filings contain that information.  So XBRL does not deal with this issue at all and is, in my view, a flaw in XBRL because you cannot express this and therefore every software tool consuming information works differently.

In the SEC's case, they provide an RSS feed thich contains lists of reoprting entities and the submissions of those entities.  You can find that RSS feed here:

http://www.sec.gov/Archives/edgar/monthly

If you go into one of those RSS feeds (look at the XML, THAT is what a computer application will read; you can VIEW this via a browser).

And so, if you notice my Excel application; it eliminates that step by providing a workbook which contains all this information.

STEP 2: What information do you want?

The next thing is that you need to know WHAT information you are looking for.  Because the US GAAP Taxonomy uses multiple XBRL elements to express the exact same financial reporting concept, you are forced to "map" the XBRL concepts to what you are looking for.

For example, the US GAAP Taxonomy uses the elements "us-gaap:LiabilitiesAndStockholdersEquity" and "us-gaap:LiabilitiesAndPartnersCapital" to represent the one financial reporting concept "LiabilitiesAndEquity" which I am using within my system.  This is a pretty basic example, "Revenues" is a much more complex example as you pointed out.  But, the issue is EXACTLY the same: you need to understand WHAT to look for in the SEC XBRL financial filing.

I did this for 51 concepts that I am looking for, see the VBA code.  I did this the WRONG way in my code, basically hard coding it.  I have subsequently moved the "tree" of IF statements into a database. 

STEP 3: Which period, which piece of the entity, which reporting scenario?

The next thing you need to do is for each concept that you want, you have to get the correct fact within the correct context.  For example, you have "current period" and "prior period" and "year to date" and "quarter to date".  You also have "consolidated entity" and different subsidiaries or business segements or geographic areas and so forth.

The SEC did a VERY, VERY nice thing.  They made it EASY to identify the "current period" and the root reporting entity. So you can leverage the way the SEC says the information needs to be structured and the reported concept "dei:DocumentPeriodEndDate" (which is basically the balance sheet date of the current period).  From that you can find the YEAR TO DATE period of the income statement.  And because of the way the "root entity" or consolidated entity is consistently articulated because of the SEC rules, yuo can leverage that consistency to get the "consolidated" information.

What may be confusing you here is that I am "taking the happy path" through the information.  I ONLY want (a) the CURRENT period, (b) the CONSOLIDATED entity, (c) of the ROOT entity.  (Clearly if you want EVERY period and EVERY entity breakdown and EVERY scenario this is more complicated, but the same general ideas apply.)

STEP 4: Impute missing information

Because filers inconsistently report facts, I impute or "plug" missing information based on existing information and known relationships.  For example, not all filers report "us-gaap:Assets".  If a filer, say, has only one asset, "us-gaap:Cash", many leave out the concept "us-gaap:AssetsCurrent", "us-gaap:AssetsNoncurrent" and "us-gaap:Assets".  However, I know that for 100% of all companies who report a classified balance sheet that "Assets = CurrentAssets + NoncurrentAssets".  That is universally true, that relation NEVER changes and the fact that 98+ percent of filers FOLLOW that rule PROVES that the rule is true.  The other 2% have confirmed errors in their filing or do strange things which are beyond the capabilities of my algorithm to handle.

STEP 5: TEST, TEST, TEST

To be SURE that I am getting the correct information I run the information through a battery of 21 tests which are universally true about balance sheets, income statements, and cash flow statements. Again, these tests are played out in the 7160 SEC filings that I am looking at (10-K only, not the other forms).  There is SOME variability that I have dealt with such as a classified versus an unclassified balance sheet and a single-step or multi-step income statement.

STEP 6: Populate Excel

That is it, put the result in Excel for each of the concepts that you want.

*************************************************** 

Again, like I have said, this is "the happy path" to a small set of information.  Getting at any OTHER information is some variation on the steps above: what entity, what filing, what fact, what part of the entity, what period, what scenario.  There are sometimes other characteristics; but these ideas work for EVERYTHING.  I can PROVE that, it is a fact. 

YES, the more you deal with the other variations, the more complicated the computer code necessary.  Things can be made easier by improving the US GAAP Taxonomy and eliminating duplicate instances of the same information, better organizing the taxonomy to enable the ability to more easily map the concepts used to the information you want.  The system can also be improved by better inbound validation by the SEC to eliminate errors in the information.  The system can be improved by minimizing the need to imply things because a filer did not explicitly make it available.  But, these issues do exist now so they need to be dealt with.

All of the above is reflected in the VBA code shown in this prototype and in the working Excel application which you can run, turn your debugger on if you want, and WATCH the entire process unfold in front of your own eyes: 

http://xbrl.squarespace.com/journal/2013/5/5/accuracy-rate-raises-to-973-for-sec-xbrl-filings-prototype-f.html

Does this get you to where you want to be?  If not, tell me what I am missing and I will attempt to fill in those gaps. 

Much of this stuff can be simplified by using a web service or someone who sorts this out for you.  Data aggregators do this including the mappings, that is HOW they get that information.  There is no magic, only hard work.  That is the "high end".  Other web serivces such as the XBRL Cloud web service don't provide the "final" interface, but they do all the "stuff" necessary to get you the information you want, you build your own interface. 

The GOOD news is that you can now get the financial information of thousands of companies in minutes.  Think of how long this process took three years ago when this task was either (a) 100% manual or (b) the parsing necessary was so complicated and cost prohibitive that only big companies could afford to do it.  Maybe this is not perfect, but it works and is useful.  In time, things will get even easier!

Accounting research just got a whole lot easier because of XBRL.  You should start seeing commercial quality software which will enable accountants and other business users to perform tasks with far less effort than in the past in the near future.

How do I know? Well, because I built a working prototype of such software.  The three videos below will walk you through what that software does. I have been maintaining a tool which I used to analyze SEC XBRL financial filings.  What I could do was really interesting, but very limited due to my programming skills.

But now, I reconfigured much of my tool to use the XBRL Cloud Web Service which (a) replaces all of the infosets which I was working with and (b) provides independent renderings of EVERY SEC XBRL financial report component.

Way back in 1999 when we first started down the XBRL trail, I had created prototypes which showed how XBRL could be used to compare financial information across financial reports.  I compared that to the very popular AICPA product Accounting Trends and Techniques.  I have tried over, and over, and over to make this work how I wanted it to work. Well folks, this dream is now reality!

As I see it, everything else is about "the details."  Does my prototype work perfectly?  No, pretty much every aspect of this needs improvement. Is the data public companies are providing perfect? No, lots of room for improvement there also.  But fundamentally, this stuff works and if you look closely you can get a glimmer of what financial reporting will look like in the future. Digital financial reporting does have its advantages.

Check out the videos and screen shots below and decide for yourself if XBRL might be useful to accountants after all:

• General overview: Provides a general walk through of the "Financial Reporting Trends" working prototype accountant's analysis tool.
• Closer Look at Filtering Entities and Disclosures: Focuses on showing you how you can filter the long list of entities into different helpful groupings.  Also, shows how disclosures are organized in various ways to make working with them easier.
• Closer Look at Viewing Financial Report Information: Focuses on showing you what information you have to work with once you get to the component you want to have a look at within a reporting entity's financial report.
• Closer Look at Fundamental Accounting Information Extract and Working With Components: Focuses on showing you how a set of 51 fundamental accounting concepts are extracted from SEC XBRL financial filings and how a set of 21 tests are used to make sure the relations between those concepts are tested to be sure the information retrieved is correct.  This Excel version of this prototype lets you try out extracting fundamental accounting information from SEC XBRL financial filings. Looking at the code helps you grasp how to do it.
• Screen shots: This is a set of screen shots to let you take a closer look at what my working prototype does.

And yes, all this stuff is in one application. The application was built using Microsoft Access which is a rapid prototyping tool. As I said above, a lot of the heavy lifting is done using the XBRL Cloud Web Service. My tool was NOT built to be a product.  You could probably look at the tool I created and find 50 different useful products. Literally.

I am not trying to win any awards with the video, just trying to quickly show what the working prototype does and learn better how to communicate this information so keep that in the back of your mind. The prototype is helpful in showing what XBRL can enable and more importantly what it takes to make digital financial reporting work.

A commercial tool which lets you do some of what I can do right now is Calcbench. Note their tools for auditors. Tools for M&A and benchmarking. Tools for academia. Others will likely create other useful tools for accounting research.

My first pass yielded an information accuracy rate of 95%. The next pass pushed that up to 96.6%. The next realized 97.3%. Focusing only on commercial and industrial companies, basically creating sub categories but focusing on that primary category, yielded 98.4% accuracy.  These incremental improvements were realized by tuning my algorithm and adding additional metadata used by that algorithm.

All this work ultimately resulted in a 98% overall accuracy rate for the extraction of fact values for 51 fundamental accounting concepts proven by the 21 relations between those facts expressed within SEC XBRL financial reports. This graphic provides a summary of these results:

All this work also resulted in a more precise understanding of why SEC XBRL financial filings to not pass the 21 tests which I have specified and ultimately in an inability to reuse information from an SEC XBRL financial filing using automated processes.  That is the goal: robust, reliable, predictable automated reuse of the information.

And while I do want to be able to reuse the SEC XBRL financial information, the over-arching goal is an understanding of how to build systems which make use of XBRL-based information which are robust, reliable, predictable and the information within the system can be reused dependably.  Without that, what good is the system?

If you have not tried it already, experiment with the Excel-based prototype for extracting information using my algorithm for grabbing SEC XBRL financial information. Also, you can see the algorithm which I am using.

The following is a summary of the specific issues which I have encountered which cause information reuse issues:

• Discovery of the root reporting entity for a small number of filers (about 58)
• Significant variability in the concept used by SEC filers to report revenues.
• Lack of clear totals for the sub categories which make up operating income (loss).
• Lack of clear totals for distinguishing between nonoperating income (loss) and interest and debt expense.
• Filers crossing categories of fundamental concepts (for example, including the total of one category within another category).
• Inappropriate extension of these high-level concepts.