Digital Financial Reporting

The following is a summary of information related to the verification of XBRL-based financial reports. I have accumulated this information as part of trying to figure out how to verify SEC XBRL financial filings.

To start, let me define verification.  By verification I mean:

• An accountant or team of accountants can perform a specific set of steps which will allow them to be sure that the financial report which they created is a "true representation" or a "true and fair representation" of the financial information of the reporting entity for which the financial report has been created. (Note that the term "true and fair" has specific meaning and I may need to tweak these terms; auditors use the term "present fairly", but it would be hard for me to believe that "true and fair" is not a reasonable statement)
• Management of the company for which the financial report has been created can ask the team of accountants "are you sure these are correct" and the accountant or team of accountants can reasonably reply, "yes, we are sure".
• A third party accountant can state that a financial report presents fairly the financial information of the reporting entity because they have performed a specific set of steps which allow them to be sure that the financial report "presents fairly" such information.

The primary points here are that (a) verification is tangible proof that the financial report is "true and fair" and that (b) verification by the party who is not independent or verification by a third party that is independent has to do with WHO did the verification, not what work is done to verify the financial report.

What I want to stay away from here is the debate as to whether an auditor "audits" financial information expressed using XBRL.  There is a boatload of work that goes into making sure the numbers and other information are "presented fairly" and what exactly goes into the financial report.  That is definitely "audit" or "attest" type work.  I am not talking about that audit work.

There are two sources of information related to verify or "address the completeness, accuracy, or consistency of XBRL-Tagged Data" (basically, what one needs to do to achieve verification):

• AICPA SOP 09-1: Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data
• A paper, Assurance on XBRL Instance Document: A Conceptual Framework of Assertions, which analyzes AICPA SOP 09-1 and other documents which help achieve verification.

This blog post of mine has links to both of these documents. The second document has references to other resources. The second document, the paper, makes the following statement:

SOP 09-1 provides only an illustrative list of management assertions for handling the XBRL-tagging engagements under the SSAEs as agreed-upon procedures without considering a framework. Without a conceptual framework, the assurance process for XBRL instance documents would be ad hoc and inconsistent.

I agree with that statement, a conceptual framework is important.  The paper provides a conceptual framework.  I cannot tell if the authors are holding that out as "the conceptual framework".

Another important thing pointed out by the paper is that the reliability of software applications which are used to assist accountants, management or third party accountants is critical. One must understand what the software is doing, what it is not doing, and different software applications should perform the same fundamental processes in the same manner.  Today software is more like a "black box" and no one understands exactly what the software is doing and no software could possibly perform all the steps because the steps are not even defined adequately (more on that below).

I would point out that neither the AICPA SOP nor the paper provide a detailed set of steps that, if followed, would ensure that said document is correct, accurate, consistent, etc.  What I am wondering is how a conceptual framework can be specified without knowing all the detailed steps which are necessary.  Maybe you can do that, but it has been my experience that people who try and summarize things before they understand all the details tend to make mistakes and leave things out.

I would point out that there are three things I believe that both the AICPA SOP and the paper are doing which I believe should be done differently.

1. Both mix terms that relate to the XML/XBRL technical syntax and terms that relate to semantics. It is my view that there is no need to use terms that relate to technical syntax at all.
2. Both focus on "XBRL". What if other formats for expressing financial information come to exist or of someone chooses to use RDF/OWL or some other form of XML?  Further, it is because there is a focus on XBRL here that leads to mixing the XML/XBRL technical syntax and financial report semantics and terminology which is both hard to follow and difficult for a business person to understand.
3. Neither provide enough details as to the steps necessary.

Fundamentally, I believe that a set of verification assertions has no need to consider the medium or format by which the financial information is being made available; be that format traditional financial reports made available on paper; in electronic form such as Word, HTML, or PDF; or even digital form such as XBRL, RDF/OWL, other forms of XML; or other digital formats/mediums such as within some sort of software application for viewing or otherwise consuming financial information.

The Financial Report Semantics and Dynamics Theory has no regard for medium or format of financial reports. This theory breaks financial reports into pieces which are understandable to business users:

• Financial report: Report which communicates financial and nonfinancial information to users of that report.  Contains facts, characteristics which describe those facts.
• Fact: A piece of information which is reported in a financial report. Facts have values which could be textual, numeric, or prose. Numeric facts have two additional traits: units and rounding. Facts may have one or more additional parenthetical explanations.
• Characteristic: A characteristic provides information necessary to describe a fact. A fact may have any number of characteristics.
• Parenthetical explanation: A parenthetical explanation provides additional descriptive information about a fact.
• Component: A component is a set of facts which go together for some specific purpose within a financial report.
• Relation: Facts can be related to other facts.  Characteristics can be related to other characteristics.
• Property: Facts have a known and finite set of properties. Characteristics have a known and finite set of properties.  Components have a known and finite set of properties. The concept characteristic has additional properties: period type, data type, balance type. Relations have a known and finite set of properties.

This video walks you through this set of primitive or fundamental or rudimentary building blocks of a financial report. These building blocks have no regard for medium/format.  I believe they are understandable to business users.  While business users may disagree on the name of the building block, it is rather hard to dispute the notion of these rudimentary building blocks.

And so, if there are a set of building blocks and if that set of building blocks and each building block's properties are finite; it seems to me that a definable, finite set of steps can be articulated and if one does not lock themselves into one technical syntax, then you can rely on only financial report semantics to articulate these steps.

To be clear I want to list the high level objectives which I believe are important to verify a financial report and define some important terms:

• Completeness: Having all necessary or normal parts, components, elements, or steps; entire.
• Correctness: Free from error; in accordance with fact or truth; right, proper, accurate, just, true, exact, precise.
• Consistency: Compatible or in agreement with itself or with some group; coherent, uniform, steady. Holding true in a group, compatible, not contradictory.
• Accuracy: Correctness in all details. Conformity or correspondence to fact or given quality, condition. Precise, exact. Deviating only slightly or within acceptable limits from a standard.
• Fidelity: Where accuracy focuses on the details of one fact; fidelity is accuracy of all facts considered as a whole in the reproduction of something as compared to actual facts.
• Integrity: Holistic accuracy, accurate as a whole. The quality or condition of being whole or undivided; completeness, entireness, unbroken state, uncorrupt. Integrity is a concept of consistency of actions, values, methods, measures, principles, expectations, and outcomes.
• Validity: Complete, correct, consistent, accurate, has fidelity, has integrity.

I have provided a detailed set of characteristics of a quality financial report, I repeat that set of characteristics here having "tuned" them to the Financial Report Semantics and Dynamics Theory and the other ideas and notions I have come across:

• True and fair representation of financial information: The objective of a financial report is to provide a true and fair representation of the entity which issued the financial report. A financial report is a true and fair representation if it is complete, correct, consistent, accurate, has fidelity and integrity. Validity.
• All financial report formats convey the same message: A financial statement can be articulated using paper and pencil, Microsoft Word, PDF, HTML, XBRL, or other format. But while the format may change, the message communicated, the story you tell, should not change.  Each format should communicate the same message, regardless of the medium used to convey that message.
• Information fidelity and integrity: A financial statement foots, cross casts, and otherwise "ticks and ties".  As accountants we understand this and many times this fact disappears into our unconsciousness because it is so ingrained.  Of course things foot and cross cast; of course the pieces tie together. Said another way, a financial statement must be correct, complete, consistent, and accurate. Only trained accounting professionals who understand how the XBRL medium works can tell if all financial statement computations are properly articulated and verified to be correct.
• Justifiable/defensible report characteristics: Facts reported and the characteristics which describe those reported facts should be both justifiable and defensible.
• Consistency between periods: Generally financial information expressed within one period should be consistent with the financial information expressed within subsequent periods, where appropriate.  Clearly new information will be added and information which becomes irrelevant will be removed from a financial report.  Changes between report elements which existed in both periods should be justifiable/defensible as opposed to arbitrary and random.
• Consistency with peer group: If your company chooses one approach and a peer chooses another report element selection choice; clearly some good reason should probably exist.  This is not to say differences would not or should not occur.  Rather, why the differences exist should make sense.  Generally financial information between two peers should be more consistent as compared to inconsistent.
• Information renderings make logical sense: Renderings of facts and characteristics which make up the components of a financial report should make logical sense. The financial report rendering should make logical sense without regard to the format of the financial report.
• Clear business meaning: A financial report should be unambiguous.  The business meaning of a financial report should be clear to the creator of the financial report and likewise clear to the users of that financial report.  Both the creator and users should walk away with the same message or story. A financial report should be usable by regulators, financial institutions, analysts, investors, economists, researchers, and others to desire to make use of the information the report contains.

As such, I venture to summarize all these pieces into a set of risks, assertions to overcome that risk, whether the verification can be automated or must be manually performed, and the required skill level necessary to perform such step:

• Risk - Full inclusion: All relevant facts, characteristics which describe facts, and parenthetical explanations are not included in the financial report. Assertion - Completeness: All relevant business facts, characteristics of those business facts, and parenthetical explanations of those facts have been included. Manual by person with accounting skills.
• Risk - False inclusion: No facts, characteristics which describe facts, or parenthetical explanations which should not be included have been included. Assertion - Existence: No facts characteristics which describe facts, or parenthetical explanations of those facts are included within financial report which should not be included. Manual by person with accounting skills.
• Risk -Inaccuracy: Property of a fact, characteristic, component, or relation is inaccurate. Assertion - Accuracy: The properties of all facts, characteristics, components, relations are accurate, correct, and complete. Some automated, some manual by person with accounting skills.
• Risk -Infidelity: All facts, characteristics, and relations considered as a whole do not provide the necessary fidelity. Assertion - Fidelity:  Considered as a whole, the facts, characteristics, and relations properly reproduces the financial and nonfinancial facts, characteristics, and relations of the reporting entity. Some automated, some manual by person with accounting skills.
• Risk -Integrity not intact: Integrity between facts and characteristics is inappropriate. Assertion - Integrity: Considered as a whole, the facts and characteristics of those facts reflect the true and proper relations between facts and characteristics. Some automated, some manual; to the extent that a relation is expressed testing of relations can (and should) be automated rather than manual, accounting skills.
• Risk -Inconsistency: The facts, characteristics, their relations and their properties expressed are inconsistent with prior reporting periods or with peers of the reporting entity. Assertion - Consistency: The facts, characteristics, relations, and their properties are consistent between financial report periods and with peers, as is deemed appropriate. Some automated, some manual by person with accounting skills.
• Risk -Not presented fairly: The financial report is not presented fairly, in all material respects, and are not a true and fair representation in accordance with the financial reporting framework applied. Assertion - Presented fairly in all material respects: The financial report is presented fairly, in all material respects, and provide a true and fair representation in accordance with the financial reporting framework applied (US GAAP, IFRS, etc). Some automated, some manual by person with accounting skills.

So now I need to come up with the precise detailed steps for all of this and then cycle those through all this information to be sure the big picture and the details fit together.  Give that I have already been through all these detailed steps with my model/reference implementation for an SEC XBRL financial filing I do understand most of the steps (here are the steps which I have thus far, they are also detailed and explained in this document which explains the working prototype verification application which I created).  Basically, what I really need to do is organize those detailed steps within this framework.

Aberdeen Group published a study, Taking XBRL and Financial Disclosure Management to the Cloud, in which it states (emphasis is mine):

While external drivers such as the compliance mandate drove much of XBRL adoption in the early part of 2011(as cited by 55% of the respondents in the Enabling Compliance and Business Improvements through XBRL, report in April 2011), internal drivers such as executive orders to improve data quality (42%) and demand to improve staff productivity (30%) guided adoption of XBRL and other financial disclosure management tools in the latter part (Q3 and beyond) of 2011 (as per the August study, entitled Effective Disclosure Management: Ensuring Compliance and Improving Organizational Communication). XBRL adoption in 2012 continues to move along this trajectory with one key difference - companies are now looking beyond basic capabilities of financial reporting and towards expedited information delivery, leveraging fewer resources, and reducing operational costs.

Ask yourself the following question.  How are you going to verify that your disclosures are complete, correct, consistent, accurate, have fidelity, and have integrity? Is following the Edgar Filer Manual (EFM) sufficient? While there is some guidance in this area, that guidance leaves a lot to be desired.  Further, software is no where close to where it needs to be to help accountants who create this information, management who have to sign off on this information, and third party accountants who might need to verify this information.

You may be able to get away with submitting less than stellar information to the SEC, but do you really want that same quality standard used internally?

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.