Digital Financial Reporting

A Wired article asks the question, How Many Spreadsheets Does It Take to Run a Fortune 500 Company? The article points out that companies rely on spreadsheets to fill gaps in company systems.  The article asks the question, "Does it work?"

I say a better question is, "Is there a better way?"  Personally, I think there is a better way.  Here is a collection of blog posts related to spreadsheets:

• Great Video about the Issues with Spreadsheets
• Need for a Global Standard Spreadsheet Alternative
• Time for a New Take on the Electronic Spreadsheet
• Semantic Spreadsheet
• Updated Vision of the System
• Radically Tailorable Tool
• End-user Computing: Business Users Building Software

This is the key point in that Wired article:

The problem is that we always build enterprise software by starting with a static data model or an object model, and then we're surprised when the resulting systems are inflexible. What if we took different approach? What if we turned the problem upside down? Instead of a static data model, we build services around a Modeling Engine that is purpose built to change dynamically.

What I am calling a semantic spreadsheet is not totally flexible like an electronic spreadsheet.  It is flexible exactly where you need flexibility, but no where else. For example, if you tried to express a balance sheet in an Excel spreadsheet you can absolutely create a balance sheet because you have 100% control, to the extent that Microsoft Excel has features, therefore you have that same level of flexibility. 

But that is not what a business user needs to create a balance sheet.  Business uses don't need infinite flexibility to mask the reality that the electronic spreadsheet does not understand balance sheets, what business users need is for the application to understand balance sheets!  The spreadsheet needs to understand that a balance sheet has "assets", it has "liabilities", it has "equity", that "assets = liabilities + equity", that assets can be current and noncurrent, and that property, plant and equipment is a noncurrent asset.

The business user interacts with the balance sheet model, not the raw electronic spreadsheet model.  The raw electronic spreadsheet model knows nothing about balance sheets, that causes the following: (a) the user of the electronic spreadsheet needs to know more about balance sheets and (b) the electronic spreadsheet has to be overly flexible because it does not understand what you can and cannot do when you create a balance sheet.

How the heck do you get an application to understand a balance sheet?  Machine readable metadata.  You define "things" such as assets, liabilities, equity, current assets, noncurrent assets, etc.  You define "relations between things" such as "assets = liabilities + equity".  You do this for every disclosure.

Sound like a lot of work?  It is a lot of work.  The US GAAP XBRL Taxonomy is a huge step in this direction.  But what is even better is all the balance sheets and other disclosures submitted to the SEC by public companies in the form of digital financial reports.  I don't want to go into details here, just know that it is not as much work as it might seem.

First, it is create once, use many times.  Second, it is way more effective and efficient for a computer to manage as much of this complex process as possible rather than rely on humans who make mistakes, who change jobs, and who are expensive.  Humans will certainly be necessary, but machines will be able to assist humans.

So you will not only be working with a modeling engine, you will be working with a financial report modeling engine.  Don't understand all this?  Go read the Financial Report Semantics and Dynamics Theory. That proves that SEC XBRL financial filings fit into a model.

There will be other types of modeling engines: not-for-profit financial report modeling engine, state and local governmental financial report modeling engine, pension plan financial report modeling engine, expense report modeling engine, purchase order modeling engine, and so forth.  Purpose built and specific driven by machine readable metadata, not infinitely flexible electronic spreadsheets.

Think of this as radically tailorable software, business users configuring software using metadata.