Digital Financial Reporting

I have updated the document Digital Financial Reporting Principles.

Looking at individual XBRL-based financial filings is helpful. Looking across many, many XBRL-based financial filings with a focus on specific aspects of that financial report is likewise beneficial.  Carefully and consciously comparing and contrasting many XBRL-based financial filings helps one build a mosaic, increasing ones understanding of digital financial reports even more. Consciously comparing and contrasting XBRL-based financial reports helps one see and understand important and insightful information about those XBRL-based financial reports.

Digital Financial Reporting Principles offers the following important information:

• Conceptual overview of an XBRL-based, structured, digital financial report
• Framework and theory for thinking about a digital financial report
• Reference implementation of XBRL-based digital financial report
• Summary of common sense digital financial reporting principles

If you believe that digital financial reporting will play a role in the future of financial reporting, then this document will help you.  Whether you are a professional accountant trying to get your head around this new technology or a software vendor trying to build useful software that professional accountants; Digital Financial Reporting Principles will help you find your niche.

Public companies provide information about subsidiaries to the SEC as an exhibit to their 10-K filing. Using Microsoft as an example, if you go to their SEC filing page, look for EXHIBIT 21 and you will see their list of subsidiaries.

But there is a bit of a problem.  That list is not machine-readable.  But what if the information were provided in a machine-readable format, such as XBRL.

I created a prototype of that machine readable list of subsidiaries.

I arbitrarily picked the comany XCEL ENERGY INC.  Here is their SEC filing page.  Here is their EXHIBIT 21 which shows their list of subsidiaries.  Here are the pieces of the prototype:

• Define arcroles: The first thing I did was define the arcroles that I need to represent the relationships.  There are TWO types of relationships.  The first is the relation between a parent company and a subsidiary.  The second is the state of incorporation and the company that is incorporated in that state.  Here are those two arcroles defined in an XBRL taxonomy schema. (This is a prototype set of arcroles; these really belong in the XBRL International Link Role Registry.)
• List of entities: Next, I created a list of entities.  I did that using an XBRL taxonomy schema. That also includes labels for each entity and documentation that explains the PURPOSE of each subsidiary which XCEL included in their EXHIBIT 21. (Now, this taxonomy schema is not properly modularized; I would have to think about exactly how to do this; but that is just an organization and maintenance issue.)
• List of states: I am going to need a list of states to indicate the state of incorporation. Here is that XBRL taxonomy schema.
• Represent the relations: Next, I represented the relations.  I did that using an XBRL definition linkbase.  It is in that XBRL definition linkbase that the list of subsidiaries is represented and the state of incorporation is represented by creating those relations.  Basically, the XBRL definition arcroles are used to express the relations between the subsidiaries and states of incorporations expressed in the XBRL taxonomy schema and those relations are stored in an XBRL definition linkbase.

Here is what the relations look like in an off-the-shelf XBRL Taxonomy creation tool: (this does not show the arcrole that expresses the relation, that is shown as a popup.

That can be a bit hard to read.  Here is exactly the same information imported into an Excel spreadsheet:

(Click image for larger view)

So there you go; information that is both human-readable by simply rendering the information in HTML on the SEC web site, or machine-readable.

Pretty much any type of relation can be represented using this approach.  Here are some other types of relations between entities or related to entities that could be represented in a similar manner.

You could do this exact same thing using RDF/OWL but those tools are harder to understand than XBRL tools.  Frankly, which technical syntax is used matters less.  Having the information in some machine-readable form (that is also human-readable) rather than only in human-readable HTML documents that require significantly more work to make use of the information the documents contain.

Digital!

I have updated the commentary linkbase(s) that I have been experimenting with for the US GAAP XBRL Taxonomy.  Here are three versions for the 2013,  more for 2013, 2014, 2015, and 2016 US GAAP XBRL Taxonomy.

Here is a prototype references linkbase for 2013.

I will explain this more later.

I have updated what I call my reference implementation of an XBRL-based public company financial filing to the SEC.  You can get to the new reference implementation here.  There you will find a high quality example of an XBRL-based digital financial report with complete human-readable and machine-readable documentation.

If you gave the exact same financial information about one economic entity to ten different professional accountants; you would expect that all ten accountants would create a fairly similar financial statement for that economic entity.  Each professional accountant would represent that financial information similarly in a set of financial statements in all material respects.  Each accountant would create a true and fair representation of the economic entity's financial information in the financial statement they created.  That is true whether the information is formatted in HTML or PDF or Word or XBRL. Right?

Try that experiment with an XBRL-based financial report.  How do you think that might turn out?

How would you define "correct" or "best modeling approach"?  This is how I defined correct for my reference implementation:

• Every model structure is logical and consistent.  There are no inconsistent and therefore perhaps confusing or potentially misinterpreted modeling situations.  All pieces of the model structure act consistently and how they interact with other pieces is well understood and predictable.
• Every computation is expressed and proven to work correctly.  Every computation must be proven to work correctly by passing one or more business rules.  If a computation relation exists and it is not expressed, then there is no way to tell if the computation works correctly per the XBRL medium.
• No duplicate facts.  Duplicate facts result from modeling errors and therefore should not exist.
• All reported information is consistent and does not contradict other information.  If there is no specific reason for an inconsistency which can be articulated which justifies the inconsistency or contradiction; then you are being inconsistent and one of the approaches must be dropped.  Each report fragment should be correct and should interact appropriately with other report fragments.
• Each property is correct.  Each property of any component, fact, report element, or parenthetical explanation must be correct from a business meaning or semantics perspective.
• Meaning can be logically explained to a business professional.  The meaning of each and every aspect of the digital financial report can be explained, logically, to a business professional.  If the meaning cannot be explained, then it cannot be considered to be correct.
• True and fair representation of financial information.  Overall, the financial report needs to work.  In all other ways the information expressed is correct, complete, accurate, and consistent.

If how to create a digital financial report is not well understood, then XBRL-based digital financial reports will never be usable. A digital alternative for a general purpose financial report will not magically appear. What a digital financial report ends up being will come from deliberate effort, skillful execution, and rigorous testing.

The documentation of the reference implementation will help software vendors understand digital financial reports.  All the files are there for software vendors to use for testing.

Check out the reference implementation.  Understand digital financial reports by analyzing and experimenting.  It is through this analysis and experimentation that professional accountants will understand how to make digital financial reports work reliably and predictably.

Artificial intelligence seems to be making a turn.  I mentioned a TED Talk video by Jeff Hawkins, How Brain Science Will Change Computing.  Stephen Wolfram in his video, AI and the Future of Civilization, seems to be saying many of the same sorts of things Jeff Hawkins is saying.

What is possible using artificial intelligence? While it is a mistake to over-state what might be possible; it is likewise a mistake to understate the possibilities.  What would an expert system related to financial reporting look like?  What would that expert system do?

The objective of general purpose financial reporting is to provide financial information about companies that is useful to capital providers in making decisions.  A little more specifically, the goal of financial reporting is to communicate the financial position and financial condition of an economic entity.

There are two types of processes that can be used to execute that objective: (1) manually, (2) automated.  I know that a human can perform 100% of the process of creating a financial report.  But what portion of report creation can be automated?

Creating a financial report is part symbolic-analytic service and part routine production service to use Robert Reich's perspective of work/jobs or tasks.  A financial report is not a random collection of stuff.  There are many, many patterns that exist in financial reports.  In fact, the financial report itself is purely mechanical.  Deciding what should go into the report and how to measure what goes into the report is not mechanical at all, that requires judgement.

What sorts of things go into a financial report?  Disclosures.  Disclosures have patterns.  If you compare the income statements of an insurance company you see patterns. The income statement of banks have patterns also.  Lots of patterns exist in other income statements.  Are financial reports uniform?  Of course not. But financial reports are not random either.

My document Understanding Slots, Blocks, Templates and Exemplars points out a lot of these patterns.  How to describe a system formally is pretty well understood.

What if you took all the pieces that relate to a financial report and you put all that information into machine-readable form.  What if you structured all the pieces of a financial report so that a software application could interact with the pieces, and you had a piece of software that served as an engine that understood all of those structures.

If you had all of that, what portion of the mechanical aspects of creating a financial report could be automated?  What would be the benefits of such a financial report creation process.

Is any of this possible?  Who knows.  But as you might be able to tell from my Digital Financial Reporting Manifesto, I will try and find out.