Digital Financial Reporting

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.