Digital Financial Reporting

A digital financial report is a finite set of structural "things" or "entities" and relations between those things/entities.  To be clear let me say that I am talking about the mechanical aspects of a digital financial report.  These mechanical aspects are distinct from the subjective or judgmental aspects of a financial report. These subjective/judgmental aspects have to do with which things or entities exist in the report, some aspects of the values of those things/entities, how the values are measured, and so forth.

Global standard languages, such as XBRL, describe these things/entities.  XBRL is not the only global standard which can be used.  OWL 2 DL is also a global standard which can describe these things/entities and relations between them.  If you want to get a feel for the issues involved with describing these things/entities and relations between them, see this excellent document.

There are many global standard languages for describing such things/entities and the relations between them.  There are two things that all of these global standards have: some syntax for expressing such information and some set of semantics which provides the expressive power of the global standard language.

First-order logic can be used to express a theory which fully and categorically describes structures of a finite domain (problem domain).  This is achieved by specifying the things of the problem domain and the relations between those things.  A theory is simply a system of ideas which is intended to explain something.  For example, Financial Report Semantics and Dynamics Theory is a theory that explains how a financial report works. A theory is simply a communications tool.

No first-order theory has the strength to describe an infinite domain.  Essentially what this means is that the things and the relations between things which make up a problem domain must have distinct boundaries.

This is not to say that such a system cannot be flexible.  For example, a form is not flexible.  A financial report is not a form.  This is not to say, however, that a financial report cannot be finite.

While a form is finite but inflexible, a financial report is finite and flexible.  The difference is the notion of a "slot" or "opening".

A slot is simply an allotted place in an arrangement where something can be logically and sensibly placed.

For example, suppose you wanted to add something to a roll up of property, plant and equipment as shown below:

• Land             1000
• Buildings       2000
• Furniture         500
• Total PPE     3500

You cannot add a second total to a roll up as a roll up only has one total.  What makes sense is to add another line item to the total of the roll up, somewhere in the list of existing line items.  One slot is adding a line item between "Buildings" and "Furniture".  Another slot is adding a line item before the first item "Land" or after the last item "Furniture".

Further, whatyou add to the list is also constrained.  For example, what you add needs to be a number as a roll up involves showing how some list of numbers roll up.  You would not add text.  And it cannot be just any number, it needs to be an "as of" type number (as contrast to a "for the period" number from, say, the income statement).  Why?  Because all of the other numbers in the list are "as of" some balance sheet date, not "for the period" of some income statement or cash flow statement period.

A financial report is finite in the sense that it is made up of exactly the following structural pieces or things (which can be referred to as classes) which have different types of slots:

• Economic/accounting entity which creates report
• Report which contain a set of components
• Component which contains or group sets of facts
• Characteristics which describe and distinguish facts contained within a component
• Blocks which are parts of a component (sub-groups of facts, for example, the disclosure Funding Status of Defined Benefit Plans is made up of two roll forwards, a roll up, and a hierarchy each of which is a block of the component)
• Relations pattern which can be either a "whole-part" type relation, an "is-a" type relation, a concept arrangement pattern, or a business rule which describes relations
• Concept characteristic-type relations which can be a "roll up", a "roll forward", an "adjustment", or a "hierarchy"
• Properties of an economic/accounting entity, report, component, block, fact, characteristic, or relation pattern

The structural pieces or things/entities of a financial report can be grouped into classes.  No new classes can be added.  Classes may never be redefined.  However, subclasses can be added and identified as being associated with one of those existing classes of things/entities.  But added subclasses can only be added as specified by the system, for example XBRL-based financial filings.  For example,

• Adding new economic/accounting entities: An economic/accounting or reporting entity is created by creating a new instance of identifier, the CIK number of a public company.
• Adding new report:  A new report is created by creating a new report instance.
• Adding a new characteristic: A new characteristic can be added, if a system allows, but the characteristic MUST be distinguished as being either a "whole-part" or "is-a" type of relation or some existing subclass of existing relations (which must be one of those two).
• Adding new concept characteristic: A new concept can be added to a balance sheet such as "Ultra-tangible asset", however it MUST NOT break the rules of a "roll up" because a balance sheet is a roll up. When the new concept is added, it MUST be identified as a subclass of something that exists on a balance sheet which can contain ONLY assets, liabilities, or equity.
• Adding new disclosure (component or block):  A disclosure is in essence a set of facts which must be disclosed.  A set of facts is represented as a component.  To add a new disclosure, a reporting entity simply creates a new component and/or block.  The added component MUST be one of the existing relations patterns (i.e. no new patterns can be added).  That newly created component is identified as a subclass of an existing disclosure if that is appropriate, or creates a totally new root disclosure class by creating a subclass of the class "component".  A reporting scheme may, or may not allow the addition of completely new disclosures; rather some schemes might require a disclosure to be a subclass of some existing disclosure for one reason or another.
• Adding new properties: New properties MUST NOT be added, XBRL-based financial filings to the SEC does not allow the addition of new properties, there is no "slot" available.

Different systems can have different rules for allowing new classes, subclasses, relations between classes, or properties. System boundaries can be extended by adding new relation patterns.  New relation patterns must be consciously and formally added in a controlled and coordinated manner only by system implementers before they are allowed to be used.  System boundaries can be extended by adding new classes or properties.  New classes and new properties must be consciously and formally added in a controlled and coordinated manner only.

As an example, consider these report frames.  Every public company can be grouped into one of 95 report frames.  Are some of those report frames illegal?  If so, take the report frame off the list.  Does some public company have a report frame which is not on the list?  Then add the report frame and instead of having 95, there are 96 report frames.

Every other class works precisely the same way.  And so, the system is finite, the system has boundaries, but the system is flexible but only where specific flexiblity is exposed.

That is a slot.

If you want to get a peak at where financial reporting is headed, take a look at the Fluent Editor.  You have to use your imagination a little, but if you play with that tool for a while it will likely change the way you think about XBRL.

Another important thing to remember is that Fluent is a general purpose tool rather than a specific use tool.  That is important to understand because if you realize that, then you can understand that a tool specific to financial reporting can be an order of magnitude easier to use.  This is because rather than handing the general needs of everyone, a special purpose tool is focused on financial reporting only.

(Click image for larger view)

Fluent Editor is an ontology editor.  In the XBRL world, they use the term "XBRL taxonomy". But don't be fooled by the terms.  The interesting thing about Fluent is that rather than editing using the syntax of the language you are using, the user edits using controlled natural language.

This YouTube video shows the Fluent Editor in use.

A controlled natural language is a subset of natural language which uses restricted grammar and vocabulary in order to reduce (or eliminate) ambiguity and complexity. The user of the application works with what looks like English language sentences.  I was able to do more in one day than I could in six months trying to figure out an OWL editor!  Literally.

There is one thing that Fluent makes crystal clear for those who still don't grasp that syntax really does not matter.  Take a look at the following:

• Fluent syntax:  This is an HTML printout of what the application user works with. This is the actual syntax stored in the native format of the application.
• RDF/OWL syntax: This is the RDF/OWL that you get when you export or save the information to a global standard format.
• OWL/XML syntax: And here is the OWL/XML format.

All three of those files say EXACTLY the same thing.  They are 100% interchangeable.  Really.

Syntax does not matter.

What if you could edit XBRL taxonomies in that manner, using natural English sentences.  But rather than using general sentences (i.e. OWL can be used to represent things in many, many different domains so the tool is very flexible), you used an even more restrictive syntax which applies ONLY to financial reporting?

What does that get you? Ease of use. The more flexibility and options that you have, the harder things are to use.  Clearly you need the RIGHT flexibility and options.

So think of financial reports. In the past the financial reports have been unstructured text.  Today, because of XBRL, financial reports are structured.  That is the role that XBRL provides, the structure of the information so that the pieces of information can be read by a machine.  But XBRL knows nothing about financial reporting.  But what if you explained financial reporting in terms that a machine (such as a computer) can understand.  That is what the Financial Report Semantics and Dynamics Theory does. What a machine needs to know are the "things" you are working with and the "relations between the things".  You then convert that information (the things and the relations between the things) into a technical syntax, preferably a global-standard technical syntax, and then the computer can do useful things for us humans.  The machines can automate tasks which had to be performed manually before because the information was unstructured (and unreadable by machines).

This document, From SHIQ and RDF to OWL: The Making of a Web Ontology Language, seems really technical but if you wade through it, it really is not that hard to understand the key ideas it is communicating. There are two primary points which that paper makes:

1. Some really smart people are consciously working very hard and are very directed to solve a very specific problem: safe to use machine-readable semantics.
2. OWL 2 DL + a safe subset of SWRL is that "base" set of machine-readable semantics.

All this is NOT to say that business professionals will be dealing directly with all these technical things.  As the controlled natural language that I started with in this blog post shows, all this can be distilled down to easier to interact with human interfaces.  Complexity will be beat into submission.  Market competition will see to that.

XBRL will evolve and converge with the functionality of OWL 2 DL + a safe subset of SWRL.  What I do not understand is how XBRL Dimensions and XBRL Formula fits into this equation.  One important thing to understand is that OWL 2 DL does not do math.  XBRL, however, does do math via XBRL calculations and XBRL Formula.  XBRL Dimensions provides higher-level functionality that RDF/OWL needs.  Proof of that is the effort of the Government Linked Data to build their Data Cube vocabulary.  This is now a W3C recommendation.  That makes it clear that (a) data cubes are desired and (b) OWL does not have that functionality "out of the box" (i.e. it has be be constructed).  I don't understand how compatible XBRL Dimensions and the W3C RDF Data Cube are.

What does all this mean?  Digital financial reporting is coming to the masses.  Public companies filing to the SEC in the XBRL format are providing the important detailed information as to how to make digital financial reporting work correctly.  We are not there yet.  But things are improving and becoming easier.

Who will be the software vendor that provides the killer app which will make professional accountants to want to leverage structured information?  Time will reveal the answer to that question.

That is all I will say right now.  Stay tuned for more information!

Here are several additional and improved working prototypes that I created in order to communicate some things to people.  You can expect this sort of functionality in commercial software eventually.  If you use a little imagination you can start to see the possibilities structured information enables.

All of these prototypes relate to disclosures and examples of disclosures which appear in financial reports. The prototypes were created in order to test metadata and communicate ideas to software vendors:

1. Disclosure viewer: A financial report is a set of disclosures provided by an economic entity.  This is a list of about 1000 such disclosures which might appear in a financial report.
2. Understanding Concept Arrangement Patterns: Each disclosure can be categorized into what I call a "concept arrangement pattern".  These are the concept arrangement patterns:
   1. Roll Up: A + B + C + N = Total
   2. Roll Forward: Beginning balance + Changes = Ending Balance
   3. Adjustment: Originally stated balance + Adjustments = Restated balance
   4. Hierarchy: Concepts are related, but not mathematical.
   5. Text Block (Level 1 Note): A Level 1 Text Block is something that the SEC specifies that public companies provide.  Basically, an entire note is provided within a Level 1 Text Block.
3. Understanding Relation Between Level 3 Disclosure Text Block and Level 4 Detail Disclosure: Public companies are required to provide a Level 3 Text Block and Level 4 Detail for each disclosure.

If you have any ideas of additional demos and prototypes please send me an email.