Digital Financial Reporting

David Wenberger's book Everything Is Miscellaneous points out two important things:

• That every classification scheme ever devised inherently reflects the biases of those that constructed the classification system.
• The role metadata plays in allowing you to create your own custom classification system so you can have the view of something that you want.

As we move from "atoms" to "bits", people drag along the rules which apply to atoms and try to apply those rules to solve problems in the world of bits. This, of course, does not work. Everything Is Miscellaneous has countless examples contrasting the physical organization of atoms (such as books in a book store) and the organization of books digitally (like Amazon.com).

Third Order of Order

There are three orders of order:

• First order of order. Putting books on shelves is an example the first order of order.
• Second order of order. Creating a list of books on the shelves you have is an example of second order of order. This can be done on paper or it can be done in a database.
• Third order of order. Adding even more information to information is an example of third order of order. Using the book example, classifying books by genre, best sellers, featured books, bargin books, books which one of your friends has read; basically there are countless ways to organize something.

So what does this have to do with the US GAAP Taxonomy? It should be built to allow others to reorganize it as they see fit. Now, don't jump to any conclusions here.  I am not saying that the US GAAP Taxonomy is random and can be organized every which way and still be meaningful. There is key data points which will always be true, these are rules which define the information's financial integrity. Many of these "key data points" don't exist in the US GAAP Taxonomy today. These are just relations between pieces of the taxonomy which relate to financial reporting. Things like the balance sheet must balance.

Third order removes the limitations which people seem to assume exist when it comes to organizing information. Weinberger says this about the third order of order:

In fact, the third-order practices that make a company's existing assets more profitable, increase customer loyalty, and seriously reduce costs are the Trojan horse of the information age. As we all get used to them, third-order practices undermine some of our most deeply ingrained ways of thinking about the world and our knowledge of it.

The US GAAP Taxonomy was built by the accounting standards setter, the FASB. It was built by accountants. It is a consensus-based product. Not one SEC XBRL filer uses the US GAAP Taxonomy as is to file with the SEC.  Every SEC reorganizes the US GAAP Taxonomy.

But the US GAAP Taxonomy is not built to be reorganized. The structure of the taxonomy is more like a book.  Can the US GAAP Taxonomy be reorganized? Of course it can. But it is certainly not optimized to allow for reorganization and reorganization is not even mentioned in the design characteristics. As such, it will cost more and be harder to create and maintain these reorganizations.

So how do you make it easier to reorganize? Many smaller pieces which can be put together as needed is vastly easier for a computer to deal with than having one large piece and trying to break that piece apart.  That is one example of what can be done.  Another is communicating the metadata which exists in the taxonomy, for example the information modeling patterns employed.  A third is to make the existing metadata real metadata, rather than burying it in the labels of the concepts. Another is to add more metadata.

As accountants, analyts, and others use the US GAAP taxonomy ways to make the taxonomy easier to reorganize will become apparent. Just keep the idea of the third order of order in the back of your mind.

And if you can, check out Everything is Miscellaneous.  You can read an insightful review here. You can read the prologue here and read chapter one here.  You can read multiple chapters here at Google books.  You can buy it on Amazon.com here.

OK, building on the last post where I provided a high level summary of a logical model of SEC XBRL filings, here is an implementation of that logical model so you can better understand it:

• SEC XBRL filing and taxonomy prototype.  This shows you what an SEC XBRL filing would look using only explicit tables, no implicit tables.
• Relations info set. This is an info set of the relations information. Basically, this is the information communicated within an XBRL taxonomy distilled down to its essence.
• Tables info set. This is an info set of the reported information.  Basically, this is the information communicated within an XBRL instance, putting all the tables together with their axes, distilled down to its essence.

These info sets are not new, I copied them from the info sets I created for the Business Reporting Logical Model but, like the PDF in the last post, changed the terminology to match the US GAAP Taxonomy and SEC XBRL filing terminology.

To render the tables info set so that a human can read it, you use the tables info set plus the relations info set.  To see this, try looking at the XBRL instance in the Firefox XBRL Viewer add on.

Business users and software vendors will eventually realize that there is a logical model which the US GAAP Taxonomy and SEC XBRL filings follows. Exposing this logical model to business users hides the more complex and technical syntax of XBRL from those users. This blog post summarizes the logical model which exists for SEC XBRL filings, in my view and per the FASB US GAAP Taxonomy Architecture.

This PDF shows a visual representation of that logical model. This really should be in UML, but I don't know UML well enough to create that or I would.

This is a summary of much of the key terminology used in that logical model diagram:

• Networks. A network is a way to break an SEC XBRL financial filing into smaller pieces. There are two reasons why you might need to break a financial filing into pieces: because you want to or because you have to. The SEC Interactive Data viewer renders these networks in specific ways using the number and category of the network for ordering. Creating a network causes a section to appear within the navigation pane on the left hand side of the SEC XBRL previewer.I said that there were two reasons to create networks: because you want to create a section and because you have to create a section. The primary thing that a network does is it separates things which would otherwise collide.
• Tables. A table is used to combine things which go together.  There are two types of tables: explicit tables and implicit tables. Tables are comprised of axis and line items, which we will discuss in a moment. The line items of a table have common axis. A table has one or more axis and line items. You can use a table from the US GAAP Taxonomy or you can define your own tables. This is done by creating a table, for example "Debt Instruments [Table]". There is another way you can create a table which is to use what amounts to a "default table". A default table is everything which exists in a network which is not in an explicit table.  Explicit tables give you more explicit control over how things show up in the SEC Interactive Data viewer.
• Axis. An axis is a means of providing information about characteristics of the line items within a table, be that table explicitly defined or implicitly defined. Explicitly defined [Table]s are the only tables to which you can add axes. All tables, be they explicitly defined or implicitly defined, have two axis which will always be there: Entity and period. The entity axis, or entity identifier, always exists for an explicit or implicit table and the entity axis is always the SEC filer CIK number. The period axis, or reporting period, always exists for an explicit or implicit table. Other explicit axis which can be defined might include things such as:Class of common stock [Axis] or Subsequent event type [Axis].
• Domains. An axis always has exactly one domain. A domain is one of the possible values of an axis. A domain can have one of two meanings: total of the member or it may simply be a place holder. For example, say you have the axis "Regions [Axis]".  That axis might have the domain "Regions, All [Domain]" which represents the total of all regions, the sum of all the members.  Whereas, suppose you had the axis "Subsequent event types [Axis]".  Subsequent events are never aggregated, but you would still need to provide a domain such as "Subsequent event types, all types [Domain]", although that domain would never actually be used within a report.
• Members. A domain may, or may not, have members. Members are the possible values of an axis also (the domain is also a possible value as stated above).
• Line items. Line items are concepts which can be reported by an entity, they can contain values. Line items is a special type of axis. Because line items can report values, they have data types such as string, number, etc. They may also have a balance type (debit or credit), a period type (as of a point in time, for some period, etc), and a few other characteristic which we will get into when we cover the details.  Line items contain concepts. Concepts can be concrete meaning that they can be reported or abstract meaning that they are never reported, they are only used to organize the concepts contained within a set of line items.
• Information models. Concepts are not interspersed randomly, they have patterns.  Said another way, concepts are organized into different information models.  The common information models include: [Roll Forward], Roll up (often referred to as a calculation), Hierarchy, Adjustment, Grid.
• Financial integrity (business rules). Taking the notion that concepts are not randomly placed within a set of line items further than just the information model; certain information models have financial integrity.  A balance sheet always has "Assets" and "Liabilities and Equity".  A balance sheet always balances. The line items of Assets will always foot.  The line items of "Liabilities and Equity" will always foot. These characteristics are expressed using business rules.
• Fact. Concepts are reported as facts whose characteristics are described with axis within an SEC XBRL filing. Facts have values, they have axis which describes its characteristics. Facts may be numeric or non-numeric. Numeric facts have an amount, non-numeric facts are made up of textual information. Facts are an intersection of axis and line items (remember that line items are a special type of axis) and a value. A fact is associated with a concept, they reference a concept within the set of line items. Facts are associated with axis, they reference a set of axis within an implicit or explicit table.
• Fact Value. Facts have a value which can be numeric or non-numeric. An important non-numeric value type is a narrative or [Text Block] which is a fragment of escaped XHTML.
• Fact attributes. If the fact is numeric, it has two attributes which describe additional information needed by numeric facts: units and decimals (rounding).  Units provides information about this units of the numeric fact such as monetary, shares, or some other units.  The decimals (rounding) provides information as to the number of decimal places to which the number is accurate, such as to the thousands, millions, billions, hundredths, etc.
• Footnotes. Facts may also have footnotes (comments, don't confuse this with notes to the financial statements) which provide addition information about the fact.

The graphic depicts what we will discussed, showing the relationships between the components. There are many different ways to depict this information, the most formal being UML (Uniform Modeling Language). UML is a standard way of depicting this information. However, we are using a less formal approach to articulating this information to make it easier for business readers to understand the relations. UML provides additional details, but is harder for business readers to understand.

Summary narrative of logical model

An SEC XBRL-based financial report can be logically broken down into sections. These sections are called tables.  A table can be organized within a network. Networks organize where tables show up in software applications such as the SEC Interactive Data viewer application. There are three categories of networks: Document, Statement, and Disclosure. The numbers within the network names determine the ordering of the networks within software applications.

Tables are groupings of facts which appear in a financial report for some specific purpose. Facts within a table have similar characteristics.  These characteristics are articulated using an axis. Line items are a special type of axis. Line items contain concepts.  These concepts can contain values.

Axis cannot contain values, rather their values are the domain or the member. Axis always has a domain. A domain may be a total of all members or it may only be a placeholder and never used to report information. There are two special types of axis which do not have a domain: entity and period. Numeric values have two additional attributes: units and decimals. Units explains the units of a numeric value and decimals explains the rounding of a numeric value. Values may also have footnotes which provide additional information about a specific value or a set of values.

Facts reported do not have random relationships, the relationships between facts have patterns, this is referred to as an information model. A table may contain numeric concepts with information models such as roll ups, roll forwards, grid, adjustments, complex computations. Or if the numeric information has no relationship or textual information is reported, the information model is simply a hierarchy. Financial integrity takes these relations a step further and ensures the financial information within one table ticks, ties, foots and cross casts.  Additionally, financial integrity ensures that one table properly relates to other tables.

For more detailed information and an example see my next post.

Here is an SEC XBRL filing I created which makes use of the new FASB 2011 US GAAP Taxonomy. I have not been able to run this through EFM validation yet as I don't know anyone who has adjusted their validation to support the new taxonomy yet.

There are one issues I still need to resolve in that prototype.  I am using 2008 negated label roles and I know there is a 2009 version.  But, I will wait to update that until I see an updated EFM. Also, the US GAAP Taxonomy now provides a Report Date [Axis].  I need to change from using a report date axis which I created in the company extension taxonomy.

This does include XBRL Formulas which use the new taxonomy.

First off, before you jump to conclusions, this blog post is not about making any sort of judgment about what should be comparable and what should not.  That is for the financial reporting supply chain to figure out. This blog post shows the moving pieces of comparability and how to move those moving pieces should comparability be desired.

There are two set of prototype financial statements which I have created to work with, explore, test, and otherwise figure out how comparability works in XBRL.  Here are those two sets:

• Comprehensive example comparison: This prototype compares three financial statement-type XBRL instances which are constructed following the Business Reporting Logical Model (BRLM). This prototype is unconstrained by the idiosyncrasies of the US GAAP Taxonomy or SEC XBRL filing rules. Because I was able to create my own GAAP taxonomy, I could created it how I wanted to create it, maximizing comparability. This example shows the best comparability and how to achieve it, unconstrained by others.
• Reference implementation of SEC XBRL filing comparison: This prototype compares three SEC XBRL filings.  Each is a legal SEC XBRL filing as each uses the US GAAP Taxonomy and passes Edgar Filer Manual (EFM) validation, for the most part. Some things are intentionally done to make some specific points about comparability.

Moving parts of comparability

So what are the moving parts of comparability? When you think about comparability you need to think like a computer because it is the computer which leverages the "stuff" you provide to perform any comparisons. That stuff can take three forms: XBRL instance, XBRL taxonomy, other external stuff. Let us now look at those three pieces. (The Business Reporting Logical Model explains many of the terms used below. Section 4.3 of this document reconciles many of these terms to the US GAAP/SEC terminology used.)

• XBRL instance: The XBRL instance has all the fact values and meta data values which gives contexts to the fact values which you want to compare. Meta data values provide contexts for the fact values.  The fact values are the values.  For example, say you have a value "1000". The fact value is the value, plus the collection of measures which describe the value such as the concept which might be "Cash", the period which might be "December 31, 2010", the legal entity which might be "ABC Company", etc.  A fact value also has attributes which provide additional information such as the currency of the value which might be US Dollars or Euros (called units) and the rounding information of the value (called decimals).
• XBRL taxonomy: The XBRL instance contains all the fact values, the XBRL taxonomies defines much, but not all, of the meta data used by the XBRL instances. XBRL taxonomies do not define the periods which can be used, the entity identifies which can be used, the currencies or other units, or the rounding values; those are defined by the XBRL instance and unconstrained. But the taxonomy defines everything else including: networks (some people call these extended links but that term is actually incorrect, network is the correct term), hypercubes (called [Table]s in the US GAAP taxonomy, dimensions (called [Axis] in the US GAAP taxonomy), concepts (called [Line Items] many times in the US GAAP taxonomy), and values for dimensions/[Axis] which are called members (called [Member]s in the US GAAP taxonomy.  A special type of member is the domain (called [Domain] in the US GAAP Taxonomy.
• Other stuff: Other stuff, external to XBRL, is important to understand because you do need it and there are no standards for this as it is beyond the scope of XBRL, but these things are still needed.  One example of other stuff is some way for a computer to find the set of XBRL instances you want to work with, such as an RSS feed. The SEC created an RSS feed to provide links to XBRL instances. If you look at my comparisons, I followed the SEC lead and used RSS as the format for providing my list of files.  Others have their way of getting a computer application to a set of XBRL instances you will want to compare. Another thing you will need is a way to map meta data defined multiple times by different filers to indicate that it is the same. Other types of mappings are used to overcome meta data issues.  You will understand this better after the discussion we will have next.

So those are the moving pieces. Again, keep in the back of your mind that you need to consider how a computer deals with all these moving parts, not how a human deals with them.  The whole point here is to automate the process and avoid using human effort where possible.

Working with the moving parts

Now we look at some examples of working with the moving parts and how comparability is impacted. Differences may seem subtle, and they are.  But it is these nuances which make comparability work or not work. We will walk through this from the top down.

• Defining networks: Networks, which many people refer to as extended links or groups, is one tool which can be used to achieve comparability at the highest levels.  For example if you tell the computer you want to compare balance sheets, you can give it the network name for the balance sheet and grab that from each XBRL filing which you want to compare.  For example consider this network, this network and this network of ABC Company, XYZ Company, and QQQ Company of the reference implementation above. Not that they are all the same, "Network: 104000 - Statement - Statement of Financial Position, Classified (http://xbrl.us/us-gaap/role/statement/StatementOfFinancialPositionClassified)" from the US GAAP Taxonomy.  Well, that is actually illegal per SEC XBRL filing rules.  Each filer is required to define their own networks.  As such, networks are not helpful in comparing balance sheets or any other pieces of SEC XBRL filings because every network of every filer is unique for everything! By contrast, the vast majority of the networks of the comprehensive example comparison are the same. So, to improve comparability; define networks so they can be shared between filers which improves comparability.
• Defining hypercubes or [Table]s: Drilling deeper into XBRL taxonomy models the next highest level we run into after the network is the hypercube or [Table] in the US GAAP Taxonomy. Looking at the same portion of the taxonomies of ABC, XYZ and QQQ companies, the balance sheet, let us look at them another way; via the [Table] rather than the Network. If you check out the three links you will see that each is to a [Table] with the label "Statement of Financial Condition, Classified [Table]".  Now, look a little more closely and notice that the concepts are actually different, the are NOT the same.  Each company defined their own concept for the balance sheet table.  How will a computer understand that each of these are the balance sheet?  Well, it will not. By contrast look at this [Table] which is the same for ABC, XYZ, and QQQ. All three use the concept from the US GAAP taxonomy "us-gaap:Nonmonetary Transaction, by Type [Table]". Now, this is easy for a computer to understand to be the same [Table] so it can easily be retrieved and compared from all three prototype SEC XBRL flilings.
• Defining dimensions of [Axis]: OK, now go back to taxonomies of ABC, XYZ and QQQ companies and this time focus on the [Axis] of the Nonmonetary Transaction, by Type [Table].  Notice that the [Axis] "Report Date [Axis]" is defined by each company individually which can be seen by the different namespace prefixes abc, xyz, and qqq in each taxonomy.  By contrast, look at the "Nonmonetary Transaction Type [Axis]" which has the "us-gaap" namespace in each taxonomy, so that is the same [Axis] in each.  Again, the same helps comparability, different hinders comparability.  Now, analysts can create a mapping which tells the computer that they are the same, but that takes humans to do work which takes time and costs money.
• Defining domains: You get the general idea, so I will not repeat this for the [Domain], basically if the [Domain]s are defined in the US GAAP Taxonomy they are more comparable than ones defined in the individual company extension taxonomies.
• Defining members: Same deal for [Member]s.
• Defining concepts or [Line Items]: Same deal for [Line Items].
• Defining units: It is worth pointing out how units works a little differently.  Imagine every individual company having to define their own units, such as "USD" for US Dollars.  Not good. If each GAAP taxonomy, US and IFRS, defined the units then cross taxonomy comparisons are harder, mapping would be involved.  XBRL defined the attribute "units", so that can be shared between taxonomies, in fact, it must be as it is required on all numeric facts. Even better, XBRL actually relied on the ISO standards, specifically ISO 4217 which defined currency codes, such as the code for US Dollars "iso4217:USD" which is the global standard for specifying what currency something relates to.

So who defines the information/meta data has significant impact on comparability as you can see. Global standards such as ISO codes enable the most comparability. Things defined by XBRL itself are slightly less comparable. Next are things defined by a US GAAP Taxonomy.  Last are things defined by individual filers. Experiment with the two comparison prototypes above and see how they work in software applications. You can learn even more about the nuances of working with XBRL to create the comparability which you desire.

Impact of financial integrity on comparability

Financial integrity has a big impact on comparability. For example, if there is no agreed upon foundational definition of a balance sheet, income statement, statement of changes in equity, cash flow statement then those creating analytical software have to create one and normalize every different financial statement created by each individual SEC filer in order to create comparability.  That means two things: (1) Different analysts or data aggregators can create different definitions of the foundational definition of statements and (2) It is so complex to get data out of the many different filings that you will have to go through some data aggregator to get useful data.

But what if there were an agreed upon foundational definition of financial statements, certain policies, and certain disclosures? Then, querying the information at the highest levels would be quite easy.  At the lower levels, individual filers still have the flexibility to show the information they want to show but there is at least some basis for comparing.  Another way to say this is that computers don't do to well with random.

Conclusions

Try comparing the information in the two sets of XBRL instances above.  The results you get from the "comprehensive example" comparison will be better than the "reference implementation" comparison. That is because the comprehensive example was built to be comparable.  The reference implementation was constructed to communicate some comparability issues and had to follow the US GAAP Taxonomy and SEC XBRL filing rules.

Comparability is not an art, it is pure science and testing comparability is quite objective. Some financial reporting supply chain deciding WHAT will be comparable is an art and is quite subjective and political. Whatever the supply chain might decide can be expressed in XBRL. Understanding how to use the XBRL medium helps one use the features of the XBRL medium far better than leaving things to chance.

Again, this blog post deals with the science of comparability, not the art of what should be or should not be disclosed. That is a different discussion.