Digital Financial Reporting

The following is a summary of information about XBRL-based digital financial reports which may, or may not, be apparent to you.  All this was not apparent to me until I observed very deeply many, many XBRL-based public company digital financial reports.  This information is not laid out well in either the US GAAP XBRL Taxonomy nor in the SEC Edgar Filer Manual.

Notion of "Section" or "Report Fragment" or "Component"

While it does not have an official name in the EFM, section 6.7.12implies the notion of a "section" or what the US GAAP XBRL Taxonomy architecture calls a "report fragment" or what I call a "component":

6.7.12  A link:roleType element must contain a link:definition child element whose content will communicate the title of the section, the level of facts in the instance that a presentation relationship in the base set of that role would display, and sort alphanumerically into the order that sections appear in the official HTML/ASCII document.

The link:roleType link:definition text must match the following pattern:

{SortCode} - {Type} - {Title}

The {Type} must be one of the words ‘Disclosure’, ‘Document’, ‘Schedule’ or ‘Statement’.

I gave this idea a name, the "SEC Disclosure Type", and represented this information in the Financial Report Ontology:

Notion of "Level"

Later on in that same section 6.7.12, the EFM discusses the notion of "level" and explains the ordering of the sections (described above) relative to one another.  That section states, in part:

1. Each Statement must appear in at least one base set, in the order the statement appeared in the official HTML/ASCII document.

2. If the presentation relationships of more than one base set contains the facts of a Statement(to achieve a layout effect, such as a set of rows, followed by a table with a dimension axis on the vertical, followed by another set of rows) then the {SortCode} of that base set must sort in the order that the rows of the Statement will be displayed.

3. A Statement that contains parenthetical disclosures on one or more rows must have a base set immediately following that of the Statement, where all facts in its parenthetical disclosures appear in presentation relationships.

4. All base sets containing the contents of Footnotes must appear after base sets containing the contents of Statements.

5. A Text Block for each Footnote must appear in at least one presentation relationship in a base set.

6. Each base set for a “Footnote as a Text Block” presentation link must contain one presentation relationship whose target is a Text Block.

7. Base sets with presentation relationships for a Footnote tagged at level 2 must appear after all base sets tagged at level 1.

8. A base set with presentation relationships for a Footnote tagged at level 3 must appear after all base sets tagged at level 2.

9. A base set with presentation relationships for a Footnote tagged at level 4 must appear after all base sets tagged at level 3.

A couple of things.  The EFM the term "base set" when they actually mean "Network" or "Network of relations" I believe.  Regardless, what they are referring to is the sections or fragments or components that make up a full report which are represented by the "base set" or "Network" or "Network of relations".

I captured the notion of "level" in the Financial Report Ontology as follows:

Notion of Report Element Categories

Both the EFM and the US GAAP XBRL Taxonomy Architecture imply the notion of report element categories.

Further, there are allowed and disallowed relations between these report element categories which I have summarized graphically as follows:

(Click image for larger view and more information) 

Notion of the Concept Arrangement Pattern

Concepts (and Abstracts which is a form of a concept) are arranged in patterns.  The US GAAP XBRL Taxonomy explicitly mentions the "Roll Forward" pattern (Beginning balance + Changes = Ending Balance).  But there are other patterns.  These are summarized in the Financial Report Ontology as follows:

Notion of the Member Arrangement Pattern

Just like how concepts have arrangement patterns; the [Member]s within an [Axis] likewise have patterns.  While not as fully developed (yet), there are two specific types of patterns which are articulated in the Financial Report Ontology:

A "Whole-Part" relation is where something is composed exactly of their parts and nothing else or more where the parts add up to the whole.  A "Part-Of" relation simply describes the parts, but the parts do not add up.

Relation Between Level 3 Text Block and Level 4 Detailed Disclosure

If you read the EFM or observe XBRL-based public company financial filings, you understand that there is a relationship between the Level 3 Text Block disclosure and the Level 4 Detailed disclosure of information.  Here are two specific comparisons:

• Property, plant and equipment by type
• Long-term debt maturities

If you look at those two documents and you consider the other information above (and other information which I have not gone over), you see lots of patterns.  To provide a basic example, consider those two disclosures above.  These can be found represented in XBRL-based public company financial filings in at least the following four ways:

• Property, plant, and equipment by Type [Roll Up]
• Property, plant, and equipment by Type [Roll Up] (using Axis/Member)
• Long-term debt maturities [Roll Up]
• Long-term debt maturities [Hierarchy]

Notion of Disclosure Business Rules

You take all the information above and you can articulate knowledge in machine-readable form.  Here is an example of four such disclosure business rules:

Those machine-readable rules (which you can grab here) can be used to generate the human-readable business rules needed by business professionals.

Business rules for every disclosure

Similar to the fundamental accounting concept relations business rules, imagine business rules for every possible disclosure.  That is what is on deck for XBRL-based public company financial reports!  Just like the fundamental accounting concept relations consistency can be measured, consistency of disclosures to the disclosure rules can likewise be measured.

A financial report is really many report fragments which work together to represent the entire report.  The report fragments need to be internally consistent and consistent with other reoprt fragments.  Why is this important? These rules are used to both describe and keep digital financial reports consistent with that description.

For more information, please read chapters 1 through 10 of Digital Financial Reporting.

Article 9 of the Business Rules Manifesto states:

Article 9. Of, By, and For Business People, Not IT People
 
9.1.  Rules should arise from knowledgeable business people.
 
9.2.  Business people should have tools available to help them formulate, validate, and manage rules.
 
9.3.  Business people should have tools available to help them verify business rules against each other for consistency.

Business rules can relate to data quality logic and business logic.  Both are important to business professionals.  Business rules are used to both describe a domain and to verify that information expressed is consistent with that description.

Take a basic data quality example: the allowed relations between the categories of pieces that make up a digital financial report.  I call this the model structure relations.  The categories of pieces include: Network, Table, Axis, Member, Line Items, Abstract, and Concept.

The US GAAP XBRL Taxonomy Architecture Section 4.5 describes the relations between those categories, sort of.  You can go read the document and sort out the allowed relations.

This set of machine-readable XBRL definition relations likewise describes allowed/disallowed relations between the categories of the pieces.  While that information is machine readable, it is hard for a human to understand that those XBRL definition relations are saying.  It is almost impossible for a business professional to understand them.

Why does a business professional need to understand the relations?  First, to determine if the relations are correct.  Second, when working with a digital financial report, they need transparency into why something is wrong: which rule is being violated.

This is another way to express business rules:

(Click image to go to rules)

That graphical view above allows a business professional to better understand the machine-readable rules.  The tabular view below does the same thing.

(Click image to view)

Business professionals don't know how to read Python code.  Why would the XBRL US Data Quality Committee provide business rules in the Python format? First, business professionals cannot read them.  Second, if you don't use the Python language to create your software you need to convert the Python into the format that you need.

A neutral format such as the XBRL global standard is a much better medium for expressing business rules.  Software can read the rule and convert it into whatever format they might desire.

Here are several high-quality basic XBRL Formula examples.

• XBRL Instance and Taxonomy (and other helpful human-readable information)
  • Example 1
  • Example 2
  • Example 3
  • Example 4

You can see the messages provided and the results of the rules here. (Uses the XBRL Cloud Evidence Package which shows how the rules are used.)

Each of 76 small examples has XBRL Formulas based business rules associated with them.  Just click on each template and on the page brought up, see the XBRL instance, the XBRL taxonomy and the XBRL Formula based business rules file.

By "high-quality" I mean that the rules solve real but fairly basic business rules needs and they have been tested against 4 XBRL Formula Processors which (a) each say the syntax is correct and (b) provide the same results for a given business rule.

This is a working prototype of a business rule creation interface:

(Click image for larger view)Business rules are created leveraging patterns in the semantics for which rules are constructed.  For example, "roll up" and "roll forward" rule creation templates are used rather than forcing business professionals to learn to work with the XBRL Formula syntax. 

In a document related to a periodic review of the structure and effectiveness of the IFRS Foundation, the term "structured digital reporting" is used and described.  See page 13 of the request for comment which states in part: (emphasis was added by me)

Relevance of IFRS in structured digital reporting: IFRS Taxonomy

29. Users of general purpose financial reports do not all access or process the information in those reports in the same way. Some investors and analysts focus on how information is presented by management, as reflected by their support for the IASB’s projects on Financial Statement Presentation and the Disclosure Initiative. Other investors and analysts are more focused on the data within a general purpose financial report, and either extract data from the reports to use in their models or use data aggregator services to access the data. IFRS deals with the substance and content of the transactions and other economic phenomena that should be reported in general purpose financial reports. The IASB’s expertise is in determining how transactions and economic phenomena should be classified, measured and presented in general purpose financial reports. The IASB focuses on understanding the needs of the different types of users and uses of general purpose financial reporting and sets its Standards with these in mind.

30. The IASB’s Standards are developed on the basis that entities are required to prepare a general purpose financial report whether that report is printed or in electronic format, ranging from a PDF version to one that is ‘tagged’ (in a computer-readable code that identifies specific items) using a structured data format. One of the reasons the IASB produces the IFRS Taxonomy is to assist with the accurate digital representation of IFRS in a structured format—ie with the information tagged and structured to help with searches and analysis.

I use the term "digital financial reporting".  But structured digital reporting and digital financial reporting are talking about exactly the same thing.

More and more people seem to be understanding that "digital" is a new way to represent financial information. "Printed" financial reports will likely always hang around just like vinyl records hang around even though most music is in MP3 format.  But "digital" will likely increase in volume, and "printed" will likely decrease in volume over the coming years.  "Digital" will change financial report creation work practices.  Just like you can "print" a photograph from a digital image; rather than starting with the printed image and "scanning" the print to get a digital copy. 

Today's practice of "bolting on" the structuring process to the end of the print process is backwards.  This blog post describes in general terms how structured digital reporting/digital financial reporting will work. This blog post explains what makes structured digital reporting/digital financial reporting.

I know this is a mental leap, but this video shows CAD software which is used to design cabinets in action.  Notice how parameters are changed and then the image in the drawing and the drawing itself changes.  I know it is hard to imagine, but structured digital reporting/digital financial reporting will work in a similar manner.  This blog posts will point you to a document which helps you understand this.

Structured digital reporting/digital financial reporting is not only inevitable, it is imminent.  Investment in becoming an XBRL master craftsman will pay dividends for a long time to come. Hone those knowledge engineering skills.

As I said, I screwed up the implementation of the fundamental accounting concepts. They work fine, they are just hard to maintain. And so, I am creating a refactored version of the fundamental accounting concepts metadata in order to test some new ideas.  None of the rules will change, only the way the rules are articulated.

The goals of the refactoring are the following:

• Use pure XBRL:  While I tried to use XBRL as much as I could, the impute rules were not in an XBRL format.  Basically, they were text files.  No problem, I rearticulated the rules using XBRL Formula. Here is an example of one rule in XBRL Formula.
• Consistency with other rules:  There are a bunch of other business rules that I have.  I wanted to standardize on one approach to articulating business rules.
• Remove redundancy:  If you look at the impute rules you can see that many rules are redundant. To correct this I made the rules more modular, one rule per XBRL Formula file.  Why?  Because I can then pick and choose individual rules easily.
• Improve the impute process: If you look at the impute rules they are in a specific sequence. The reason is that the order in which things are imputed matters.  And so I did the obvious thing and I constructed the rules in the order that I wanted (forward chaining).  But there are two problems.  First, I am not completely sure I got the rules in the correct order.  Second, figuring out the correct order is complicated.  The way to fix that problem is to use backward chaining and let the software figure out the impute order.
• Minimize maintenance effort:  A more modular configuration is much easier to maintain.
• Allow others to easily configure or reconfigure rules: With the old approach it is much harder add one rule or remove one rule. With the new approach, using XBRL's extensibility features and XBRL's prohibition functionality, adding or removing rules becomes significantly easier.

Here is what I have this far.  Here is the prototype entry schema.  That entry schema points to the set of rules you want to apply.  You can completely ignore a rule by creating a schema and leaving the rule out.  You can add new rules by creating a rule formula using XBRL Formula and then create your own schema and point to your rule and any other existing rules that you desire.  So far I have the cash flow statement concept relations rules completed and ready for testing and one impute rule.  I am pretty sure I have the relations rules correct but I need to check the syntax of the impute rules as I have not written that type of rule before.  Here is a list of what I have:

• CF1: NetCashFlow = (NetCashFlowFromOperatingActivities + NetCashFlowFromInvestingActivities + NetCashFlowFromFinancingActivities + ExchangeGainsLosses)
• CF2: NetCashFlowContinuing = (NetCashFlowFromOperatingActivitiesContinuing + NetCashFlowFromInvestingActivitiesContinuing + NetCashFlowFromFinancingActivitiesContinuing)
• CF3: NetCashFlowDiscontinued = (NetCashFlowFromOperatingActivitiesDiscontinued + NetCashFlowFromInvestingActivitiesDiscontinued + NetCashFlowFromFinancingActivitiesDiscontinued)
• CF4: NetCashFlowFromOperatingActivities = (NetCashFlowFromOperatingActivitiesContinuing + NetCashFlowFromOperatingActivitiesDiscontinued)
• CF5: NetCashFlowFromInvestingActivities - (NetCashFlowFromInvestingActivitiesContinuing + NetCashFlowFromInvestingActivitiesDiscontinued)
• CF6: NetCashFlowFromFinancingActivities - (NetCashFlowFromFinancingActivitiesContinuing + NetCashFlowFromFinancingActivitiesDiscontinued)
• CF Impute rule 01: if (NetCashFlow eq 0 and not(NetCashFlowContinuing eq 0) and not(NetCashFlowDiscontinued eq 0)) then (NetCashFlow = NetCashFlowContinuing + NetCashFlowDiscontinued + ExchangeGainsLosses) else (NetCashFlow eq 0)

Business professionals, don't worry about the XBRL Formula syntax.  You will never deal with that syntax.  Smart software vendors will use techniques to have the software deal with the syntax.  Specific techniques are outlined in this document.  There are plenty of patterns in those formulas to latch onto and burry deep in user software so you never deal with syntax.

Business professionals should be focused on the rules themselves, if they agree or disagree with specified rules.  Because the fundamental accounting concept relations are so, well fundamental, there really is not much to disagree with for these six rules.  Besides, given that over 95% of all public companies are consistent with these rules, coming up with a reason one of these rules is wrong will likely prove challenging.  But for other unproven rules reaching consensus will be important.

There is one issue.  XBRL Formula processors don't support a global standard chaining approach, backward or forward.  This is not a problem.  Proprietary chaining approaches can be created and used until XBRL International publishes a global standard chaining specification.

XBRL master craftsmen pay attention!  This is important stuff.  If you have any feedback which will further improve this prototype please send it along.  I would prefer not to redo this a third time.