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 October 1, 2020 - October 31, 2020
Best Practices for Automating Record to Report
This blog post summarizes information related to a best practices approach for automating aspects of the record to report process (R2R). This blog post walks you through a prototype that turns a set of journal entries into the four primary financial statements (balance sheet, income statement, cash flow statement, statement of changes in equity).
As The Knowledge Graph Cookbook: Recipies that Work says (page 47), "The basic rule is that content tagging and classification should take place as soon as possible after the content is created."
This is achieved by making sure that all information is machine readable. This involves:
- Creating a proper, well organized chart of accounts.
- Making sure all necessary information is included in journal transactions using work tags. This involves creating the appropriate work tags and entering them when transactions are entered into the general ledger so you don't have to perform this task at the end of the month when you want to generate a financial report.
- Defining a machine readable organization of the high-level classes into which the chart of accounts rolls into.
- Generating detailed roll forwards of every balance sheet account.
- Mapping the chart of accounts into the high-level classes creating what amounts to a report writer.
- Creating rules that make sure everything is working effectively.
- Pressing a button to generate a report.
Here is the ultimate target exemplified by another prototype I have created. Specifically, this set of primary financial statements. That report is both human readable and machine readable. All the math is checked using automated processes. Here is another auto generated report for checking to be sure everything is working as expected.
Here is where I will summarize the details of my best practices approach for automating the record to report process. I will explain all the details in forthcoming documentation. To achieve this result (still not 100% complete yet) I did the following:
- I created a well-thought-out chart of accounts and published it in XBRL.
- I created a proper base taxonomy, overcoming the deficiencies of existing taxonomies such as the US GAAP XBRL taxonomy and IFRS XBRL taxonomy.
- I created all of the rules necessary to support the full record to report process.
- I added one additional piece of metadata that is missing from the vast majority of accounting systems which makes automated report generation impossible. That piece of metadata is included within the accounting system and was entered when transactions were entered, is provided within the general ledger transactions exported from the accounting system, and are used to generate the balance sheet roll forwards of each real account and cash flow statement line items.
- Everything is controlled via the complete set of rules.
- Everything is checked using automated processes to be sure no mechanical, structural, mathematical, and logical information is as was expected.
Note that I am NOT SAYING that 100% of every step that is necessary to be sure the report is correct has been automated. What I am saying is that I have automated probably more than anyone else has been able to automate and this system is flexible enough to accept modifications such that every reporting situation that I am aware of can be handled.
The objective here is to create a repeatable process that guarantees high-quality output reliably and consistently. This is achieved by using machine-readable rules that provide the necessary control.
What I have NOT done is meet the "self-service" objective yet. Why? Because I am not a good enough software engineer. Not even close. I am working with others to turn this working proof of concept into a "self-service" process that other professional accountants can operate, manage, and maintain.




Oughtomation
Oughtomation is published by xalgorithms.org and is described as follows:
Oughtomation is any simple, factual, general-purpose computational method that gives effect to MUST, MAY and SHOULD assertions amongst individual and organizational agents.
This paper, An Introduction to 'Oughtomation', provides a high-level overview of rules.
Oughtomation appears to be engineered to be very safe, similar to Datalog. For more information about problem solving paradigms, logic, and rules see this blog post and this blog post. The following is from an explanation provided of Oughtomation to me in an email:
Our method is more like Datalog, the simpler subset of Prolog. We're concerned with declarative facts and rules, and we limit functions to simple arithmetic and boolean operations. In Datalog rules can be expressed as two-part clauses: the facts (input conditions of the rule.xa records) and its logical implications (output assertions of the rule.xa records). These are combined in our system with transient facts (is.xa message) and the whole set of logical implications (ought.xa message). Facts alone (lookup.xa records) are like rules but with no implications. A fact asserts a predicate being true for a particular combination of values. And each rule asserts that GIVEN a context, WHEN certain facts occur in specific relations, THEN an additional fact is deemed to exist in a derived relation. (Maier et al., 2018, pp. 3–5) This provides the basis for programming with first-order logic. Datalog separates statements of logical relations from resolution procedures, so that programmers can focus on specifying the logical relations with purely declarative facts and rules. The machine optimizes how each problem is to be solved using its available procedures.
Computational professional services is becoming more and more real!
####################################
XF Grammar (XBRL International)
Brainstorming "Digital" Accounting and Audit Automation
This is just a collection of thoughts at this point. This information will be better organized at some point later. If you have any thoughts or ideas, please send them to me.
First, remember that double entry accounting is a mathematical model. Second, before now, there is some accounting and reporting metadata that exists within an accounting system and in report writers but that metadata tends to be (a) not very well organized and (b) incomplete. What I mean is sure, you have a "chart of accounts" within an accounting system; but that is not enough to be able to automatically generate a proper balance sheet, income statement, cash flow statement, and statement of changes in equity. For example, Workday created a feature in their product called "work tags" for precisely that reason. Work tags is somewhat of non-standard, informal method of getting additional metadata necessary to enable the auto-generation of a complete set of financial statements (balance sheet, income statement, cash flow statement, statement of changes in equity).
So, what if an accountant were to:
- Create a well organized chart of accounts.
- Map that well organized chart of accounts to the higher level items which make up a proper financial report.
- Formally add "tags" to transactions at time time of transaction entry. Preferably these "tags" are standard.
- Do all of the above in machine-readable form that is also readable by humans.
- Create an automated process that enables the generation of proper financial reports (balance sheet, income statement, cash flow statement, statement of changes in equity).
- Append that process to similarly create accounting policies and disclosures using a controllable process rather than ad hoc Excel spreadsheets which are then cobbled together to generate a complete financial report (primary statements and all the notes).
- Audit that controllable and far more automated process and the resulting report using similar automation mechanisms; coordinating the "accounting" and "reporting" and "auditing".
- Leverage the control, coordination, machine-readable metadata, and other aspects of digital to make the bookkeepers and accountants that enter transactions smarter so that there are fewer mistakes that need to be fixed. This is done by making accounting systems more similar to software like Intuit's TurboTax; reviewing work and pointing out problems.
So how do you achieve increased automation?
Automation is about removing friction, driving costs down, speeding processes up, and improving efficiency and productivity. Automation is about improving processes in order to deliver better value for less cost, faster than other known alternatives.
We want to create ongoing repeatable processes that are reliable because the processes can be controlled thus achieving verifiable high-quality. Because the repeatable process is reliable this enables effective automation. The effective automation is the result of the control over the process. That control is enabled by the machine-readable rules.
It is these rules that enable control which enables quality which enables effective automation. So, who creates the rules and what are the rules that need to be created? There are rules that control the "delivery mechanism" or physical representation of the rule. Those are technical oriented rules, they are not the concern of business professionals. Those rules simply need to work effectively; these technical oriented rules are buried deep within the system to make sure the system is working effectively and as expected. Computer scientists and information technology professionals manage and maintain these technical oriented rules.
Accounting professionals create, manage, and maintain the logical rules related to accounting, reporting, and auditing. As such, these rules need to be "self-service". Accounting professionals must be empowered by software applications to effectively perform these creation, management, and maintenance tasks.
With the implementation of self-service rules, accounting and business professionals can control their processes, the process logic. Rules provide control; control leads to high-quality; high-quality enables effective, reliable automation; effective automation makes tasks and processes better, faster, and cheaper. Productivity gains result.
Why would professional accountants reject better, faster, and cheaper processes? Why would they not want productivity improvements?
Promises of better, faster, and cheaper processes mean nothing. Software vendors need to deliver the goods; that is when things will start changing for professional accountants. Partial solutions will not do. Complex solutions that are too hard for accounting professionals to use (i.e. not self-service) will not do. Solutions that do not guarantee repeatable high-quality will not do.
I have a proven, best practices based method for guaranteeing high quality. While there are a number of software vendors that have implemented pieces of this method; no one can currently provide a complete solution. Pacioli, XBRL Cloud, XBRL Query, and Pesseract come close. Luca provides some good ideas. Stay tuned to see how to deliver solutions that do actually work reliably.




Saving the World from Spreadsheet Disaster
The Wired article, Meet the Excel Warriors Saving the World from Spreadsheet Disaster, tells the story of "a quiet battle against illogical formulas, copy-and-paste errors, and structural chaos that cause data carnage."
The article points out,
Research suggests more than 90 per cent of spreadsheets have errors, and half of spreadsheet models used in large businesses have “material defects”. Given some 750 million people use Excel globally, there are plenty of errors needing attention. One prominent researcher calls spreadsheets the dark matter of corporate IT.
A possible solution to many of the problems with spreadsheets is another type of spreadsheet: the deductive spreadsheet a.k.a. the semantic spreadsheet.
Here are a couple of examples:
- Example 1: (here are the details)
- Example 2: (here are the details)
- Example 3: (here are the details)
OMG is contemplating creating a standard semantic spreadsheet. What exactly are the advantages? Here are some of the advantages:
- Information can be defined using standards.
- Information is linked together using logic, not presentation artifacts (workbook, row, column, cell).
- Rules can be separated from spreadsheet information.
- Standard sets of rules can be used across many spreadsheets.
- Information is both human-readable and machine-readable.
- Creators of spreadsheets can maintain control over those spreadsheets.
While presentation-oriented Excel and other such spreadsheets have their place and will likely never go away, semantic spreadsheets also have their place. In fact, semantic spreadsheets is the foundation upon which computational professional services will be built.
The NOVA program, A to Z: The First Alphabet, points out (minute 16:30 to 17:30) that the first writing in the form of spreadsheets were used to keep ledgers for accountancy to track commerce. Over 7000 years ago, the need for accounting drove the creation of writing.
Accounting has moved beyond clay tablet spreadsheets to papyrus and then paper spreadsheets. In the 1970s and 1980s, the electronic spreadsheet was developed. It is time for the next step in the evolution of the spreadsheet.




Updated Reporting Styles Metadata
I made some adjustments to the rules that support reporting styles. Here are the NEWEST version of reporting styles for the following reporting schemes:
The prior format still works, but I would recommend this new format because the logic is more correct.
To determine which reporting style to use for a US GAAP or IFRS reports submitted to the SEC, I have a web service that maps a CIK number to which reporting style that entity uses. I will likely do something similar for ESMA filings.



