Digital Financial Reporting

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.