Digital Financial Reporting

Fairly early in the evolution of XBRL I started collecting "patterns". These patterns have gone through numerous versions and terms, but I think that I am now settling on a more precise set of terminology and an improved set of examples.

All the things in say an SEC XBRL financial filing are not the same.  Many people refer to all of these things erroneously as "tags".  The more proper term is perhaps report element, the things which make up an SEC XBRL financial report. All of the report elements can be grouped into a finite set of categories: network, [Table], [Axis], [Member], [Line Items], Concept, [Abstract]. (i.e. they are not random)

These report elements are related to other report elements in specific ways.  For example, a [Table] is made up of one or more [Axis] and exactly one set of [Line Items].  Understanding which category of report elements relates to other category(s) of report elements and how is (a) helpful to creating SEC XBRL financial reports which are logical and sensible and (b) is something which can be leveraged by software.

These relations have patterns.  I used to group all of these patterns together calling them sometimes simply "Patterns" or "Metapatterns" or "Information Models".  My thinking on this has changed based on maturing ideas and very good input from others.  Here are my new terms and updated sets of examples which explain these relationship patterns:

• Accounting Concept Arrangement Patterns: What I used to call "metapatterns" or "information models" are really better called accounting concept arrangement patterns or [Line Items] arrangement patterns.  That is what they are: how the concepts within a set of [Line Items] are arranged or organized.  Could be a roll up, roll forward, hierarchy, adjustment, variance, some complex computation, etc.
• Member Arrangement Patterns: What I used to call "member aggregation models" is really better called a member arrangement pattern because these patterns describe how the [Member]s or an [Axis] are arranged.
• Report Component Arrangement Patterns: What I used to call "flow models" is better called report component arrangement patterns because what they do is describe how the components which make up a report are organized or sequenced.

I am not totally sure that everything in each group is actually a pattern of that group.  Further, I am not totally sure that I have accumulated every possible pattern for financial reporting.  What I can tell you with certainty is that (a) these relations are NOT random and (b) computer software can leverage these patterns.

There are three other things which are helpful in using this information:

• Business Use Cases: These are basically a set of business use cases which I have distilled from financial reports and financial report taxonomies over the years.  Both IFRS and US GAAP financial reports are covered.  What these do is let you focus on the nuances of working with digital financial reports. These business use cases are small, focused, and well documented.
• Comprehensive Example: The components of a financial report do not exist in isolation, they can many times relate to other components.  For example, a balance sheet intersects with the statement of changes in equity in that the facts which represent the beginning balance and ending balance of each equity account appears in both report components.  The comprehensive example helps sees these intersections.  The comprehensive example helps you understand these intersections and understand how one pattern must be created so that it properly intersects with other report components.
• Reference Implementation(of an SEC XBRL Financial Report): While all of the previous examples where general and not relating directly to the US GAAP or IFRS taxonomies, this reference implementation is a high-quality example of an SEC XBRL financial filing. [NOTE: This is a work in progress currently as software vendors update their products to support the 2013 US GAAP Taxonomy]

While documentation of all this information is provided for each set of patterns or examples, you can get the complete set of information on the Digital Financial Reporting page. As it is becoming increasingly clear that digital financial reporting will be part of our future, it is increasingly important that accountants understand the nuances of using technologies such as XBRL.

This is an updated set of business use cases.  Similar to the updated metapatterns and comprehensive example, it includes fixes to XBRL Formula namespaces and schema locations along with some bug fixes.

Continuing to build on some thoughts. Again, this is a stream of consciousness information dump.

I am trying to figure out what you can do with semantics once they have been expressed and what sort of software you would use to do what you might want to do.  This blog post says the following:

A semantic reasoner, reasoning engine, rules engine, or simply a reasoner, is a piece of software able to infer logical consequences from a set of asserted facts or axioms. The notion of a semantic reasoner generalizes that of an inference engine, by providing a richer set of mechanisms to work with. The inference rules are commonly specified by means of an ontology language, and often a description language. Many reasoners use first-order predicate logic to perform reasoning; inference commonly proceeds by forward chaining and backward chaining.

This web site, Introduction to Ontologies and the Semantic Web is useful.

This PDF, An Introduction to the Semantic Web, is likewise very useful.

This post on some math news list helps understand differences between first-order logic and second-order logic. The Stanford Encyclopedia of Philosophy describes first-order logic and second-order logic here as (in essence):

• First-order logic: Deals with objects in a domain.
• Second-order logic: Deals with properties of objects in a domain.

Propositional logic, or statement logic, is the branch of logic that studies ways of joining and/or modifying entire propositions, statements or sentences to form more complicated propositions, statements or sentences, as well as the logical relationships and properties that are derived from these methods of combining or altering statements.

A statement can be defined as a declarative sentence, or part of a sentence, that is capable of having a truth-value, such as being true or false.

More to come...

Updated the comprehensive example.  XBRL Formula namespaces and schema references adjusted. These now work with every XBRL processor that I have access to which includes UBmatrix XPE, UBmatrix Taxonomy Designer, XBRL Cloud, and Arelle. Should work fine with CoreFilings TrueNorth, but I did not test that.

I have updated the business rule examples which I have provided using XBRL Formula to work with the 2013 US GAAP Taxonomy.  You can find these business rules here:

• US GAAP Domain Level Rules
• Industry Level Rules for Commercial and Industrial Companies
• Reportability rules (Prototype)

Business users creating SEC XBRL financial filings will eventually realize that these rules are very helpful and will want to use these types of business rules.  Understanding how to create these business rules using XBRL Formula is a good skill to have.  Understanding what you can and what you cannot do with XBRL Formula is also a good thing to know.