Digital Financial Reporting

You can now get a Neo4j database in the cloud for $.09 per hour of operation.  I am fiddling around with the graph database using my accounting knowledge graph examples.

Most accountants don't recognize this yet, but many of the current practices used for creating financial reports are obsolete.  It is true that a new paradigm has not yet been fully and completely worked out yet but that new paradigm is well on it's way.

Remember the good ole days when we used to create financial reports using clay tablets?

Accounting and reporting has moved beyond clay tablet first to papyrus then to paper.  In the 1970s and 1980s, paper was replaced by word processors and electronic spreadsheets.  Effectively "e-paper".  Now we are moving to digital.

Single entry ledgers were improved by using two synchronized ledgers (i.e. double entry accounting).  Double entry ledgers are about to be improved by adding a third synchronized ledger (i.e. triple entry accounting).

It is time for the next step in the evolution of accounting and the financial report.  No one can really say with certainty what the next step in this evolution will bring, but there are a few things that are certain. 

1. Some sort of change is inevitable.
2. Modern technologies exist that will be employed such as artificial intelligence, structured information, digital distributed ledgers, knowledge graphs, etc.
3. The same technologies that cause the problems of information overload and information complexity will be used to solve those same problems.
4. Standards will play a significant role. 

Here are a few prototypes that I have created that help accountants understand that change is inevitable and what these new accounting, reporting, auditing, and analysis tools might look like. 

• Pacioli, a Toolbox for Auditors: If an accountant cannot prove to themselves or to others that something like an XBRL-based financial report is (a) properly functioning and (b) conveying the meaning that is intended to be conveyed; then digital financial reporting is a non-starter. So, that tool for making sure financial reports are correct is fundamentally necessary.
• Pesseract, an Expert System for Creating Financial Reports: The creation of financial reports needs to be "self-service", meaning accountants need to be able to fundamentally create the reports.  Pesseract is a working proof of concept for creating XBRL-based digital financial reports. (If you are an accountant and want a license to try this software out, please contact me and I will send you a license good for one year.)  This free, open source tool can get you started with understanding digital financial reports.
• Financial Reporting Metadata: Without high-quality metadata, digital financial reporting is a non-starter because it would be impossible to (a) meet the demands of robust financial reporting schemes such as US GAAP, IFRS, and others and (b) make it impossible to create software applications that are easy enough for the average professional accountant to use.
• Proven, Best Practices based Framework and Method: Accounting, reporting, auditing, and analysis is complex.  If you read through the Essence of Accounting you will understand the specific complexities.  Per the law of conservation of complexity you cannot remove complexity from a system; however, you can move the complexity around.  Being smart and clever plus hiding complexity from end users can make XBRL-based digital financial reporting work effectively and be easy to use. Per the notion of irreducible complexity, you cannot simply remove something that is necessary from a system and expect that system to work effectively.  Removing complexity is not an alternative, but hiding complexity can work effectively.  My method shows you how to achieve this. My framework and method works effectively per implementations in four software applications: Logical Contract's Pacioli, XBRL Cloud's Evidence Package, XBRLQuery, and Pesseract which is a working proof of concept.

Here is an example of what is achievable.  Because of the mathematical foundations of double entry accounting it is particularly well suited to leveraging computers to achieve work.  And while it is the case that accounting, reporting, auditing, and analysis will be the first areas of knowledge to digitize because they are so well suited; they will not be the last.  Computational Professional Services is a real thing. Think electronic semantic spreadsheet.

Things are already changing; the signs are all around you if you look.  Be careful not to hold on to obsolete practices too long as that can reduce your value. Here is everything you need to master XBRL-based digital financial reporting.

Here are two very good FREE resources for understanding knowledge graphs and graph databases.  O'Reilly is publishing a book, Graph Databases, which can be downloaded for free.  It has a few ads from Neo4j at the very beginning.

Neo4j provides the Neo4j Sandbox which is a cloud-based graph database implementation that you can spin up in your web browser.  To get started with Neo4j you can watch this video (about 15 minutes) and/or work through this Neo4j tutorial.

There are plenty of other graph databases such as TigerGraph and Grakn.  Each has pros and cons.  I will use Neo4j to provide some examples for you.

The Neo4j syntax is Cypher.  Here is a Cypher example that you can load into Neo4j for the FASB's SFAC 6 Elements of Financial Statements. When you load the Cypher example, it will look something like this in Neo4j: (Click image for larger view)

As I pointed out, accounting is an area of knowledge that can be organized into a knowledge graph. There are principles for using knowledge graphs properly. The Cypher syntax is one approach to organizing and using this information.  XBRL is another.  Prolog is another.  You can convert bidirectionally between Cypher, XBRL, Prolog, and RDF+OWL+SHACL.

Here is my Logical Theory Describing Financial Report.  Here is the essence of that theory represented in Cypher syntax. When you put the Cypher into the Neo4j graph database sandbox, it will look like this: (click image for larger view)

Another view of the same information is this representation in Javascript. Here is that same information in the XBRL syntax. This is a human readable rendering of the XBRL.

XBRL is both machine-readable and can be easily converted to machine-readable.  XBRL syntax can be converted to the technical syntax of your choice.  What is consistent between all of these representations is the logic that is represented.

If you distill accounting down to its essence the importance and potential ramifications of all this becomes quite clear.  If you want to learn how to represent information using XBRL, here are the essentials. Here are a bunch of really good accounting related examples. Here is what you need to master XBRL-based digital financial reporting.

Don't be left behind.

As this O'Reilly article, Toward the next generation of programming tools, points out; software developers are used to bad tools.  Being able to use bad tools seems like some sort of hazing or right of passage necessary to become a computer programmer.

That is going to change.

Why does software for using XBRL have to be ugly, hard to use, and not produce a quality result that matches current quality levels of a financial report created using current processes?  Sure, the processes need to change in order to automate a significant portion of the currently far too manual processes.  But if the quality level is not maintained or improved, there is ZERO probability that modern approaches to accounting are going to be adopted. ZERO.

The point of accounting is to get things right. That is why two ledgers are used (i.e. double entry accounting) when one ledger could work but the probability of errors would increase.

Wired's article The End of Code helps you understand some of the possibilities.  The way I see it is that business professionals will configure logical rules and logic engines will do the work.

Around 1990 or so, I heard someone say that Microsoft Excel was the most used software development environment in the world. Using spreadsheet objects, Excel macros, and Visual Basic for Applications (VBA) people were building all sorts of software applications including full fledged accounting systems.

Per this article, Microsoft Excel Becomes a Programming Language, Microsoft is increasing Excel's power even more making it a true programming language. Apparently LAMBDA functions are being introduced making Excel Turing complete.  As I understand it, a LAMBDA function is an unnamed function that can be passed round to other functions and the function's logic able to be accessed. (Not really sure what that means frankly.)

Per the article, Excel has 750 million users around the world.  The article states, “Excel formulas are written by an order of magnitude more users than all the C, C++, C#, Java, and Python programmers in the world combined.”

Now, most accountants don't understand how to even write basic VBA; rather they stick to formulas and functions to get work done.  Average accountants likely will not create LAMBDA functions in Excel, but will more likely use LAMBDA functions or even function libraries created by others to get work done.

Ultimately, I believe Excel will suport "semantic spreadsheets" or essentially true multidimensional pivot tables that are grounded in logic rather than presentation oriented artifacts.

In the 1980s, the electronic spreadsheet put 400,000 accounting clerks out of work. But at the same time electronic spreadsheets also created 600,000 accounting jobs.  Over the coming years this scenario will likely play out again.  Repetitive data entry type work will disappear allowing higher value-added analysis type work to become cheaper to perform.  You just need to make sure you have the right skills.