XBRL stands for Extensible Business Reporting Language and is an XML-based file which uses accepted financial reporting standards to exchange financial statements across all systems.
According to the XBRL.org website, “The international XBRL consortium is supported by more than 600 member organisations, from both the private and public sectors”. And some of the most important features of XBRL are: Testable Business Rules and Strong Software Support.
Recently, in FlexRule we have built a software application based on Charles Hoffman’s Fundamental Accounting Concepts. In this app, we can validate SEC Filings against the Fundamental Accounting Concepts (accounting’s business rules).
In this project, we have modelled all the networks (Balance Sheet, Income Statement, etc.). In this article, all examples and screenshots are taken from the Balance Sheet network. Below is a flow that shows how we modelled the steps:
As you can see from the above screenshot, the Flow contains 4 steps, as follows:
- Load XBRL instance
- Reading reported facts by mapping
- Imputing related information that are not reported
- Running accounting consistency rules
Load XBRL instance
In this step, we load the XBRL instance in order to have full control of all of its elements.
FlexRule can deal with complex XML documents easily as part of its dynamic and powerful expression language. You don’t need even to use any external utility. To learn more please check XML101.
Reported Facts and Mappings
According to the each XBRL accounting Concept, each related Fact has its own mapping in the instance.
So in the second step, for each Fact we created a Decision Table capable of searching in the XBRL instance to find an existing mapping for each Fact.
For example, as you can see in the screenshot below, Assets can be reported in 2 addresses: us-gaap:Assets and us-gaap:AssetsCurrent
If no mapping is found, then the Fact is flagged for further investigation.
The Decision Requirement Diagram (DRD) allows us to resolve the hierarchical mappings for all reported Facts. As you can see in the screenshot below, all Facts have been added to a DRD.
There are multiple different DRDs in the solution that allows resolving dependencies for each individual networks. The above example is for “Balance Sheet Classified”.
In step 3, we used a decision logic (Decision Table) for imputing the rules. In this step, according to the reported Fact’s values and Impute rules, we might come up with new values for some Facts. Here is an example of one of the Impute rules:
if (($Assets = 0) and not($LiabilitiesAndEquity = 0) and ($CurrentAssets = $LiabilitiesAndEquity)) then ($Assets = $CurrentAssets) else ($Assets = $Assets)
And in the last step, by having all Facts values (reported and imputed), we will run multiple decision logic in form of Decision Tables to find out which consistency rules will be met.
Below is an example of consistency Decision Tables:
To learn more about how decision table works have a look at our resource hub.
In future posts we will talk more about our software application and the way it works.
Last updated November 6th, 2019 at 12:19 pm, Published March 20th, 2017 at 12:19 pm
VP of Customer Success, leading digital and decision transformation initiatives for customers across industries and ensuring successful project implementations with 10+ years of experience and focus on product innovation, end-to-end customer support, and managing high-performing and talented customer success team.