Digital Financial Reporting

A identification key or taxonomic key is a printed or computer-aided device used for identifying some entity that is unknown. Keys are constructed so that the user is presented with a series of choices about the characteristics of the unknown thing; by making the correct choice at each step of the key, the user is ultimately led to the identity of a thing. Taxonomic keys are also helpful in classifying things into a standard taxonomy consistently.

Here are two examples of printed keys: Example 1 | Example 2

Two examples of machine-readable keys are: Fundament Accounting Concepts and Reporting Styles (Reporting Frame Codes) and Disclosures (Which is a work in progress).  Don't be confused by the human-readable stuff that you see.  Trust me, all that information is machine-readable in global standard XBRL.

There are two types of keys:

• Single-access keys: A single-access key (dichotomous key, sequential key, analytical key, or pathway key) is an identification key where the sequence and structure of identification steps is fixed by the author of the key.
• Multi-access keys: A multi-access key enables the user to freely choose the set and characteristics that are convenient to evaluate for the item to be identified.

Single-access keys and multi-access keys serve the same purpose.  Each approach has its advantages and disadvantages.

One advantage of multi-access keys is that users can enter or select information about an unidentified thing in any order, allowing the computer to interactively rule out possible identifications of the entity and present the user with additional helpful information and guidance on what information to enter next. A disavantage of multi-access keys is that you have to understand a certain amount about a domain to use them; the more you understand about a domain the more useful multi-access keys can be.

One advantage of single-access keys is that if you don't understand the domain or don't understand enough the single-access keys can serve as bread crumbs that provide a path to the answer you are looking for.

How do taxonomic keys relate to financial reporting?  Here is a specific example.  When you are trying to find a concept in a taxonomy "hunt-and-peck" will work.  You can also consult with an expensive expert.  Another approach is to leverage a taxonomic key.  The US GAAP Financial Reporting XBRL Taxonomy provides the following two concepts:

• Net Income (Loss) Attributable to Parent (us-gaap:NetIncomeLoss) which has the documentation "The portion of profit or loss for the period, net of income taxes, which is attributable to the parent."
• Income (Loss) Attributable to Parent (us-gaap:IncomeLossAttributableToParent) which has the documentation "The portion of profit or loss for the period which is attributable to the parent."

The only difference in the documentation is that the first has "net of income taxes" and the second does not.  Does that mean that the first is used if you have income taxes and the second is not?  No.  There are a lot of public companies don't report income taxes and use the first concept.

The difference between the two concepts is that the first applies to corporations and the second applies to partnerships.  How do I know that?  Two reasons. First, if you look at the hierarchy of concepts in the presentation relations, the second is contained within the parent concept which is "Partnership income".

Another reason I know this is that the majority of corporations use the first concept wether they report taxes or not.

So, if you were working with the US GAAP Financial Reporting XBRL Taxonomy and the software tool you were using knew that the financial report was a corporation and not a partnership, it could help guide you to the correct concepts within the taxonomy.  The same idea applies to what type of industry or accounting activities you report, what style of reporting you use, preferences you have, and so on.  Software can help guide you through the process of using the taxonomy more correctly by understanding things about the taxonomy concepts that you might use.

There are other uses for keys.  "Hunt-and-peck" and "consult an expert" works for creating disclosures also.  But computer-aided taxonomic keys work well also.  If you think about what I pointed out in the blog post Automating Accounting and Reporting Checklists, keys is one of the technology tools that can be leveraged by computers to help professional accountants perform work.  The more metadata you have, the more keys you can provide.

I experimented with Tableau years ago. One of the most interesting things to me was OData.  Back then, I thought it would be great to be to get information directly from a financial report into Tableau and present the information.  Guess what.  28msec now supports OData.

When I found out that 28msec supported OData, I took their demo link, pasted it into Tableau (I had to upgrade from version 8.2 to the current version which is 9.3), and I created this.  It does not look that great, but I just wanted to prove that the 28msec atom-xml feed actually worked in Tableu, which it does.

I would encourage people to experiment with the 28msec queries an Tableau.  Here are a bunch of example queries.  There is documenation that will help you create queries at the bottom of the blog post.  If you come up with anything good, let me know.

It can be very challenging to understand that something is an error in an XBRL-based public company filing to the SEC.  Software tools for examining such digital financial reports that exist today leave a lot to be desired.  One software tool that provides the comprehensive set of functionality professional accountants need is hard to come by.

What I do to resolve this issues is build my own tools.

Here is a prototype tool that I created that I hope makes a leap toward helping the average accountant understand inconsistencies in XBRL-based public company financial reports for the purpose of correcting those errors.  I am trying to get one or more software vendors to offer this sort of functionality in a commercial tool.

I did not build ALL of this functionally myself.  I am leveraging the XBRL Cloud Viewer and queries provided by 28msec.  What I did that is unique is to combined functionally provided by different software vendors, add some of my own functionality, to get a tool that is closer to what I desire.  It is far from perfect, but it does help one examine digital financial reports and see and understand issues.

To understand the issues, first you must understand that there should NOT be any issues.  For example, here is a query of the balance sheet information for about 100 public companies.  I can do this exact same query on the classifed balance sheet information for 5,293 public companies that report using a classified balance sheet, and 5,042 or 96% of public companies are consistent with my expections.  My expectations are things such as the balance sheet balancing, Total assets = Current assets + Noncurrent assets; Total liabilities = Current liabilities + Noncurrent liabilities; things like that.

I can run another query of the 251 or 4% of public companies that report a classified balance sheet which does NOT meet those expections.  Here is a taste of that, about 70 companies that have inconsistencies.

A good question is: What exactly is the CAUSE of the inconsistencies?  And that is what my prototype helps you see.  Here are THREE common reasons for inconsistencies, all of which are filer errors:

• Inappropriate use of the concept "us-gaap:AssetsNoncurrent" when the filer should be using the concept "us-gaap:NoncurrentAssets" to represent long-lived assets in the geographic area disclosure. (Example)
• Inappropriate use of the concept "us-gaap:LiabilitiesNoncurrent" where the filer DID NOT INCLUDE long-term debt in that concept whereas the US GAAP Taxonomy and other filings clearly include long-term debt as part of "us-gaap:LiabilitiesNoncurrent".  Besides, the US GAAP XBRL Taxonomy provides the concept they should have used, "us-gaap:LiabilitiesOtherThanLongtermDebtNoncurrent". (Example)
• Inadvertantly reversing the concepts used to represent "Equity attributable to parent" and "Equity (including the parent and noncontrolling interest). (Example)

There are other specific causes of inconsistencies.  If someone tells you, "Extensions are the cause of inconsistencies," you can probably assume that because they make general statements like that they don't understand exactly what causes inconsistencies.

If you have any ideas on how to improve my prototype, please let me know.  Why?  Because I am trying to get software vendors to build better tools.  Any help would be greatly appreciated.  You can build your own tools also using the 28msec SECXBRL.info query tools.

28msec used my fundamental accounting concept relations metadata to implement what I would call normalized comparisons of public company financial information based on those fundamental accounting concept relations.  Here is a taste: (there is more to come)

Normalized Information

• Classified balance sheet, entity comparison
• Classified balance sheet, period comparison (you can do cross period comparisons for any entity with these queries also)
• Classified balance sheet, fixed assets reported (alternative), entity comparison
• Unclassified balance sheet, entity comparison
• Income statement, reports gross profit and operating income (loss), entity comparison
• Income statement, reports revenues, operating expenses, and operating income (loss), entity comparison
• Income statement, reports revenues, costs and expenses, and operating income (loss), entity comparison
• Income statement, reports revenues, operating expenses, nonoperating expenese, entity comparison
• Income statement, interest based revenues
• Income statement, insurance based revenues
• Net income (loss) breakdown
• Statement of comprehensive income (loss)
• Cash flow statement
• Cash flow statement (alternative) excludeds exchange gains
• Net cash flow breakdown, continuing/discontinued
• Net cash flow breakdown, continuing/discontinued (alternative, excludes exchange gains)

To understand the difference between the as reported information and the normalized view, please see this resource where that is explained.

Additionally, they implemented an awesome as reported comparison query.  You can see that in action here.  (I arbitrarily picked Alaska Airlines as the company to provide examples for. You can do these queries for ANY public company, ANY disclosure.)

As Reported Information

• Cash, cash equivalents, and marketable securities
• Deferred tax assets and liabilities
• Components of income tax expense
• Funding status of defined benefit plan details
• Funding status of defined benefit plan details (more)
• Operating segment information (takes a minute, but worth the wait)
• Derivative instruments information (Yes, works with text blocks)
• Significant accounting policies
• Balance sheet (for EVERY QUARTER and FISCAL YEAR)
• Income statement (fiscal years)
• Income statement (fiscal years AND quarterly information)
• Comprehensive income
• Cash flow statement
• Document and entity information

These tools will be very, very helpful getting the quality XBRL-based public company financial reports where it needs to be to make this valuable resource as useful as possible. Also, while I am showing the human-readable version of the query, there is also a machine-readable version of the query (XML , JSON and CSV).  Here is an example of that:

• Income statement (machine readable XML)

Thank you to 28msec for implementing these queries; thank you to the SEC for having the foresight to move to structured reporting.

ADDED: Here is documentation that helps you understand how to create the as reported queries.

ADDED: See this working prototype that I created using these queries.

ADDED: This is the metadata that drives the queries.