Digital Financial Reporting

Verification that a financial report is "valid" is not a mystery.  Accountants have been doing this for years.  However something very significant has changed.  In the past, this verification process was a 100% manual process.  Green eye shades, 10 key calculators, and deep accounting knowledge required by all who undertook this process.  And because the process was so manual and because humans make mistakes, no matter how hard one tried things always slip through the cracks.

But now because financial reports can be read by a computer software application because of the structured nature of the financial report, such as a digital financial report expressed using XBRL, many things change. Many parts of the verification process can be automated such as checking mathematical computations and "if...then" type checks, "IF you have this financial statement line item, THEN you must provide this policy and this disclosure."

Another thing has changed.  All those financial reports which were here-to-for verified using only human processes can now have automated processes applied to them very effeciently and effectively.  All sorts of automated processes such as what is being called the SEC "RoboCop" or accounting quality model. Likely many interesting things will be discovered which have been missed before by humans.

While there are many interesting and sophisticated processes which will likely be thrown against financial reports in the coming years because they have become digital, below are the basics of creating a quality digital financial report such as an SEC XBRL financial filing.

Thinking through the process of verification

Let us start with fundamentals. Verification is the process of research, examination, and other tasks and steps required to prove or establish validity; evidence that establishes or confirms the accuracy or truth of something. Verification is a formal assertion of validity.

Validity can be defined as being well grounded; producing the desired result; free from logical flaw; based on sound reasoning; cogent; faithful.

Validity when it comes to a financial report is, arguably, that such a financial report is a true and fair or a faithful representation of a reporting entities financial and nonfinancial information articulated by such a financial report. Looking at this backwards - an untrue or an unfair report - is certainly not desirable. (Don't confuse true and fair as used here with the term "presented fairly" as used by auditors, we are discussing something different here.)

A financial report can be said to be valid if it possesses certain traits which can be defined in general terms and for clarity are listed below to bring them into the reader's mind. (These terms are highlighted in the AICPA Statement of Position 09-1 Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data, http://bit.ly/XIoqxv ):

• 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.

Assurance on XBRL instance document: A conceptual framework of assertions (see http://bit.ly/VjHwdG) points out the need for a framework for verifying the appropriateness of a digital financial report.
While these four notions which relate to the "trueness" and "fairness" must exist for every fact reported by a financial report, they also need to exist when considering the financial report in its entirety and the relations between reported facts. Further, it would seem to be appropriate to add the term "sensible" and perhaps even "logical" to this list. Clearly digital financial reports should be both sensible and logical.

Two other notions help bring the notion of trueness and fairness of information at the fact and at the report level into focus, looking at the financial report holistically:

• Fidelity: Fidelity relates to the loyal adherence to fact or detail; exactness, faithfulness. The representation of the facts, events, transactions, and other circumstances represented within a financial report properly reflect, without distortion, reality. High fidelity is when the reproduction (the financial report) with little distortion, provides a result very similar to the original (the reality of the reporting entity and environment in which the reporting entity operates).
• Integrity: Integrity is holistic fidelity. Integrity relates to the fidelity of the report in its entirety, of all parts of a financial report, from all points of view. Integrity is holistic accuracy, accurate as a whole. Integrity is the quality or condition of being whole or undivided; completeness, entireness, unbroken state, uncorrupt. Integrity means that not only is each component of a financial report correct but all the pieces of the financial report fit together correctly, all things considered. The reported facts are logical and sensible as well as the relations between reported facts are logical and sensible.

To an accountant the notions of verification and validity and that a financial report must be complete, correct, consistent, and accurate as defined above are a statement of the obvious. Perhaps accountants have never really thought about the verification process in these terms, but accountants get this.  Accountants have performed these tasks for hundreds of years. This is not new to accountants. Further, these traits which a financial report must possess are the obligations of those creating these reports; they are not options. Accountants don't pick and choose whether a financial report is to be true and fair; those traits must be true by definition.

What is new is that now accountants must rely on software to help them fulfill this obligation.

True and fair representation in more specific terms

Looking at the verification process in more specific terms, arguably the following would hold to be true of a financial report which represents the financial information of a reporting entity:

• Comply with financial reporting standards: Clearly a financial report must comply with the rules (i.e., IFRS, US GAAP including applicable SEC rules, industry/activity practices, other common practices), and reporting entity choices where they have options.
• Full inclusion/false inclusion: Everything which should be disclosed has been disclosed as deemed appropriate by such rules and the reporting entity choices.
• Foots, cross casts, ticks and ties: A financial report foots, cross casts, and otherwise "ticks and ties". All mathematical relations must be intact. All nonnumeric relations must be sensible and logical.
• All financial report formats convey the same message: A financial report can be articulated using paper and pencil, PDF, HTML, XBRL, or some other computer readable formats. While the format may change, the message communicated, the story told, should not change. Each format should communicate the same message, regardless of the medium used to convey that message.
• Justifiable/defensible report characteristics: Facts reported and the characteristics which describe those reported facts should be both justifiable and defensible by the reporting entity.
• Consistency between periods: Financial information expressed within one reporting period should be consistent with the financial information expressed within subsequent reporting periods, where appropriate. Changes between report elements which existed in both periods should be justifiable and defensible as opposed to arbitrary and random.
• Consistency with peer group: If a reporting entity chooses one approach/report element and a peer chooses a different approach/report element; clearly some good, explainable reason should exist for such difference.
• Useful, sensible, logical renderings: Renderings of facts, characteristics which describe the facts, parenthetical explanations which further describe such facts, and other representations should make sense, be logical, and ultimately be useful in understanding the information. While there may be differences of opinion as to how to format or present such information; there is significantly less or no dispute about the logic. Disclosures are informational, they relate to information without regard to formatting or other presentational artifacts. The term "notes" or "disclosure notes" or "footnotes" relate to organizing disclosures and are presentational in nature. Someone creating a financial report has far more latitude and discretion as to how to organize disclosures into disclosure notes than they do as to what must be disclosed.
• Unambiguous business meaning: A financial report should be unambiguous to an informed reader. The business meaning of a financial report should be clear/unambiguous to the creator of the financial report and likewise clear/unambiguous to the users of that financial report. Both the creator and users should walk away with the same message or story, an identical understanding of the reported facts. Users may interpret the facts in different ways, but the facts should be the same for all parties.

Verification will always include both automated and manual processes.  Automating processes can improve quality and reduce costs.  But, not all processes can be automated.  The judgement of an accountant cannot be automated.

What are your ideas about what a quality financial report looks like?  If you have improvements to these ideas or of you have better ideas I would like to understand those ideas and why you believe they are better.

In an interview with Craig M. Lewis, SEC Division of Risk, Strategy, and Financial Innovation, the following statement was made:

The SEC was really just allowing firms to have a window to figure out how to tag data. Now that the window has shut, we are just going to start to use the data.

This is a fairly good clue that the SEC is going to clamp down on quality.

There are many other clues.  The interview with Craig Lewis is enlightening in many ways.  I feel this is the most practical look into how the SEC views the evolution toward digital financial reporting. Both software vendors creating software and filers don't want to miss reading the answer to this interview question:

How can companies be sure their XBRL filings are not automatically flagged in the monitoring system you are developing?

I would say, check your work. If you make a mistake in how you record an element, that would affect the score you get from the model and might make you more likely to be pulled up for a review-I would argue, correctly so. The model will tell the reviewer which factor was contributing to the score, and if one factor comes out and has a large impact on the score and can be traced back to a recording error in the XBRL data, you will be flagged because you made a mistake in providing us your XBRL data. I do not view that as a problem.

Software vendors who can keep SEC filers off the "radar" will likely be preferred to those who put filers on that radar.

I would encourage everyone to read the entire article, it is packed with information.  But I will point out one additional important statement.  Note the following comment relating to "two separate documents" (i.e. the desire for one document): 

My view is that the real solution to this is inline XBRL: creating a document where the tags are embedded directly into your filing so that you do not have to have two separate documents. This seems to be where the industry is moving, and I fully support that.

While Mr. Lewis' statements may not be what the SEC is thinking, it does offer clues into where SEC filings are headed.

Most of the prior analysis which I have done related to the ability to discover the identity of a reported fact from the perspective of the concept characteristic of that reported fact.  For example, this web page summarizes information I was able to extract from the 30 companies which make up the DOW, the Fortune 100, and the S&P 500. If you look for "cells" which are orange, I could not find that piece of information.

So for example, if you look on the DOW list, you see that I cannot find only one value: Net cash flow for General Electric.  This is because GE created an extension concept for that commonly reported fact.  If you look on the Fortune 100 list you see 3 information points which I could not find. If you look on the S&P 500 list you see two things. First you see about 35 missing information points, that is about 1.4% as compared to .6% of the total number of information points for the DOW and Fortune 100.

But if you look at row 232 which is Host Hotels you see numerous missing information points. Row 270 which is Legg Mason has a similar issue.  What is going on here which is different?

So, here is the deal.  Of 7,160 reporting entities which I analyzed (I trimmed my set of 7,199 down slightly due to duplicate CIK number issues and multiple CIK issues which don't relate to XBRL); I could not idenfity ANY INFORMATION for 54 reporting entities. It also means that I could effectively discover information for 7,106 of the SEC XBRL financial filings, or 99.2% of all filings.

Why? Well, the graphic below summarizes the reasons and this PDF provides all the details.

Results of root reporting entity analysis

Basically, 99.2% of SEC filers model their information and you can discover the "root" reporting entity or what is called the "economic entity" or "accounting entity".  That accounting entity might be broken out in the report as different legal entities.

And so the vast majority of SEC filers allow for the discovery of the root accounting entity and may provide additional details for different legal entities, variable interest entities, or other reporting entity or accounting entity breakdowns.

There are some very specific things that these reporting entities do which make it challenging to identify the root of the reporting entity/accounting entity.  Generally, these are inconsistencies with the ways other filers report information (the remaining 7,106 where you CAN discover the information).  Here are a few examples (go through the entire PDF above if you are interested in the details and want to become a digital financial reporting master craftsman):

• Extension for consolidated entity: Legg Mason does something different than most filers. Click on the link to go to their balance sheet and look at the value of the Legal Entity [Axis]. Rather than using the Entity [Domain] to represent the consolidated entity, they created an extension concept, lm:ConsolidatedLeggMasonGroupMember.  But that WOULD have worked, however they also made another mistake, they provided the Entity [Domain] report element which would have represented the consolidated group in their modeling, but they did not USE that report element.  The dynamics of both these things make the root reporting entity unidentifiable explicitly like most other filers.
• Successor/predecessor: There are two ways SEC reporting entities articulate successor/predecessor related information: using the Scenario [Axis] (18 filers use this approach, here is one) and using the Legal Entity [Axis] (4 filers use that approach, here is one).  There could be others, I did not check this.  Having two approaches is unnecessarily inconsistent.  These 22 filers stood out because again, each of them also modeled some sort of root entity but reported no facts for that entity which they modeled.  This is similar to Legg Mason above, leading to not being able to detect the root entity using automated approaches.
• Equity component [Axis] used on balance sheet: I have no idea why but 11 SEC filers saw fit to model the balance sheet using the "Equity component [Axis] which is both rather strange and leads to not being able to discover the root accounting entity. Here is one example.

There are other funky things that SEC filers do, again look through the PDF. A great way to learn how to do things correctly is by learning from the mistakes of others.

One thing that I find particularly interesting is that if you consider the fundamental accounting relations which I had mentioned in a prior blog post and consider these reporting entity/accounting entity breakdown approaches; that frames the primary financial statements nicely into a neat little "package".  Of the 7,160 SEC filings in my set of 2012 10Ks, there are only about 210 which have specifically identifiable errors/issues which, if fixed, would provide a solid set of financial information.  The list of errors/issues is finite.  These are all very fixable.  In fact, I believe that all of these errors are detectable using automated verification processes. This set of reporting entity/accounting entity errors is likewise finite and fixable.

While it might be challenging to get the SEC to implement the inbound verification necessary to make these issues go away (and achieve a solid information set) at least for the primary financial statements; maybe the market would do it.  Maybe XBRL Cloud would.  It just builds on the framework which they already have in their EDGAR Dashboard.

When the FDIC implemented their XBRL-based system, on day one the FDIC said 18,000 mathematical errors simply disappeared from call reports. (Read page 26 in XBRL for Dummies) Granted, the SEC XBRL financial filings are more complex that FDIC call reports.  However, it seems like we could be getting close to a similar benchmark for these SEC filings.  Granted, it is only an incremental step but is seems both achievable and useful if achieved. I would go as far as predicting that primary financial statement information (balance sheet, income statement, cash flow statement) reuse could be very real within one to two years even if the SEC does nothing.