Digital Financial Reporting

If you follow this blog you know that I post quite a bit of information. I have taken information relating to working with SEC XBRL financial filings and consolidated it into a single resource: Understanding SEC XBRL Financial Filings which you can get to here.

This resource is useful for more than creating SEC XBRL filings. As this HL7 video points out (see slide 4) you need three things to make interoperability work: technical interoperability, semantic interoperability, and process interoperability. XBRL provides the technical interoperability, the XBRL technical syntax. If used correctly XBRL can provide the semantic interoperability also it seems. Process interoperability I don't really grasp well yet. I don't think XBRL provides that.

So check out this resource whether you work on SEC XBRL filings or not. This resource is not for the XBRL novice. But, it can help beginners or those with intermediate or advanced skills add to their skill set. I know that over the three years that it has taken me to accumulate and grasp this information I have learned quite a lot. Hopefully this will help you.

In my popular video How XBRL Works (pushing 12,000 views) I did my best to explain three important notions needed to properly understand XBRL.  This is a better articulation of that information. Watching the video can also be helpful in gaining a better understanding of these important key terms. If you don't have a proper understanding of these terms, it is doubtful that you have a proper understanding of XBRL.

Unstructured versus structured information

Digital information comes in two forms:

• Unstructured which means the information contains no identifiable structure and therefore it is unrecognizable and therefore not usable by computer software. Further, no controlled navigation within the pieces of the unstructured information is possible due it its lack of structure.
• Structured which means the information has identifiable structure which can be recognized and utilized by computer software. Further, because of the structure navigation within the pieces of structured information is possible because of the structure.

Truth be known, everything that a computer works with has to be structured at some level and the level of structure determines what a computer can do with that digital information.

Structured for presentation versus structured for meaning

There are two approaches to structuring information digitally:

• Structure for presentation. An example of that is a Word processor document which is structured using headings, sub headings, paragraphs, tables and lists. An Excel spreadsheet is also an example of structuring for presentation, it uses worksheets, columns, rows, and cells.
• Structure for meaning.  An example of that is database or a taxonomy or other type of classification system. A database structures the presentation into rows and columns, but the rows and columns are associated with defined names which have specific meaning.

Syntax versus semantics

More often confused are the two parts of structured information.  Both parts are important, but for different reasons:

• Syntax describes the form of the information and is generally not relevant to a business person. This is syntax: <Name>John Doe</Name>. Syntax is important to technical people.
• Semantics communicates the meaning of the information. For example, "the balance sheet balances" is semantics. Business meaning is key to the digital world.

Interoperability = Business benefits

What does all this mean to you?  More than you might think. Properly weaving business systems together provides significant business benefits. For example, SAP says in this article that its customers have sharply cut costs of creating regulatory reports by 75 percent. If you are not experiencing that magnitude of benefit you may be confusing some of these terms.

As his video about HL7 points out (see slide 4) you need three things to create useable business system interoperability:

• Technical interoperability is concerned with the conveyance of payload. This is syntax, what physically gets transferred.
• Semantic interoperability communicates meaning unambiguously. Semantics are domain specific. The business systems on both sides of the transfer need to have the same understanding of the meaning for the transfer to work effectively.
• Process interoperability enables shared human understanding that is needed to coordinate work processes and enable business systems to interoperate. Basically, the work flow needs to be understood.

Think "Semantic Spreadsheet"

This short 6 minute video helps you see the world differently (the first video, "Basics of Quantrix Modeler"). In the video the narrator makes up the terms used in his matrix, "Net Income", "Revenue", "Expenses". For financial reporting use of that semantic spreadsheet or what the narrator calls a "matrix", you would generally not create the concepts used yourself; you would generally pick most of them from the US GAAP or IFRS taxonomy.

Evolution

We are not there yet.  Business software is not what it needs to be. For example business intelligence software is too focused on OLAP, it does not handle text well preferring to work with numbers, and it is "read only", you cannot write information back to the database generally.  The US GAAP Taxonomy is modeled like a the documents accountants are used to, not like the data model that it should be. Each implementation of the XBRL standard is unique to that implementation, for example the SEC and FDIC implementations of XBRL don't interoperate.

All these issues will be worked out over time. Don't make the mistake of confusing the moving pieces to this puzzle.  The better you understand the moving pieces, the fewer mistakes you will make in working with new technologies such as XBRL.

I have been trying to articulate the benefits of unique, explicit [Table]s in the US GAAP Taxonomy for quite sometime. In trying to figure something else out I stumbled across a paperwhich helps communicate why unique, explicitly [Table]s are superior to [Table]s which are not unique and [Table]s which are implicit.

First off, let me explain what I mean by unique [Table]s and by explicit [Table]s.

A good example of a non-unique [Table] is the "Statement [Table]" which appears in the US GAAP taxonomy.  What does the "Statement [Table]" represent?  Well, it represents many things and that is the underlying problem. It could represent a balance sheet, an income statement, a cash flow statement or actually anything because some vendors are using "Statement [Table]" to express every [Table]. So, what I mean by unique [Table]s is exactly the opposite and exactly as it sounds.  Just like concepts or other things in the US GAAP Taxonomy each [Table] has ONE meaning, one name.  Rather than using "Statement [Table]" to identify multiple things, each [Table] is specific: Balance Sheet [Table], Income Statement [Table], Cash Flow Statement [Table], and so forth.

By explicit [Table]s I mean that there are no implicit [Table]s.  What I mean by that is that today, everything exists in a "[Table]" in the US GAAP taxonomy.  And of course you will say, "No, that is clearly not correct, one can cleary see that is not the case." But, this is exactly my point.  True, you can't "see" the [Table], but it is there.  What I mean is that after you address all the explicit tables identified by the XBRL hypercubes marked with a "... [Table]" in the label and name, you have one more table which implicitly exits.  Basically, it is the "everything else [Table]" which has no name.  It has two [Axis], the "Reporting Entity [Axis]" which is instantiated using the XBRL syntax "entity identifier" portion of a context and the "Period [Axis]" which is articulated using the XBRL syntax "period" portion of a context.

Don't make the mistake of confusing syntax and semantics. Just because it is called part of the XBRL context does not mean that from a business perspective that it is not an [Axis].  First off, be aware that ALL [Axis], be they XBRL Dimensions defined or XBRL 2.1 defined, are expressed using part of an XBRL context element.

So, what I am saying here is rather than modeling things to show up under the "unnamed [Table]" implicitly, it is better to be explicit and define the [Table].  Further, having multiple "unamed [Table]"s violates the first notion of making every [Table] unique.

"Why?", you ask.  Here is why. Navigation and use of the taxonomy and the SEC XBRL filings is superior if [Table]s are unique and explicitly defined because navigation within the pieces of the taxonomy and/or SEC XBRL filings because of the unique "handles" of the [Table]s.

If [Table]s are unique, you dont also have to use the network to uniquely identify WHICH of the non-unique [Table]s you mean should you be trying to tell a computer software application which of the non-unique [Table]s you desire to use.  Further, there is no need to ask what defines the [Table], the hypercube which defines the table with the "... [Table]" label/name on the end or the set of [Line Items] which make up the [Table].  You will not have that question because every [Table] is unique and you will never run across that situation.

Computers need these unique handles to understand exactly what you desire. Unique, explicit [Table]s provide the handles needed to control navigation between pieces of a taxonomy or SEC XBRL financial filing.  Without unique [Table]s, there is no way you can get around using network information to create unique handles.

If you need more details please read the paper. It is quite technical, but it lays all of this out quite nicely.

The FASB and IASB have been working to create a common conceptual framework for financial reporting and the accounting information system which feeds financial reports.

The FASB stated in its publication Conceptual Framework for Financial Reporting: The Objective of Financial Reporting and Qualitative Characteristics and Constraints of Decision-Useful Financial Reporting Information(a FASB Exposure Draft):

A common goal of the Boards-a goal shared by their constituents-is for their standards to be clearly based on consistent principles. To be consistent, principles must be rooted in fundamental concepts rather than a collection of conventions.

Much of this framework relates to things like recognition and measurement concepts which are very important to the accounting information system as they impact the numbers that will turn up on a financial report.  But, they are not really relevant to the notion of a financial report itself.

There are a number of things in the FASB/IASB framework which are directly related to financial reports. Let me point those out.

Objective of a financial report

First of, something of key importance is the objective of a financial report.  To paraphrase, the objective of a financial report and financial reporting is to provide useful information to capital providers.

Financial statements

Phase Aof the conceptual framwork project defined financial statements a company would report as:

• Balance sheet
• Income statement
• Cash flow statement
• Statement of changes in equity
• Related disclosures

"Related disclosures" can be broken down further, basically a categorization of the disclosures, by the FASB accounting standards codification.  I summarized the topics here and mapped the topics to the US GAAP taxonomy. I would venture to break "related disclosures" into the following based on the FASB accounting standards codification and the US GAAP Taxonomy:

• Organization
• Consolidation
• Basis of Reporting and Presentation of Financial Statements
• Significant Accounting Policies
• Disclosures, Financial Statement Accounts
• Disclosures, Broad Transaction Categories

Elements of financial statements

Financial statements are broken down into 10 elements by SFAC 6.

• Assets
• Liabilities
• Equity
• Investments by owners
• Distributions to owners
• Revenues
• Expenses
• Gains
• Losses
• Comprehensive income

Other places have definitions of these elements of a financial statement such as here.

Seeing the "financial report schema"

It is looking more and more like there is a "financial report schema" hiding within US GAAP and IFRS. It seems to me that this schema is a basis for defining what a financial report looks like, somewhat of a blueprint. This blueprint or schema can be read by a computer software application to validate the semantics of the financial report.  Humans use this schema today in the form of a disclosure checklist. But I believe that this schema can also be used by software applications to verify SEC XBRL financial filings.

Not only would SEC XBRL financial filings follow a schema, but the US GAAP Taxonomy should follow this schema also.  The schema may be different for different industries.  For example, the schema of a balance sheet is different for a classified balance sheet and an unclassified balance sheet.  The schema is different for a single step income statement and a multi-step income statement.  The schema is different for a partnership and corporation.  But, financial reports are not random.  They do have schemas.

For years people involved with XBRLhave said, "XBRL will be easier to use when XBRL disappears behind the scenes..." Are you seeing XBRL disappear behind the scenes in the software you are using?

What if the XBRL US GAAP Taxonomy "disappeared" altogether?  What do I mean by that? We don't need XBRL, what we need is what XBRL provides. Think about watching TV if people still do that today. I really don't watch TV much, but I do watch the digital recording of the PBS News Hour any time I want, not just at 6:00 PM after I have rushed home from the YMCA from my workout so that I don't miss it.

Take a close look at the little US GAAP Taxonomy Reorganization which I created. It is not that great, I know.  I wish I were a better programmer.  XBRL is disappearing a little. But consider this:

• List of Objects: That list provides the collections of objects in the US GAAP Taxonomy in a flat list. The objects are a little better than XBRL terminology.
• HTML Information for an Object: This, which you can get to from the list above by clicking on the HTML link, is simply a listing of information about an object. This is a rendering of information, no XBRL involved.
• XML Information for an Object: This is just like the link above, except rather than providing the information to you in HTML so you can read it, this provides the information in XML so that a computer application can read it.  This is a pseudo-web service, WSDL. Not sure I have the syntax perfectly correct.  This is not XBRL either.

Does it really matter what form the US GAAP Taxonomy is in when software vendors receive it for use? When it is created it is created in software which stores the XBRL taxonomy information within a relational database.  XBRL is only generated to make the taxonomy available to others.  Those that use the taxonomy tend to work with it as XBRL it seems.  But it seems to me from what I am doing is the taxonomy is actually much easier to use in pretty much any other format that XBRL.

XBRL is just a means of transporting or exchanging the information the US GAAP Taxonomy contains. When you add additional information, for example see these key ratios, you may or may not use XBRL for this information.  XBRL does have some advantages because you can exchange the information with others. But there are other data formats.  Relational databases is a very popular one today.

If you use a relational database, why do you still have to use the funky terms used by XBRL? Why can't easier terms be used?

Just rambling.