Digital Financial Reporting

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.