Digital Financial Reporting

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.

There are people saying that the electronic spreadsheet is dead meat. This article in Government Technology titled XBRL Ends Spreadsheet Hell points out some of the shortcomings of the electronic spreadsheet. In his book Pull: The Power of the Semantic Web to Transform Your Business, David Siegel says (page 176) "The days of general-purpose word processors and spreadsheets are over."  He sees the replacement as being semantic information.  Business Intelligence (BI) vendors say that the arbitrary rows and numbers of electronic spreadsheets will be replaced by BI tools which use real world names and terms (i.e. semantic information).  Here is a tutorial for one BI application which walks you through how this works.

These is plenty of information on how to avoid what many people call "spreadsheet hell", like this one.  The love/hate relationship we all seem to have with spreadsheets, what seems to be a necessary evil, is fairly well documented.

Me, I started my accounting career in 1982 with the IBM PC and VisiCalc. Remember that! (Here is a screen shot from Wikipedia.org)

I was an auditor at what was then called Price Waterhouse.  I used paper spreadsheets to create things like audit schedules.  It took some doing, but we got the managers and partners to start letting us use these new fangled electronic spreadsheets.

But it was not long before I started seeing the limitations of spreadsheets and started to make use of database applications.  I started with a database called RBASE.  Eventually I moved to Microsoft Access, which I still use today for all sorts of things.  Basically, I use spreadsheets, databases, and XML/XBRL to achieve the things I need to achieve.

Frankly, I personally don't see the general purpose spreadsheet totally going away.  There will always be a need for general purpose spreadsheets.  However, I do believe that somewhere between 2% and 20% of all spreadsheets could and should easily be replaced by databases and other sorts of applications.  As many as 80% of spreadsheets could be replaced if you worked at it just a little, most likely.

One of the thing which I see replacing spreadsheets are more specific purpose applications.  You can think of these as "templates".  They may even look like spreadsheets.  But, you cannot add anything you want to the spreadsheet looking thing, you have to follow the data model.  These specific purpose applications will be in a global standard data format, such as XBRL or maybe RDF/OWL.  Different applications created by various software vendors will exchange these little specific purpose templates, serving specific needs.  Importing and exporting information from one business system or process to another will be easy.  This importing and exporting will be like little data exchange contracts between users.

This video helps see why the more spreadsheets you can make go away, the better you will be able to use the business information you work with (from YouTube, Chet Phillips):

Can you make all your spreadsheets go away?  Probably not.  Experiment with the low hanging fruit, the 2% to 20% which are pretty much a no brainer.

This is my next iteration of what I have been calling an interactive information viewer:  Interactive Information Viewer.

(Here are blog posts which discuss and can take you to prior versions of this prototype:  First version, Second version.)

In this most current version I have incorporated many, but not all ideas yet, from this blog post relating to the best ideas for getting the most out of your XBRL architecture.  I guess I started on this idea of what I am now calling an interactive information viewer when I was working on the US GAAP Taxonomy.  I took what I learned from that process, took it further, and came up with XBRLS which is basically a profile of XBRL. Additional ideas came from the COREP taxonomy and from the FINREP taxonomy.  What I called a "neutral format table" had evolved into "interactive information viewer".

Fundamentally, I am stil pursuing the goal of a business user defining a data model (dynamic model where extension is an option, not a static form), articulating information based on that data model, exchanging that information with another business user within an automated process.  There can be zero ambiguity, the semantics need to be understood the same by both those creating and consuming the information, the information needs to be readable by a human and by a computer AND all this needs to be done by business users...no IT department assistance at all.  Clearly this cannot be done unless there is off-the-shelf software on both ends of this exchange and that software needs to be operated by a business user.  But before that software can be built, we need to know what is needed to make all these moving parts work together effectively in order to achieve this goal.

The SEC implementation of XBRL offers a lot of clues as to how to make this work.  It seems to me if the SEC can make this work (i.e. business users filing financial information with the SEC) then I should also be able to get this to work.

The term "interactive information viewer" comes from the following.  First, the SEC used a term "interactive data".  I borrowed from the SEC but changed the use of data to information because XBRL is really more concerned with information than data. (See this blog post for more information on that difference.)  The "viewer" part comes from the notion of the way you look at business information is more how a Microsoft Excel pivot table might work or how a business intelligence tool works.  Basically, there are two things that you gain.  First, the information on the report is not fixed, the user can move it or reconfigure it.  Second, you loose the two dimensional nature of paper meaning that a computer can present things in more than two dimensions.

So in this prototype, imagine you could reconfigure the columns and rows or take a column or row and move it to the "Slice" section in the upper left hand corner.  Again, much like an Excel pivot table or business intelligence application.  There are three things which make Excel pivot tables and current BI applications not do the job here: (1) They don't understand XBRL, (2) They like the aggregate things (i.e. the OLAP piece), (3) They don't handle text well (i.e. they are optimized for numbers, not numbers and text).  These things will be worked out I am pretty sure.

So, an interactive information viewer is configurable in that the consumer of the information can "pivot" things to see them how they desire to see them.  This blog post discusses more of the characteristics of such an application.  Here is a demo/tutorials of one software application which shows you some of the basic ideas here (see the "The Basics of Quantrix Modeler" or the video tutorial on the left side).  Remember, here they are only dealing with numbers; but imagine if you could use numbers or text in the models.

The key here is the XBRL taxonomy.  All this is very, very possible today...but the problem is that every solution is proprietary in that you have to use the data format of those applications.  So, you cannot exchange the data between applications.  If business users can agree on one way to create a taxonomy and if ever software application supported that format, then we would have what we need.  XBRL is capable of doing this, but XBRL "out of the box" is just too flexible, there are too many options. So, we just need to agree on a subset, a profile, of XBRL which is 100% compliant to the XBRL specification.  Then enough software needs to support that profile.

The following is a list of the top ten (or so) ideas for getting the most from your XBRL architecture.  These ideas are based on assessing how well a number of different well-thought-out XBRL architectures seem to be working. Also, as part of the XBRL International Taxonomy Architecture Working Group where these sorts of things are discussed, I believe these ideas can help improve any implementation of XBRL.

While these ideas are good to consider for any system which implements XBRL, the ideas are particularly important for systems which allow for the extension of XBRL taxonomies.

1. Create a clear, unambiguous, formally documented information model. One of the biggest problems XBRL taxonomies have is inconsistent information models.  An information model is simply how the relations within a taxonomy are structured.  This is of particular importance when extensibility is employed within your system.  For example, the US GAAP Taxonomy creates structures such as [Table]s, [Roll Forward]s, and other such structures.  They explain how these structures are to be created.  You should do the same in order to be able to evaluate how your taxonomy is created and in order to explain how your taxonomy should be extended.  Taxonomies are simply not random.  Make yours clear, unambiguous, and formally document it so those extending your taxonomy can follow the rules.
2. Use either segment or scenario, there is no real reason to use both.  Eliminating unnecessary options makes things easier.  There is no semantic difference between using the segment context element and the scenario context element.  Besides, if different XBRL instance creators use different elements, comparability then becomes an issue.  You can avoid both of these problems by simply using one or the other. Which is as easy as tossing a coin really.  Using scenario seems to be the best, but the US GAAP Taxonomy suggests segment.  You can pick.
3. Tuples and XBRL Dimensions are redundant, pick and use one or the other; personally I prefer XBRL Dimensions. The biggest problem with using both tuples and XBRL Dimensions is explaining when to use one and when to use the other.  The primary reason I don't like tuples is because they significantly inhibit extensibility.  Basically, tuples add back the XML content model with XBRL worked to remove.  XBRL Dimensions can do everything that tuples can do, but tuples are not nearly as functional as XBRL Dimensions.
4. Don't mix dimensional and non-dimensional models; personally I prefer a dimensional model.  If you use XBRL Dimensions, then every concept should be attached to a hypercube thus requiring the dimensions of the concept to be explicitly identified.  Mixing a dimensional model and a non-dimensional model causes headaches which can be avoided by simply using one model or the other. Since business information is inherently dimensional anyway, I personally prefer a dimensional model, using XBRL Dimensions consistently throughout your XBRL taxonomy.  Mixing models also make using XBRL Formula much trickier.
5. Precision and decimals are redundant, pick and use one or the other; personally I prefer decimals. The precision and decimals attribute on a fact value serves the same purpose.  There is pretty much universal agreement that only one of these should have been created. Having both causes more work when working with XBRL instance information which contains both.  FRTA suggests that decimals be used.  So does the US GAAP Taxonomy.  I agree and suggest using decimals because it is easier for business users to understand.
6. Always differentiate dimension values and concepts.  When creating an XBRL taxonomy you don't want users of the taxonomy to mix up what is a dimension value (such as a domain or a member) and what is a concept which can be used to report a value.  The US GAAP Taxonomy diferentiates domains and members by appending "[Domain]" or "[Member]" to such dimension values and assigning those types of elements to a special type value of "domainItemType".  You could also use the substitutionGroup to differentiate these two types of XML Schema elements. That way, users don't get confused.
7. Make each hypercube unique. There are advantages to making each hypercube in an XBRL taxonomy unique.  Take a look at this taxonomy. Search for the line items which say "Statement [Table]".  You can see what I am talking about more clearly by looking at this. What is the point of using the same hypercube for each set of dimensions and concepts?  Why not use a different unique hypercube name for each hypercube?  This has a number of benefits, including making the extended link as any form of semantics unnecessary.  The FINREP taxonomy makes each hypercube unique.
8. Don't use complex typed dimensions. Complex typed members allow literally any XML you can think of as a possible value, except for XBRL itself.  It is way too much to ask for a software application to implement something like this.  Further, using it to compare to entities effectively can be quite challenging.  You can achieve the same results by using a number of simple typed members, which are much easier to build an interface for and easier to make work.  Complex typed members for dimension values are far more trouble than they are worth and should be avoided.
9. Don't be redundant in expressing taxonomy information. If you express things twice in two different ways, you create work in that you now have to make sure the two things you are expressing are in sync.  For example, expressing information in a presentation linkbase and also in a definition linkbase causes such redundant information.  The FINREP taxonomy figured this out and does not make a presentation linkbase available with its taxonomy.  In the short term this can be a bit of a challenge to effectively do because most software applications rely on the presentation linkbase.  Overtime and as software gets better, this will not be an issue.  First, realize that you are creating redundant information.  Second, if you can, you may want to consider not making this redundant information available in your XBRL taxonomy.
10. Give serious consideration to using XBRL Formula rather than XBRL calculations. XBRL Formula is several orders of magnitude more powerful that XBRL calculations.  Also, XBRL calculations have their idiosyncrasies.  More and more people are moving to XBRL Formula.  You may want to give strong consideration to abandoning XBRL calculations and using XBRL Formula instead.  XBRL calculations can be easier in certain situations.  The tradeoffs should be understood and evaluated in making your decision.
11. Be sure to require that all hypercubes be closed.  All hypercubes you create which have an "all" role should be closed (and all your hypercubes which have a "notAll" role should be open if you happen to use those).  Leaving a hypercube open basically lets anything exist in the context.  What is the point of that?  Be explicit and close all your hypercubes.

Understanding and using these ideas can make the systems you use XBRL within work better, more consistently, and with far fewer issues.  Consider them when you make your implementation decisions.

There was a post to the XBRL-Public mailing list which pointed out this Twitter feed which tweets each SEC XBRL filing.

I am not sure how useful it is, but this Twitter feed is certainly clever and shows some other possibilities.  What would be more clever, more interesting, and potentially more useful is to Tweet information which is contained in an XBRL filing.  Because it is easy to extract information from within an XBRL filing or across XBRL filings; the combination of XBRL and Twitter can be a great way to make all sorts of information available.

Imagine, oh let's say a produce broker (because I use to work for a produce broker and know a little how this works), using a mechanism such as this for making information available to suppliers on what he is interested in buying or customers keeping them informed as to what he has available to sell, special deals he has on produce he has to move before it spoils, etc.

Creating a dynamic information feed using Twitter or an RSS or ATOM feed or some other such mechanism becomes child's play.  Or, taking someone else's XBRL feed, extending it, adding additional information (basically mashing up multiple sources of information) is another possibility.

One final idea.  What about creating a botwhich monitors some piece of information, sending out Tweets which you can get on your iPhone.  Maybe, using my produce broker example, it monitors the price of lettuce offered by several brokers helping you to get the best price or helping you identify when the price point where you want to start acting has been achieved.

The Semantic Web is going to be great!