« Standards Make Markets | Main | XBRL Taxonomy Creator Prototoype Shows Real Time Validation »

Understanding the Meta-Model of a Financial Report

In his paper On the Unification Power of Models, Jean Bézivin points out the advantages of models: conceptual simplicity, clear architecture, efficient implementation, high scalability, and good flexibility.  Even models can have models.  A model of a model is a meta-model. You can even have meta-meta-models!

Models are basically about leveraging patterns. I have been pointing out the conceptual model of a financial report for quite some time.

So, I think that what I am actually representing is the meta-model of a financial report.  I say that because each financial report created is actual itself a model.  Both OMG and ISO describe the difference between and implementation, a model, and a meta-model.  It seems that in a financial report facts are reported, the reporting entity describes and represents those fact relative to other facts in a model, and that financial report model is described by a meta-model.

Here is the most recent version of my model, or meta-model, of a financial report which is a type of business report:

  • Report: A report is a set of identifiable facts distinguished from one another by one or many characteristics plus information that can be used to describe and verify the logical, mechanical, mathematical, structural, and other such relations between facts.
  • Fragment: A fragment is a part of a report.  A report is made up of one or many fragments.  A fragment is a set of facts.
  • Fact: A fact defines a single, observable, piece of information contained within a report, or fact value, conceptualized for unambiguous interpretation or analysis by one or more distinguishing characteristics.  Facts can be a single numbers, a phrase of text, or prose (a set of numbers and/or text formatted generally for human consumption).
  • Characteristic: A characteristic describes a fact (a characteristic is a property of a fact). A characteristic provides information necessary to describe a fact and distinguish one fact from another fact. A fact may have one or many distinguishing characteristics.
  • Fact Table: A fact table is a set of facts which go together for some specific reason.  All the facts in a fact table share the same characteristics.
  • Relation: A relation is how one thing in a report is or can be related to some other thing in a report.  These relations, often referred to as business rules, describe logical, mechanical, mathematical, structural, and other such constraints.  There are three primary types of relations (others can exist):
    • Whole-part: something composed exactly of their parts and nothing else; the sum of the parts is equal to the whole (roll up).
    • Is-a:  descriptive and differentiates one type or class of thing from some different type or class of thing; but the things do not add up to a whole.
    • Computational business rule: Other types of computational business rules can exist such as "Beginning balance + changes = Ending Balance" (roll forward)  or "Net income (loss) / Weighted average shares = Earnings per share".
  • Grain: Grain is the level of depth of information or granularity.  The lowest level of granularity is the actual transaction, event, circumstance, or other phenomenon represented in a financial report.

Essentially, the model of a business report and therefore a financial report is the multidimensional model.

Now, when the XBRL technical syntax was created, certain terms were used.  Unfortunately, the XBRL technical syntax was created without the logic of a business report being expressed within a model.  And so, there are some differences and inconsistencies in the terms used by the XBRL technical syntax.  Further, when the US GAAP XBRL Taxonomy and IFRS XBRL Taxonomy were created, they used even different terms.  For example, people thought that the term "hypercube" and "dimension" were too technical and so they used the terms "Table" and "Axis" instead.  All these terms cause confusion.

Here are the terms used by those implementing software, in the creation of XBRL taxonomies or the model structure of the report, and used within the XBRL technical specification to describe a business report:

  • Network/Group: A Network is a technical artifact that really has no meaning by itself because those creating XBRL-based digital financial reports use Networks in different ways. Other terms used to describe a network are "group" and "base set". A Network/Group essentially breaks a report into fragments.
  • Hypercube/Table: A Table is the same thing that XBRL calls a hypercube.  A Table/Hypercube simply groups some set of Axes, Members, Line Items, Abstracts, and Concepts together into a logical structure.  Again, because Table's are used inconsistently by creating XBRL taxonomies, they really have no meaning by themselves. Tables/Hypercubes are essentially another way to break a report into smaller fragments.
  • Dimension/Axis:  An Axis, or what XBRL calls a dimension and XBRL Formula calls an aspect, is one approach to representing a Characteristic. Entity and period core dimensions that are always required.  Those creating XBRL taxonomies can create additional non-core dimensions.
  • Member: A Member is a possible value of a Characteristic.
  • Primary Items/Line Items:  A Line Items, or Primary Items as called by the XBRL Dimensions specification, is in essence a special type of Dimension/Axis which specifies a data type, period type, and optionally a balance type. Line Items/Primary Items are Characteristics.
  • Abstract: An Abstract is simply used to organize Line Items/Primary Items; they provide no real meaning.  When used, Abstracts can make a model easier to understand.
  • Concept: A Concept is in essence a type of Member.  You can think of a Concept as a value for the Line Items Characteristic.  A Concept is special in that it can be used to represent a Fact Value.
  • Fact: A Fact is a fact value plus all supporting Characteristics which describes the fact.  Numeric facts have the additional properties of rounding and units.  Optionally, a fact can be associated with one to many parenthetical explanations.
  • Parenthetical explanation: A parenthetical explanation (implementation of an XBRL Footnote) is a property of a fact which provides additional descriptive information about the fact.  Basically, a parenthetical explanation is a comment that you add to a Fact.
  • Report: A report is the combination of an XBRL instance plus the XBRL taxonomy schema and all linkbases which describe and can be used to verify the logic, mathematics, structure, mechanics, and other such information within the report.

To test this model, I looked at the pieces and the relations which made up the model structure between the pieces in 5,734 XBRL-based reports, all of which were 10-Ks, to examine the relations between the pieces that made up the report.  This matrix summarizes the results:

(Click image for larger view)

There is one additional structural piece that I created for the purpose of untangling the XBRL-based reports that are submitted to the SEC which are maybe 10% t0 20% of the time structured "illogically" or more complicated than the representation really needs to be mainly because many of the creators of reports tend to be more focused on the presentation of the reports rather than the representation of the information contained in the reports. 

I call this additional "utility" structure that I created the Block.  A Block is simply a fragment of a report that shares the same Concept Arrangement Pattern and Member Arrangement Pattern.  A concept arrangement pattern is simply how Line Items/Primary Items can be logically organized and a member arrangement pattern is simply how Members of a Dimension/Axis are organized.

The notion of a Block would not be necessary if XBRL taxonomies where architected "crisply".  You only need Blocks to untangle poor taxonomy designs which lead to poor report representations.

Financial reports submitted to the SEC using US GAAP or IFRS follow the model described above.  ESMA appears to be using that same model.  AISC which uses IFRS AU also follows that model.  See this side-by-side comparison.  As such, this model appears to be somewhat of a de facto standard meta-model of a financial report.

There is one more part of the meta-model of a financial report. That other thing is the "stuff" that goes into the model such as "assets", "liabilities", "equty", "net income", "net cash flow", and such.

From early meetings of XBRL International such as the one in London, people have been calling for US GAAP and IFRS to share certain concepts.   So, I still don't know if this is a good idea or not.  But, an alternative is to map high-level US GAAP terms to their closest counter part in IFRS.  I am not saying that these financial report items are measured the same or even mean the same thing.  I am simply pointing out similarities which result from a financial reporting scheme following the accounting equation which is the basis for double-entry accounting.

Now, if you talked to the typical accountant about this comparison across reporting schemes; they would likely be pedantic and miss the point.  They would say, "You cannot compare US GAAP and IFRS."  First, I am not 'comparing'.  What I have done is created a four column list and in each column I have provided the concepts in the different reporting schemes that have the closest match.  Yes, it is true that "Assets" is measured differently and defined differently under IFRS than US GAAP.  HOWEVEVER, that does not mean that this information below is not useful.  Notice the extremely high correlation of high-level accounting concepts reported under US GAAP, IFRS, and IFRS AU.  That is not a coincidence.  You might not be aware of the accounting equation: Assets = Liabilities and Equity.  All this other "stuff" is just a breakdown of the details of assets, liabilities, and equity.

If you look at this pragmatically, this is incredibly useful information for a host of reasons.

As far as I can tell, FIBO (Financial Industry Business Ontology) defines a number of terms including: assetsliabilities, and equity (see this RDF file).  EVERY financial-related reporting scheme might define assets, liabilities, and equity differently.  However, all the pieces WITHIN "assets" and "liabilities" and "equity" MUST act correctly per the rules of double-entry accounting which is defined very clearly in mathematical terms how double-entry accounting work. 

Financial reporting taxonomies simply cannot make stuff up; they are beholden to the higher-level logic of the accounting equation and other logical, mathematical, mechanical, and structural well understood "rules of the road" so to speak.

And so, it makes sense that certain high-level concepts will be the very similar or the same, and they are, even though these can be measured differently when creating a financial report.

Here is a comparison of US GAAP, IFRS, and IFRS AU high-level terms: (see pages 7 to 11)

(Click image, see pages 7 to 11)

So basically, the FASB and IASB follow a meta-meta model when they create their US GAAP and IFRS meta data and represent that in the form of the US GAAP and IFRS reporting schemes.  The FASB and IASB don't get to define the logic of double-entry accounting.

There are other meta-meta models that financial reporting must follow.  Mathematics is one of them.  Roll ups and roll forwards are defined by the rules of mathematics, not by the FASB or IASB.

And so, the logical, mathematical, structural, mechanical, and other such rules are not defined by economic entities that create fianancial reports; rather those rules are defined by a higher meta-model (or meta-meta model) to which all financial reports mush comply.

Posted on Thursday, December 20, 2018 at 09:02AM by Registered CommenterCharlie in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.