Digital Financial Reporting

There is increasing talk about the need for quality SEC XBRL filings but there is less information on exactly how to create a quality SEC XBRL filing. Some pushing validation services say that their validation is key to achieving quality. Some feel that quality is not even important because the SEC does not require anything beyond the validation you must pass to submit your XBRL filing to the SEC. Others say quality is not important because few investors use the SEC XBRL information.

What constitutes quality?

The ultimate test of quality is whether the SEC XBRL information is usable in an automated manner.  After all, what is the point of spending millions of dollars articulating all this financial information in XBRL if it is useless? Using one report, leveraging the interactive characteristics of XBRL, comparing a company over time, comparing companies. XBRL's utility is the ultimate testament of the quality of SEC XBRL filings.

I have been pushing for quality for quite some time, well before it was even in fashion. I have also spent a significant amount of time trying to figure out exactly what "quality" means when it comes to an SEC XBRL filing. This is what I have learned about quality.

To start, this information is based on empirical evidence. I do eat my own dog food.  This is the latest iteration of what I think quality XBRL looks like, I call it a reference implementation of an SEC XBRL filings. Now BE CAREFUL HERE!!! This is both a work in progress and I consider this an ideal XBRL filing and not necessarily what you would want to file with the SEC.  There are a few things I am trying to determine beyond SEC XBRL. This prototype filing is close to what I would file with the SEC and it can help you figure out how to get where you want to be, but like I said, this is still a work in progress and I am working toward an even higher goal.  That said, the example can be quite useful in seeing what a quality SEC XBRL filing might look like.

So, these are my thoughts on quality which I will try and reference to my reference implementation to endeavor to explain each piece of the quality puzzle.

Defining quality

This is my definition of quality SEC XBRL filing: A business user of the paper or HTML version of the financial information and the XBRL version of the financial information will reach the same conclusions.

Paper, HTML, Word, Excel, PDF and XBRL are all mediums. Different mediums have different characteristics, paper has different characteristics than XBRL. If you are working with a medium, you need to understand the characteristics of that medium.  Most accountants understand how to create a financial statement using the paper, HTML, or Word mediums. They are less skilled at using the XBRL medium. So, quality of an SEC XBRL financial statement involves the proper use of the XBRL medium to articulate the financial information you are communicating. The message should be the same as the message one might glean from reading a paper-based financial report, at a minimum.

Unique characteristic of XBRL: computers can read it

The unique aspect of XBRL is that a computer can read the information. Whereas a human is required to make sure that 100% of the information expressed using the medium of paper, HTML, Excel, Word, PDF or other medium that a computer cannot understand; XBRL is different in that a computer CAN understand the information expressed in the XBRL medium.

Can a computer understand 100% of that information? No way.  That will never happen. But there are many things that a computer can understand.  As such, automated validation of information expressed within XBRL is possible.  That (a) reduces the cost of verifying the information and (b) frees humans to focus on things that a computer cannot handle.

What is even more interesting is that because XBRL is a global standard, your report can be read by someone elses software application.  For example, XBRL Cloud validates every SEC XBRL filing and reports the results. So does XBRL US with their consistency suite. The Firefox XBRL viewer add on can be used to read your report. Other software will likely appear. So, SEC XBRL filings can be consumed by any application which supports the standard, particularly since the SEC XBRL filings are all public information.

Automated verification a computer can perform

The following are the automated verification or validation which XBRL can perform. Humans still play a role in some of these. I will cross reference the type of validation to a set of four categories which I have heard automated validation placed into: correctness, completeness, consistency, and accuracy. I will also provide examples of this validation where I can.

• Edgar filer manual (EFM) validation. This is the only validation required to pass a filing into the SEC. But this is far from what is necessary to tell whether your financial information is correct. There are different interpretations in SEC EFM validation. That is why XBRL Cloud validation is different than SEC XBRL validation required for submission.  Here is the validation results for the reference implementation for the XBRL Cloud EFM validation, provided complements of XBRL Cloud. This covers XBRL syntax validation, SEC specific validation requirements which includes meta data related, some light semantics. (Relates to: correctness, consistency, completeness)
• Information model validation. Tests to be sure you are creating things such as your [Table]s, [Roll Forward]s, roll ups, and hierarchies consistent with the US GAAP Taxonomy. Doing so is specified in the US GAAP Taxonomy Architecture. This helps make sure your extension taxonomies are consistent with the US GAAP Taxonomy and with other SEC XBRL filers. For example, section 4.5 covers how [Table]s are to be created. I don't have a validation report for this, but this shows what the reference implementation taxonomy looks like which follows the US GAAP Taxonomy information model. (Relates to: consistency)
• Extension points and extensibility rules validation. Tests to see if where you are extending the US GAAP Taxonomy is appropriate and if you are creating logical extensions. For example, putting an income statement line item on the balance sheet is illogical. Or, adding a concept at the same level as "Assets" and "Liabilities and Equity" on the balance sheet might not make much sense. (Relates to: consistency)
• Financial integrity validation within a [Table]. Tests to be sure that each [Table], be that [Table] explicitly defined or implied, is "internally consistent and correct". Financial integrity is discussed here.   For example, does your balance sheet have "Assets", "Liabilities and Equity", does your balance sheet balance, and do all the line items add up correctly? That is financial integrity, just like a paper based financial statement. (Relates to: correctness, consistency, completeness, accuracy)
• Financial integrity validation between [Table]s. Tests to be sure that explicit/implicit [Table]s are properly related to one another. For example, the balance sheet ties to the statement of changes in equity.  The cash flow statement cash account needs to tie to the balance sheet.  Disclosure details need to tie the financial statement line items. (Relates to: correctness, consistency, accuracy)
• Internal consistency. When I originally created my reference implementation I did not have access to the XBRL US consistency suite.  I asked that model be run through that suite of tests and the consistency suite pointed out that the reported issued shares was less than the reported authorized shares, which is impossible.  Internal consistency relates to the consistency between reported facts within an XBRL report.
• Computations validation. A type of consistency is whether all the numbers foot, cross cast or otherwise tick and tie.  XBRL calculations offers some help here, for example here is the validation report for the reference implementation which shows that things add up.  But there are things that XBRL calculations cannot test, something else must be used.  For example, [Roll Forwards], dimensional aggregations, and other more complex computations. Need to be verified whether the SEC tests these or not.  This XBRL Formula linkbase is used to test the reference implementation, here are the passing results. (Relates to: accuracy)
• Consistency with prior period filings. The ending balances in your period 1 filing will become the beginning balances in your period 2 filing. Automated validationests to see if the current period filing beginning balances tie to the prior period filing ending balances are possible. (Relates to: correctness, consistency, completeness, accuracy)
• Disclosure checklist validation. Also sometimes referred to as reportability rules, these tests help to make sure your disclosures are complete.  For example, if PPE is reported, you have to include your PPE policies and PPE disclosures. This has less value for a financial which is already complete, when making modifications for new disclosures this can add value. (Relates to: completeness)
• Industry standards validation. Are industry practices being followed if the applicable industry is different than US GAAP for commercial and industrial companies. (Relates to: correctness, consistency, completeness)
• Rendering validation. Does your SEC filing render correctly, using the SEC previewer for SEC filings. Test to see how the XBRL instance renders within the SEC previewer. (Relates to: consistency)
• Comparability validation. Tests to see how well an XBRL filing can be compared to a similar XBRL filing. (Relates to: consistency)
• Key performance indicators validation. Tests for wild fluctuations against internal benchmarks and industry averages.  Much like an auditor's variance analysis. (Relates to: correctness, consistency, accuracy)
• Best practices validation. Other common practices. (Relates to: correctness, consistency, completeness, accuracy)

Should accountants REALLY have to do all this?

Should accountants have to deal with things like XBRL syntax validation and making sure your HTML ampersands are double escaped in your SEC XBRL filings? No.  Computers should do all this behind the scenes and these sorts of things should just happen. But software is not mature enough yet to hide these technical things from accountants.

The marginal value of some of these validations is higher than others currently. That will change as software improves and the marginal effort to employ these validations decreases.

Should you care about all these things?

Do you care if your financial reports tick, tie, cross cast, foot, etc?  Sure you do.  Should you care about your XBRL? Why wouldn't you care?  You are responsible for it.  Besides, look at it this way.  XBRL will eventually be the only thing you will be filings with the SEC at some point and you will be legally liable for your SEC XBRL filing. Do you think you should care about it?

Eventually you will care.  You may as well get the quality where you want it while the SEC limits your legal liability. Why wait until you are liable to figure out how to master the medium you will likely be using in the future.

Longer term view

The longer term view you take, the more it makes sense to deal with the quality of your XBRL based financial report sooner rather than later.  We are paving the last mile of finance, after all.

Did I miss any opportunities to automate validation of a financial report? If so, please let me know.