Digital Financial Reporting

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.