Digital Financial Reporting

This is what Niccolo Machiavelli said about creating new systems back in the 1500's.  Just as applicable today:

It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than a new system. For the initiator has the enmity of all who would profit by the preservation of the old institution and merely lukewarm defenders in those who gain by the new ones.

Niccolo Machiavelli

 Another version of the same quote:

It must be considered that there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things.  For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order, this lukewarmness arising partly from fear of their adversaries, who have the laws in their favour; and partly from the incredulity of mankind, who do not truly believe in anything new until they have had the actual experience of it.

Niccola Machiavelli

A new order of things for financial reporting has been arising.  The pieces are slowly falling into place.  The ability to structure information using the XBRL format is only one piece of the puzzle.  Here are other pieces as I see it:

• US GAAP: If US GAAP did not exist, digital financial reporting would not be possible because the necessary agreed upon standard financial reporting semantics would not exist.  US GAAP is that agreement and has been a work-in-progress for a hundred years.  IFRS is another effort to create standard financial reporting semantics.  IFRS was significantly influenced by US GAAP.
• Internet: Without the low-cost connectivity and standards of the Internet, digital financial reporting could never be possible.  My personal view is that "the Web" is not nearly as important as the internet.
• Machine-readable Version of Key Portions of US GAAP: The US GAAP XBRL Taxonomy is a machine-readable version of the portions of US GAAP necessary for digital financial reporting. The US GAAP XBRL Taxonomy is also readable by humans.
• Machine-readable Business Rules: Article 9 of The Business Rules Manifesto states that business rules are "Of, By, and For Business People, Not IT People". Article 9 has three important sub sections:
  • 9.1. Rules should arise from knowledgeable business people.
  • 9.2. Business people should have tools available to help them formulate, validate, and manage rules. 
  • 9.3. Business people should have tools available to help them verify business rules against each other for consistency.
• Software Tools that Understands Business Rules: You can have all the machine-readable business rules that you want; but if you don't have any machines to read the rules, the value of the rules is hard to understand.

More and more machine-readable business rules are becoming available.  For example, the Financial Report Ontology is a working prototype of some of those rules.  For example, the machine-readable information about financial statement disclosures (and human-readable) summarizes many common sense, logical, mathematical, and other obvious business rules.

To the extent that financial information is consistent with business rules, that financial information will be reusable by automated machine-based processes of all sorts.  Information which is not consistent with established business rules indicates inconsistencies within the system.

In a distributed system such as financial reporting where you have thousands and perhaps millions of financial reports being created by millions of reporting entities taking the time to create formal, standard, well-thought-out business rules to control the system is essential to making the system work correctly.

None of this happens by accident.  It takes intension, conscious effort, discipline, rigor, skillful execution, and persistence.  The result does not need to be complex, the system can be sophisticated and also simple and elegant.

This video is an excellent discussion of extensibility and what it takes to make extensibility work correctly.  One key takeaway is that all of the following needs to be addressed to make extensibility work:

• syntax
• vocabulary
• validity (validation)
• meaning (semantics)
• behavior

This is somewhat technical.

I stumbled across a new technical syntax which is very, very interesting: OData. This video provides a good explaination of what OData is and why it exists.  The synopsis is that OData is a web protocol (i.e. uses HTTP) for querying and updating data.  There are two formats: JSON and ATOM.  You can kind of think of it as a relational database on the web.

Here is an example of OData.  If you are familiar with Microsoft Access and the Northwind sample data, here is Northwind expressed as OData using the ATOM format: (this is best viewed in Google Chrome because you can see the XML)

• Database: This link is to "the database" itself.  It in essence lists the tables and queries which are contained in the database. It is a set of collections which are available.
• Customers: This is the "customers" collection or table.
• Regions: This is the "regions" collection or table.
• Products: This is the "products" collection or table.

I could do more, but you get the idea.

You can find additional information on OData on this blog.

What is the most interesting is this.  Recall the "regions" collection mentioned above.  Check this out.

So what is going on is this.  OData is a format readable by Tableau Public.  Why is this important?  The primary reason is that it allows you to create a LIVE DATA FEED!

I will show you more reasons this is important.  Stay tuned!

This is a test visualization I created using Tableau Public.  What I did was create a Tableau visualization, save it to Tableau Public, and then embed the visualization object into my blog entry.  This is a direct link to this prototype test visualization: (Shows information about the number of networks and the total reported facts of the Fortune 100 companies.  Also provides information about who the generator was)

Couple of things to note.

• It took me about 45 minutes to create this prototype, I have never used Tableau before.
• Tableau supports Excel, CSV, TXT, and some other formats but does not support XBRL directly.  You can convert XBRL to CSV, such as using the SECXBRL.info web service (here is an example)
• What Tableau seems to do is upload your data into their database.  Not sure if you can create visualizations which automatically update if data changes.  For example, it would be great if I could hook the Tableau visualization to the SECXBRL.info web service which provides information in the CSV format.
• Unfortunately, Tableau seems to be forcing OLAP on you similar to Excel pivot tables and other BI type applications.  Hopefully I am wrong, but that is what I see. On the other hand, they do have both measures and attributes.  So I could be wrong about this.  (Hopefully I am wrong)
• What I find incredibly interesting is that newspapers are embedding these dynamic visualizations into their news stories.  For example, check out this Seattle Times article. Here is another in the Sydney Morning Herald

What if information from a digital financial report could be worked with in this manner?  Imbed into analysis reports.  Drill down from analysis reports to the actual report (i.e. SEC XBRL financial filing).

Simple is not easy, simple is hard. 

"Simple" is not about doing simple things.  Simplicity is the ultimate sophistication. Make sophisticated things simple.

These are ideas, ideas which I try and live by, discussed in this presentation; Simplify Everything. Do Anything.

This prototype is my idea of simple.  It can be simplified even more.

Simple is elegant.