I have developed a technique that uses standard, off-the-shelf software or existing open-source software to make certain that the high-level fundamental accounting concept relations are (a) intact and consistent and (b) assure that a user of the report can reliably extract information from an XBRL-based financial report.
Further, if the SEC enforced its own rules that require XBRL calculations to be provided, then the entire balance sheet, income statement, cash flow statement, statement of changes in equity; and any disclosure that ties to those statements would also be verified to be correct (roll ups). This would still leave roll forwards and dimensional roll ups not being computed however because.
But, if software vendors and filing agents helping public companies create XBRL-based reports would use XBRL Formula during the creation process to verify all mathematical relations, then 100% of all facts that are on the primary financial statements or tie to the primary financial statements would be verified to be mathematically consistent with what one would expect.
Let me say this again. If the technique described in the first paragraph were used, then all of the fundamental accounting concept relations continuity cross checks would be passed by every software vendor and filing agent. What that would mean is that the validation results would look like this:
Note that there are ZERO inconsistencies with the high-level fundamental accounting concept continuity cross checks.
So, how does my technique work? It works like this: Each public company declares and/or configures their "reporting style" or their fundamental accounting concept relations when they create their report using machine-readable rules. The SEC could build upon this by (a) requiring reporting entities to include this declaration/configuration in their report and (b) providing validation that MUST be passed for a report to be accepted as filed with the SEC.
The process works like this:
- Define concepts: Each fundamental accounting concept is represented in machine-readable XBRL form, like this.
- Define impute rules: Each "impute rule" that is used to derive unreported facts is created in machine-readable XBRL form, using XBRL Formula. Here are two impute rules for deriving commonly unreported subtotals: Noncurrent Assets | Liabilities. (Ugly and hard for humans to read, yes I know; but (a) experts would create these rules that average accountants would use and (b) the users would interact with natural language representations of the rules such as "Assets = Current Assets + Noncurrent Assets" and "Liabilities = LiabilitiesAndEquity - Equity".) (Here are the 105 impute rules that I use)
- Define consistency rules: Each "consistency rule" would be defined in machine-readable XBRL form, using XBRL Formula. You would create sets of these rules for each statement format. Here are two examples: Classified Balance Sheet | Order of Liquidity Balance Sheet (Unclassified) (Here are the 49 consistency rules I use)
- Declare/Configure: Those creating reports would select (a) the consistency cross checks rules that described their reporting style and (b) any impute rules that are necessary for a machine to understand their high-level reported information. They would include the rule sets in their XBRL instance by referencing the rules. The rules could be included during the report creation process to test the consistency of the report to the consistency rules. The rules could be REMOVED from the XBRL instance prior to submitting to the SEC until such a time, if ever, that the SEC allows the rules declaring/configuring the fundamental organization of the report are allowed to be submitted.
- Result: The result would be (a) machine-readable rules that explicitly explain/declare the configuration of the report and (b) machine-based processes for verifying the consistency of the report to the declared configuration using existing off-the-shelf or open source XBRL processors and/or XBRL Formula processors.
This ZIP file contains a working proof of concept. This was run using the UBmatrix XBRL Processor and XBRL Formula Processor. This is the command line BATCH file that I used. I am going to test this same working proof of concept using Fujitsu, XBRLQuery, XBRL Cloud, and any other XBRL processor/XBRL Formula processor that I can get my hands on or get someone else to test.
This may not be the most effecient way to process this, but it does work effectively.
What I can imagine is that the Big 4 CPA firms and other interested parties will provide a lot of valuable input as to what is an allowed financial report configuration under US GAAP and IFRS.