Digital Financial Reporting

Think artificial intelligence is just a buzzword?  The following companies are members of the Partnership on AI:

• Apple
• Amazon
• DeepMind
• Google
• Facebook
• IBM
• Microsoft
• OpenAI
• ACLU of Massachusetts

The following is the stated purpose of the partnership:

Established to study and formulate best practices on AI technologies, to advance the public’s understanding of AI, and to serve as an open platform for discussion and engagement about AI and its influences on people and society.

Don't be an information barbarian or fall for the hype of the snake oil salesmen.  Learn about artificial intelligence.  Articles such as Artificial Intelligence Demystified are good, but they don't help you understand how AI works.  To truly understand capabilities, you have to understand how it works. Here are some helpful resources that business professionals can understand and that help you grasp how the technology actually works:

• Comprehensive introduction to expert systems
• Knowledge engineering basics for professional accountants
• Comprehensive introduction to business rules
• Comprehensive introduction to problem solving logic
• Comprehensive introduction to intelligent software agents

We live in the Information Age (also known as the Computer Age, Digital Age, or New Media Age).  The Information Age was brought about by the Digital Revolution.

But many business professionals, including accounting professionals, are information barbarians. Their information tools are primitive and unsophisticated. Their information skills, let's just say, lack refinement and grace.

How did this happen? It seems to me there are three reasons:

1. A rapid pace of change.
2. College education is not keeping up.
3. Supplemental learning is not appropriate.

There could be other reasons.  How we got where we are is likely interesting, but what is more important is fixing the problem. 

One wrong approach to fixing the problem is the "learn to code" hysteria. As I have pointed out, I am not alone in thinking that "learn to code" is misguided. And besides, as I also pointed out, the Wired magazine article The End of Code points out that we won't be "coding" in the future, we will be training computers like we train dogs.  Sure, learning to code would not hurt anything.  But, learning to code will not turn an information barbarian into a civilized member of the information age.

Another wrong approach was proposed by the CFA Institute in a paper. While the CFA Institute did articulate an excellent vision of how structured data can be used to fix the currently inefficient process (i.e. barbaric) of financial reporting; they call for auditors to receive "increased education in technology".  Personally I think that is not the right approach.  The right approach is to provide auditors with better software tools.

I am not sure if is a complete solution to the problem, in fact I don't think that it is.  But part of the problem business professionals have will be solved by understanding a set of 15 principles that I find helpful when thinking about digital financial reporting.  Here is a summary:

1. Prudence dictates that using financial information from an XBRL-based digital financial report should not be a guessing game.
2. A near zero defect financial report is useful, a defective financial report is not.
3. Rules prevent anarchy.
4. The only way to achieve a meaningful exchange of information without disputes is with the prior existence of and agreement as to a standard set of technical syntax rules, business semantics rules, and workflow rules.
5. Explicitly stated information or reliably derived information is preferable to implicit information.
6. Digital financial reports can be guaranteed to be defect free using automated processes to the extent that machine-readable business rules exist.
7. When possible to effectively create, machine-based automated processes tend to be more desirable than human-based manual processes because they machine processes are more reliable and cost less.
8. Computers have limited reasoning capacity.
9. Business rules should be created by knowledgeable business professionals, not information technology professionals.
10. The stronger the problem solving logic, the more a machine can achieve.
11. Catastrophic logical failures are to be avoided at all cost; they cause systems to completely fail.
12. Complexity cannot be removed from a system, but complexity can be moved.
13. Part of a system is not really that useful.
14. Simplicity and simplistic are not the same thing.
15. Apply double-entry bookkeeping procedures, processes, and techniques to digital financial reports.

There is nothing technical or hard to understand about those principles.  Most are simply common sense.  But, if you don't have that framework it is hard to keep in mind what is important.

In another Wired article, Barack Obama, Neural Nets, Self-driving Cars, and the Future of the World, the ex-president pointed out another issue:

"There are gonna be a bunch of choices that you have to make, the classic problem being: If the car is driving, you can swerve to avoid hitting a pedestrian, but then you might hit a wall and kill yourself. It's a moral decision, and who's setting up those rules?"

As I previously pointed out, that statement which relates to self-driving cars points out two things that accounting professionals and other business professionals need to consider when thinking about something like intelligent XBRL-based digital financial reports:

1. WHO: who writes the rules, the logic, which software follows,
2. HOW: how do you write those rules and put them into machine-readable form and get all this to work reliably?

The changes will not be from sustaining innovations, they will be disruptive innovations.  Things like XBRL are new knowledge media that offer completely new capabilities.  As the currently barbaric financial reporting processes are transformed, one should consider learning from other such transformations.  For example, the evolution of drafting from vellum to computer, can be learned from. Emulate the good, avoid the bad.

In my view, what business professionals need to understand to thrive in the information age are the following two fundamental things:

• First, business professionals need to understand that computers work using the rules of formal logic.  Formal logic is a discipline of philosophy.  Computers work based on the rules of mathematics. Mathematics is based on the rules of formal logic.  Understanding how to think using formal logic will help you understand the real capabilities of computers.
• Second, business professionals need to understand a few basics about knowledge engineering. This will allow business professionals to more effectively communicate with information technology professionals.

That is really it. None of this needs to be a mystery or some "black box" that you don't understand how to properly employ. Artificial intelligence is more than a buzz word; but right now there is a lot of hype related to that word.  On the one hand, don't fall for the sales pitches of the many snake oil salesmen.  On the other hand, don't ignore good capabilities.

The XASB Financial Report Proof of Concept is exactly that, a proof of concept.  What I am doing is stealing every good idea of every taxonomy I have been exposed to, using those ideas in this proof of concept and avoiding all the mistakes others have made that lead to problems.  This financial reporting proof of concept uses the imaginary XASB accounting standards, so I can avoid any constraints imposed by the FASB's US GAAP XBRL Taxonomy and/or IASB's IFRS XBRL Taxonomy in my working prototype.

Further, any public company can use these ideas to file their XBRL-based financial reports to the SEC. Why? Because that is where I got most of what went into this proof of concept: by reverse engineering public company XBRL filings to the SEC. What this proof of concept does is decouple what the SEC requires that would not be applicable to other financial reporting schemes.

What is the point? To create a perfect, or as near as perfect as possible, zero-defect intelligent XBRL-based digital financial report. Why? Software testing.

Here is my first working prototype:

• Reporting checklist rules (what must be reported)
• Disclosure mechanics rules (logical, mechanical, mathematical relations between the things that make up a disclosure)
• Fundamental accounting concept relations rules (basic accounting relationships within and between disclosures)
• Model structure rules (relationships between the basic structural elements that are used to express disclosures)
• Business rule arcroles (used for representing reporting checklist and disclosure mechanics rules, rules-arcroles.xsd)
• Other arcroles (used for representing other relationships and rules, fro-arcroles.xsd)
• Conceptual model (building blocks of a digital financial report)
• Base XBRL taxonomy (financial and nonfinancial conscepts and characteristics, including XBRL formulas which represent relations between concepts, used to create report)
• Company extension XBRL taxonomy (economic entity specific businesss rules, including XBRL formulas, used to create report)
• Financial report XBRL instance (the actual financial report)

More to come so stay tuned! Don't make the mistake of misinterpreting what you see.  Lots and lots of stuff is going to change in the taxonomy itself.  Also, the modularity of this is not what I want, so that will likewise change.  Also, I need to tune the conceptual model.

If you have any comments or suggestions, please send them to me if you so choose. Great way to learn!

To understand the details, please see Intelligent XBRL-based Digital Financial Reporting.

In a prior blog post I mentioned the world's first XBRL-based machine-readable digital financial reporting checklist.

I made some improvements:

1. Natural language tree view of rules: Before I simply provided a flat list of rulesand a JPEG image of what shows up in an XBRL taxonomy tool when the tool reads the rules. That view still exists, but the natural language tree view is easier to use for many things. If you click on a disclosure, you will note that you are taken to the disclosure mechanics rules.
2. Tuned the arcroles:  I made a few tweaks to the arcroles based on actual usage of the arcroles in software.
3. Processing steps view: I created a view that breaks down the rules by processing step. This helps me think through some things.
4. List of disclosures reference by the reporting checklist: This provides a list of each of the disclosures referenced by the reporting checklist.
5. Multiple reporting checklists:  When I started the fundamental accounting concept relations I made a basic mistake.  The mistake was that I tried to put all the relations into one set.  Ultimately I realized that there was not one set of fundamental accounting concept relations; rather there were multiple sets.  That is where the notion of reporting styles comes from.  Banks, insurance companies, and real estate investment trusts have different reporting checklists than say a software company.  And software companies have different reporting checklists than say an airline.
6. Natural language representation of disclosure mechanics rules: I now have a natural language representation of disclosure mechanics rules.  I have this working but I have not made this publicly available yet. See more below.

Now, what is becoming apparent is how the reporting checklist rules and the disclosure mechanics rules work together. And, it is seeming like the fundamental accounting concept relations fits into the mix here but I don't quite have that dialed in yet.  This is how I differentiate the two:

• Reporting checklist rules: A reporting checklist and it's rules help make sure you are providing the appropriate disclosures in a financial report.  Some disclosures are always required, some are required if a specific line item is reported, and other disclosures can exist but there is no way to use automated processes to test whether they should be provided or not.  Also, disclosure alternatives are provided for.  So, for example, a reporting entity could provide (a) a separate income statement and statement of comprehensive income; or (b) a combined statement of income and comprehensive income.  The reporting checklist rules seem to relate to WHAT must be provided.
• Disclosure mechanics rules: The disclosure mechanics rules are used to check the logical, mechanical, mathematical, and some accounting related relations within the "stuff" that makes up a specific disclsoure.  So, if you provide a specific disclosure the disclosure mechanics rules specify WHERE it is provided an HOW is is provided.

What it is looking like to me is that the fundamental accounting concept relations rules will migrate into the disclosure mechanics rules.  I don't really want two separate things when one thing will do.

Also, as I mentioned above, I have natural language representations of the disclosure mechanics rules. While I have not provided this publically yet, here is an example.  Consider the disclosure of the components of inventory:

Business rules for disclosure: disclosures:InventoryNetRollUp. The disclosure...

• goes into a Network with the SEC Sort Code: Disclosure (alternatives are Document, Statement, Disclosure, Schedule)
• must be represented as the concept arrangement pattern: Roll Up (alternatives are Roll Up, Roll Forward, [Text Block], Hierarchy, Adjustment)
• must be represented as using the Level 3 Disclosure [Text Block]: us-gaap:ScheduleOfInventoryCurrentTableTextBlock
  • OR, alternative, the Level 3 Disclosure [Text Block]: us-gaap:ScheduleOfUtilityInventoryTextBlock
• the fro:RollUp total must be represented as the Level 4 Detailed Concept: us-gaap:InventoryNet
• requires the policy to be reported using the Level 2 Policy Text Block: us-gaap:InventoryPolicyTextBlock
  • OR, alternative, Level 2 Policy Text Block: us-gaap:InventoryMajorClassesPolicy
  • OR, alternative, Level 2 Policy Text Block: us-gaap:InventorySuppliesPolicy
  • OR, alternative, Level 2 Policy Text Block: us-gaap:InventoryWorkInProcessPolicy
  • OR, alternative, Level 2 Policy Text Block: us-gaap:InventoryFinishedGoodsPolicy
• requires the note to be reported using the Level 1 Note Text Block: us-gaap:InventoryDisclosureTextBlock

Believe it or not, the information above and this XBRL definition linkbase say exactly the same thing. In fact, the human readable version above was generated from the XBRL definition linkbase!

Which is easier for you to read and use? Which is easier for a machine to read and use?  Is there anything particularly technical about the natural language articulation of the rules?  That is the point!

Now, imagine how much a machine can help the creator of an XBRL-based financial report if it understood the information above. And that is how you make intelligent XBRL-based digital financial reporting work.

Finally, think about this: What if you never pressed the "Save as XBRL..." button of your software application.  Would those machine-readable rules still be useful?

Here is a great video on disruptive innovation: https://www.youtube.com/watch?v=yUAtIQDllo8

I took a prototype XBRL taxonomy that I had, modified it, and created three different XBRL taxonomies that help people focus on and see one specific thing related to XBRL Dimensions.  The specific area of focus is the use of hypercubes. 

In XBRL there are three general approaches to representing information:

1. Nondimensional
2. Dimensional
3. Mixtue of dimensional and nondimensional

XBRL International has issued guidance that says"Don't mix dimensional and nondimensional models."  XBRL International's guidance (Recommendation 3.5) states, "Where a taxonomy makes use of dimensions, all concepts should be associated with at least one hypercube, even if that hypercube has no associated dimensions."

Both the US GAAP and IFRS XBRL taxonomies violate that guidance.  I predict that ultimately, both of those taxonomies will be corrected.

Now, if you are using a dimensional model, using XBRL Dimensions, the next question you might have is HOW should you be using XBRL Dimensions.  The one specific aspect that I want to focus on is the naming of hypercubes.

There are FOUR possibilities:

• Unique hypercubes: Give each hypercube a unique name.
• Single hypercube: Create ONE hypercube and use that for representing EACH set of facts you report.
• Single hypercube, single line items: This is the same as #2 but in addition to unique hypercubes you also have one unique concept for representing the primary items dimension or what the US GAAP and IFRS taxonomy call [Line Items].
• Nonunique hypercubes: Give each hypercube different meanings from time-to-time.

Below I will explain each alternative, provide an example XBRL instance and XBRL taxonomy for the alternative (i.e. download), an HTML page you can use to view the taxonomy (i.e. view), and highlight the pros and cons of each alternative.

Unique hypercubes

By unique hypercube I mean that each hypercube has a different unique name and is used to represent one specific report fragment.  In the example below you see the hypercube label "Financial Highlights [Table]" which has the corresponding name "gaap:HypercubeTable".  Note also that the primary items are labeled consistent with the hypercube, "Financial Highlights [Line Items]. (Download | View)

(Click image for more information)

The primary advantage of this approach is that you can extract information from an XBRL instance using the hypercube.  Because each hypercube has a unique name such as "BalanceSheet" or "IncomeStatement", you can identify the report fragment using the hypercube to reliably extract information because each hypercube is unique.

The primary disadvantage of this approach is that you have to provide all of those hypercube names and the related names for the primary items.

Single hypercube

By single hypercube I mean that you create a single hypercube, say labeled "Hypercube [Table]" and named "gaap:HypercubeTable", and then use that single hypercube to report each report fragment. Note that the primary items are still unique to the report fragment represented. (Download | View)

 (Click image for more information)

The primary advantage of this approach is that you don't need to create all those hypercube names.

The primary disadvantage of this approach is that you cannot use the hypercube to extract information for fragments of the report because each fragment uses the exact same name. 

Single hypercube, single line items

This is the exact same as "single hypercube" above, but you also use one concept to represent each set of  primary items.  Note below that the primary items are labeled "Hypercube [Line Items]" and named "gaap:HypercubeLineItems" as contrast to the unique label and name above. (Download | View)

 (Click image to view more information)

The primary advantage of this approach is that like having one concept that is used for each hypercube; if you use one concept for the primary items of each hypercube, you don't have to fiddle with coming up with all those names.

The primary disadvantage; well, I really don't see any disadvantage.  Having a single concept such as "Hypercube [Line Items]" helps you realize that the primary items is really just like a dimension.  The only difference between primary items and members is that primary items have data types because they will contain fact values.

Nonunique hypercubes

"Nonunique hypercubes" is a possibility, but I reject that approach because it really does not make much sense.  Why would you do this?  An example of this is some XBRL-based public company financial reports to the SEC.  One example is Microsoft.  They use "us-gaap:StatementTable" for each of the primary financial statements, for some disclosures, and then specific hypercubes for other disclosures. (Download)

(Click for more information)

There are no real advantages to this approach really.  Frankly, it is confusing.  You can see that confusion when you compare how different public companies report information to the SEC.

The disadvantages of this approach is that, again, you cannot use the hypercube to extract information for a specific report fragment from a report.

===================================================

So there you have it.  Which alternative is best?  Well, that depends on what you want to achieve I guess.