Digital Financial Reporting

I did not go to the XBRL US Conference in Austin, but from what I have heard and from what Rob Blake says on his blog, there is increasing focus on SEC XBRL financial filing quality.  Here is a part of Rob's blog post (you can get to the entire post here):

SWEAT THE DETAILS:  Being active and engaged in the XBRL review process is one thing.  Understanding all the moving and required parts of the review itself is another.  Much attention was given to helping companies “see beneath the content” and better understand the various aspects of an XBRL submission that need to be reviewed.  “Feel good” reviews comparing the XBRL to the HTML need to be supplemented with a detailed and thorough (dare I say Complete…=) review of the signage/calculation structure of the XBRL as well as the information contained in the extension taxonomy.  Companies that currently place the primary review responsibility on external service providers with little to no direct activity need to change the model immediately to bring a large portion of the review process in-house.  Now is a really good time to sweat the details around an XBRL submission.

For those who have been following my blog you know that I have been harping about quality for a number of years. The need for "quality" is going to become a buzz word which people throw around, saying that they can do "quality" and others cannot in order to sell their software.

Don't let software vendors fool you.  Ask good questions.  Educate yourself. I can tell you from first hand knowledge that most software vendors cannot yet deliver on this promise of quality yet.  Zero.  If they could, I would see that fact in the results of my analysis of SEC XBRL financial reports.  Some software vendors are better that other software vendors in certain specific areas.  For example, if you look at something like the XBRL CLoud EDGAR Dashboard, look in the columns marked "E" for Edgar Filer Manual and US GAAP Taxonomy Architecture validation.  That is the tip of the verification iceberg!  Some software vendors don't even get that right yet.

Like Blake says, "feel good" reviews and less than complete reviews just will not cut it.

My document Guide to Verification of an SEC XBRL Financial Report helps you see what a complete review looks like.  It also helps you understand what to expect from software to help you.  Further, you don't need to be dealing with XBRL technical syntax at all.  Literally, not at all.  Good software will hide the XBRL technical syntax and allow you to focus where you truly need to focus: on the business meaning, on the semantics.

Just ask yourself one simple question: How do you know that your SEC financial filing is a true and fair representation of your entities financial information and what evidence do you have to prove that?  Ask software vendors and filing agents that question and have them walk you through exactly how they do that.  The guide above helps you understand the details of "true and fair".

Software vendors love uneducated customers, they are easy to sell to.  Don't be an uneducated customer though.  Become consciously competent as soon as you can. 

You know that for digital financial reporting to really work, business users must be able to successfully be able to create and prove to themselves and other business users that digital financial reports such as SEC XBRL financial reports are true and fair representation of their financial information. We will end up there.  May as well get their sooner rather than later.

A short six minute video I created back in 2008, How XBRL Works, has exceeded 20,000 views on YouTube.

In discussing something on the XBRL Formula Working Group list the following statement was made which I wish more people creating taxonomies and software vendors understood:

"the formulae are part of the model, not an afterthought"

Business rules expressed using the two global standard means available, XBRL calculations and XBRL Formula, are key to creating a quality XBRL taxonomy.  Business rules define/document important relations and other information.  Without this information, those using taxonomies to express financial information in an XBRL instance will have holes in their knowledge of how to properly model reported information and holes in their ability to verify that the information they expressed was correctly expressed.

Those creating XBRL instances can get around this problem by creating their own business rules, and in fact this is the only practical way to help them be sure that the information they are expressing has been correctly expressed.  But the down side is that each business user creating what amounts to their set of proprietary business rules does so in a vacuum on their own and there is no guarantee that any two business users will consistently express relations which should be consistent across all XBRL instances or classes of XBRL instances.

People will eventually figure this out.

Lack of business rules causes another problem: poor renderings.  These business rules contain information which could be leveraged to detect patterns and leverage those patterns to render the information contained within a financial report expressed using XBRL.  Software developers complain about how flat XBRL is.  Well, it is actually not the case that XBRL is flat.  The relations are just not expressed in  the XBRL Schema, they are expressed in other places.  These missing relations which would exist if the business rules were expressed using XBRL Formula would reveal how un-flat financial information is.

Don't understand what I am talking about or want more detailed information? Explore these disclosure templates.  Each has an XBRL taxonomy, XBRL instance, and business rules expressed using XBRL Formula and explained in the form of a brief narrative.  An example is below:

Well modeled XBRL taxonomies yield very good renderings.  Providing a complete set of business rules in the form of XBRL Formula forces good modeling.  The business rules expressed using XBRL Formula makes semantic information explicit, exposing it to software vendors, allowing the information to be leveraged by software.

Today, well modeled digital financial reports have these semantics.  People just are not seeing these semantics. Not business users or software developers.  But just because you cannot see the semantics does not mean that they do not exist.  These metapatterns prove that.

It is going to be fun to use all that SEC XBRL information! Here is a little sample I put together from the data set I extracted:

Food Stores: Net Income to Income Tax Comparison

I just tossed some stuff together.  The chart I made shows net income (green bar) as compared to income tax expense (red line with yellow diamond) for Food Stores.

Not a big deal you say.  Could have thrown this together in a matter of minutes in Excel.  Go to each filing, find the two numbers for each company, copy and paste them into Excel.  Repeat for each of the 18 companies.  OK, now do the same thing for each of the approximately 68 different industries/activities and the some 7,000 public companies.  Want different data points, maybe assets or research and development?

Hopefully you are starting to get the point and see the huge marginal benefit in terms of cost savings related to reusing all this information.

And this benefit is not limited to SEC XBRL financial information.  Any time you want to collect information from sources external to your organization or department think of what a pain it is.  Consider trying a global standard format for collecting all this information. 

Sure, software has a ways to go before one can say with a straight face that business users can do this themselves, no IT department.  We will get there.  We will get there. 

In my last post I discussed what I found when I analyzed the core financial integrity of the balance sheets of all 7,220 SEC XBRL filings for June, July, and August of 2012.

In this blog post I will discuss the core financial integrity of the top 100 SEC filers as determined by total assets of the filer.  This Excel spreadsheet has a summary of the data and findings.  This HTML page has the same information.

This is what I found:

• Only 3 core financial integrity semantics errors: Of these top 100 SEC filers, there are only three core financial integrity errors that I found: (1) HARTFORD FINANCIAL SERVICES GROUP INC/DE created an extension concept hig:NetIncreaseDecreaseInCash to express net cash flow; (2) HARTFORD LIFE INSURANCE CO created an extension concept hic:NetIncreaseDecreaseInCash to express net cash flow; (3) EXELON GENERATION CO LLC created an extension concept exc:LiabilitiesAndStockholdersEquityIncludingPortionAttributableToNoncontrollingInterestto express Total liabilities and shareholders' equity.  It would be hard to justify either of these three extensions given that 99% of all other filers used concepts from the US GAAP Taxonomy.
• Out of 900 data points, only 3 errors: So, out of a total 900 data points, there were only 3 errors!  That is great.  How did I get to 900? Well, there are 10 data points I was looking for: entity registrant name, document period end date, period start date, assets, liabilities and equity, liabilities, temporary equity, equity, net cash flow, net income. I did not really need one of them, entity registrant name.  So that leaves 9.  9 data points times 100 filers, that gives me 900.
• If total liabilities is not reported, causes data retrieval issues:  Not having total liabilities and I guess also total temporary equity reported causes problems extracting data because it is hard to know if you got the numbers correct.  What I mean is that it is almost certain that "assets" and "liabilities and equity" are correct because you can get the numbers and check to be sure that the numbers are the same (i.e. the balance sheet balances) and therefore you can be confident that you are working with the correct numbers.  But if (a) totals are not reported and (b) there is uncertainty as to which concepts a filer will be using on a fact; that leads to uncertainty as to whether you have actually retrieved the correct data or imputed values correctly.  What does this mean? Totals such as total liabilities, total temporary equity and total revenues should always be required to be reported because that allows those pulling out their data to be sure they are pulling out the RIGHT data.
• Balance sheets balance: The balance sheets balance for 100% of the top 100 SEC filers.
• Balance sheets exist: Balance sheets exist for 100% of the top 100 SEC filers.
• Root entities exist: Root entities exist for 100% of the top 100 SEC filers.  For example, while EXELON GENERATION CO LLC had 5 CIK numbers, there was exactly one root company into which the other entities flow. So, if you want to get the numbers, it is clear what entities to go after in the modeling of the information.
• No "audited" or "unaudited" members: None of these filers use an [Axis] to express that the information is audited or unaudited. (See the discussion about this in the prior post.)
• Document period end date always ties to balance sheet date for most current period: The document period end date always ties to the most current balance sheet date.
• Least confident in fact net income (loss): Of all these facts, I am least confident in the fact net income (loss).  There are two reasons for my lack of confidence.  First, there are so many different concepts filers could use for net income (loss).  Second, if filers use the wrong concept in the wrong order the wrong fact value will be retrieved.  This has to do with totals being provided.  I am looking for net income (loss) including the portion attributable to any noncontrolling interest and including any portion attributable to preferred stockholders.  It would be better, in my view, if one concept existed for this and if every filer used that one concept.

I am beginning to see automated use of this information rearing its head.  It is the little things that matter.  This is particularly true for smaller companies which want to extract information from the SEC XBRL public company information set.  Sure, big data aggregators can work through any data retrieval issues.  But, there will be a cost passed on to users for fixing these errors and therefore the cost of the data will be higher; perhaps much higher if there are lots of issues.  The fewer the issues, the more consistent the information provided, the easier it is to get the information, and therefore the cost of the information will be lower.

That is what I see.  How do you see it?