Digital Financial Reporting

This 2006 speech, The Interactive Data Revolution: Improved Disclosure for Investors, Less Expensive Reporting for Companies, by Chairman Christopher Cox of the SEC explains his vision for XBRL-based financial reporting.

In the speech, Cox points out that perhaps we are approaching XBRL which he calls "interactive data" from the wrong end.  Rather than taking about the "gizmos" that make it work we should be talking about the reasons interactive data will improve our lives.

It seems to me that we might be approaching this from the wrong end. Instead of talking about all the gizmos that will make markets work better and give investors better tools than they have today, we ought to be starting with the reasons that interactive data will make the lives of investors, companies, and even regulators better. Watchmakers, after all, do not sell their products by talking about tachometers and rotors. They tell you that their watches keep perfect time. You don’t have to know anything about movements to be able to tell time — and to know that it’s always better if your watch hasn’t stopped before an important appointment. With interactive data, the parts and internal movements can be daunting, but the result is to make investing easier and better for the individual and for the market as a whole.

Interactive data is a marriage made in heaven for investing and high tech.

All this distills down to flipping bits.  But, all the pieces of the puzzle need to be put together in such a way that business professionals can operate these systems without the involvement of technical professionals.  The "gizmos" for doing this need to be hidden from business professionals.

It is not only financial reporting that will benefit.  Financial reporting is just one obvious use case.

Moving to more modern approaches to accounting, reporting, auditing, and analysis that are more appropriate for the digital evironment of the fourth industrial revolution is progressing slower than I would have expected.  Perhaps it is slower than you would have expected also.  Maybe not.

Change will ultimately come.

German physicist Max Planck pointed out that science advances "one funeral at a time". Or more precisely: (Wikiquote)

“A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.”

Perhaps a bit morbid, but true. The guy in this video says the same thing at minute 30:10. Paradigm shifts are hard for people to make.

Email did not make 100% of snail mail go away.  Paper-based financial reporting will likely always exist.  A digital alternative to a paper-based or e-paper general purpose financial report does provide value.  But to provide value, it has to work correctly.  Well, I know that it can work correctly.

Don't take short cuts.  Yes, it can be tough to balance short-term realities and the longer-term objectives.

The graphic below shows visually the role that XBRL plays in connecting accounting, reporting, auditing, and analysis processes:

(Click image for larger view)

This video, Digital Financial Reporting, put out by the Australian SBR project explains the two approaches to implmenting digital financial reporting: built-in and bolt-on.  Bolt-on simply adds more work.  Built-in takes more time and effort to implement, but it leads to improved process effencicy.

These are the sorts of processes and tasks that get improved:

(Click image for larger view)

This narrative helps you understand the moving pieces of accounting, reporting, auditing, and analysis in a digital environment.

In the first and second industrial revolutions, water power, steam power, and electrical power contributed to automating many manual tasks.  In the third and our current fourth industrial revolution computers and computer software will help automate many cognitive tasks.

In their paper; xAudit: Auditing Representation in XBRL Based Documents; Allison Ramon Araújo de Santana, Paulo Caetano da Silva, Márcio A. Pereira da Silva, and Maurício Codesso explain how audits can be made more efficient and more effective leveraging machine-readable information.  Here is the abstract of the paper:

Most financial documents are presented to governments and governors in computer language (e.g., XBRL). Information acquired from said reports should be free from faults, omissions and fraud, making it trustworthy to the point of supporting strategic decisions by the organizations that receive them. Although XBRL technologies present financial data and its accounting semantics, the auditing techniques used (which make this data even more trustworthy) are not stored or listed in the XBRL taxonomies. This fact makes it difficult to perform the auditing of these files, given that it’s up to the auditor to apply the concepts of auditing manually, without the assistance of the automated auditing process. With the continuous auditing it’s more and more possible to avoid the recidivism of fraud or even to identify it more quickly. Despite many auditing operations being performed under the XBRL perspective, it has not yet been defined a standard for the auditing of XBRL files. This paper proposes the establishment of a link database (Linkbase, in XLINK language), based on the XBRL specifications, which has been named xAudit, for the listing and storing of auditing techniques in XBRL taxonomies. To do so, a solution has been created, based on the XBRL definitions and auditing-specific regulations. Using xAudit, people try to solve the shortage for a standard for XBRL auditing. Some important points of the auditing process are raised in the present article. Using xAudit, it’s expected that organizations can achieve improved results, real-time verification and accurate data analysis.

Here is other information that I provided related to the audit of XBRL-based information.

In my view, there are important distinctions that need to be kept in mind.

The first distinction is the difference between the "syntax" piece (i.e. what syntax) and the "logic" piece need to be kept separate in ones mind.  The logic is explained in my document that explains what is necessary to communicate semantics (i.e. the logic) between two parties.

The second distinction is the difference between the "facts" that are reported within a report and the "financial report logic" itself which is about the consistency, completeness, and precision of the terms, associations, assertions, and facts WITHIN some report.  You can have a report that is consistent, complete, and precise; but the FACTS are fraudulent.  You could also have a report where the fact are 100% true and fair, but the report is incomprehensible.

The point is, when thinking about "audit" of "XBRL" if these things are separated appropriately, a proper system can be created.  If you don't separate these concerns appropriately, you are likely to create an incomprehensible mess.

So, the best way to figure out what xAudit (or whatever it will end up being called) should be and what the possibilities are is to build a prototype.  Here you go: (this is my initial, very, very early prototype)

• XBRL taxonomy schema for xAudit (Prototype)
• Human readable rendering of the above XBRL taxonomy schema and relations (Prototype)
• Audit Tests Modeled in DMN (Prototype)
• xAudit arcroles for representing audit tests (Prototype)
• Audit checklist (Prototypes as XBRL definition linkbase)
• Audit checklist + MINI labels (easier to read, same as above)
• Audit checklist human readable view (use this if you don't have an XBRL taxonomy tool)
• Sample XBRL instance (Prototype, checklist used to test this report)
• Next step: Add audit risk.

Heck, if we create a modern approach to financial reporting, we need a modern approach to auditing. The AICPA has their "dynamic audit initiative". We have rudamentary AI assisted audits. Anyone want to help reinvent the audit?  Give me a shout.

OMG has some business process model documentation that is referenced.  See BPMN and and BPM on the OMG web site. BPMN by example. BPMN example. Others are Decision Model and Notation. XPDL, XML Process Definition Language.  ISO 19011:2018 Guidelines for auditing management systems.  International Standards on Auditing. International Auditing and Assurance Standards Board (IAASB).

########################

XBRL, How it Implies the Audit Process

Business Process Model and Notation (Wikipedia)

BPM Software

Business Process Management

List of BPMN Engines

BPM Institute

How to Conduct an Audit Engagement

This is a nice XBRL to JSON converter. Here are some other projects created by Marcio Alexandre. Here is a paper related to the audit of XBRL-based information.

If you grab information from one of my modern approach to creating a reporting scheme prototypes; you can see that everything distills down to a chain of logic gates that are used to construct a chain of reasoning.

For instance, grab this Excel spreadsheet that contains VBA code that extracts metadata from the US GAAP Ontology-like thing.  You can use that and other metadata to create things like:

• This interface
• This comparison
• This validator
• These extraction tools
• This HTML rendering
• This different HTML rendering
• This SEC viewer
• This metadata interface
• Or anything else...

That is more, most of the associations are very simple "from" one concept, "to" some other concept, and the nature of the relationship explained by some "arcrole".  The most complicated logic represented are the impute rules that look like this:

if (NoncurrentLiabilities = 0 and not(CurrentLiabilities = 0) and not(Liabilities = 0)) then (NoncurrentLiabilities = Liabilities - CurrentLiabilities) else (NoncurrentLiabilities = NoncurrentLiabilities)

That is the toughest software application interface that needs to be created, expressing that relationship.  Yes the volume of rules is rather large and there is a lot of professional knowledge that you need to have to create the rules; but professional accountants have that.  So, accountants will only work with LOGIC to represent knowledge of a domain that they understand.

Fundamentally, a computer is a bunch of "1s" and "0s" and everything you create is about flipping the right bits with some programming language.

What is a bit different here is that all my metadata is declarative as contrast to interpretive.  That changes the programming paradigm.  Rather than creating procedural code that is locked into one sequence of IF...THEN statements; the logic is represented via the XBRL technical syntax (instance, taxonomy schema, linkbases) and they a rules engine is used to process the logic represented via the declarative rules.

Semantics are represented in the form of models. The rules engine understands the semantics, models, and how to read the decarative metadata (logic) and can sort everything out.

This is closer to logic programming that functional programming.  This is a different paradigm than most software developers are use to.

Powerful stuff!