Digital Financial Reporting

In a message posted to XBRL-Public, the IFRS Foundation announced the release of business rules for the IFRS taxonomy. The business rules are made available using XBRL Formula.  This is the text of their post should you not be a member of the XBRL-Public list:

The IFRS Formula Linkbase 2012 is now available to download. The current version of the formula linkbase is an updated version of the formula prototype which was released in October 2011. The 2012 formulae are designed to work with the IFRS Taxonomy 2012. The majority of the improvements between the current version and the prototype are related to the content.

The formula linkbase can be used with software packages supporting the XBRL formula specification 1.0 and allows for additional validations of the reported facts. The IFRS Formula Linkbase 2012 is developed in a generic manner, which means it can be used directly on the filings created, on the basis of the IFRS Taxonomy (instance documents) or the company specific extensions to the IFRS Taxonomy (filer extension taxonomy and instance document). The guidance documentation for formula linkbase is available to download with the current release.

Technical changes between the current version and the prototype include:

· Positive and negative formula validation has been placed in separate files.
· Redundant members in the filter for the Dimension aggregation formulae are now removed.
· Precondition expressions in the validation have been simplified (Earnings per share formulae).

For futher information and to download tthe files, please visit
http://www.ifrs.org/tools/IFRS+Taxonomy+Formula+Linkbase+2012.htm

The IASC foundation released todaythe 2010 version of the XBRL taxonomy for financial reporting under IFRS. The taxonomy includes an IFRS for SMEs (small and medium enterprises) entry point for the taxonomy.  Here are links to:

• 2010 IFRS XBRL Taxonomy Home Page
• Link to physical files
• Link to documentation (which they say is coming soon)

Also, I took the IFRS for SMEs presentation information and imported that into an Excel spreadsheet, ran some macros against the information to format, color, and otherwise made it easier to read.  You can grab that Excel spreadsheet here if you want to have a look at the IFRS for SMEs taxonomy.

This XBRL taxonomy is likely a good sign of things to come in terms of XBRL taxonomies for financial reporting.  I believe that this is the first financial reporting XBRL taxonomy which incorporates decisions made by the Interoperable Taxonomy Architecture group (IASCF, SEC, EDINET).

Will IFRS (International Financial Reporting Standards) for SMEs (small and medium sized  enterprises) be the way private companies in the United States report?  Personally, I hope so.  It is looking like this may be a possibility.  I hear estimates that there are between 8 million and 20 million such private entities in the US.

First, let me provide some useful IFRS for SME resources which are helpful for US private companies: 

• IASB IFRS for SME Web Site: Here is the official web site for IFRS for SMEs.
• AICPA IFRS for SMEs to US GAAP Comparison Wiki: The AICPA is making available a wiki which compares IFRS for SMEs to US GAAP which you can find here.
• IASB IFRS for SMEs Training: This web page has training materials you can download for free.
• IFRS for SMEs: The Next Standard for U.S. Private Companies?  This is a Journal of Accountancy Article which looks at this question.
• Moss Adams Presentation: This is a Moss Adams presentation on the topic of IFRS for SMEs, a nice summary.
• IFRS Training: Here are some IFRS training courses in Seattle and Vancouver.
• AICPA IFRS FAQ: Here is a web page with frequently asked questions about IFRS for SMEs maintained by the AICPA.

Now, why would I personally like to see the US go to IFRS for SMEs for reporting by US private companies? Here is my list of reasons: 

1. IFRS for SMEs is easier than US GAAP.  The standards are something like 230 pages.  US GAAP is way bigger than that, most of which is not relevant to 99% of smaller and medium sized entities who report to say a bank in support of a loan.
2. The rest of the world is moving toward IFRS and IFRS for SMEs.  The US should be part of the broader global community, not an island.
3. IFRS for SMEs is high quality.
4. Using IFRS for SMEs globally turns the very fragmented accounting software market into a global market.  This will reduce the cost of accounting software and improve the quality of that software for everyone.
5. A global set of financial reporting standards means the possibility of a global framework for auditing those financial reports.  Today, auditing is more locally oriented.  If private companies around the world use IFRS for SMEs, auditing (reviews, compilations also) costs will go down.
6. The AICPA has  recognized the IASB as an accounting standards setting body.  You can actually use IFRS for SMEs today, if your financial institution will accept it.
7. If the SEC (Securities and Exchange Commission) mandates IFRS for public companies, which it just might do; private companies reporting alternatives could be one of the following: IFRS for SMEs, a US adapted version of IFRS for SMEs, full IFRS, a new separate GAAP for private companies, or US  GAAP as it exists today.  The IFRS for SMEs alternative seems to make the most sense, all things considered.

Will IFRS for SMEs be used by private companies in the US?  Time will tell.  My bet is yes. IFRS for SMEs is a concise, complete, simplified set of accounting principles which better meets the need of financial statement users, particularly if you see the world as a global economy.  On the other hand, the US conversion to the metric system didn't go that well.  We shall see what happens.

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.

It is my personal view that the Statement of Changes in Equity in the US GAAP Taxonomy is very odd and will not work properly for the reasons I will list in a moment.  The information in this blog post is to help accountants understand this section of the US GAAP Taxonomy better, help you understand other sections of the taxonomy better because of a better understanding of the statement of changes in equity, and to empower accountants to provide better input so that a better statement of changes in equity can be modeled in the US GAAP taxonomy.

First off, let me give you a few links to help you to go and look at the statement of changes in equity. I am using the commercial and industrial companies (CI) version of network 148600 - Statement of Shareholders' Equity and Other Comprehensive Income.   Here is a link to the taxonomy viewer provided by the US GAAP Taxonomy.  This is the same information presented in a slightly different way, a flat list that you can view rather than a hierarchy which you need to open. There are other statements of changes in equity in the US GAAP Taxonomy.  The ideas in this analysis apply to every one of those.

I am looking at this statement from the perspective of an accountant.  I do understand the XBRL better than most accountants, I realize that.  This is the point of the statement that this is odd.  If more accountants undersood these things, I specualte that they would agree with me.  Here is my list of reasons why the statement of changes in equity is very odd:

1. Nothing else in the US GAAP Taxonomy is modeled in this manner.  There is nothing else in the US GAAP Taxonomy that is modeled in the manner that the statement of changes in equity is modeled.  Sure, the word [Roll Forward] is in some of the concepts, but it looks like no other [Roll Forward].  This makes the statement of changes in equity harder to understand.  Basically the approach used is to have a bunch of [Line Items] and the funky axis "Statement, Equity Components [Axis]" (which you can see here or here) and the intersection of the line item and the axis is the "cell" into which the fact value would go.  Semantically, this is NOT how a statement of changes in equity works.
2. The statement of changes in equity is a collection of [Roll Forward]s.  This goes with the first statement in that there are a lot of things in the US GAAP Taxonomy which are similar to the statement of changes in equity; all the other [Roll Forward]s.  That is what the statement of changes in equity is, changes from a balance on one date to the balance on another date.  That is what every [Roll Forward] articulates.  Why does this statement not follow that pattern?
3. You get lots of strange contexts which makes validating computations significantly more difficult.  The resulting "cells" of information have different XBRL Dimensions information within the context.  This causes two things to happen.  First, you cannot use XBRL calculations to validate a simple calculation which can be validated in normal [Roll Forwards] (the changes piece) and XBRL Formulas to validate the changes in the balance are likewise more challenging to construct.
4. You have no idea which combination of [Line Items] and [Axis] are allowed.  It is not the case that every [Line Item] can be within any or every equity component.  Because of the way this is modeled, additional rules have to be created to tell you which [Axis] is allowed on which [Line Items].  This is unnecessary with other [Roll Forward]s, the [Roll Forward] provides you with the list of useable concepts.  (Again, this is why this statement should be modeled as a [Roll Forward].
5. Concepts used in this statement don't "fit" into other areas of the XBRL instance.  The statement of changes in equity contains lots of things which are used in other areas of an XBRL instance.  For example, Net Income (Loss) from the income statement; dividends paid which are disclosed on the cash flow statement, those sorts of things.  And there are a lot of them.  All these pieces can fit nicely together if a taxonomy is modeled correctly.  The strange axis "Statement, Equity Components [Axis]" used on this statement makes that impossible.  You will see this when you try and model your XBRL instance.
6. Not everything has a class of stock, so why the [Axis].  People don't seem to grasp the fact that the [Axis] of a [Table] apply to all [Line Items] in a [Table].  The class of stock [Axis] (which you can see here or here), modeled in this statement, means that EVERY line item has a class of stock.  Semantically, this is simply not the case from an accounting perspective.

There are some other issues that I have with the statement of changes in equity such as that it cannot handle restatements caused by prior period adjustments due to changes in accounting policies or corrections of an error.  But I will save this for another day.  I want to focus on the fundamental modeling of the statement, not additional things which need to be added to the model.

Part of the reason that the statement is modeled the way it is in my view is because there is a miscommunication between the technical people and the domain people when it comes to this statement.  Many accountants give the misperception that there is an infinite number of things that can go into the statement of changes in equity and this is simply not the case.  Further, it is not the case that the [Line Items] can go under various equity components in an arbitrary manner.  Where things go is not arbitrary at all and filers have little control of where to put things, US GAAP tells them where things go.  And so should the model of the statement of changes in equity.

Another part of the reason certain modeling decisions are made, and incorrectly in my view, is that accountants are obsessed by how things are presented and they don't fully understand the connection between presentation and the modeling of the taxonomy.  Key points missed are that the best thing for presentation is to do things consistently and logically, focusing on semantics, not XBRL syntax.  But as this understanding becomes better as a result of seeing working SEC XBRL filings and filings that don't work so well, practices will drift to the proper effective result.  The sooner and the more accountants understand how XBRL works, the faster we will get there.

Some clues as to how things do work in XBRL can be seen in some things that I had laying around from several years ago (about 2005 time frame) which were used to test the IFRS GP taxonomy.  I could not decide if providing these would be more helpful to people or confusing.  If you focus on the right things you can get the true points.  At the risk of confusing people, I will make these things available.  The point here is to see another model of a statement of changes in equity, how it works, and contrast that to how the US GAAP Taxonomy statement of changes in equity works.  This has nothing to do with comparing IFRS and US GAAP.  This is about how to model information and the results which you derive from modeling things in specific ways.  So, I make this available in that light.  Please don't read the wrong things into what is being shown.  Further, realize that the 2005 IFRS GP was done in 2005.  I learned a lot from that taxonomy.  It is not an example of how a taxonomy should be created today in my view.  That said, there are certain aspects that are created correctly.  That is what I want to focus on.

So first off, here is the end result of my testing:  This PDF.  The PDF may seem a little odd, but the point was to PROVE that the IFRS taxonomy was constructed correctly. What the PDF shows is what is called a [Roll Forward] (IFRS calls it a movement analysis) for EVERY equity line item.  EVERY type of change is shown.

This is the XBRL instancefrom which the PDF is created.  Again, this is test data.  But, the same idea applies whether you are creating a test financial expressed in XBRL or a real one:  do ALL the computations add up?  How do you know that they add up?

Well, we used the XBRL calculations and XBRL Formulas to test the computations.  There are three types of computations:

• The columns add up to what is shown in the right most column which is "Equity, Total".  XBRL calculations are used to express those computations.
• The total changes adds up, that is the second row from the bottom, "Total Changes for Period" in the PDF.  Each column needs to add up.  (Even though this number may not be shown on the actual statement of changes in equity).
• The roll forward (or movement needs to add up.  For each column, the first row which is "Balance at December 31, 2003" + the second to the last column "Total Changes for Period" = the last row which is "Balance at December 31, 2004".  XBRL calculations cannot perform this test.

Here are the two validation reports which test EVERY ONE of these computations:  XBRL Calculations and the XBRL Formulasvalidation results.  The calculations validation comes from the XBRL calculations expressed with the IFRS GP taxonomy, see this calculation linkbase.  The XBRL Formulas come from a formula linkbase I created.  Originally back in 2005 when I was testing this I used a proprietary version of XBRL Formulas which UBmatrix created.  I updated those formulas to the XBRL Formula 2008 specification, which you can see here.  These calculations and formula validation results can be a little hard to read because they are not organized as an accountant would want to see them.  But, all the information is there.  Again, the point is that EVERY computation is validated.  I KNOW that everything adds up.

Another important point on the PDF is that if you look at the numbers, they have the correct "polarity" (whether they are shown as positive or negative).  What I mean is this.  Look at the fifth column from the right which is "Treasury Shares".  Notice how the number in the first column is -1,100.  Now, some accountants would say that should be shown as positive, not a negative.  No worries.  Simply change the style sheet which renders this information.  You can see the style sheet here.  If you know how to read the XSLT you can see that it is very easy to flip the number from a positive to a negative by changing this XSLT:

<xsl:value-of select="format-number(/xbrli:xbrl/ifrs-gp:TreasuryShares[@contextRef='I-2003'] * -1,'#,##0','base')" />

All you would do is change the -1 to a 1 and the value from the XBRL instance would be shown as positive, rather than negative.  People obsessed with wanting to show this as either positive or negative are missing the point that people should be able to show this HOWEVER THEY WANT TO.  XBRL provides what is needed in order to achieve this flexibility.

Conclusions

Here are my conclusions.  Take a look at the evidence above and consider all the other things which my might feel appropriate to consiser and reach your on conclusion.  But my own personal conclusion is this:

1. The statements of changes in equity are [Roll Forward]s and they should be modeled as such.  This would make understanding how to create a statement of equity in XBRL a whole lot easier.
2. Accountants are going to want to validate their computations to be sure the fact values expressed in the XBRL instance properly foot and cross-cast.  All of them, even the reconciliation of the beginning and ending balances.
3. The taxonomy should express the proper financial reporting and accounting semantics.  Not everything in a statement of equity has a "class of stock", so that [Axis] is NOT appropriate in the statement of equity.  It would be very approprate for certain pieces of the statement of equity, but not for the entire statement of equity.  This means that rather than modeling one big herky [Roll Forward], the it would be more appropriate to model each [Roll Forward] separately.
4. The side benefit of number 3 is that you know which concepts you should use in which columns of the statement of equity.
5. The IFRS GP taxonomy of 2005 proves that this can work.  You can see for yourself in the links above.  You can also see how this works and can see that it is, in fact, nothing more than a [Roll Forward].
6. Modeling the taxonomy and rendering the information in the XBRL instance are two different things. A taxonomy with a consistent information model, the base and any extension, is easy to render.

As more and more SEC XBRL filings get made with the statement of changes in equity more and more filers will have to grapple with this statement.

If someone sees a better way to model the statement of changes in equity I would love to know about it.  But you need to provide a well thought out prototype so you can think through all these pieces, rather than providing "vapor XBRL instances and taxonomies" which may not work like you think they would work.  Run what I am showing through the ringer.  Heck, if you have something better let's us that approach.  All I personally care about is that this works for financial reporting.