Digital Financial Reporting

Three different software applications get the same results using three different code implementations when they run the Financial Report Semantics and Dynamics Theory core financial report semantics (see section 2.13 and the proof).

• Microsoft Access Prototype: The first application I used to prove the semantics was a working prototype application which I built using Microsoft Access.  I used that application to figure out how to get the information and just generally dink around and see if the SEC financial filings would look as I thought they might look.
• CoreFiling Magnify/Sphinx: The second was CoreFilings review tool Magnify using rules generated by their other product Sphinx to build and run the rules.
• UBmatrix/Edgar Online XBRL Processor using XBRL Formula: The third was UBmatrix's XBRL processing engine XPE. The tool that I used to build those business rules was Microsoft Notepad.

Basically, I am getting the same results from all three of these software applications. That is a very good sign. While I did not run the entire battery of tests like I did for the balance sheet here, I did spot check both the Magnify/Sphinx results and the XPE results and they are as I would have expected.  Further, the XBRL Formulas which I created could actually run in any XBRL processor which supports XBRL Formula.  That is one of the advantages of XBRL Formula.  The down side is that creating XBRL Formula can be rather challenging, creating Sphinx rules is much, much easier.

CoreFiling offers a 30 day trial of Magnify.  I would suggest taking advantage of that.  Here are the Sphinx rules which I created.  First, here they are in their raw format, basically text. Second, here is the rules basewhich you can load into Magnify.  (If you cannot figure out how to load this ask CoreFiling support or email me, I will provide you with a set of instructions.)

UBmatrix offers a free download for noncommercial use.  The XBRL processor comes with a sample application interface you can use to run XBRL Formual validation.  You can go here and sign up.  To try the rules using their tool, you will need this XBRL Formula file.  You can download the file or just point the application to this URL. Be aware that this works only with the 2011 US GAAP taxonomy; you have to change the namespaces to work with the 2009 taxonomy.

Side note: Arelle is an open source XBRL processor which has XBRL Formula capabilities.  I cannot read the validation results report so I have no idea if it outputs the same results or not.  But, if you are shopping simply based on price, you cannot beat this free open source XBRL processor.  You can download Arelle here.

Here are three SEC XBRL financial filings which show that they are valid using my Microsoft Access application, CoreFiling Magnify, and UBmatrix XPE.  All of these applications give the same results for the tests in the proof section of the Financial Report Semantics and Dynamics Theory:

1. My Model SEC XBRL financial filing: (for more info see here) These are the UBmatrix XPE validation results.  (This is an older version of the validation results, I have way more rules this one including filer specific validation rules.  These were also created within Magnify, still doing some tuning on those, will make them available later, these are very good examples.)
2. Bitstream Inc: (for more info see here) Their validation results from UBmatrix XPE showing no errors. Trust me on the Magnify results, I don't have permission to make their validation results files available at this point. I don't really have a report for the Microsoft Access database application prototype.
3. DEMAND MEDIA INC: (for more info see here) You can see by the XPE validation results that there are no errors. Magnify similary shows no errors, as does my Access prototype application.

Now, these filings each have errors.  These errors are quite easy to see and are pointed out by each of those same three software applications:

1. Intelimax Media Inc: (for more info see here) Their balance sheet is off by $50,000, probably due to a typo or something.  XPE validation results. Note the "notSatisfied" result and the message "$v:VARIABLE_Assets=974344 = $v:VARIABLE_LiabilitiesAndEquity=924344". This JPEG of the SEC filing's balance sheet clearly shows the error.
2. FORCE ENERGY CORP: (for more info see here) This balance sheet is off because Liabilities and equity for both the current and the prior period were entered as NEGATIVE values, rather than positive values.  You can see that here in this XPE validation report.  You can also see it here clearly on this JPEG of the actual balance sheet.
3. ZALDIVA INC: (for more info see here) Some people may not consider this an error; but I do.  This is basically sloppy and if thousands of other filers can balance their balance sheet, the 9 filers with minor filing errors can balance theirs also.  The balance sheet does not balance, it is off $2 which can be seen from this XPE validation report.  You can see this cleary on this JPEG of their balance sheet. You could put a tolerance within XBRL Formulas or Magnify rules to deal with this, but really?
4. Original Source Entertainment, Inc: (for more info see here) Don't quite get this but the XPE validation report points out that the balance sheet does not balance.  The amount is off by the amount of common stock for both periods, as can be seen by this JPEG.
5. TEXAS PACIFIC LAND TRUST: (for more info see here) Now, you need to look close at this one. If you look at the SEC balance sheet per this JPEG, nothing seems strange.  But when you look at the XPE validation report, what is going on becomes clearer. See this more clearly using the Magnify interface and you see that the filer reversed the sign of the fact assets for both the current and prior period. If you try and foot the value for assets manually, you see a second error. The filer modeled "Land" incorrectly, so the value would not add up correctly.  But, this was not caught because the filer created no XBRL calculations to verify that Assets foots correctly.

I cannot wrap this up without pointing out three things that I really like about Magnify.  The screen shot below are the validation rules checklist which is provided, which is formatted extremely well.  The first thing I really like is that ALL the rules are shown, the ones which are validated by the software and the ones which need to be validated manually.  Notice the light gray check marks.  Those need to be validated manually.  Second, the rules I created show up with all the other rules.  There are no separate lists of rules in different places, there is just one list.  Third, all the rules are shown, ones that pass plus ones that fail and they are distinguished nicely in the interface.

So there you have some things you can experiment with, good examples and not-so-good examples of filings and how core financial report semantics can be verified quite easily.  I show three software applications can do this type of work, but any XBRL processor which supports XBRL Formula can process that XBRL Formula file which I used.  If you have an XBRL Formula processor, try it out.  Be sure to let me know if it does or does not work for you.  Then, perhaps I can expand my list even more.

Looking at the balance sheet semantics of SEC XBRL financial filings can help understand what is meant by semantics and how useful understanding the semantics can be. Looking at the semantics also helps one understand the benefits of consistency.

Inconsistencies have implications.  For example, consider all the adjustments which would need to be made to software programs which read SEC filings if, say, a balance sheet did not physically report the fact with the concept "us-gaap:Assets".  The software would need to have code to handle all the possible exceptions that might come up.  Another way is to simply always require us-gaap:Assets to be on the balance sheet, even if you have no assets (report zero) or you only have one asset such as cash (still put in the total for current assets and total assets). 

Life would be so much easier and using the information would be easier and more dependable. Think about the implications when you look at the modeling choices filers have made in their balance sheets.

To look at balance sheet semantics in SEC XBRL financial filings, this is what I did.  First, I had to get filings to look at.  I used the SEC RSS feed archive.  I used October 2011 and November 2011. I looked at all 10-K, 10-K/A, 10-Q, and 10-Q/A filings.

From that list I looked for three things:

• Did the filer report "Assets"?
• Did the filer report "Liabilities and Equity"?
• Did Assets = Liabilities and Equity?

Pretty basic and reasonable financial reporting semantics.  Since all filers report balance sheets, balance sheets have assets and they have liabilities and equity; and balance sheets are supposed to balance, you would think that 100% of the filings would have those three characteristics.

This is what I found in the 8,098 SEC XBRL financial filings in my test set:

• 8,010 filings did have both of those facts (assets; liabilities and equity) and the balance sheets did balance (assets = liabilities and equity)
• 88 filings did not pass those three tests

So the obvious next step is to figure out WHY the 88 did not have those semantics. To do that I had to manually look at each of those 88 filings, which I did and the results are here in this PDF.

This list breaks those 88 tests down into categories:

• 4 filings CORRECT: Confirmed to be correct, uses Net Assets approach, need to adjust theory to consider net assets.
• 25 filings IN ERROR: Filer created concept which they used rather than using US GAAP Taxonomy concept because they felt "Liabilities and member equity" or "Liabilities and partner deficit" or "Liabilities Stockholders Equity and Redeemable Interest" made their number unique, not fitting into the definition of the concept with the standard label "Liabilities and Equity" (see http://goo.gl/g4UdH). However, this seems hard to justify. "Liabilities and Equity" seems rather clear, lots of other filers seem to agree with my view.
• 9 filings IN ERROR: Minor rounding error (most were $1, two were $2); I personally consider this sloppy.  Why can everyone else put in the correct numbers and have assets = liabilities and equity?
• 25 filings IN ERROR: Pretty clear filer made an error by choosing the wrong concept (say us-gaap:AssetsCurrent rather than us-gaap:Assets), transposed a number, entered an incorrect number, etc.
• 6 filings IN ERROR: Filer created extension concept called "TotalAssets", clearly us-gaap:Assets should have been used.
• 1 filing IN ERROR: Filer has balance sheet, but does not have an assets section, only liabilities and equity (i.e. could have provided Assets with a balance of $0). A balance sheet has both assets and liabilities and equity.  They perhaps could have called their statement "statement of liabilities and equity". Further, other filers added assets with a zero balance.
• 2 filings IN ERROR: Filer has balance sheet, has an Assets section, but that section contains only "Cash"; no total for "Current Assets" or "Total Assets".  Personally, I would add the concept "assets" and put the total on the statement.
• 6 filings IN ERROR: Clearly inappropriate use of the concept "us-gaap:AssetsNet" on a balance sheet (rather than a statement of net assets).  Easy to see that us-gaap:Assets should have been used.
• 2 filings IN ERROR: Filer used a nil attribute, should have used a zero. This is pretty clear in the EFM, besides there are lots and lots of filers who do use zeros in such cases.
• 1 filings IN ERROR: Created concept "NetAssetsInLiquidation", should have used "us-gaap:AssetsNet".
• 7 filings UNKNOWN: Unable to determine, but the balance sheet does not balance, seems incorrect, but could possibly be correct. Here is more information on those 7 balance sheets.

All of those add up to 88.  If all the errors were fixed and if I could figure out the 7 other strange filings which have balance sheets that don't balance, imagine how easy it would be to write a query to get total assets of all SEC filers at any point in time, for any set of filers.  We are so, so close to being able to do this for total assets of SEC public companies.  Once that is achieved, then other areas can be dealt with.  There is no magic involved here, pretty basic stuff.  Plus, you could double check your query by also requesting liabilities and equity and seeing that the two numbers you retrieved agree.

Now, you may not personally agree with my choices as to whether something is, or is not, an error.  Frankly, it does not matter which of us is correct.  What is important is consistency.  Unless there is a reason for not being consistent.  If that is the case then we both adjust our model to reflect all the allowable alternatives.  The bad things occur if there is no one model we can agree to.

Again, no magic here.

It is a game of inches, but there is definitely movement!

Allstate (not to pick on them, but I needed to pick an example) created the extension concept all:CashPeriodIncreaseDecrease in this filing (screen shot below) and used it to express net cash flow per their cash flow statement:

Allstate has subsequently changed this and now they use the US GAAP Taxonomy concept us-gaap:CashPeriodIncreaseDecrease (this screen shot) on their cash flow statement:

This is a small move, but I am seeing lots and lots of these sorts of these small, positive movements in SEC XBRL financial filings.  There is a ways to go, but the momentum is building.

Creating Financial Reports Using XBRL Leveraging the Financial Report Semantics and Dynamics Theory

XBRL does not need to be the nightmare that it is today for business users and even software developers trying to implement it in support of business users.  Digital business reporting which leverages XBRL will never take off and reach its potential if it is a bolt on process or outsourced service which generates structured information which few, if any, can make effective and efficient use of.

There is another way.

The Financial Report Semantics and Dynamics Theory may seem odd to an accountant.  Of course a balance sheet balances, of course things need to foot, tick, and tie.  These obvious semantics and dynamics never had to be documented in the past because humans did the work and they innately understand what those dynamics are and that these semantics and dynamics are true.

But computers don't understand these semantics and dynamics, software engineers don't understand many of them and in order to create software applications to serve business users, these semantics and dynamics do need to be documented.  The alternative to this is exactly what you see going on today: relating to XBRL at the XBRL technical syntax level, hard to grasp terminology, different interpretations of semantics because only the syntax is agreed to, and befuddled business users wondering how it is that XBRL is supposed to benefit them in some way.

What if XBRL were approached differently, articulating those semantics and dynamics? This is what would result:

• Terminology understandable by business users
• Easier to build software
• Easier for business users
• Safe
• Robust
• Clear financial report level semantics
• Efficient and effective verification framework

While global agreement on the terminology and object-level semantics and dynamics would be preferable; having a global agreement is not necessary to end the nightmare.  The semantics and dynamics of a financial report are agreed to.  Balance sheets do balance.  They also foot.  Computations must be correct.  XBRL-based financial reports must be true and fair representations of an entities financial report, just like their HTML or Word or PDF or ASCII version is today.  While global agreement as to the semantics and dynamics might get us where we need to be sooner rather than later; we will get where we need to be.

What, do you really think that business users will tolerate the nightmare?  Innovative software vendors can, and will, solve this problem and put an end to the frustrating and expensive nightmare.  Rest assured.

If you want to be one of those innovative software vendors or if you are one of those frustrated business users who feel they are paying way more than need to in order to satisfy the SEC XBRL mandate, consider checking out Digital Financial Report Framework Leveraging XBRL to explore an alternative.

This document provides a reconciliation between the semantic objects of the Financial Report Semantics and Dynamics Theory, the model which I put together for implementing SEC XBRL financial filings, and the XBRL technical syntax. It helps make clear two areas of ambiguity of SEC XBRL financial filings:

1. When should a network be used and when should a [Table] be used. Said another way, what meaning exactly does a network have and what meaning does a [Table] have.
2. When should a characteristic which describes a financial fact be modeled as a concept and when should it be modeled as a [Member] of an [Axis].

These two issues are a bit of a big deal because having these choices makes it more difficult to create easy to use software and increases the complexity and therefore the cost of creating SEC XBRL financial filings.

Anyone who creates SEC XBRL financial filings probably understands these issues.  OK, so what do you do about this?  Well, for the first issue; many SEC filers are already doing a good thing which is to create a one-to-one correlation between networks and [Table]s.  This is a safe thing to do.  Some filers, and I know that 100% of Edgar Online filings are done this way (I used to work there), is to always use a [Table].

So basically, if there is a one-to-one correlation between networks and [Table]s then there is no ambiguity between what a network means and what a [Table] means because they mean the same thing. As such the first issues is not that hard to work around, although it does not fix the problem.

The second issues is somewhat trickier but there are some guidelines you can use.  First off, your choice of whether to model something as a concept or an [Axis] is many times determined by how something else has been modeled. 

For example, if you want to figure out how to model the components of "cash and cash equivalents" or "inventory" and you want them to show up correctly on your balance sheet and you want your balance sheet to foot correctly; you pretty much need to model the detailed components as concepts because everything else on the balance sheet is a concept. 

On the other hand, you could choose to disclose the details in the disclosures and therefore you would choose either approach; modeling those details as concepts or as [Member]s of an [Axis].  In this case, as long as there are no other areas which would be goofed up and not fit together properly; I personally would choose to model the information as [Member]s of an [Axis] in most cases.  The primary reason is that you can then connect things together better, for example the details and policies which might relate to those details.

The data point model tries to solve this issue of trying to figure out whether to model something as a concept or as the [Member] of an [Axis] (i.e. this issue is not unique to the US GAAP Taxonomy) by modeling a set of base items as concepts and all further details as [Member]s of an [Axis]. However, that might be a bit too radical of an approach to standardize on. But the data point model is additional justification to vier toward using [Member]s of an [Axis] if you have a choice between two options.