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