BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  It is for innovators and early adopters who are ushering in a new era of digital financial reporting.

Much of the information contained in this blog is summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the three documents on this digital financial reporting page.

Improved Financial Reporting Checklist, Natural Language Rules

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:

Posted on Tuesday, January 24, 2017 at 01:10PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Comparing and Contrasting Three XBRL Taxonomy Representation Approaches

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.

Posted on Sunday, January 22, 2017 at 07:55AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Understanding that XBRL is a Knowledge Media

Most people think about XBRL in terms of what it is.  Using that definition, XBRL is a global technical syntax for exchanging information.  Another way of looking at XBRL is in terms of the value it provides. Using that definition, XBRL imparts knowledge.  XBRL is a new medium.  XBRL is a high-fidelity knowledge media.

In his book, Systematic Introduction to Expert Systems, Frank Puppe discusses the notion of knowledge media. This figure, a modified version inspired by Frank Puppe's Figure 3.2, shows some knowledge media in order to contrast some specific advantages and disadvantages of the different media.  This will help you see the value of the XBRL knowledge media:

Inspired by Frank Puppe's Figure 3.2, page 21.

The graphic shows a knowledge bearer on the left which imparts some knowledge to a knowledge receiver on the right via some knowledge media.  Just a few knowledge media are shown.  Here is a summary of some of the advantages and disadvantages of the list of knowledge media which are shown in the graphic above:

  • Direct contact between knowledge bearer and knowledge receiver: With some media you need direct contact between the bearer and receiver of knowledge.  For example, with Word of mouth you generally need direct contact.  With a Book, a Video, or XBRL you don't need direct contact.
  • User control over information access: Word of mouth, Book, and Video all tend to be sequential access to the information.  You tend to receive information in a specific order.  With XBRL, it is easy to reorder or reconfigure information.  The user can easily control of the order of information access.
  • Verifiability of information: Verifying the information you receive is possible using any media.  However, because XBRL is machine-readable; automated testing can be used to verify information and experimentation is easy. For example, I can test the complete set of XBRL-based public company financial filings using software in a matter of a few hours. Word of mouth, Book, and Video media is not machine-readable.
  • Testing information ambiguity: Because XBRL is machine-readable in terms of meaning but Word of mouth is not machine-readable and Book and Video are not machine-readable in terms of meaning; XBRL can be used to measure the ambiguity of information conveyed.  The effects of vagueness and poorly articulated information can be made very clear using testing, and so such ambiguity can be minimized between the knowledge receiver and knowledge bearer.
  • Information fidelity: Fidelity is the degree of exactness with which something is copied or reproduced. With Word of mouth the fidelity tends to be maximized because the bearer and receiver are communicating directly. If there are issues in understanding, questions can be asked. With a Book or Video, there tends to be a bit less fidelity perhaps.  With XBRL, because information is converted from what is more an analog (paper) to a digital representation, their might be a loss of fidelity if the digitization is not done well.  It is sort of like the difference between a record which is analog, a CD which is digital format, and a MP3 which is compressed digital format.  The price you pay for the smaller MP3 files is lost fidelity, but what is lost is the frequencies far beyond a human's ability to hear. Everything is a tradeoff.
  • Reach versus richness: In their book Blown to Bits, Philip Evans and Thomas S. Wurster point out the new economics of information.  In the past, you could have reach or richness, but typically not both at the same time.  The internet completely changed this economic equation. Reach is access to information.  Richness to quantity, timeliness, accuracy and variety of information. Word of mouth tends to be the richest information, but the reach can be lower.  Books have excellent reach, but less richness.  With XBRL you can have excellent reach and richness.

However, in order to make use of a knowledge media effectively, the following three conditions must be satisfied:

  1. Easy for knowledge bearer to represent information: The effort and difficulty required for the knowledge bearer to successfully formulate the knowledge in the medium must be as low as possible.
  2. Clear, consistent meaning: The meaning conveyed by the knowledge bearer to the knowledge receiver must be clear and easily followed by human beings and be consistent between different software applications. The result cannot be a "black box" or a guessing game and users of the information should not be able to derive different knowledge simply by using a different software application.
  3. High-quality information representation: The form in which the knowledge is represented to the receiver must be as good as possible.  The quality must be high whether the knowledge receiver is a human-being or an automated machine-based process.  Sigma level 6 is a good benchmark, 99.99966% accuracy.

The knowledge conveyed by a zero defect intelligent XBRL-based digital financial report as to the financial condition and financial position of an economic entity is just an example of the capabilities of the XBRL knowledge media.  Digital business reports of other sorts are possible also.  Think semantic spreadsheets.  See here and here.

Posted on Monday, January 16, 2017 at 02:45PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Clear Vision of Intelligent XBRL-based Digital Financial Reporting Tool

If I had a tool for creating zero defect (sigma level 6 quality) US GAAP and/or IFRS general purpose financial reports leveraging intelligent XBRL-based structured information and I could create those reports faster than you can create financial reports today, incurring less costs than you incur today, and with a higher quality level than the financial reports that you create today; then would you buy that tool?

What if the tool had all the necessary pieces, it was complete.  What if the tool was easy to use.  What if the tool was inexpensive.

Do you know how to build such a tool?  Do you know the proper technologies to employ to create the tool?  If you are a business professional, do you understand how to specify such a tool?

Leap frog the competition: Intelligent XBRL-based Digital Financial Reporting

No magic. Skillful execution.  Attention to detail.  Quality of a master craftsmen. Engineering excellence. Steve Jobs would be happy.

Purpose-build for disclosure management and financial report creation, intelligent XBRL-based digital financial reporting products collect information about financial report creation projects and allow this information to be coordinated across all other representations of the project, so that every statement, policy, and disclosure is based on internally consistent and complete information from the same underling financial information database. Risk of noncompliance is minimized.  Cost of compliance is minimized. Effort to comply is minimized.

All the information provided by this resource is released into the public domain.  Two key pieces of the resource are a summary of the background information necessary to understand the problem correctly and a conceptual model that pushes the technical aspects into the background, freeing professional accountants from technical details so they can focus on the accounting and reporting.

Next step? Turn the vision into a reality.  Stay tuned.

Posted on Thursday, January 12, 2017 at 06:52AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

XBRL Open Information Model 1.0

XBRL International has published a candidate recommendation for the XBRL Open Information Model (OIM) 1.0.  XBRL International defines OIM as follows:

The Open Information Model provides a syntax-independent model for XBRL data, allowing reliable transformation of XBRL data into other representations.

My personal view here is that this is a good step in the right direction, but there is not really anything that is "XBRL data".  XBRL is a technical syntax.  There is "financial data" and there is "nonfinancial data" and either of those types of data, or information really, can be represented using the XBRL technical syntax.

What is still missing is a global standard conceptual model for business information, including financial information.  Until that global standard model exists, here is the conceptual model that I am using.  I arrived at that by reverse-engineering XBRL-based public company financial reports which were submitted to the SEC.

My conceptual model has a significantly deeper level of meaning than is provided by the XBRL International OIM.

Posted on Monday, January 9, 2017 at 08:54AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint