Digital Financial Reporting

In this blog post I provided an overview of the meta-model of a financial report.  In this blog post I provide an overview of the meta-model of a business report.

Here is the most recent version of my model, or meta-model, of a 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 is the multidimensional model.

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.

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

• Network: A Network is a technical artifact that really has no meaning by itself because those creating XBRL-based digital business reports use Networks in different ways. A Network essentially breaks a report into fragments.
• Hypercube: A Hypercube simply groups some set of Axes, Members, Primary Items, Abstracts, and Concepts together into a logical structure.  Hypercubes are essentially another way to break a report into smaller fragments.
• Dimension:  A dimension is one approach to representing a Characteristic. Entity and period core dimensions that are always required so you never have to create those dimensions, they will always exist.  Those creating XBRL taxonomies can create additional non-core dimensions leveraging XBRL Dimensions.
• Member: A Member is a possible value of a Characteristic.
• Primary Items:  Primary Items as called by the XBRL Dimensions specification, is in essence a special type of Dimension which specifies a data type, period type, and optionally a balance type. Primary Items are Characteristics.
• Abstract: An Abstract is simply used to organize Primary Items; they provide no real meaning, only organization of Concepts.  When used, Abstracts can make a model easier to understand.
• Concept: A Concept is in essence a special type of Member.  You can think of a Concept as a value for the Primary Items Characteristic.  A Concept is special in that it can be used to represent a Fact Value. A Concept specifies a data type, a period type, and optionally a balance type.
• Fact: A Fact is a fact value plus all supporting Characteristics which describes the fact and Comments which further describe a Fact.  Numeric facts have the additional properties of rounding and units.  Optionally, a fact can be associated with one to many parenthetical explanations.
• Comments: Comments (implementation of an XBRL Footnote) is a property of a Fact which provides additional descriptive information about the 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.

Since a financial report is a special type of the more general business report, this model was tested using 10-K financial reports 0f 6,674 public companies submitted to the SEC via the XBRL format. So, financial reports prove the model of the business report. The relationships between the implementation pieces which make up the model structure are more restricted than what the SEC allows.  The following are the allowed model structure relations:

(Click image for larger view)

The graphic articulates the model structure relations: illegal per XBRL, allowed (green OK), and disallowed (orange Disallowed).  Essentially, this prescribes XBRL presentation relations.  While XBRL does not enforce these relations, the business report model does because the disallowed relations are illogical.  The matrix of relations still might need a little tuning.

I created one additional "utility" structure that I call 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 Primary Items can be logically organized and a member arrangement pattern is simply how Members of a Dimension 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.  Taxonomies can be logical, but poorly organized.  Blocks take care of the "poorly organized" part.  Business rules will take care of the "logical" part.

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

The logical, mathematical, structural, mechanical, and other such rules are not defined by entities that create business reports; rather those rules are defined by a higher meta-model (or meta-meta model) to which all business reports mush comply such as the rules of logic and the rules of mathematics.

The business report model is further documented in Business Report Semantics and Mechanics Theorywhich was written by Rene van Egmond and myself with the input of others.  That is a first draft which will be improved as our testing progresses.

Rene and I are trying to get XBRL International, OMG, or someone else to more formally publish this model.  We shall see how successful we are with that endeavor.

Stay tuned!