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 June 7, 2020 - June 13, 2020
Accounting Cycle: Closing Entries
This explaination is for the benefit of computer scientists/software engineers. Accountants learn this stuff in Accounting 101.
At the end of an accounting cycle which is usually a year and at the end of a calendar year (i.e. December 31) for most companies; you "close the books" for that period. Note that companies can, and many do, have year ends other than December 31. Further, an accounting cycle could be a 52/53 week period. Retailers use this approach to enhance comparibility.
If you want to understand the accounting cycle and closing entries, this is a good explaination. This YouTube video explains closing entries. (This YouTube channel has lots of good information about accounting.)
So this is the entire accounting cycle (with some helpful videos that explain specific steps):
- Journalize Transactions
- Post Transactions to General Ledger
- Trial Balance
- Adjusting Entries
- Adjusted Trial Balance
- Preparation of Financial Statements
- Closing Entries
How do you explain all this to a computer? It amazes me how dumb computers really are. They understand none of this. Each detail of each step needs to be explained.
It seems that what I need to do is use the fundamental accounting concepts to define the high level concepts like "Assets", "Liabilities", "Equity", "Revenue", "Expenses", "Net Income (Loss)", "Net Cash Flow", and so forth. I need to explain which of those are REAL (permanent) accounts and which are NOMINAL (temporary) accounts to enable the closing process to be automated. These relations can all be expressed using XBRL definition relations.
How the chart of accounts is mapped into those high level concepts is done using the roll up relations represended by XBRL calcuations.
I created all of this for the not-for-profit XBRL taxonomy. See here for human readable information. See here for machine readable information.




Forbes: Impact of Artificial Intelligence on Professional Services
A Forbes article, The Impact Of Artificial Intelligence On Professional Services, points out that accountants and lawyers are using artificial intelligence to cannibalize their own businesses...before someone else does. The article points out:
The firms that prosper will be the ones that grab the opportunity first to re-skill their technology and their people. The future is not about number-crunching transactions, but about judgement and wisdom.
And it says:
Automation is about removing friction, driving down costs, speeding processes up, and generally improving efficiency. Making goods and services better and cheaper is a good thing: it makes us all richer.
The article discusses what EngineB, the Big 4, several of the next tier and challenger firms, the Institute of Chartered Accountants in England and Wales (ICAEW), and Microsoft are doing to improve efficiency.
EngineB is not the only one automating processes. ContractZ.app, Logical Contracts, and likely others are all over this opportunity. People are thinking about using distributed ledgers for audits. AI assisted audits are here.




Proof Business Use Case Represented in Six Technical Syntax
The OMG's forthcoming Standard Business Report Model (SBRM) is a logical conceptualization of a business report. XBRL International's Extensible Business Report Language (XBRL) is one technical syntax that can be used to represent a business report in machine-readable form. There are other machine-readable formats.
My "Proof" test case or business use case exercises 100% of what you would ever find in an XBRL-based digital financial report. Believe it or not, it is true. The Proof representation was specifically designed for that purpose; to exercise SBRM in order to make sure it met the needs of financial reporting. I have many other test cases/use cases.
I have now been able to represent 100% of the financial report logic found in the Proof representation using six different technical syntax (seven if you view raw XBRL and Inline XBRL as different technical syntax). You can download each one and have a look at it from here:
- XBRL: This representation includes raw XBRL and Inline XBRL. Other functionality can be performed such as validation and rendering using standard off-the-shelf software that supports the global standard XBRL. To understand all that, see this web page.
- Microsoft Access (i.e. SQL): The XBRL, Excel, and CSV representations all came from this Microsoft Access database application. You can download the version with the code that outputs XBRL here.
- Excel: This Excel version is simply an Excel spreadsheet for each database table.
- CSV: This CSV version is simply the Excel spreadsheet saved as CSV from Excel.
- RDF/OWL/SHACL: (Work in progress) This is being created by the team creating SBRM; the Proof version has not yet been created, this is a representation of the Accounting Equation that is partially complete for the time being.
- PROLOG: (Work in progress) This is being created by a PROLOG expert and will be completed over the next several months. Currently, a PROLOG version is provided for the SFAC 6 example which does not include a couple of mathematical relations that the Proof representation includes, but it will give you a very good idea that the Proof example can be represented using PROLOG.
What does this mean? First, no matter what technical syntax is used; 100% of the business logic of the use case must be able to be represented vial that technical syntax. This pretty much proves that any of the syntax alternatives above could be used to represent a business report in machine-readable form. You can choose which technical syntax you prefer to work with; but you cannot simply leave information out. Second, if you can get information into any one of these technical syntax you can convert the logical representation into any other technical syntax.
Which technical syntax is best? Well, that is up to you. Pick whatever technical syntax you like from above. Create another technical syntax. Each alternative has a specific set of pros and cons.



