Digital Financial Reporting

What is the purpose of an SEC XBRL financial filings? (Or any digital financial report really)

1. To define one absolute reality: To arrive at some one absolute definition of "true and fair representation of financial information"?
2. To create a shared reality to achieve a specific purpose: To arrive at a shared common enough view of "true and fair representation of financial information" such that most of our working purposes, so that reality does appear to be objective and stable. So that you can query information reliably, predictably, repeatedly, safely.

Many people seem to believe that the answer is one forced absolute reality is being thrust on them.  That is why they tend to think that everything is involves judgment and that everything is subjective.  But this is to miss the point. A shared view of reality which is clearly interpretable and understood to achieve the purpose of meaningfully exchanging information so that time is reduced, costs are reduced, and information quality improves.

The goal is to arrive at some equilibrium, to balance the duality, as the author states, to recognize that there is no singular objective reality but in spite of that, we create a common enough shared reality to achieve some working purpose. To make reality of the financial reporting domain appear to be objective and stable in certain specific and agreed upon ways in order to fulfill some higher purpose.

From what I can see, the accounting profession has yet to agree on the purpose and they have not successfully communicated that purpose to IT professionals because (a) they have not agreed on the purpose and (b) they don't even understand that they need to agree on and communicate that purpose so accountants have not taken the time to agree on or define that purpose.

The book Data and Reality: A Timeless Perspective on Perceiving and Managing Information in Our Imprecise World, 3rd Edition, by  William Kent, helps understand issues related to getting machines such as computers to work with information.  This describes the book:

This book addresses timeless questions about how we as human beings perceive and process information about the world we operate in, and how we struggle to impose that view on our data processing machines. The concerns at this level are the same whether we use hierarchical, relational, or object-oriented information structures; whether we process data via punched-card machines or interactive graphic interfaces; whether we correspond by paper mail or e-mail; whether we shop from paper-based catalogs or the web. No matter what the technology, these underlying issues have to be understood. Failure to address these issues imperils the success of your application regardless of the tools you are using.

Data and Reality gracefully weaves the disciplines of psychology and philosophy with data management to create timeless take-aways on how we perceive and manage information. Although databases and related technology have come a long way since 1978, the process of eliciting business requirements and how we think about information remains constant. This book will provide valuable insights whether you are a 1970s data-processing expert or a modern-day business analyst, data modeler, database administrator, or data architect.

This provides more information about and excerpts from the book. Under the section "A View of Reality", the author describes the equilibrium which must be struck to create useful machines: (I made the important pieces bold)

In addition, there is a question of purpose. Views can be reconciled with different degrees of success to serve different purposes. By reconciliation I mean a state in which the parties involved have negligible differences in that portion of their world views which is relevant to the purpose at hand. If an involved party holds multiple viewpoints, he may agree to use a particular one to serve the purpose at hand. Or he may be persuaded to modify his view, to serve that purpose.

If the purpose is to arrive at an absolute definition of truth and beauty, the chances of reconciliation are nil. But for the purposes of survival and the conduct of our daily lives (relatively narrow purposes), chances of reconciliation are necessarily high. I can buy food from the grocer, and ask a policeman to chase a burglar, without sharing these people's views of truth and beauty. It is an inevitable outcome of natural selection that those of us who have survived share, within a sufficiently localized community, a common view of certain basic staples of life. This is fundamental to any kind of social interaction.

If the purpose is to maintain the inventory records for a warehouse, the chances of reconciliation are again high. (How high? High enough to make the system workably acceptable to certain decision makers in management.) If the purpose is to consistently maintain the personnel, production, planning, sales, and customer data for a multi-national corporation, the chances of reconciliation are somewhat less: the purposes are broader, and there are more people's views involved.

So, at bottom, we come to this duality. In an absolute sense, there is no singular objective reality. But we can share a common enough view of it for most of our working purposes, so that reality does appear to be objective and stable.

But the chances of achieving such a shared view become poorer when we try to encompass broader purposes, and to involve more people. This is precisely why the question is becoming more relevant today: the thrust of technology is to foster interaction among greater numbers of people, and to integrate processes into monoliths serving wider and wider purposes. It is in this environment that discrepancies in fundamental assumptions will become increasingly exposed.

If you like Data and Reality, you might like Everything is Miscellaneous and Models. Behaving. Badly. also.

A Compliance Week, Even With SEC XBRL Guidance, Problems Persist, has some pretty strong statements:

“XBRL has been a failure since the beginning,” says Dave Frankel, an independent consultant with SlingStone Group, formerly with EDGAR Online. “The SEC had the right idea but didn’t commit to it fully. This latest guidance is kind of a weak attempt to get things moving in the right direction. Most in the industry are skeptical whether it will have any effect.”

“The way data quality is being managed around this whole initiative has been terrible,” he [Campbell Pryde] says. “I don’t think it could be any worse. There’s been very little communication from the SEC, so there hasn’t been a strong incentive for folks to get it correct. It’s a cycle, and hopefully the SEC attention to this should start to break the cycle.”

“I think the data is pretty useful even as it is,” Ghai says [Pranav Ghai, co-founder of Calcbench]. “Obviously changes need to be made, but we can make great use of the data, and we do.”

While the data quality situation is certainly not great, it is far, far from a failure.  Currently 19% of all SEC XBRL financial filings I analyzed satisfy a set of 7 minimum criteria for making basic use of the information and 95% of all filers are 5 or fewer errors from meeting that criteria.

It will be interesting to see how many "All stars" I find for the 2014 SEC XBRL financial filings.

In his book Models. Behaving. Badly. the author Emanual Derman points out:

Theories discovered by great leaps of individual insight eventually become transformed into formulas anyone can learn.

Not that I think we are there yet, but we are getting closer. It takes hard work to master a model or create a theory.  A creator is attempting to discover the seemingly invisible principles that hide behind appearances. Theories don't simplify. Theories describe the principles by which the world operates. A theory is characterized by its intent: the discovery of essence.

Theories make things easier to understand.  Theories articulate rules that anyone can follow.

Rene van Egmond and I have been collaborating, trying to figure out how to properly apply XBRL to financial reporting since the very first XBRL International meeting in 1999.  Rene has a strong technical background, I have a strong financial reporting background. We both know people all around the world who know bits and pieces about XBRL.  We have both looked at this information attentively.  We have both looked at it closely.  We have both looked at it over, and over, and over. I was funded by UBmatrix to do nothing else but understand XBRL for over 12 years and took full advantage of that opportunity.  I worked with world class accountants on creating both the IFRS and US GAAP XBRL taxonomies. I was lucky.

Rene and I put our knowledge together to create the Financial Report Semantics and Dynamics Theory two years ago. We are in the process of updating that document, the update which is a work in progress is available here.  Suggestions, feedback, and other comments which lead to improving the document are greatly appreciated.

Nothing significant has really changed in this document. We are mainly honing and tuning. What is significant is that there are two commercial implementations which make use of the model of a financial report proposed by this document: Edgar Report Information web service of XBRL Cloud and SECXBRL.info of 28msec.

The most interesting of the two is SECXBRL.info because anyone can see the implementation for free because 28msec makes the DOW 30 information available for free. The XBRL Cloud implementation costs $9.95 per month to use.

Neither of these impelmentations provides a complete financial report model processor.  Both focus on the underlying information which is the first step. Both implementations are a big step in the right direction of providing real value to business users and prove the model.

Another important thing to understand is that the partial proof which was undertaken in the document has been repeated two more times and results are consistent with that first partial proof. Basically, SEC XBRL financial filings prove this theory.

"What?", you ask. "That seems to be a contradiction.  What good is the Financial Report Semantics and Dynamics Theory if SEC filings follow that theory but the quality of SEC filings is so poor?  How does that compute?"

Well, you can see what is going on if you have a look at the Digital Financial Reporting Principles document or if you look at the Understanding Minimum Processing Steps for Effective Use of SEC XBRL Financial Filing Information document which explains how to look at certain specific details of SEC XBRL financial filings.

Basically, this is a TWO step process, not a ONE step process.  You don't just blindly consider the SEC filing.  You must consider the filing itself and the CORRECTNESS of the thing that you are looking at in the filing.  The perfect example of what I am talking about is the part of the theory which says "Assets = Liabilities and equity" because I checked 100% of the population of SEC XBRL financial filings.

Let me walk you through this so that you are clear as to what I am saying.

First, I wanted to pick something which was absolutely uncontroversial and probably had the fewest errors so that I can test 100% of the population.  That is why I picked "Assets = Liabilities and equity".  The accounting equation. No rational accountant disputes this fact.

Second, you apply pure logic.  Nothing subjective, nothing which can be remotely disputed; logic and common sense.  Either an SEC filing's current balance sheet balances or it does not.  This is the process of seeing if the balance sheet balances:

1. You have to have the financial report with the information in it.
2. You have to figure out the accounting entity or "entity of focus" to use from the report.
3. You have to figure out what the current balance sheet date is of that report.
4. You want to get the correct concept(s), two concepts in this case, "Assets" and "Liabilities and equity" from the report.
5. You want to be sure that you don't get the wrong facts, the incorrect reporting scenario or some other aspect which you did not want.
6. You want to see if the two concepts have the same value, see if the balance sheet balances.
7. You repeat this process for 100% of the population of reports.

You perform those steps and you look at the results.  I have performed this task numerous time, here are the results for the last time.  On page 7 you see the results for this one test. 

Of 6,674 SEC filings, I was able to obtain 6,674 reports (#1). I was able to figure out the "entity of focus" for 6,622, all but 52 (#2). I manually looked at all 52 that I could not discover the entity of focus for.  Because of the process I was using, the error related to either not finding the entity of focus (#2), not being able to figure out the current balance sheet date (#3), or not being able to find the concept "Assets" or "Liabilities and Equity" (#4). Common errors included representing the entity of focus incorrectly, an inconsistent articulation of the balance sheet date, the wrong current balance sheet date, the filer incorrectly creating an extension concept for expressing "assets" or "liabilities and equity", or using the wrong concept from the US GAAP XBRL taxonomy such as "us-gaap:AssetsNet" to express "Assets".  Basically, every fact was accounted for and I could prove that they were correct or that they had an error.

For the 6,622 where the facts were found, I found the concept "assets" and I found the concept "liabilities and equity" and the two fact values were the same which is what I expected for 6,593. That left 29 filings where the balance sheet did not balance.  I looked at each of those manually and found that either the filer was using a "tolerance" (i.e. they had a small rounding error), they transposed numbers in their report, they provided the wrong fact in their XBRL which did not match the value in the HTML, or they simply make a mistake and their balance sheet did not balance.

And so, 100% of the set of filings was accounted for. Of the set, on ever occasion "assets" SHOULD have equaled "liabilities and equity" or it ACTUALLY DID.

My hypothesis was correct!  Balance sheets balance.

OK, so the logic seems to work.  Can the same logic be applied to other situations?  Well, turns out that there are plenty of situations where the logic can be applied.  First, all the things in the Financial Report Semantics and Dynamics Theory.  That is WHY those things were put into the theory, BECAUSE they apply.

How do I know these things apply?  Well, go read the FASB conceptual framework of financial reporting.  If that is too hard, the Wiley US GAAP guide and the intermediate accounting text book (a) explain the conceptual framework in terms which are a little easier to understand and (b) they are likewise consistent with the Financial Report Semantics and Dynamics Theory.

Digging in a little further, you see other logical and sensible situations articulated within the Digital Financial Reporting Principles document which you would always expect to be true. You can summarize this stuff and organize it into what I am calling a digital disclosure checklist.

Folks, this is stuff that accountants do today! Now, two things are going on.  First, external financial reporting managers are simply misapplying XBRL. Here is an uncontroversial example of that.  Can a fact be both a finite lived and an indefinite lived intangible asset at the same time?  Or course it cannot.  But that is exactly what this filer is saying in this disclosure. This has nothing to do with someone's opinion.  XBRL works in specified ways (i.e. the XBRL Specification is called a specification for a reason).  You don't get to make stuff up.  Besides, suppose you could just make stuff up.  How would that work for exchanging information?

Am I seeing things incorrectly? If I am, please enlighten me.  All Rene and I are trying to do is create the best, most elegant and well crafted work that we can.  Is there some more logical, rational approach which works and all those SEC XBRL financial filings are really right, it is just that no one understands how to interpret them?  Something else, some other theory? Some other model?

If someone knows about some other theory which explains what is going on, please enlighten us.  Alternatively, if you are looking for some way to wrap your head around what is going on with SEC XBRL financial filings, Rene and I hold out to be a model what works.  Leverage our formula. Our formula is proven by SEC XBRL financial filings themselves and by two commercial implementations of the base model.

Any ideas or other feedback to make this theory even better would be gladly accepted.

For 100 years or so financial reporting has been paper based. It was only in the last 25-30 years that financial reports been created electronically in a word processor and then printed or saved to an electronic format such as PDF or HTML.

During the age of paper, paper-based spreadsheets were used to summarize, aggregate, or other organize detailed information which made its way to the financial report. Electronic spreadsheets replaced paper-based spreadsheets.

External financial reports can be required to be provided to a regulator such as the Securities and Exchange Commission (SEC), such is the case for public companies.  Certain industries comply with the requirements of other regulators such as financial institutions provide financial information to the Federal Deposit Insurance Corporation (FDIC).

Private companies provide external financial statements to commercial lending institutions in support of commercial loans.  State and local governmental entities provide external financial statements to voters and to lenders who provide bonds and other financing.  Not-for-profit entities provide financial statements in support of federal grants.

The flip side of compliance with the rules and regulations related to external financial reports is noncompliance.  Noncompliance is a risk which is managed by those creating external financial reports.

Because, historically, external financial reports were unstructured; there was no other way to ensure compliance then by throwing humans at the problem.  Compliance involved humans doing lots of work.  Pretty much all the work really.

When information is structured something very significant changes.  While unstructured information is not understandable by machines such as computers; structured information can be understood. How much can be understood is dependent on the nature of the structure. The richer the structure, the more information that can be provided in machine readable form.  The more information provided in machine readable form, the more a machine can understand.

But the structure alone is not enough to provide much value to those creating external financial reports. When computer readable business rules that articulate information about the structured information, very interesting things start to happen.

As I said earlier, humans were the only way to make sure the information of unstructured external financial reports were in compliance (correct, complete, accurate, consistent).

When information is structured and when a rich set of business rules is created, some of the tasks associated with compliance can be moved from manual tasks performed by humans to automated tasks performed by machines.  How much which was manual can be automated?  That depends on the structure and on the business rules created.

Why turn manual processes into automated processes?  Why do auto makers use robots and other machines in the process of creating cars?  Automation can be cheaper than humans in many cases.  Machines make way fewer mistakes than humans when repetitive tasks are performed.  Machines are faster than humans. Machines are more consistent, tolerances are tighter, quality can be better in certain areas.

Can 100% of the process of creating an external financial report be automated and performed by machines?  No way.  There is a tremendous amount of professional judgment which is required to create an external financial report.  Tasks that require human judgment can never be automated.  However, there are repetitive, mindless tasks that are also part of the external financial report creation process.  Many of those tasks can be automated.

What are the benefits of successfully automating here-to-for manual tasks? This is the value proposition:

• Taking manual processes and automating those processes using structured information and machine readable business rules. This can save time, reduce costs, and improve quality.
• Taking complex tasks which require significant knowledge and reducing the knowledge which is required by having a machine assist the business user, supplementing that human's knowledge.
• Reducing the time needed to create an external financial report.
• Increasing the quality of the external business report by leveraging automation, thus reducing human error by reducing the tasks which humans perform.
• Reducing the risk of noncompliance.
• The discipline and rigor of defining the rules in machine readable form causes an increase in the clarity of the business rules articulated over the current approach of defining these business rules which tend to have gaps, inconsistencies, ambiguities, duplication, etc.

Now, if you take current processes, leave those processes in place, and then try and structure information after the fact it is very hard to grasp the value of structured information.  But if you totally reengineered the process of creating an external financial report, the value is easy to understand.

How many business rules are we talking about?  Many thousands potentially.  Sound overwhelming? Well, those business rules already exist.  They are organized in the brains of the humans who perform those manual processes.  A human gets sick, a human finds a new job, the knowledge leaves the organization.  Machine readable business rules becomes part of the organization's knowledge base and internal processes.  A significant amount of the value is the business rules themselves. Many of these business rules are documented, but documented in forms not readable by machines.

Business users are in control of the metadata and business rules, not IT departments. Applications are driven by models, metadata, and business rules.  Rather than IT departments hard coding rules which business users have to then rely on IT departments to change when the business environment changes; business users reconfigure metadata and change business rules to adapt systems to new business circumstances.  This is a new paradigm, machines driven by models and metadata controled by business users.

Business users will work with software which have financial disclosure models and financial disclosure processors. These software applications understand the structured information, metadata, and business rules.  The software does not force business users to deal with the underlying technologies. Complexity is hidden from business users by the models and processors.

Which technical syntax is used to structure information and articulate business rules is a secondary consideration.  Global standard technical syntaxes are better than proprietary technical syntaxes.  More expressive technical syntaxes are better than less expressive technical syntaxes.  Internet enabled structured information is better than non-Internet enabled structured information.

Pressing the "Save as XBRL..." button is of secondary consideration.  Whether the structured information is used for further analysis is a by product of properly creating the structured information.  Using the information for analysis has nothing to do with whether structured information has value in the creation process.

If value can be created in the process of creating external financial reports, it is highly likely that value can be created in other domains using the same or similar technologies and techniques.

But to realize this value the system needs to work.  The information created and exchanged to a consumer of the information must have the same meaning to both parties.  The system should be reliable and predictable.  Processes must be repeatable and safe.  This cannot be a guessing game if it is to be useful.

Achieving the value proposition is a choice. All the necessary technology exists.

The most amazing thing happened today. 

Someone pointed out Blockly to me. I created this in Blockly in just a matter of minutes:

(Click to go to Blockly project)

Here are some demo applications which make use of Blockly.

While I think Blockly is amazing, that is not the amazing thing that happened. The amazing thing is that the guy who told me about Blockly said that he heard about Blockly from the FASB! Someone named Andie.

Turns out that Andie is a data modeler and likes ontology:

Andie joined the IFRS XBRL team at the beginning of 2012 and is now a part of the wider Disclosure Initiative which looks at all things disclosure and taxonomy. She is a data modeler, XBRL expert and quite keen on Ontology. Average working days include anything from working on ways to improve extensions in XBRL, modeling IFRS standards, working with the Conceptual Framework team, analysis of IFRS disclosures and developing the future model and management of the IFRS Taxonomy. She manages the consistency of the taxonomy with XBRL specifications and is currently a member of the XII Taxonomy Architecture Task Force. In previous roles she has worked at Ernst & Young with their XBRL team, for Atos Origin working on the Banco de España XBRL project and in the dim mists of time at DecisionSoft/Corefiling. Andie has also plied her trade as a data modeler and XML consultant on a number of other projects involving no XBRL whatsoever! In her spare time she dabbles in data analysis, photography and archaeology none of which bear any relation to her degree in Biological Sciences from Oxford.

THIS IS AWESOME!

The most awesome thing about all this is that Andie is a data modeler and does not have an IT background.

What seems to have happened is that the people who created Scratch, which I pointed out on my blog back in 2009, helped Blockly get going or something.  Don't know, does not matter, it is just great that Blockly exists.  That should help people understand that all digital financial reporting does not have to be complex.