Digital Financial Reporting

I remember back in, oh I think it was 2001 or 2002 when a few of the technical people introduced the linkbase to XBRL. Most people did not "get it" back then. I did not "get it" at first. But, with the help of some really good technical people, I eventually understood what a linkbase was, why it was important, and why we needed to use them in XBRL.

A linkbase is basically the way XBRL expresses a semantic network. A semantic network is an artificial intelligence technology.

I am not going to go into explaining what a semantic network is, I have a different point.  My point is that if you are a technical person or a business person and you don't understand the meaning of terms such as network, graph, syntax, semantics, RDF, OWL, SKOS, metadata; then you are at a significant disadvantage.

Why do I say this?

The world of financial reporting is about to change in a very big way.  It is already changing. If you don't understand where financial reporting is going then you likely don't know how to get there. Let me give you one specific example.

In a prior post, I mentioned Risk Modeling at the SEC: The Accounting Quality Model.  In that speech; Craig M. Lewis, Chief Economist and Director, Division of Risk, Strategy, and Financial Innovation at the SEC; described some things the SEC are doing.  Do you believe that what the SEC will do will work and to what extent?  Do you know how the SEC is going to build what they are proposing? Do you understand what to do to build counter measures so you don't unnecessarily stick out on the SEC radar?

There will be many layers to this notion of The Accounting Quality Model.  The first layer is basic financial semantics.  If your financial report does not have an identifiable balance sheet, if that balance sheet does not provide expected concepts such as "Assets" and "Liabilities and Equity" and "Equity", if your balance sheet does not balance, if your "Assets" and "Liabilities and Equity" don't foot; you will be flagged.  Why?

Accurate processing of the subsequent layers is impossible unless the first layer processing is successful.  The more sophisticated processing which the SEC seems to be envisioning by that speech cannot be achieved unless all the first layer ducks are all in a row.  Now, one could take the view, "Hey, let's just hinder the SEC's attempts at higher level processing by making sure we have issues which block their ability to process our information."  Some people will likely take this approach, but that will not last long.

But forget about the SEC and SEC XBRL financial filings; I am only using that as an example of what is possible.

What if your organization could apply similar approaches to your internal systems?  What if your organization had an internal Accounting Quality Model-type or some other semantic model that you used to evaluate all sorts of things similar to how the SEC is going to use all that XBRL information?

Welcome to knowledge management!

If you don't understand what a graph is, what a network is, what metadata is, how RDF inference engines work, why semantics are more important than syntax; then it is highly unlikely that you "get" what I am saying here.  Thus the need to understand.

If you don't understand these terms, if you don't understand that XBRL linkbases are semantic networks, then it is highly unlikely that you are a business person who is pushing for the correct software applications or that you are a software developer who is architecting or otherwise developing the correct software.

If you are a business person and you don't understand those sorts of terms, then it is highly unlikely that you can communicate appropriately and convince other business people where things are going.

If you are a business person and you don't understand those sorts of terms, then it is highly unlikely that you can articulate to a software developer what software they should be building.

A business user needs to understand these sorts of things in order to understand what metadata they need, why they need it, and how to properly express that metadata.

A technical person who does not understand what a graph is won't realize that when most people create XML, the generally create trees which are more limited than graphs.

I could go on and on but if you will get my point, you probably already have.

Folks, syntax does not matter (or maybe it is better to say that it is only one thing that matters), it is the semantics that matter. XBRL is a technical syntax.  It is just a format that you output to when you need the things XBRL has to offer.  And XBRL has a lot to offer.  It's status as a global standard is very important.  All those standard taxonomies for financial reporting are important.  But the biggest benefit XBRL offers is its business rules engine.  RDF/OWL does not have this functionality.  XML alone does not have it either.  XBRL alone also has its disadvantages, for example limited functionality for expressing metadata.

RDF/OWL has its advantages, such as its inference engines.  Anyone who thinks that they don't need to use XBRL or RDF/OWL because they already use XML does not understand the differences between those three technical syntaxes.

Semantics is where all the action is.  That is what enables the sort of thing the SEC envisions and describes in that speech.  You can have that sort of sophisticated processing also, internally, in your organization. This type of processing is by no means limited to external financial reports.

Interested in RDF?  This Introduction to RDF provided by IBM is a good place to start. This RDF Tutorial is also quite helpful.

This article; Thinking XML: Basic XML and RDF techniques for knowledge management, Part 7; helps to make the point that syntax does not matter, it is all about the semantics.

These same ideas apply to XBRL.

Craig M. Lewis, Chief Economist and Director, Division of Risk, Strategy, and Financial Innovation
U.S. Securities & Exchange Commission, describes ways the SEC will use all that SEC XBRL financial information in his speech, Risk Modeling at the SEC: The Accounting Quality Model, to the FEI Committee on Finance and Information Technology.

There are two particular pieces of this speech which I would like to highlight.  First, this statement about The Accounting Quality Model:

While we have several projects in development, we are particularly excited about what we call an “Accounting Quality Model” (AQM).  This model is being designed to provide a set of quantitative analytics that could be used across the SEC to assess the degree to which registrants’ financial statements appear anomalous.

Anomalous.  Deviating from what is standard, normal, or expected.  Sticking out from the pack.  Seems like a great way to stick out of the pack is modeling things incorrectly where most SEC filers do model thing correctly (see this analysis for the 271 of 8289 who stick out to me and my dinky little Microsoft Access database application).

To provide a little bit of an example of what the Accounting Quality Model is and how it would be used, Mr. Lewis provides the following example related to how analysis of discretionary accruals and non-discretionary accruals can help detect earnings management:

Second, we need to understand generally where it is possible to discern the effects of earnings management.  Typically, they manifest in the discretionary choices that management can make under GAAP when reporting its financials.  In accounting jargon, total accruals are the difference between free cash flows and income before extraordinary items.  It is the difference between what accountants recognize as revenue and expenses and the actual cash flows available to shareholders.  We can decompose total accruals into two broad categories: discretionary accruals and non-discretionary accruals.  Non-discretionary accruals are accounting adjustments made in strict adherence to GAAP and are relatively objective.  Discretionary accruals however, may be subjective and require the preparer to exercise considerable accounting judgment.  As is generally recognized, this influence over the potential accrual values can allow for opportunities to, for example, smooth income and therefore, manage earnings.

What a great opportunity for filing agents and XBRL software vendors:  validation/verification processes which make sure an SEC filing does not stick out.

Measures, counter-measures.  The SEC will likely be hammering all that XBRL-based information. Clearly if the SEC processes cannot make heads or tails out of the information they will request a filer to correct their filing.  That will improve information quality for everyone, making all that information usable by automated processes.

Periodically I take a look at SEC XBRL financial filings for a number of reasons.  The results of my most current analysis of 8289 SEC XBRL financial filings for core financial semantics can be found here:

• Narrative
• HTML page of the 271 individual issues I see
• Excel spreadsheet of raw data

All the raw data is provided as a way to easily get to each SEC filing so you can determine for yourself if you agree or disagree with my personal assessment. You can look at the 271 issues for yourself, they are explained best in the narrative. This is a summary of what I see in terms of core financial report semantics for the 8298 SEC financial filings:

• Only 3 financial filings did not provide a balance sheet
• 100% of those filings which did provide a balance sheet reported a fact which could conceivably be discovered to be "total assets"
• 100% of those filings which did provide a balance sheet reported a fact which could conceivably be discovered to be "total liabilities and equity"
• Only 24 of those filing which did provide a balance sheet did not report a fact which could conceivably be discovered to be "total equity" (but each of those DID have equity, the just did not provide the total)
• Only 6 financial filings did not provide an income statement
• 100% of those filings which provided an income statement provided something which could be conceivably be discovered to be "net income"
• Only 67 financial filings did not provide a cash flow statement
• Only 6 of those filings which provided a cash flow statement did not report a fact which could conceivably be discovered to be "net cash flow" (but each of those DID have net cash flow, they just did not provide the total)

The information related to the issues is stratified in a number of ways, see both the narrative and the Excel spreadsheet. One interesting perspective provided is by generator.  This graphic shows the issues by generator as compared to the total number of filings submitted by that generator and a percentage of total issues as a percent of total submissions by generator:

The generators highlighted in yellow have an issues rate greater than 5%.  A total of 16 generators had no issues, but then again they had a relatively small number of filings each.  The total of 151 for all 16 represents 2% of total filings.

SEC Calls Again for Corrections in XBRL Filings.

Patience with repetitive, simple errors in XBRL filings is wearing thin at the Securities and Exchange Commission.

“Limited liability applies only to filers who make good faith efforts to comply with the rules and who promptly correct errors when they are made aware of them.”

“They have widespread skepticism about the reliability or usability of the data,” she said, in part because they see how commonly it contains errors. “It harms their ability to analyze your companies accurately.”