Digital Financial Reporting

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.