Digital Financial Reporting

Here are a bunch of sample queries which work on SECXBRL.info.  These will work until May 31, 2015.  Queries are for noncommercial use.  Results are returned in HTML, but if you want results returned in XML, simply change format=html to format=xml.  You can change query parameters. Here is API documentation:

(NOTE that SECXBRL.info change the beginning of the URL to http://secxbrl.28.io/v1/ and the public token to c3049752-4d35-43da-82a2-f89f1b06f7a4  The queries need to be adjusted for those two changes.

1. Get facts from the a specific network from a specific report: execute.
2. Get facts from a specific component by specifying the disclosure name from a specific report: execute.
3. Get fact from a specific CIK, a specific fiscal period, a specific fiscal year: execute.
4. Get facts whose concept is revenues from all the entities which make up the DOW 30 for fiscal year 2014 and break those results out by geographic area: execute.
5. Get facts whose concept is assets from a single entity with a specific CIK number for fiscal year 2012 and break that information down by business segment: execute.
6. Get facts whose concept is assets from every entity in the DOW 30 for fiscal year 2014 and break that information out by business segment: execute.
7. Get facts whose concept is goodwill from every entity in the FORTUNE 100 for all fiscal years available and break out that information by business segment: execute.
8. Get facts whose concept is PropertyPlantAndEquipmentNet from every entity in the FORTUNE 100 for fiscal year 2014 and break the information out by property, plant and equipment type: execute.
9. Get facts whose conept is assets for an entity with a specific CIK for Q1, Q2, and Q3 of fiscal year 2014 and break the information out by legal entity and business segment: execute.
10. Get facts whose concept is assets for an entity with a specific CIK for all fiscal years and break the information out by reporting scenario: execute.
11. Get facts whose concept is assets for the entities which make up the S&P 500 for all fiscal years and break them out by reporting scenario: execute.
12. Get facts whose concept is us-gaap:ProvedUndevelopedReserveVolume from the entities which make up the S&P 500 for all fiscal years available and break that information out by type of reserve: execute.
13. Get facts whose concept is us-gaap:Goodwill for the entity with the CIK 66740 for fiscal year 2012 and break that information out by business segment: execute.
14. Get facts whose concept maps to the fundamental accounting concept fac:ResearchAndDevelopment for all the entities which make up the DOW 30 for fiscal year 2014: execute. (By looking at the XML format you can see the actual US GAAP XBRL Taxonomy concept which was used by each entity.)
15. Get a specific fact but explicitly specify the legal entity dimension: execute.
16. Get a specific fact but explicitly specify that all legal entities be returned: execute.
17. Get facts whose concept is assets for a specific CIK for Q1, Q2, Q3, and FY 2014 and break the information out by business segment: execute.
18. Get facts whose concept is assets for a specific CIK for Q1 fiscal year 2014 and break out by business sgement: execute.
19. Get year-to-date Q1 2014 revenues for the S&P 500 broken out by business segment: execute.
20. Get facts for text block nature of operations for the DOW 30 for 2014 trying numerous different concepts: execute.
21. Get facts whose concept is assets for S&P 500 for 2014 and breakdown assets by business segment if the entity reports business segments: execute.
22. Get facts using the ticker symbol: execute.
23. Get facts for two concepts: execute.
24. Get facts for revenues using mapping: execute. (this XML file lets you see what concept was used to report revenues)
25. Get all the fundamental accounting concepts for Coca Cola: execute.
26. Get all the funcamental accounting concepts for Coca Cola for two periods: execute.
27. Get all the fundamental accounting concepts for the DOW 30 for 2014: execute.

 You can learn more about queries here by experimenting with the DOW 30.

Computer science is, well, science.  Getting a computer to successfully perform work has little or nothing to do with emotion, theological dogma, personal opinion, or such.  (Although, when you are creating a standard some of the discussions can be emotional, theological, and filled with personal opinion.)

Zeroing in on the Holy Grail of Meaningful Information Exchange summarizes what I have learned and discovered while trying to make digital financial reporting work appropriately.  My document was inspired by the introduction to the document Ontology for the Twenty First Century: An Introduction with Recommendations.  That document tends to be more oriented to scientific domains.  My document tries to explain the same ideas to business professionals.

Here are the bullet points:

• Computers have three strengths
  • Information storage
  • Information retrieval and processing
  • Ubiquitous information distribution
• Computers can be harnessed to perform certain work effectively, if done correctly
• There are major obstacles to harnessing the power of computers
  • Business professional idiosyncrasies
  • Information technology idiosyncrasies
  • Inconsistent domain understanding of and technology's limitation in expressing interconnections
  • Computers are dumb beasts
• Computers are tools
• Ontologies are tools
  • Philosophy has used ontologies for 2000+ years (not machine-readable)
  • Computer science now leverage ontologies (machine-readable)
• Knowledge engineering is, well, engineering
• Technical syntax matters, but not that much
• Software must be usable by business professionals because they own the problem domains
• The holy grail of meaningful information exchange is...

Deliberate, rigorous, clear, logically coherent, consistent, and unambiguous ontologies created by business professionals can make dumb beasts appear to perform magic.

The US GAAP XBRL Taxonomy is more than just something used for creating XBRL-based financial reports for submission to the SEC.  Both public and private companies can benefit from the US GAAP XBRL Taxonomy.

There is a difference between alternatives and ambiguity.  I look at this difference in the resource Differentiating Alternatives from Ambiguity.  I also point out how the structured nature of XBRL-based financial reports helps machines assist humans in increasing clarity, logical coherence, consistency, and reducing ambiguity.

In the financial reporting world we can live with clear, known alternatives or options.  Professional accountants use their judgment to pick and choose amongst those known alternatives or options; applying what they consider the best alternative given all available alternatives or options.  Exercising professional judgment is and should be part of financial reporting.

What financial reporting cannot live with are diverse interpretations which result in different results based on the exact same facts due to standard definitions and principles that are vague, inconsistent, logically incoherent, and ambiguous.  A different understanding of the exact same facts is not judgement; it is lack of clarity, lack of consistency, lack of coherence, and ambiguity.  You can have different interpretations of facts, that is judgment.

The vagueness, inconsistencies, logically incoherent, and ambiguities in the definitions and principles used in financial reporting standards are not alternatives or options; they are unintended errors in the standards.

Working with and creating XBRL-based financial reports of public companies revealed the following:

• ASC inconsistencies and conflicts in segmentation of an economic entity.
• Lots of variability in where the line item Income (loss) from equity method investments is reporting on the income statement.
• Two different ways to compute net cash flow.

Are these conscious alternatives designed into US GAAP or the result of errors in financial reporting standards?  Decide for yourself.

Machine readable ontologies such as the US GAAP XBRL Taxonomy will highly likely result in higher quality financial reporting standards because the machines can help humans create clear, consistent, logically coherent, and unambiguous standards.

Like anything else created by humans; accounting standards can be vague, inconsistent, and ambiguous unless care, discipline, and rigor are used to clearly, accurately, and precisely express the true intent of those standards.  This includes both US GAAP and IFRS accounting standards.

When humans try and describe complicated things such as accounting standards in books it is easy to inadvertently make mistakes which contribute to vagueness, inconsistencies, and ambiguities because the only way to check what you have written is manually using humans.  But when one uses machine-readable formats to express such information then machines can be used to check to make sure there is no vagueness, inconsistencies, or ambiguities.

While it is unlikely that all vagueness, inconsistencies, and ambiguities could ever all be removed; they certainly can be reduced if good tools are leveraged.

The paper, An analysis of fundamental concepts in the conceptual framework using ontology technologies, written by Marthinus Cornelius Gerber, Aurona Jacoba Gerber, Alta van der Merwe point out how tools such as ontologies and reasoners can be used to improve financial reporting standards.  Here is the abstract of that paper:

The interpretation of financial data obtained from the accounting process for reporting purposes is regulated by financial accounting standards (FAS). The history and mechanisms used for the development of 'The Conceptual Framework for Financial Reporting’ (the Conceptual Framework) as well as the financial accounting standards resulted in impressive volumes of material that guides modern financial reporting practices, but unfortunately, as is often the case with textual manuscripts, it contains descriptions that are vague, inconsistent or ambiguous. As part of the on-going initiatives to improve International Financial Reporting Standards (IFRS), the International Accounting Standards Board (IASB) promotes the development of principle-based IFRS, which aim to address the problems of vagueness, inconsistency and ambiguity.

This paper reports on the findings of a design science research (DSR) project that, as artefact, developed a first version ontology-based formal language representing the definitions of asset, liability and equity (the fundamental elements of the statement of financial position as defined in the Conceptual Framework) through the application of knowledge representation (ontology) techniques as used within computing. We suggest that this artefact may assist with addressing vagueness, inconsistencies and ambiguities within the definitions of the Conceptual Framework. Based on our findings, we include suggestions for the further development of a formal language and approach to assist the formulation of the Conceptual Framework. The project focuses on the Conceptual Framework for Financial Reporting after the incorporation of Phase A in the convergence project between the Financial Accounting Standards Board (FASB) and IASB.

While it is true that things such as machine-readable ontologies and reasoners can be used to reduce vagueness, inconsistency, and ambiguity from the financial reporting conceptual framework; they can also be used to make sure that financial reports are created consistent to that conceptual framework.

The machine-readable business rules expressed within an ontology both describe some problem domain such as that of financial reporting and check to see if financial reports are created consistent with that description.  The utility of machine-readable business rules does not make a lot of sense if you think about the paper-based or unstructured financial reports created for the past hundred years.

However, when you think about digital financial reports such as XBRL-based public company financial reports submitted to the SEC which are structured and therefore machine-readable; the utility of machine-readable business rules makes far more sense.

Professional accountants use many tools which are only readable by humans.  A good example is the disclosure checklist, a memory jogger used in the process of creating financial reports.

As the authors of the document point out, in the accounting world we can live with clear, known alternatives and professional judgment to pick and choose amongst those known alternatives; applying the best alternative all things considered.  What we cannot live with is diverse interpretations with different results based on the "same definitions and principles" which are really caused by vagueness, inconsistencies, and ambiguities in the definitions and principles.

Digital is not software, it is a mindset. Digital financial reporting is closer than you might think.  Never heard of the term "ontology"? Smart professional accountants are improving their knowlege engineering skills.

Things are getting clearer and clearer.  I have had the graphic below which compares the expressive power of different technical syntax.  The expressive power of a technical syntax is important because to the extent that some machine-readable technical syntax can be used to describe some problem domain; it is to that same extent that the machine-readable technical syntax can confirm consistency with that problem domain.

To say this another way: description of the problem domain and verification that things expressed are consistent with the description of that problem domain are two sides of the same coin. This may not seem important until you remember that:

The only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax rules, business domain semantics rules, and workflow/process rules.

(Click image for larger view)

So one of the aspects I have been confused about is what is shown in this second graphic below.  The outer circle represents two ideas: (a) All the "things" and "relations between things" that need to be expressed so that digital financial reporting can work effectively; (b) the fact that some of the "things" and "relations between things" need to interact with other machine-readable problem domains.  Basically, the outer circle represents the theoretically possible goal of what is required.

But machines, such as computers, that humans build are never perfect.  You are limited by the available technology which can be used to build the tool. The next circle represents what is currently available as the most powerful and appropriate tool for expressing the "things and relations between things" expressible by the tool finite first-order logic.

Now, this is still a little bit confusing to me.  I am not exactly sure what term I should be using here.  I use finite first-order logic, as contrast to infinite first-order logic for a specific reason.  "Infinite" systems cannot be expressed and they tend to not work predictably and they can have unforeseen blowups.  That is not desirable.

What is desirable is a system that is safe, predictable, reliable, repeatable and therefore a dependable tool.  Someone described this as "expressive power must be useful-yet-harmless". Another important thing is that we need maximum expressivity (that goes furthest towards meeting our data-collection needs) without sacrificing the quality referred to as decidability. The system must be "decidable".

While I used the term finite first-order logic I have heard others use terms such as: Description Logic which seems to be a subset of first-order logic; mathematical model or model theory; predicate logic; propositional calculus; and for good measure I will throw in simply logic.  I see all of these things as being more similar than being different.  The key here is that you can describe the real world by creating a theory, expressing that theory using a set of logical axioms, and you can prove that theory using formal logic.

Ultimately, anything that is created to express the "things and relations between things" of a problem domain must be put into machine-readable form.  That requires a syntax that a machine can read.  If you go back to the first graphic, you see two technical syntaxes at the top of the list: XBRL and RDF/OWL.

I have tried and tried to get both XBRL and RDF/OWL to express 100% of what is needed to be expressed for the problem domain of financial reporting.  Each technical syntax has a set of pros and cons.  Each technical syntax is capable of expressing 100% of what would need to be expressed, it seems.  However, neither expresses 100% of what is needed right now.  Does one syntax have an advantage over the other currently?  Well, because XBRL supports dimensions and mathematical computations and OWL does not; I would give XBRL an advantage.  Or said another way, the "path" to what is necessary seems shortest using XBRL rather than RDF/OWL.

(Click image for larger view)

The bottom line:  Frankly, I really cannot tell which technical syntax is the best syntax.  What I can say is that since XBRL-based financial filings is what is required by the SEC right now, one must eventually get the information into that syntax.

In terms of expressing the "things" and the "relations between the things", I find the document Ontology for the Twenty First Century: An Introduction with Recommendations hands down the most comprehensive resource for explaining that.  That document is organized nicely into "layers" that you can work through. Most business professionals will never be able to understand that information in the manner that it is articulated in that document.  What will happen is that the important pieces will be combined into a set of building blocks, encapsulated within significantly easier to use software, and then business professionals will use that software.

This is a bit of a leap, but there are three examples of easy to use software which shows the possibilities:

• Blockly: Many people might not get what I am saying, but think "Legos".
• Scratch: Again, that is a bit abstract but keep "Legos" in your mind and watch the video in the upper right hand corner.
• Quantrix: Watch as many videos that you can, but don't miss the Quantrix Key Concepts video.

And this document describes those "Lego" blocks.  Some accounting professionals need to understand basic knowledge engineering principles.  They will help software vendors build the right tools.

It is becoming increasingly obvious that the way to simple, elegant, and easy to use digital financial reporting is a clear, consistent, logically coherent, rigorous, and well-thought-out formal description of the things and relations between things to the extent that they can be described by finite first-order logic.  Most of what is necessary to express these things and relations between things is already available.  Proof of that is my ability to detect inconsistencies with the descriptions that I created.  The pieces which make up digital financial reporting must be created with high intension, specific conscious effort, well-thought-out direction, making specific conscious choices, and skillful execution by professionals with resolve to achieve that goal.

But I am just one certified public accountant from Tacoma, Washington.  It will take collaboration and cooperation to build the control mechanisms necessary to get all public companies, financial analysts, software vendors, filing agents, the FASB, the SEC, data aggregators, and others in the financial reporting supply chain completely on the same page.  Once digital financial reporting works for public companies, then private companies might start looking at XBRL-based digital financial reporting.

I do know that financial reporting is leading the way to the vision of what many people refer to as the semantic web. Digital is the future.  It is getting increasingly risky for accounting professionals who do not recognize this.