BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Entries in AApplication profiles (1)

Understanding Application Profiles

I use the term application profile from time to time.  Do you understand what an application profile is or how application profiles provide benefits to business users?  This blog post answers those two questions.

Section 1.4 (page 4 of 44) of the US GAAP Taxonomy Architecture explains what an application profile is from the perspective of the US GAAP Taxonomy:

Application profile - These voluntary restrictions followed by version 1.0 architecture form an "application profile" for the use of XBRL features within the taxonomy. It is strongly recommended that extensions to version 1.0 stay within this application profile. Systems using version 1.0 may, at their option, set rules which force extension taxonomies to stay within this application profile.

The US SEC follows these restrictions.  For example, the US GAAP Taxonomy Architecture says that: (a) all XBRL Dimensions information must be put into the context segment element (XBRL allows them to go into either the segment OR the scenario element), (b) typed members cannot be used (XBRL allows these), (c) no tuples are allowed (XBRL allows tuples).

These restrictions of XBRL (i.e. use segments, no typed members, no tuples) are set by the US GAAP Taxonomy Architecture and followed by the US SEC.  There are more restrictions that the US SEC places on XBRL.  For example, the SEC specifies that the context entity scheme used must be the SEC CIK number scheme and that the value of the entity identifier must be a valid CIK number.

Never does the SEC or the US GAAP Taxonomy ADD anything to XBRL, they always remove from what is allowed.  If they added things to an XBRL instance or an XBRL taxonomy, they would be violating the XBRL global standard specification.  Now, they can and do add things outside the XBRL.  For example, the RSS feed which is used to make people aware of SEC XBRL filings goes beyond XBRL.  In this way, the SEC is adding things to their system.

Now, XBRL software is not expected to use this RSS feed.  So, the RSS feed, although adding to the entire SEC system, does not break XBRL.  What we are talking about here are restrictions on XBRL, always using less than what is allowed by XBRL; thus restricting how a user can use XBRL.

Why would anyone require such restrictions?  Well, there are a couple of reasons.  One is that XBRL is a general purpose language, it has to meet the needs of business reporting as a broader use case than financial reporting which is implemented by the SEC.  XBRL provides a number of different ways of achieving something. To make it so users of XBRL within a system pick the say way and are therefore interoperable, restrictions of the approach to achieving something are necessary.

Another reason an application profile's restrictions can be helpful is in making things easier for business users. For example, in the US GAAP Taxonomy, within a [Table], it is guaranteed that you have only two types of child concepts to a [Table] concept: an [Axis] or [Line Items]. Go look at the taxonomy and see for yourself.  Taxonomy creation applications can leverage this consistency and make many things easier for users who have to edit or extend a taxonomy.

Now, a tool which supports a specific application profile may be easier to use because it leverages that profile, but there is a down side.  The down side is that the software which supports one application profile might not support some other application profile.  However, a general XBRL taxonomy editor would support any application profile which stays within the XBRL global specification.  Should like you would never want to create such software, one which supports one application profile of XBRL but does not support another application profile of XBRL.  That is the trade off.  But, considering that business users find editing XBRL taxonomies challenging and considering the size of the SEC XBRL use case, it is highly likely that software application specific to the SEC XBRL implementation will eventually appear.

Another thing worth pointing out is that the US GAAP Taxonomy is not the only application profile of XBRL.  For example, the FINREP taxonomy has its own architecture (i.e. it has its own profile). And COREP also has its own application profile.  Other taxonomies have their own application profiles also.

The fact of the matter is that EVERY XBRL taxonomy has its own application profile!  Some are documented like the US GAAP and FINREP, and others are less documented or not documented at all.  In fact, even taxonomies which do very similar things such as financial reporting have different architectures.  For example the US GAAP Taxonomy, the IFRS taxonomy and the EDINET taxonomy have different architectures.  The International Taxonomy Architecture group is comparing these architectures and working to come up with one common architecture which all three groups can use.

It is quite expensive to create an application profile, more expensive than people first realize.  You need to document the architecture such as the US GAAP Taxonomy and the FINREP documented their architectures, you have to write tests to be sure XBRL software creating XBRL taxonomies and XBRL instances stay within the application profile.  For  example, here are the test cases the SEC had to build. There are hundreds of tests.

Is it possible for the US GAAP Taxonomy, IFRS, and EDINET to all use the same application profile.  Well, actually that may not be necessary as the world is moving toward one set of financial reporting standards, IFRS.  That may or may not actually occur.  Type will tell.  It may or may not be the case that these three rather large use cases can agree on one application profile.  Time will tell.

What if you did not have to create your own application profile; what if you could just pick up someone else's and use theirs.  For example, why couldn't someone simply use the US GAAP Taxonomy architecture and the test case implementations and other infrastructure in their application profile of XBRL.  Frankly, i think that is exactly what people will do.  Software vendors are investing a tremendous amount of money in building the software infrastructure to support the SEC XBRL filers.  That software will meet a rather robust use case.  I believe that the US GAAP Taxonomy Architecture has a good chance at becoming an ad hoc standard for other business reporting use cases.  Time will tell.

What do you think wil unfold?

Here is another blog entry which explains why business users will like application profiles.

Really want to know even more?  Here is a link to a Google search for the term "application profile" on my web site.