This blog post is a reorganized version of a message I posted to the XBRL-public discussion group.
A year or so ago in a blog post I tried to explain the difference between an "open" taxonomy and a "closed" taxonomy. Someone pointed out to me, correctly so, that it is systems that are open or closed and that taxonomies always must be closed.
The XBRL International Taxonomy Guidance Document now uses these terms. What this really boils down to is the use of XBRL's extensibility. The desired goal here is to employ that extensibility effectively.
I believe that I can better articulate system dynamics now, this blog post is an attempt to do so. First though it is important to keep in the back of your mind the purpose of a system. I am speaking of systems such as XBRL-based public company financial filings submitted to the SEC which does employ extensibility. This is how I articulate the purpose of such a system:
Prudence dictates that using financial information from XBRL-based public company financial filings to the SEC should not be a guessing game. Safe, reliable, predictable, automated reuse of reported financial information by machine-based processes seems preferable.
Taxonomies MUST ALWAYS be "closed" or rather have conscious, known, understandable boundaries. Or more precisely, a taxonomy provides specific, conscious "openings" where those reporting against the taxonomy can consciously articulate specific information and therefore extend the taxonomy in conscious, known, specific ways ONLY. A machine-based system can tolerate zero ambiguity.
This is NOT to say that extensions cannot be employed. The FDIC system is successful because they matched the system and the taxonomy. The FDIC reporting system is "closed". The FDIC uses forms. Many others implementing XBRL "retreat" to this approach because they don't understand how to make XBRL's extensibility work or they believe that it cannot work so they don't bother to attempt to employ it.
The SEC use case is open reporting. US GAAP-based financial reporting is open, it is not a form. It is important to understand the difference between two terms at this point: arbitrary and standard.
- Standard: used or accepted as normal or average; something established by authority, custom, or general consent as a model or example
- Arbitrary: based on random choice or personal whim, rather than any reason or system; depending on individual discretion (as of a judge) and not fixed by law
US GAAP is not arbitrary, it is standard. A mistake the FASB made in creating the US GAAP XBRL Taxonomy and that the SEC made in defining the Edgar Filer Manual (EFM) rules is not establishing appropriate boundaries or specific, conscious "openings". To some, the system looks totally open and even random.
The external financial reporting managers of the public companies who file with the SEC know the rules of US GAAP. There is zero tolerance for error with respect to conformance with US GAAP. Now, with respect to XBRL-based digital financial reports conforming to US GAAP is hard right now because there are thousands of details that must be complied with but neither the FASB nor SEC provided those business rules which enables a machine to help external financial reporting managers conform. But that is changing. The market is providing the necessary machine-readable business rules. This can be seen by following the increasing conformance to the fundamental accounting concept conformance rules.
But there are two other missing "layers" of business rules relating to expressing financial information using XBRL-formatted information.
One missing layer is the notion of a machine-readable business report model. XBRL has an explicit business report model. In fact, XBRL has two explicit business report models which is part of the confusion when one attempts to understand the semantics of the model. There is one model expressed by the XBRL 2.1 technical specification. There is another model, built several years later, expressed using XBRL Dimensions 1.0. The people who created the XBRL Formulatechnical specification defined what amounts to an "aspect" based business report model can be used with both the XBRL 2.1 and XBRL Dimensions models. The people who wrote the XBRL International Abstract Model 2.0 also defined a model which tries to reconcile all of these different models into one business report semantic model.
This model is not "negotiable". These are technical specification all of which have conformance suites which ensures software interoperability. Arbitrary interpretation of the model is not allowed, the model is a standard. In fact, over 99.9% of the relations within XBRL-based filings conform with this report level semantic modelbecause the software they use REQUIRES them to comply because of those conformance suites. Some software does not comply and therefore you get external financial reporting managers who put a [Member] within a set of [Line Items] which makes zero logical sense. Now XBRL 2.1 allows that believe it or not, XBRL 2.1 has no knowledge of XBRL Dimensions. But XBRL Dimensions does NOT allow this and these rules are even enforced by the XBRL Dimensions specification.
Confusing? Yes, I understand. The US GAAP XBRL Taxonomy makes this even more confusing by using both the XBRL 2.1 model (no dimensions) and XBRL Dimensions (with dimensions) in the same taxonomy.
I articulated this business report model: Financial Report Semantics and Dynamics Theory. This helped me to sort through all of these moving parts and it has helped others to do the same. Further, I proved that 99.9% of SEC XBRL financial filings conform to this model.
So, a mistake the FASB and therefore the SEC (who uses the US GAAP XBRL Taxonomy created by the FASB) is making is that this business report model is not clearly articulated. In fact, the model is misunderstood and even abused. External financial reporting managers, given inappropriate guidance from others, are using the business report model somewhat like a presentation dart board. For example, anyone who puts a "Class of Stock [Axis]" on a balance sheet is misunderstanding this model. What they are saying is that "Cash and cash equivalents" has a characteristic that it does not have.
Dimensions articulate characteristics. Go to section 1.3 of the XBRL Dimensions specification which defines the term "dimension":
Dimension: "Each of the different aspects by which a fact MAY be characterised."
OK, so the question that raises is what is the definition of a characteristic. This is my definition of characteristic:
Characteristic: A characteristic describes a fact. A characteristic or distinguishing aspect provides information necessary to describe a fact or distinguish one fact from another fact. A fact may have one or many distinguishing characteristics.
Don't like my definition? Please point me to the FASB or SEC definition.
Reality is pretty clear and if a little common sense is employed, understanding this is rather straight forward: Cash and cash equivalents, Receivables, Inventory, Accounts payable, Long-term debt, Equity, don't have a class of stock [Axis] because they don't have that characteristic. If you want to break down common stock or preferred stock and you want to use an [Axis], you have to do it in another [Table].
So that is a mistake the FASB/SEC made: not clearly articulating the business report model and therefore rather than the one standard interpretation of the model, you get each external financial reporting manager, software vendor, etc. using their arbitrary interpretation of the model. That will not work.
A second mistake the FASB made is that they did not complete the US GAAP XBRL Taxonomy according to things articulated in the US GAAP Taxonomy Architecture. The notions of "extension points" and "extensibility rules" and "concept arrangement patterns" or patterns were all articulated in the US GAAP Taxonomy Architecture.
I understand extension points and extensibility rules because I was one of the authors of the US GAAP XBRL Taxonomy architecture. You can understand what "extension point" and "extensibility rules" are all about by looking at a few examples provided in this graphic:
(Click image for full graphic)
The graphic shows the fundamental accounting concepts broken down into groups:
- Concept REQUIRED. For example, dei:DocumentPeriodEndDate is a REQUIRED concept
- Concept MUST NOT be redefined or replaced. For example, "Current assets" CANNOT be redefined or replaced.
- Concept MAY be redefined. For example, NONE of the fundamental accounting concepts can be redefined.
- Concept MAY have a new child concept (subclass) created. For example, the concept "Cash and cash equivalents" can have a new subclass created such as "Petty cash".
The point is, concepts and relations between concepts act differently. The US GAAP XBRL Taxonomy treats every concept and relation pretty much the same.
Finally, part of the "extension point" and "extensibility rules" part is the notion of a "class" and "subclass". What I have discovered is that the rules necessary to provide the approprate boundaries and points of extneion go something like this:
- Concept has class: Every concept defined needs to be associated with some fundamental class.
- Don't cross classes: Filers MUST NEVER "cross classes", they cannot redefine the meaning of a class by using one class as part of another class. An example of this is how AT&T redefined operating expenses to include direct costs of sales. Filers MUST NEVER do this. Besides, the concept "Costs and expenses" already does that. Another example is filers redefininginterest and debt expense to be part of nonoperating income (expenses). A simple solution, if that is allowed, is to add a concept to the US GAAP XBRL Taxonomy "Nonoperating income (expense) including interest and debt expense.
- Associate EVERY extension with some class: Filers MUST be required to associate every extension that they create with some existing US GAAP XBRL Taxonomy class. This is not something the FASB does, but they could articulate this in their architecture. The SEC could do this, and MUST do this to make the system work correctly.
- Required totals/subtotals: I don't quite understand how to articulate this properly yet, but it goes something like this. Certain specific totals and subtotals MUST be explicitly reported. The reason is, if a machine has to impute (imply) missing values; the value is so essential that if it does not exist, there is a possibility that an error made by a creator of this information can be misinterpreted by a machine-based process and the filer error can mask an impute error. (This blog post explains the details of this, I have not totally figured this out yet)
And so, a taxonomy is never really "open" per se. A taxonomy provides specific "openings". The taxonomy enables those that report against the taxonomy known, understood openings which they must comply with. Those openings provide the system boundaries. Systems MUST have boundaries.
The FASB and SEC need to establish and communicate the appropriate boundaries via the specific openings they allow. They also need to clearly articulate and utilize the standard business report model articulated by the XBRL technical specifications. Arbitrary interpretation of the standard model will never work.