Digital Financial Reporting

These two videos help you get your head around hypercubes:

• Contrasting Hypercube Structures (more information)
• Structure Representation Strategy (more information)

Happy hypercubing!

The following provides a summary of the different strategies for representing a structure within an XBRL taxonomy. For a video walkthrough of these, please watch Structure Representation Strategy.

• Approach 1: Hypercube as Unique Identifier - Using this approach each structure is identified by a unique hypercube and therefore every structure can be identified.  Given that each representation of a disclosure within a base taxonomy is an undisputed example of the disclosure, the disclosure mechanics specification can be reverse-engineered by software and are therefore unnecessary.
• Approach 2: Network as Unique Identifier - Using this approach each structure has a hypercube of exactly the same name which forces identification of the disclosure onto the network identifier which is guaranteed to always be unique.  If it is the case that the network identifiers of the base taxonomy are used in reports; then approach 2 works just like approach 1. Assuming that each representation of a disclosure within a base taxonomy is an undisputed example of the disclosure, the disclosure mechanics specification can be reverse-engineered by software and are therefore unnecessary.
• Approach 3:  Disclosure Specification as Prototype - Using this approach, neither a hypercube nor network can reliably be guaranteed to be unique and therefore cannot be relied upon to identify disclosure. However, disclosure mechanics rules are provided that do specify an undisputed example of the disclosure and a named list of disclosures has been created either as part of or independent of the base taxonomy.  As a result, every disclosure can be identified and verified to be consistent with the specification of the disclosure, even without unique identifiers.
• Approach 4: Hypercube as Unique Identifier Plus Disclosure Specification of Prototype - Using this approach, essentially approach #1 and approach #3 are combined.  Both unique hypercubes are provided plus disclosure mechanic rules that (a) refer to the unique hypercube as part of identifying the disclosure.
• Approach 5: Network as Unique Identifier Plus Disclosure Specification of Prototype - Using this approach, essentially approach #2 and approach #3 are combined.  Both unique network identifiers are provided plus disclosure mechanics rules.
• Pathological Example: No Unique Hypercube, No Unique Network, No Disclosure Mechanics Rules, No Named Disclosure - This is a pathological example provided for contrast.  In this case there are no unique hypercubes that can be used to identify structures, no unique networks (you have to imagine this, similar to XBRL-based reports submitted to the SEC), no specification for how disclosures should be structured, and no named disclosures.  Essentially, this cannot work reliably.

For more detailed information, please refer to the document Hypercubes, section 3 Structure Representation Strategy.  Also, take the time to look at the XBRL in the tool of your choice. This video Contrasting Hypercube Structures is also helpful if you want to better understand hypercubes.  You can download those examples here or view them online here.

XBRL-based digital financial reporting will, in my personal opinion, have a cross over affect on general business reporting and in particular business intelligence software.

The video, Digital Business Reporting, summarizes this information.  Business intelligence software is explained to be the following per this web site:

Business intelligence software is a set of tools used by companies to retrieve, analyze, and transform data into useful business insights. Examples of business intelligence tools include data visualization, data warehousing, dashboards, and reporting. In contrast to competitive intelligence, business intelligence software pulls from internal data that the business produces, rather than from outside sources.

Here is an overview of the top BI tools.  One thing BI tools have in common is the data warehouse and OLAP.  Here are some issues with OLAP that I have pointed out in the past.  Here is a summary of those issues; watch the video and I explain the enhancements provided by XBRL+ SBRM: 

My deliberate, rigorous, methodical testing of XBRL and SBRM for financial reporting leads me to believe that the ideas I am using for XBRL-based financial reporting will work well for digital business reporting.  Not quite as good as for financial reporting because of the higher level models of financial reporting; but it will still work well.

What is becoming crystal clear is the following.  XBRL+SBRM is a knowledge media that:

• Enables standards setter, regulator, or enterprise to describe and specify information about some reporting scheme in machine readable form
• Enables information bearer to produce information consistent with that provided specification that is machine readable.
• Enables information receiver or consumer to effectively consume information leveraging that provided specification using automated machine-based processes.

The rules provided by XBRL + SBRM (i.e. that specification) are the “orchestra leader” that enables the harmony (i.e. mitigates disharmony) and prevents anarchy (i.e. enabling effective information exchange).

Testing proves this.

The video Distinguishing Between Properly Functioning and Improperly Functioning Logical Systems points out what can go wrong within a financial report logical system.  When an XBRL taxonomy is created, one needs to mitigate the possibility that those things go wrong.  When an XBRL taxonomy is created that does not mitigate those possibilities, others will have to do so in order to make use of the XBRL taxonomy effectively. That is the only way to put together a reliable, repeatable process.

Both the US GAAP and IFRS XBRL Taxonomies leave critical pieces out.  These missing pieces are problematic for those that want to create reports using the taxonomy correctly, want to consume information from such reports, and even those simply trying to understand the taxonomies.

The video, Compensating for US GAAP and IFRS XBRL Taxonomy Design Choices, lays out exactly how I compensated for these missing pieces in order to create quality financial reports and to extract information from such reports.

Here is an example of the way I compensated for these issues using the small SFAC 6 Elements of Financial Statements XBRL representation where possible and other examples shown in the video: 

• Used the notion of "report element categories" defined by OMG's Standard Business Report Model (SBRM).  If you look at the Microsoft Access Database application I used to create the SFAC 6 taxonomy, you will see that I leveraged the notion of report element categories.  See the table "Report Elements" and the field "ReportElementCategory".
• Used the report element categories and organized them consistent with a set of strict "model structure rules" represented using XBRL definition relations to organize XBRL presentation relations that were expressed.
• Used “derivation rules” (I used to call these impute rules) to overcome unreported financial report line items.  For example, here is the derivation rule expressed using XBRL formula to computer Liabilities should that fact not be explicitly reported.
• Used "consistency rules" to overcome contradictions or inconsistencies in reported facts.  For example, here is the consistency rules expressed using XBRL formula for the relation between Assets, Liabilities, and Equity.
• "Reporting styles" is not an issue for the SFAC 6 representation because there are no alternative disclosures shown.  However, if you look at SFAC 6 Plus; alternatives do exist. The best example of reporting styles comes from the reporting styles that I created for US GAAP. (For more information on reporting styles, watch this video)
• Using the notion of "Disclosure" is not necessary because each disclosure in the SFAC 6 example is represented using an explicit hypercube.  However, I did express each disclosure by name within an XBRL taxonomy schema.
• Using the notion of “information model” and "concept arrangement patterns" defined by OMG's Standard Business Report Model (SBRM).
• Using the notion of “disclosure mechanics rules” to specify the proper representation of a specific disclosure. Here is a disclosure mechanics rule represented in XBRL definition relations.  The best example of disclosure mechanics rules are such rules that I created for US GAAP.  Here is the Inventory Roll Up rule using in the video.
• The notion of "type-subtype" or “wider-narrower” or “general-special” (i.e. subtype) relations is not used in the SFAC 6 representation because there are so few line items and there really are no detailed (i.e. narrower) relations. An excellent example of subtype relations exsits for IFRS class-subclass relations.
• Using the notion of a "mapping rule" which is, it seems, similar to a "type-subtype" relation overcomes the situation where there more than one concept could be used to represent information or two concepts might be combined to mean what one concept represents.  Here is an example which is represented using XBRL definition relations.  Here is a more comprehensive example related to US GAAP.
• Using the notion of “disclosure rule” or “reporting checklist” specifies the circumstances when each specific disclosure is required to be reported. A set of disclosure rules is provided in the form of an XBRL definition linkbase.

A by product of using these rules is that software applications can not only verify that reports are created correctly using a relable process, but they are very helpful in constructing software interfaces that business professionals use to create and financial reports.

(If you don't understand what I mean by logical system please watch this video playlist.)

Here is some really good information related to distinguishing between properly functioning and improperly functioning logical systems, such as an XBRL-based financial report.  It also helps you understand what it takes to keep such a logical system properly functioning and how to convert an improperly functioning system back into a properly functioning logical system: 

• Video (about 10 minutes)
• PDF of PowerPoint Presentation

This is what a properly functioning system looks like:

PROPER: Here is a human-readable review tool that shows the details of a properly functioning logical system. Notice that all the statements made within the system are consistent, complete, and precise.

IMPROPER: Here is a human-readable review tool that shows the details of an IMPROPERLY FUNCTIONING logical system.  Notice that the software makes you aware of the inconsistency in the statements.

IMPROPER: Here is a human-readable review tool that shows the details of an IMPROPERLY FUNCTIONING logical system.  Notice that the software DOES NOT MAKE YOU AWARE!!! of the inconsistency.  Why?  The rule "Assets = Liabilities + Equity" was removed.

That is why business rules are critical to the process of creating high-quality XBRL-based financial reports.