BLOG: Digital Financial Reporting
This is a blog for information relating to digital financial reporting. This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting. This is my brain storming platform. This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.
Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.
Entries from September 1, 2021 - September 30, 2021
Can Bitcoin style validation solve financial statement fraud?
An article, Can Bitcoin style validation solve financial statement fraud?, has an excellent graphic provided by Auditchain that helps one understand the importance of NFTs. Here is that graphic:
I explained NFTs basics in another blog post. I point out the importance of process control in my method. Think modern accounting processes. Think about the notion of a financial report as a knowledge graph. Think "always on" audit as Engine B calls it or the "dynamic audit initiative" as the AICPA calls it. Think about ideas like Imagineering Audit 4.0 and the mirror worlds they discuss. Think about artificial intelligence assisted audits.
Think about how poorly current audit is performing.
Is traditional audit doomed?




JSON Viewer
I ran across an interesting and useful tool today, a JSON Viewer.
To try this tool out, have a look at this by clicking on it. That will open a JSON file that was provided within the JSON viewer. Click on the "Viewer" tab and have a look.
That JSON information was created by the Pacioli logic/rules/reasoning engine. The XBRL-based report that was used to generate that JSON was this PROOF report. Pacioli took the XBRL instance, XBRL taxonomy, all the rules used to verify the report and generated this file. The file itself is not like an XML file that can expand and collapse because of a stylesheet supported by most browsers. (Like this)
Now, the JSON provided is not financial report logic based, it is XBRL technical syntax based for the most part. So that file itself is not particularly useful. One day I will get the information I want if I have to create it myself.
But, this does give me an idea! Stay tuned.
Here are some other JSON Viewers:




The GQL Manifesto
The GQL Manifesto is an international effort to create an industry standard graph query language (GQL).
SQL, or structured query language, is a declarative language that one of the key underpinnings of modern information technology. SQL is the way one interfaces with a relational database management system (RDBMS) which is used to store data. One of my personal favorite tools that I have made use of during my entire career as an accountant has been Microsoft Access and Microsoft SQL Server.
The international effort to create GQL is an industry attempt to create a similar industry standard for graph databases. It is highly likely that this effort will be successful and GQL will very likely become an ISO standard GQL.
What would be incredible in my view is if Microsoft were to create a product similar to Microsoft Access or if they were to enhance Microsoft Access to support GQL. Having this as part of the Microsoft Office suite of products would be a very good thing in my view.
The book Graph Databases that is published by Neo4j provides an excellent explanation of the fundamental difference between a graph database and a relational database. See Chapter 2, Options for Storing Connected Data, page 11 which is PDF page 29. Here is my attempt to explain that difference.
In a relational database, information about relationships is not part of the actual relational model. In a graph database, information about relationships is fundamentally part of the information model.
That statement might seem odd. But it is true. Relationships are not "first class citizens" in relational databases, but they are in graph databases. Now, you can absolutely express relationships and even the meaning of relationships in relational databases. But, you have to do it in the database itself, you cannot do it as part of the database schema. In a graph database the relationship information is part of the schema rather than added into the data.
Graph databases are fundamentally more powerful that relational databases.




The Accountant Quits
The Accountant Quits is a blog and podcast related to accountants and change. This is worth checking out.




Algorithmic Business Thinking
Algorithmic Business Thinking (ABT) is an idea created by MIT that helps business professionals and computer professionals communicate. This video, Algorithmic Business Thinking with Paul McDonagh-Smith, discusses ABT.
I get the impression that Algorithmic Business Thinking builds on Computational Thinking. That is mentioned a couple of times. ABT is important as we transition from the industrial economy into the digital economy, we are in the fourth industrial revolution now.
The following are the four cornerstones of ABT:
- Decomposition: Taking larger problems or challenges and breaking them down into a series of smaller problems or challenges that are easier to manage and solve.
- Pattern recognition: Rather than trying to build everything from scratch, use things that you have done before or that someone else has done before to leverage in order to solve problems and overcome challenges.
- Abstractions: Filter out unnecessary details out of the problem or challenge in order to focus on what is important.
- Algorithms: Humans and machines working together to on an ordered, sequential set of actions in order to solve a problem or overcome a challenge.
Algorithmic Business Thinking uses the four ideas above in order to solve problems and overcome challenges.



