Digital Financial Reporting

Clearly software plays a role in the verification of an SEC XBRL financial filing.  In fact, the more computer software does for you, the less manual work you need to perform (which reduces cost) and the easier it is to achieve the quality level most accountants desire.

Continuing my assessment of how to verify an SEC XBRL financial filing; here is a preliminary list of the functionality verification software needs to provide accountants and others in support of the process of verifying an SEC XBRL financial filing:

• Quality XBRL validation (XBRL 2.1, XBRL Dimensions).  What you are creating, after all, eventually ends up as XBRL and you need to be sure your XBRL technical syntax is correct.
• Provides SEC Edgar Filer Manual (EFM) rules validation.  The SEC EFM places specific additional technical syntax restrictions on how you are allowed to use XBRL.  You will need to validate your filing against these rules.  Other semantic rules are imposed by the EFM.  Many of those can be automatically verified. (Keep in mind that other rules cannot be automatically verified and must be manually verified.)
• Logical structure verification (such as US GAAP Taxonomy Architecture rules).  The US GAAP Taxonomy specifies how to construct your model. It uses [Table]s, [Axis], [Member]s, [Line Items], networks, concepts, and abstract concepts in specific and logical ways.  Creating illogical structures is, well...not logical.  Software can easily verify that you are creating logical, and not illogical, models.
• Semantics engine for processing business rules (preferably but not necessarily XBRL Formula). US GAAP has specific semantics.  Assets = Liabilities + Equity is one example.  The SEC Regulation S-X imposes semantics.  Industry financial reporting practices have specific semantics. And finally, each reporting entity has its semantics.  How are you going to verify that all these semantics are correct if your verification software does not have a semantics engine?
• Core US GAAP financial integrity rules validation. The proof section of the Financial Report Semantics and Dynamics Theory shows that there is a core set of US GAAP financial report semantics which every SEC filer's filing has.  These 8 core rules are specified in XBRL Formula, so if you have a semantics engine which supports XBRL Formula, your software can provide this verification.
• Ability for business users to create business rules.  Clearly reporting entities have their own unique semantics and therefore will need to be able to create business rules.  Even very basic SEC XBRL financial filings have roll forwards and member aggregation rules which XBRL calculations simply cannot be used to verify.  As such, business users will need to create these rules.  Emphasis here on business user.  Creating these rules does not have to be complicated.
• Views of semantic objects, relations, properties understandable by business users. Many verification steps are manual, things humans will need to do.  To do this, they need to see the SEC XBRL financial report in ways which are understandable and helpful to them.
• Appropriate navigation between semantic objects, relevant properties, and relevant relations. These objects are both related to one another and have detailed properties which business users need to have a look at to be sure they are set appropriately. To do that, users need to be able to navigate from say facts to the characteristics of those facts and then to the properties of those characteristics in rational, helpful ways.
• Leverage information models to create proper semantic renderings.  For renderings of the information to be understandable, they must be shown correctly in the rendering.  There are exactly two reasons for bad renderings: (1) bad models, (2) bad rendering engines.  One thing most rendering engines do not do well at this time is leverage the information models of the information which was, well, modeled. Roll ups, roll fowards, adjustments, variances, hierarchies, and other information models have characteristics which software vendors could leverage in their rendering software to improve what business users see and have to therefore work with. If you know your model is good (see bullet point three above), question the capabilities of the rendering engine of the software application you are using.
• 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; users still want to understand how their filing will look on the SEC web site.
• Support for tracking of manual validation tasks and steps. Not all tasks or steps can be automated.  So, verification of an SEC XBRL financial filing will always be a combination of automated and manual tasks/steps.  Software needs to help you manage these manual verification tasks/steps.
• Comprehensive and useful set of verification reports and appropriate verification evidence package. There are many different reports which can be provided which can make you both more efficient and more effective in your verification tasks/steps.  Software should support this. Further, particularly CPAs providing agreed upon procedures, work where an internal auditor or your process requires quality documentation (i.e. think SOX); you will need an evidence package.
• Collaborative, multi-user.  Although not required, creation of an SEC XBRL financial filing tends to be collaboration and thus software which offers this feature can be helpful.
• Transparency into what the software is automatically verifying so manual verification work can be properly planned.  Verification of an SEC XBRL financial report should not be a "black box". At the very least, you need to understand exactly what verification steps software performs so that you can properly plan your the manual tasks/steps required to supplement your automated verification. As such, you need to be able to see the specific automated rules software is performing.  Today this is particularly important as software may perform different sets of validation rules.
• Comparison between multiple versions of a report in order to understand differences, for example to manage last minute changes. A very helpful feature is the ability to compare different versions of an SEC XBRL financial filing to understand changes between the two versions.  If you did extensive work in verifying your SEC XBRL financial filing 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?  Software which compares multiple versions can help you maintain control of your filing.

Finding verification software with all these features can be challenging today.  But, if you start asking for these features because you believe you need them; it helps motivate software vendors to provide these features.  What I personally do is use multiple software applications to achieve my verification needs.  This may not always be possible or practical; but it is better than trying to "roll your own" in Excel.