Digital Financial Reporting

Many people tend to offer up the explanation "there are too many extensions" as the reason why SEC XBRL financial filing information provided by public companies is not usable as envisioned.

The true reason the information is not as usable as it could be is more nuanced than that simplistic and unsubstantiated statement. When it comes to extensions, when extensions are done correctly those extension are generally a very good thing.

Did you know that per the XBRL Cloud EDGAR Dashboard that 99.9% of all SEC XBRL financial filings had the proper XBRL technical syntax? Do you realize that the XBRL US Consistency Suite found a total of 140 XBRL technical syntax errors in the approximately 100,000 XBRL financial filings submitted to the SEC? That is .14%.

Do you know that testing of a set of 7160 SEC XBRL financial filings showed that 98% of such filings pass a set of tests for 50 fundamental accounting concepts which one would expect to find and 21 relations between those fundamental concepts?

Why is it that 99.9% of all SEC XBRL financial filings have such a high rate of compliance to the XBRL technical syntax?  There is a very, very simple and straight forward answer to that question: the XBRL conformance suite.  Tests!

Back in 2001, XBRL 2.0 had a serious software interoperability problem.  Business users could create XBRL in one software application, send it to someone else using a different application, and the receiving application many times could not load the XBRL.  Clearly this was not a good situation.

The current version of XBRL, XBRL 2.1, does not suffer from that interoperability problem.  Why?  XBRL technical syntax issues were solved back in 2005 when XBRL created and started using a conformance suite to test software interoperability.  Every version of every XBRL technical specification has had a conformance suite since that time.  You can find those conformance suites along with the technical specifications.  Here is where you find the XBRL 2.1 conformance suite.

A conformance suite is simply a set of tests where the results are known and software applications are expected to act in certain specific ways when they encounter situations found in the tests.

So a good question to ask yourself is this: Why are there 140 XBRL technical syntax errors found in submitted SEC XBRL financial filings if there is an XBRL technical syntax conformance suite???  Why wouldn't XBRL Cloud and the XBRL US Consistency Checks and the SEC inbound validation get exactly the same results?  Why shouldn't the number of errors in SEC XBRL financial filings be zero?

The answer to that question is that while the XBRL conformance suite helps interoperability, it is not perfect.  The conformance suite is only as good as the tests it contains and the compliance to software vendors to those tests.  The software which the SEC uses for the inbound validation of SEC XBRL financial filings seems to give different results than XBRL Cloud's Edgar Dashboard and the XBRL US Consistency Suite.  Humans make mistakes.  Conformance suites or consistency suites and other such tests help humans make less mistakes.

It works like this as shown in the diagram:

(Click for a larger image)

The only way a meaningful exchange of information can occur is the prior existence of agreed upon syntax, semantics, and workflow/process rules.  To the extent that these rules exist, information exchanged will have the "quality" of meaning for the information to be reusable by automated analysis processes.  By automated analysis processes I mean something as simple as comparing the basic financial information of reporting entities.

So now back to the 98% of fundamental accounting concepts being in the filings and the relations between those concepts being correct.  US GAAP has agreed upon rules.  For example, "assets = liabilities and equity".  Every accountant knows that rule and other such rules.  Well, actually, seems that a handful don't know that.  Or, somehow they created a balance sheet that did not balance.  About 15 SEC filers, of a total 7160 which were tested, had a balance sheet which did not balance.

What would happen if the SEC put a rule in its inbound validation which tested to see if the balance sheet balanced for every period provided within the financial report?  Well, then those 15 reporting entities would need to correct their financial reports in order to submit them and have the SEC accept them. And, then that quality issue would not exist.

How hard is that?  Well, not hard at all.  In fact, here is that exact test along with a handful of other test in this XBRL Formuila file. You many not understand that file, but an XBRL processor which supports XBRL Formula would.  You can see those rules being enforced by the XBRL Cloud EDGAR Dashboard, see the "US GAAP Domain Level Rules" column:

Here are tests to be sure the structure of the representation is correct, I don't have a rate for that but based on looking at the XBRL Cloud EDGAR Dashboard, it looks pretty good:

So why does XBRL Cloud or XBRL US get to determine what constitutes a good or bad SEC XBRL financial filing? Why wouldn't the SEC do that?  Well, good question.  But the SEC does not.  You really cannot argue with XBRL Cloud or XBRL US or my tests of fundamental accounting concepts other than to point out where those tests are wrong.

Tests are how you articulate to computers what "good" and "bad" look like. Test are how you agree on right and wrong.  Tests is what helps a filer, the SEC, the FASB, software vendors, and those using the information understand that they are all on the same page. Tests is what enables a meaningful exchange of information.

The 99.9% interoperability at the XBRL technical syntax level and the 98% interoperability of 50 fundamental accounting concepts and 21 relations is not to say the quality of SEC XBRL financial filings is where it needs to be.  It is more a statement to show that there are some very high quality areas but that this is only the tip of the iceberg.  It also shows a path to quality: more tests.

What about those extensions? How about tests which explain where extensions are allowed and where they are not allowed?  That would provide clarity to filers.

While automated tests cannot be created to detect every quality issue, more tests will certainly help improve SEC XBRL financial filing quality.

A comprehensive analysis of 7,160 SEC XBRL financial filings has resulted in a set of common sense insights, or Digital Financial Reporting Principles, which are helpful to creators and consumers of such digital financial reports.

Looking at details across the 7,160 public company 10-K filings helps one see and understand the combined digital financial reporting "forest" which is comprised of individual digital financial report "trees". This perspective helps one understand the utility of something like the Financial Report Semantics and Dynamics Theory for relating to digital financial reports.

Although still a work in progress, this draft helps both accountants and software companies who build software for accountants get their heads around digital financial reporting, including SEC XBRL financial filings.

Here is a summary of the common sense principles:

• Recognize that the goal is the meaningful exchange of information.
• Meaningful exchange requires prior existence of agreed upon syntax, semantics, and workflow/process rules.
• Recognize that even if SEC filing rules and the US GAAP XBRL Taxonomy may allow for ambiguity; approaches do exist where SEC filings rules can be followed and information is unambiguous.
• Recognize that being explicit contributes to the unambiguous interpretation of reported information.
• Recognize the difference between presentation and representation.
• Recognize that a financial report should be a true and fair representation.
• Recognize that financial reports contain a discrete set of report elements which have specific properties and relations.
• Recognize that report elements can be categorized into common groups which have common relevant properties.
• Recognize that financial reports contain a discrete set of financial report component which can be categorized.
• Recognize the existence of and properly represent intersections between report components.
• Always strive for consistency
• Recognize and respect fundamental accounting concepts and unchangeable relations between those accounting concepts
• Recognize and respect common report component arrangement patterns.
• Recognize and respect common concept (or [Line Items]) arrangement patterns.
• Recognize and respect common member arrangement patterns.
• Avoid mixing or run-together concept arrangement patterns.
• Avoid mixing distinct characteristics and concepts.
• Recognize need for both automated and manual verification processes.
• Recognize that concepts cannot be moved between fundamental accounting concept categories.
• Avoid unknowingly changing information representation approach midstream.
• Avoid inconsistencies in network identification.
• Recognize that characteristics apply to all reported facts within a report component.
• Recognize that rendering engines render presentation differently but the meaning is the same across all rendering engines.
• Number of members reported does not change the characteristics of a reported fact.
• Label networks with meaningful information.

The Edgar Filer Manual (EFM) is a great first step, but it is not adequate to create rational, sensible, and logical SEC XBRL financial filings.

This Analysis of Document and Entity Information across 12 SEC XBRL Financial filers points out very common types of rather clear inconsistencies and contradictions found in not only the document and entity information section; but these same sorts of issues exist in virtually ever report component of SEC XBRL financial filings.

Here is one example.  If you look at the SEC Document and Entity Information (DEI) Taxonomy you will see that the SEC provides three specific [Table]s for representing this information:

• Document Information [Table],
• Entities [Table], 
• Entity Listings [Table].

Yet, not one of the 12 SEC filers analyzed breaks the information out in this manner.  They simply pack all the information into one explicitly defined [Table] or implied table.  What that causes is facts such as "Entity Registrant Name" and "Document Type" having characteristics such as "Class of Stock [Axis]" which makes no sense at all.

The crack down is coming.  Don't let SEC XBRL financial filings which you are involved with stand out in a bad day. If you find this analysis helpful, you may also want to check out the following additional information which will help you become an XBRL master craftsman:

• Summary of Analysis of SEC XBRL Financial Filings
• Understanding Characteristics
• Understanding Model Structure and why EFM Rules are Not Sufficient

In this video, Craig Lewis, Chief Economist and Director of the Division of Risk, Strategy, and Financial Innovation (RiskFin) at the SEC, describes the accounting quality model and Robocop.

One thing Craig Lewis mentions is his desire to use Inline XBRL.

Don't understand accounting enough? This video explains the accounting equation: debits on the left, credits on the right...

In a prior blog post I summarized what I see that accountants need in order to review an SEC XBRL financial report.  I also provided more details on this topic in Chapter 10: Verification of Digital Financial Reports of Digital Financial Reporting.

This bog post assumes that you actually care to do a good job in the creation of your digital financial report, such as an SEC XBRL financial filing, rather then simply comply with the SEC mandate.  An XBRL-master craftsman understands that eventually "comply" will evolve to mean more that you can get away with today.  Buying inadequate software today can lead to problems down the road when the SEC tightens the screws when it comes to quality. You don't want to fall into this trap.

This blog post updates that information and tries to provide examples of software which performs these tasks.

Verification that a digital financial report such as an SEC XBRL financial filing is a true and fair representation of your financial information will always involve manual and automated processes.  It is not possible to automate 100% of this verification process.

Where the process can be automated by the creation of business rules which computer software can enforce depends on two things: (1) the probability that a computer can automate some process, (2) the existence of the rule so that aspect of the verification process can be automated.  Basically, no rule = no ability to automate.  Also, automation saves time and money plus increases quality. Full stop.

The best software will be both invisible to the user of the software but assist the user understand exactly what they are responsible for.  Creation of a digital financial report cannot be a "black box" or where a business user does his or her best and hopes the software will fulfill their obligation and meet their legal responsibility.  No paper-based financial report would ever have been released under those terms. Once accountants are held accountable, such as by the removal of the limited liability exemption by the SEC; they will care as much about their XBRL-based financial report as they do about their HTML or paper based report with which accountants are more comfortable.

The best digital financial report creation software will both assist the creator of the financial report to verify that all aspects of that financial report they are creating is, in fact, correct during the creation process within the creation software used to create the financial report.  The business user will have complete transparency into whatthe software is doing in the way of automated testing processes so that the manual processes can be established and integrated into one complete set of verification steps.

Other verification software will be stand-alone and be independent of the actual creation process. For example, it is likely that internal and external auditors will use software which is not integrated with the creation process.

In either case, all the automated and manual steps need to be organized and managed by one software interface rather than be a hodge-podge of different software and processes which causes an increased likelihood of things falling through the cracks.

I am not going to go into details about what needs to be verified.  You can get that information in this blog post, Understanding Quality of SEC XBRL Financial Filings. The XBRL Cloud Edgar Dashboardalso provides a fair amount of what is necessary, beyond what inboud SEC validation catches. But it still lets things fall through the cracks. Few commercial products today do things like verify the fundamental accounting concepts and the relations between those concepts. Eventually, meaningful reuse of all that public company information will drive verification requirements.

The following is a summary of functionality which is necessary within software designed to assist a business user in the process of verification of a digital financial report, such as an SEC XBRL-based financial filing, tells the story that the reporting entity truly wishes to tell:

• Technical syntax validation. Digital financial reports are ultimately expressed using some technical syntax.  For example, SEC XBRL-based financial reports are formatted in the XBRL technical syntax which uses XBRL 2.1 and XBRL Dimensions 1.0.  Filers might also choose to use XBRL Formula to express and test business rules.  As such, verification software clearly needs to be able to provide feedback to the user that XBRL which has been created complies with the XBRL technical specifications.  Such software should be shown to pass the XBRL 2.1, XBRL Dimensions 1.0, and the XBRL Formula conformance suite tests. As 100% of technical syntax verification can be automated, the business user really should never need to manually verify technical syntax.  Creation software should simply create nothing other than proper XBRL.
• Automated and manual SEC Edgar Filer Manual (EFM) rules validation. The SEC EFM places specific additional technical syntax restrictions on how you are allowed to use XBRL. The EFM also has a number of semantic rules and restrictions.  Business users will need to verify that their SEC XBRL-based financial report against these rules. Many EFM rules can be automatically verified but others need to be manually verified.
• Report logical structure verification. The US GAAP taxonomy specifies how to construct the model you use to represent your financial report. It uses report elements such as [Table]s, [Axis], [Member]s, [Line Items], networks, concepts, and abstracts in specific, logical and sensible ways. (See section 4.5 of the US GAAP Taxonomy Architecture for more information.)  Software must be able to help business user not create illogical, nonsensical, inconsistent, or ambiguous representations which can lead to misinterpretation of their digital financial report.  For example, inconsistencies between the XBRL definition relations, calculation relations, and presentation relations can cause illogical and misinterpret relations.  Software can easily verify that you are creating logical, sensible, consistent, and unambiguous information using automated testing.
• Business rules engine for processing business rules.  XBRL Formula is one type of global standard rules engine which can be used to express business rules which can be used to verify both mathematical type relations and other types of relations expressed in your digital financial reports. Using RDF and SPARQL is another approach. A business rules engine of some type is necessary because the relations expressed in digital financial reports go beyond the simplistic relations verified by XBRL calculations.  As such, digital financial report creation and verification software needs to provide this functionality.  Alternatively, creation software might take the approach of generating business rules from the actual representation which is created at the time of its creation, not allowing business users to make mathematical errors. CoreFilings Magnify and SpiderMonkeycan be used in combination to create busines rules using a proprietary syntax Sphinx. You can get additional information about business rules engines here.
• US GAAP domain level and industry/activity level rules validation. US GAAP had both domain level business rules, fundamental accounting relations which never change, which every digital financial report must follow, such as assets = liabilities and equity, and industry/activity level business rules, such as commercial and industrial companies must provide classified balance sheets which report current assets and current liabilities.  Verification software and creation software should support these sorts of business rule.
• Reporting entity specific business rules. Every digital financial report will have its own reporting entity specific business rules.  As such, creation software and/or verification software must enable the business users creating these digital financial reports to create and otherwise manage their unique business rules.  Alternatively, creation software could auto-generate these business rules.  Complex and difficult to use technical tools will not meet the needs of business users. Internal auditors and external auditors will also likely have additional business rules.
• Understandable and otherwise appropriate views of financial report semantic objects, relations, properties. Software needs to provide views of report element and their properties in ways that are understandable to business users.  XBRL technical syntax oriented views of report objects is not appropriate and unnecessary.  Business meaning is what is important to business users, not technical syntax which they will never understand, nor should they need to understand.  Business user oritented semantic views, are what is necessary.  The many views necessary must support both automated and manual verification of information within the SEC XBRL financial report.  The two best examples of understandable views is the XBRL Cloud Viewer and the XBRL Cloud Evidence Package. (You can see any SEC filing in the XBRL Cloud Viewer from the XBRL Cloud Edgar Dashboard.)
• Understandable and well organized navigation between financial report objects, relevant properties, and relevant relations. Financial report pieces are related to other pieces and have properties which business users need to examine.  As such, appropriate navigation between the sometimes thousands of report objects, their relations and their properties is necessary. Again, the report objects necessary are the ones which provide meaning to business users, not the technical syntax objects.  Mixing semantic type objects and syntax type objects is likewise inappropriate. A well-organized interface both exposes and leverages the intersections between the many financial report pieces.
• Understandable, sensible semantic renderings. For renderings of the information to be understandable, they must be shown correctly to the business user. There are exactly two reasons for bad renderings: (1) bad models, (2) bad rendering engines.  If the rendering engine is good, then the only reason for a bad rendering is a bad model which can be both identified and then fixed.  One thing most rendering engines do not do well at this time is leverage the well known, common accounting concept arrangement patterns being represented. Roll ups, roll forwards, adjustments, variances, hierarchies, and other accounting concept arrangement patterns have characteristics which software vendors could leverage in their rendering software to improve what business users see and have to therefore work with. Also, all information should be shown by software, not just some information.  Appropriate semantic renderings are a basis for appropriate views of information, appropriate navigation between components, and the ability to effectively verify a digital financial report. Again, the XBRL Cloud Viewer has a very good rendering engine; not perfect but better than anything else I have run across. (Try looking at the Apple balance sheet using the XBRL Cloud Viewer.)
• SEC interactive data rendering. While it is much more likely that an SEC XBRL financial filing will be viewed within software other than the SEC interactive data viewer; business users still want to understand how their filing will look on the SEC web site when rendered by the SEC interactive data viewer. As such, verification software should include an SEC interactive data rendering within the verification software.
• Support for tracking/managing both automated and manual validation tasks and steps. Not all verification tasks or steps can be automated.  As such, verification of a digital financial report, such as an SEC XBRL-based financial filing, will always be a combination of automated and manual tasks/steps.  As such, software supporting a business user in the verification process needs to help the business user manage both automated and manual verification tasks/steps.  Automated rules can be managed by just correcting mistakes which makes the automated test not result in an error.  Manual steps are similar to the "to dos" or open items which must be manually resolved and tracked to be sure any issues have been dealt with appropriately.
• Comprehensive and useful set of verification reports and appropriate verification evidence package. Business users need to be able to print many of the same views provided by software applications used to visualize a digital financial report.  Quantity of reports is not what is important, quality is what is important.  Well-thought-out and well organized reports which can be used both for verification of digital financial reports and for providing a historical archive, or evidence package, for a financial filing. Again, the XBRL Cloud Evidence Package provides a good example of useful reports. For example, take a look at this report which allows a business user to compare the labels within an SEC XBRL financial filing.
• Transparency into what the software is automatically verifying so manual verification work can be properly planned. Verification of a digital financial report such as an SEC XBRL-based financial report should not be a "black box". At the very least, business users need to understand exactly what automated verification steps software performs so that they can properly plan their manual tasks/steps required to supplement automated verification. As such, business users need to be able to see the specific automated verification rules software is performing. Today this is of particular importance as software may perform different sets of validation rules.
• Comparison between multiple versions of a report in order to understand differences. A necessary feature of a digital financial report creation or verification application is to manage last minute changes safely.  The ability to perform automated comparisons between different versions of an SEC XBRL financial report to understand changes between the two versions of the same report is crucial. For example, if you did extensive work in verifying your SEC XBRL financial report and then there are a few last minute changes which need to be made, how can you be sure some other change was not unintentionally or maliciously introduced? Here is information about a prototype comparison utility which I created. Take a look at this screen shotwhich compares the model structure of CostCo and Walmart. Imagine being able to compare the 10 AM version of a filing with the 11:30 AM version for ANY changes.  How useful would that be? Comparisons between versions of the same report and between a reporting entity and its peers are both very useful.
• Managing workflow.  Creation of a financial report is a set of tasks which could involve a specific workflow.  Managing the workflow of creating a financial report can be beneficial to users, but is not absolutely required from a software application. For enterprise users though, this is a must-have feature.
• Collaborative, multi-user. Creation of a financial report is a collaboration.  Verification is likewise a collaboration.  Although not required by everyone; the ability to effectively collaborate with others during the verification process can be a desirable feature to some, a required feature for others.

Regretfully, there is no software that I have seen which fits this bill.  As such, most digital financial report creation processes have holes in them which result in error found in SEC XBRL financial filings. But eventually, good software will appear which provides a formal framework which leads the user through defined processes with the rigor to help them prove to themselves that their financial report is a true and fair representation of their financial information and that the financial information tells the story that they are trying to tell.