Digital Financial Reporting

I have been looking at the problem I have been trying to solve exactly backwards.

Business rule driven XBRL-based financial report creation uses the same philosophy as what Agile programming calls test driven development for creating software.  Agile financial report creation yields XBRL-based financial reports which are free from XBRL technical syntax defects, model structure defects, mathematical relations defects, logical defects, and mechanical defects.

This simple example explains the difference between the current approach used to create XBRL-based financial reports which yields quality problems and a better business rules driven approach which yields zero defects, guaranteed.

Current approach:

• Step 1: Provide fact "Assets".
• Step 2: Provide fact "Liabilities and equity"
• Report complete.

Give the steps above, what prevents the creator of a financial report from creating the fact "Assets" with a value of say 1,000; creating the fact "Liabilities and equity" with a value of "1,500"; and then submitting that report to the SEC or other regulator?  Nothing prevents the report error above from being submitted to a regulator, even though the report violates the accounting equation.  And that is exactly the sort of thing that is going on with XBRL-based public company financial filings to the SEC.

Business rules driven approach:

• Step 1: Create business rule: "Assets = Liabilities and equity"
• Step 2: Create fact "Assets"
• Step 3: Create fact "Liabilities and equity"
• Report complete.

The business rule prevents facts that would violate the accounting equation from inadvertently being created.  Software uses the business rule created in Step 1 to monitor the report creation process. Given these steps above, it is impossible to create a financial report that violates the logical relationship specified by the accounting equation, the fundamental rule of accounting.  Now, this one rule is provided only as a basic and easy to understand example.  Clearly you need more rules.  But what rules?

Here are the machine-readable business rules you need:

• Base XBRL Specification Conformance Suite: Provides hundreds of tests to make sure software is implemented consistently with the base XBRL technical specification.  Note that XBRL-based public company financial reports curently about 99.99% consistent with the base XBRL conformance suite.
• XBRL Dimensions Conformance Suite: Provides hundreds of test to make sure software is implemented consistently with the XBRL Dimensions technical specification.  XBRL-based public company financial reports are currently about 99.99% consistent with the XBRL Dimensions technical specification.
• Model Structure Relations Rules: Provides rules which specify the logical relations between the Networks, Tables, Axes, Members, Line Items, Abstracts and Concepts which make up an XBRL-based taxonomy.  XBRL-based public company financial reports are currently about 99.98% consistent with these logical relations.
• Edgar Filer Manual Rules: Provides Edgar system specific rules for public companies submitting XBRL-based financial reports to the SEC.
• XBRL US Data Quality Committee: Specifies different sets of specific rules related to the construction of an XBRL-based financial report.
• Fundamental Accounting Concept Relations Rules: Provides rules which specify the logical, mechanical, mathematical relations between the high-level financial reporting concepts represented within XBRL-based financial reports which may differ based on the reporting style used by a public company. Currently, public companies XBRL-based financial reports are about 98.88% consistent with such logical, mechanical, mathematical relations.
• Disclosure Mechanics Rules: Provides rules which specify the logical, mechanical relations between the report fragments which make up the Level 1 Notes Text Blocks, Level 2 Policy Text Blocks, Level 3 Disclosure Text Blocks and Level 4 Disclosure Details.  Currently, it is looking like public companies are between 65% and say 85% consistent with these logical, mechanical relations.
• Disclosure Mathematical Relations: Provides rules which articulate the mathematical relations of the specific disclosures provided by a specific reporting entity to both describe and can be used to verify the roll ups, roll forwards, member aggregations, and other specific mathematical relations of the report.  Currently, only roll up relations (XBRL calculations) are provided by public companies and those relations tend to be about 90% or better.  Roll forward relations, member aggregations, and other such mathematical relations are not currently represented within public company financial reports and the consistency of those mathematical relations is unknown.
• Reporting Checklist: Provides rules related to which disclosures are required to always be provided, which disclosures are required if some specific line item is material within a financial report, and other such rules.
• Conceptual Model Rules: Provides a thick layer of metadata for working with digital financial reports.  Specifies relations and rules which describe and can be used to verify consistency with the digital financial report conceptual model.  For more information see the Financial Report Semantics and Dynamics Theory.

I think that is about it for the logical, mechanical, and mathematical relations type rules.  There are other rules that are specific to more detailed areas of financial reporting and accounting.  These rules start to get into the compliance/noncompliance of regulatory rules.  I don't want to go down that path right now.

Think about it this way:  It is not about looking at the pieces of a digital financial report and finding pieces that are wrong.  It is about looking at the pieces of a digital financial report and proving that all the pieces are right.

This list of rules might seem like a lot, and it is.  Professional accountants creating reports and financial analysts using reports will not need to concern themselves with most of these rules.  For example, software deals with base XBRL technical specification and XBRL Dimensions conformance.  That is low-level stuff business professionals will never need to deal with.

If you want to understand more, please read the document Comprehensive Introduction to Business Rules for Professional Accountants.

I have been talking about how accounting and reporting checklists can be automated for quite some time.  Well, I believe that I have created the world's first machine-readable XBRL-based digital financial reporting checklist. (If anyone believes that my claim is wrong, please let me know. If it is not the world's first, it is likely the most complete.)

In fact, I believe that I have created a complete framework for representing financial reporting rules using the global standard XBRL format.  I knew that attending all those XBRL Technical Specification meetings would pay off!  To Walter Hamscher, David vun Kannon, Geoff Shuetrim who spent countless hours answering questions about what they were creating I say both thank you and here is evidence that shows that your creation works as intended.

Here is an overview of what I have created in both human-readable and machine-readable form: (this version has metadata relating to US GAAP, but creating this for IFRS or any other reporting scheme is as simple as removing US GAAP metadata and adding metadata for whatever reporting scheme you might want to use)

• Reporting checklist: This is a report-level checklist of business rules that explain the general reporting requirements.  For example, rules like "a financial report MUST contain a balance sheet" and "if inventory is reported, then an inventory disclosure is required".  Note that different report-level checklists can be created for different accounting activities of economic entities.
• Disclosure mechanics: This is the disclosure-level business rules.  These rules describe how and can be used to verify that the pieces of a disclosure fit together.
• Fundamental accounting concept relations: The fundamental accounting concept relations and the related reporting styles describe the high-level relationships between concepts and can be used to verify that reports are created in a manner that conforms to those relations. These are basically continuity equations used to cross-verify information.
• Type or class relations: This is a report-level set of business rules which makes sure that concepts are used properly relative to other concepts.  One example of these are whole-part relations for concepts that roll up relative to other concepts.
• Conceptual model: The conceptual model works at two levels.  The first is the level of a business report and is shared by each reporting scheme.  The second is the level of a reporting scheme and allows for description and validation metadata to be created for any specific reporting scheme.
• Model structure: Model structure rules enforce relations between Networks, Hypercubes/Tables, Dimensions/Axis, Members, Primary items/Line items, Concepts and Abstracts in the presentation relations. XBRL calculation relations and XBRL defninition relations are validated at the XBRL technical syntax level, however presentation relations are not.

There are other aspects to this, but it is unnecessary for business professionals to deal with them.  The XBRL technical syntax is watched over by software, at least by good software.  The XBRL conformance suite takes case of that.  Good software hides the XBRL.  The model structure is also dealt with at a lower-level.  All these details are below the business report level; business professionals should never have to deal with them (if you are using the right software).

If you are struggling to get your head around all this, I would recommend that you read the blog post, Framework for Understanding Digital Financial Report Mechanics.  All those PDFs contain information helpful in wrapping your head around why this is important and how to do this right.

I am not saying that I have this perfect, yet.  I want to get the modularization correct.  Testing the software that I am helping to create helps in this regard and helps to prove that this framework for digital financial reporting works as expected.

In the keynote address to the Big Data in Finance Conference, SEC Commissioner Kara M. Stein laid out A Vision for Data at the SEC.

Notable quotes of Commissioner Stein included (summarized by XBRL-US):

• " …recognizing that the growth in data represents both an opportunity and a necessity, how can the SEC best position itself to respond?  …  The first condition to success is acquiring the right data.  We need data that is relevant, timely, and high quality.  This is not about simply increasing the volume of data - this requires being smart about the data we gather.
• "Another condition to success is ensuring that computers can quickly and reliably interpret the data.  Structured data can be an important part of this.  SEC reporting in the last few years has begun to embrace better practices for structured data."
• "We should also embrace identifiers, like the "legal entity identifier," or LEI.  I remember vividly the uncertainty following Lehman's collapse.  Regulators and counterparties were left to sort through the rubble, trying to piece together the consequences.  It was a problem of modern complexity but without an equivalently modern solution.  LEI helps solve that problem by providing a uniform and reliable way to identify counterparties. This frees regulators to focus on the financial risks instead of data issues.  The new mutual fund reporting forms also include an important new requirement for funds to obtain an LEI."
• "An important part of defining our vision should be the creation of an Office of Data Strategy.  For some time, I have asked that the SEC develop an executive team responsible for creating and overseeing such an office.  The office would be responsible for coordinating the creation of a data strategy addressing how we collect, manage, use, and provide data.  This is a critical next step in turning our ad hoc growth as data users into a deliberate plan.  The office could lend its expertise to, and would coordinate with, our policy, exam, and enforcement offices.  Having a data strategy, and a team dedicated to it, is especially important in light of our limited resources.
• Just as the telegraph ushered in a new information era, the spread of data and data tools is changing how information is used and shared.  The promise is tremendous, and if the SEC can successfully harness the new technology, investor protection, financial stability, and the markets will all benefit."

All this is very encouraging.  If you want to brush up your digital skills, Framework for Understanding Digital Financial Report Mechanics has the information you need.