Best Processing Approach for Fundamental Accounting Concepts Metadata?
Saturday, April 16, 2016 at 07:12AM
Charlie in Becoming an XBRL Master Craftsman

I now have an updated set of fundamental accounting concepts metadata to pure XBRL. One software vendor implemented that metadata (more on that later) to create some incredibly useful queries of the XBRL-based information from public company financial reports to the SEC.  Here are three examples of those queries you will want to be sure to check out on the page above:

Analysis of interest-based revenues:

(Click image to navigate to web page)

Analysis of insurance-based revenues:

(Click image to navigate to web page)

Comparison of entity across periods:

(Click image to navigate to web page)

The query results you see are screen shots of query results.  The actual queries are a substantial improvement over other query examples that I have provided. First, it is a full implementation of the fundamental accounting concept relations.  Second, the implementation is pure XBRL and what I have been trying to get to for some time.

While the fundamental accounting concepts metadata representation approach is very good in my view and the queries using that metadata are impressive and useful; the real question that I am trying to answer is what is the best way to process this XBRL-based machine-readable metadata.

I now have three distinct sets of relations that I want/need to process:

  1. Fundamental accounting concept relations: These are US GAAP specific financial accounting relations.  These same types of relations exist for IFRS financial reporting.
  2. Disclosure mechanical relations: These are general mechanical-type relations that exist for all financial disclosures with some SEC-specific stuff mixed in that probably should be separated out.  I am pretty sure this can be generalized.  These sorts of relations are used to identify a disclosure and explain the mechanics of a disclosure.  For example, these rules are things like what concept is used to represent the total of the disclosure, what type of concept arrangement pattern is the disclosure (roll up, roll forward, etc), what is the matching text block for the detailed disclosure, and so forth.  General, mechanical stuff.
  3. Disclosure accounting relations: The most valuable stuff is the accounting knowledge related to disclosures and that is this category.  Information such as "IF you have disclosure A, THEN you also need disclosure B".  Or, "IF the line item A exists in the balance shet, THEN policy B" must be provided.  Basically, these are machine-readable rules that you would find in what accountants call a disclosure checklist.

If you don't understand what a disclosure checklist is, read Digitizing Disclosures Part 1, Part 2, and Part 3. And if you really want to understand the remaining part of this discussion and have not read it yet, I would very strongly recommend that you read the Digital Financial Reporting Manifesto because it pulls together a lot of the moving pieces to the puzzle.

And finally, keep in mind that I have represented the financial reporting ontology which is additional metadata in a pure XBRL format also.

And so this is the $64,000 question that I am trying to find an answer to: 

"What is the best way to process all of this XBRL-based metadata?"

This is where I have more questions than answers. I considered this in a blog post where I contemplated the difference between a semantic reasoner, an inference engine, and so forth. And then there was this blog post where I considered the difference between forward chaining and backward chaining.  And then you have the consideration of decidability and other logical catastrophes that need to be avoided at all cost because they completely break systems.

And so I show above WHAT I want to process.  I point out that it is specifically NOT THE CASE that "anyone can say anything about anything" for what I am trying to process. That mantra of the semantic web is a wonderful objective and a good goal; but it is NOT the objective or requirement here.

And so, this is what I speculate based on the evidence that I see:

Considering all of those details above, this is what I speculate.  The ultimate goal is some sort of reasoner, processor, inference engine, math engine, and so forth that is specific to business reports.  If another layer above the business report needs to be created for the special case of financial reporting, fine.  But try to avoid the separation if possible.  Recreating PROLOG or DATALOG might, or might not be a good idea.  I don't know.  If an XBRL Formula processor is based on PROLOG, as I have been told by people I trust, then does an XBRL Formula Processor already do a lot of what PROLOG does?

The lack of a global standard chaining model will eventually be solved, it has to be.  Either a global standard will be created or a de facto standard will appear.  Probably both forward and backward chaining models will likely be created.  Perhaps chaining models already exist.  Can you get away with forward chaining alone?  I doubt it.

Again, please read the Digital Financial Reporting Manifesto for more details. While the organization of that document could use improvement, all the important information is there.

Know the answer to this question?  Please let me know because I am seriously looking for an answer because I am working with some people who are building approaches to processing all this fundamental accounting concept relations and other metadata.

 

Article originally appeared on Intelligent XBRL-based structured digital financial reporting using US GAAP and IFRS (http://xbrl.squarespace.com/).
See website for complete article licensing information.