Fundamental Accounting Concepts

HOME

This resource provideds documentation for the fundamental accounting concepts relations metadata. Documentation is provided in both human-readable and machine-readable form. All machine-readable information is XBRL-based.

Concepts - high-level financial report concepts
Neworks - organize the concepts into sets of relations
Consistency rules - business rules that explicitly state the relations between concepts
Impute Rules - rules for imputing high-level concepts which are not explicitly reported
Mappings - concepts which economic entities use to report high-level financial report concepts
Reporting styles - sets of networks which detail how specific economic entity report

Concepts

Human-readable: HTML | Machine-readable: XBRL

Networks

Human-readable: HTML | Machine-readable: XBRL

Consistency Rules

Human-readable: RSS | Machine-readable: RSS

(NOTE: I think the HUMAN readable version should be RSS, and the MACHINE readable version would be XBRL)

Impute Rules

Human-readable: RSS | Machine-readable: RSS

(NOTE: I think the HUMAN readable version should be RSS, and the MACHINE readable version would be XBRL)

Details

Processing

This section helps you understand how to process the fundamental accounting concept relations metadata. Step-by-step instuctions are provided. If you have any questions, email me.

NOTE: If you are good at reverse-engineering things, this is an older version of the fundamental accounting concepts. You can learn this process by exploring this older process. What I think would work best is if you (a) understood the older process, then (b) walked through the new process to see how the metadata has been reorganized, and then (c) use the new metadata approach in the onder processing process. The processing process is the same; only the metadata syntax has changed between the old and new approach.

Get XBRL instance: The first thing you need to do is get the XBRL instance document you want to process. You ONLY need the XBRL instance, not the related taxonomies. For example, here is an Apple 10-Q.
Get base information: Next you need to get base information. In the sample code, see function "GetBaseInformation". You get information such as the entity name, fiscal period, etc. This step is actually not needed for processing the fundamental accounting concept relations information.
Get entity of focus For this step you don't really 'do' anyhing, you know the entity of focus or the economic entity that is reporting by default because that entity has no dimensional information in the context. So this is easy. If you want to know more about the root economic entity, then read this.
Get period information Next you need to get the current balance sheet date and current year-to-date income statement period. In the sample code, see the function "GetCurrentPeriodAndContextInformation". Essentially you are using the dei:DocumentPeriodEndDate fact value and context to get the context IDs that you need to grab the correct facts. If you want more information, read this.
Get facts based on mappings: Because sometimes a reporting entity can choose between more than one concept to report a fact, mappings are created to tell the process which concepts to look for. Each network has a mapping file. Here is an example mapping file in human-readable HTML. Here is the same information in machine-readable XBRL. Again, mapping files exist for each network. NOTE that in the older version of the fundamental accounting concept relations the mappings where HARD CODED. See the function 'GetInformation_BalanceSheet' in the sample code. Now, mappings are provided using XBRL definition relations. NOTE: I could have used the XBRL 'essence-alias' relation defined by XBRL, but I did not. I am evaluating whether to change to that standard arcrole.
Impute unreported high-level fact values: After you get all the facts, you need to impute implied information that was not explicitly reported. For example, not every reporting entity provides a line item for "Noncurrent assets". BUT, pretty much EVERY entity reports "Assets" and "Current assets" (if they report a classified balance sheet). Every accountant knows that "Assets = Current assets + Noncurrent assets". And so using the rules of mathmatics; "Noncurrent assets = Assets - Current assets". These imputes must be done IN ORDER (i.e. forward chaining). You can use backward chaining then order would not matter; but I don't have a backward chaining engine. Here is an example set of impute rules in human-readable HTML. Here is ONE RULE in machine-readable XBRL Formula. The set of impute rules to use and the order that they should be executed is contained in the schema for the network. I will get to that in a minute.
Check consistency of fundamental accounting concept relations: Next, you execute the consistency checks for each network. Those too, like the impute rules, are in the schema for each network. I will point you to that in a moment. Consistency rules are simply relations between accounting concepts that never change. The ultimate consistency rules is the accounting equation. Consistency rules are likewise represented in human-readable HTML and in in machine-readable XBRL Formula. (That is the accounting equation by the way).
Start with the schema for a network: The mapping rules, the impute rules, the consistency rules, and everything else you need to process a network of a piece of a financial report for a specific reporting style is all hooked together with an XBRL taxonomy schema. Here is the relations information in human-readable HTML and the mappings and rules in human-readable HTML. And here is the XBRL taxonomy schema in human-readable XBRL.

All of this raises the $64,000 question: "What is the best way to process all of this?" 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.

There is one other additional consideration. The fundamental accounting concept relations is a SUBSET of the complete set of processing that someone will want to do against XBRL-based digital business reports and digital financial reports. The remaining piece of the puzzle is the disclosures. I considered this. In the blog post State-of-the-Art Use of XBRL Definition Relations To Express Business Rules I have, I believe, the remaining piece of the puzzle. What that shows is that the mathematical processing is the same, but the relationship processing is more robust when you get to the disclosures. Other relations are defined here in the Financial Report Ontology. Articulating all these sorts of relations needs to be considered. And so, this is what I speculate:

It is far easier to make an XBRL formula processor (which already supports dimensions and mathematical computations well) support the additional relational processing that you need than it is to modify an RDF reasoner or other semantic reasoner/inference engine to support dimensions and mathematics.
RDF is too low-level for business professionals to deal with; business professionals will never be able to write rules in RDF/OWL. The fact-of-the-matter is that the average business person will not even be able to write rules in XBRL. That is why an abstraction layer and other techniques need to be used to move the complexity away from the business user. All this is explained in the document Understanding Blocks, Slots, Templates, and Exemplars.
The XBRL Formula specification does not have a standard chaining model. That does not mean that you cannot create chaining within an XBRL Formula processor; all the lack of a standard means is that the chaining that you come up with will not be standard because there IS NO STANDARD for chaining. As I understand it, XBRL Formula is fundamentally based on PROLOG and PROLOG supports backward chaining. So, I think that the internals of an XBRL Formula processor actually do chaining when it does it's work; but that chaining is not exposed to the user of the XBRL Formula processor. I do know that forward chaining is easier for most people to get their heads around, but it does have limitations. Backward chaining is very powerful and probably needed. My conclusion: have both backward and forward chaining features in an XBRL Formula processor. I think that might be possible, but it might not be practical.
I will not even call what is needed an XBRL Formula processor, although it will only be processing XBRL. I will call it a "business report processor" and/or a "financial report processor". A financial report is a class of business report. I think the only thing that changes when you move from "business report" to "financial report" is metadata. And therefore, it could be the case that you don't need a financial report processor at all. I don't know the answer to that either. What I do know is all the stuff that is in this document: Digital Financial Reporting Manifesto. And if financial reporting is a class of business reporting; then either (a) all business report processors need to support the stuff in that document or (b) a financial report processor is necessary.

Testing/Working Networks

Here are the individual networks that are currently working using the new pure XBRL approach: (all mappings, impute rules, and consistency rules are provided)

To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work.