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 from August 15, 2010 - August 21, 2010
First XBRL iPhone Application
The first XBRL iPhone application has appeared (at least that I am aware of). The application, created by Brix for XBRL US, can be found on iTunes here. You can read the XBRL US press release here.
I installed the Brix Project XBRL application on my iPod Touch. It was simple enough. Go to the iTunes App store, search on XBRL, select the application, and install it.
The application certainly is no killer app which will change the world, but it does demonstrate some possibilities. If you are a business person, go try out the application and apply your imagination.
- You will realize that the SEC XBRL viewer is not the only way one can view an SEC XBRL or even an HTML filing. Clearly the iPhone application shows that being able to reconfigure the presentation of information is a desirable thing as different user interfaces have different characteristics. For example, the screen real estate is different in a browser on your computer, on an iPhone, or on something like an iPad.
- The XBRL taxonomy impacts what you can do in terms of creating an interface. Look at the US GAAP Taxonomy and look at the iPhone application interface. What is in the XBRL taxonomy and filer extension taxonomies impacts (a) what you can do with something like an iPhone app or (b) the effort one has to go through to reconfigure the US GAAP Taxonomy so that you can do what you desire when you build something like an iPhone application.
- So here you have data flowing from the SEC filer, to the SEC, out to your iPhone. (I would be curious to know how long it takes to have a filing show up on an iPhone after it is filed...I will check on that.) How do you know the data is correct? This shows how important things like business rules are in making the information trustworthy enough to use.
- If XBRL is a global standard, seems to me that one should be able to "change a URL" and change the information the iPhone application shows from say the SEC XBRL filings to say maybe XBRL filings of some other regulator who has also implemented XBRL. It is not that easy today to do this, but that is the idea behind XBRL.
- Taking the last point even further, what if the iPhone application interfaced not with the SEC, but with all the regulators around the world.
Oh the possibilities...
Generic Information Feed Engine
XBRL is "behind the scenes" providing the standard data payload and agreed upon business semantics making this work. We have a standard format for video (MPEG4), audio (MP3), pictures (JPEG), documents (PDF)....What is the standard format for business data which will make business information exchange work like YouTube or Flicker or iTunes or an iPhone?
I have always thought that this would be a fantastic idea and a great way to communicate the value of XBRL. You are probably familiar with a stock ticker. Years ago I had an application which showed New York Stock Exchange prices on my desktop with a 15 minute delay. It must have cost the NYSE millions of dollars to stream that information out and a lot of people find that stock price information valuable.
But there is other information in the world other than stock prices. What if any business could, for pennies (i.e. for far less than what the NYSE spent), make available a "ticker" of some sort to stream information to whomever they desired. I used to work for a produce distributor. They needed to know the price of lettuce in California, how much lettuce was in the fields of the 25 growers they worked for, the current price of lettuce which fluctuated between $2 per box and $30 per box, and other such inputs. They did this to set their price, serve the growers and satisfy their customers.
That produce distributor managed all this with phone calls, faxes, guess work, etc. I worked there as an accountant an build an interface which helped the buyers and sellers manage some of this information first in Microsoft Excel and then it was used so much that I converted it to Microsoft Access. These were the days before the Web, but we did have PC Anyware and dial up connects from one computer to another. These guys loved this system. It took a lot of different skills to weave all this together and it was held together with bailing wire and band aids.
I could build the same thing today, far cheaper, far more robustly using XBRL in the system. But what if I didn't have to do even that. What if I could go purchase or subscribe to a service where I simply plugged in an XBRL taxonomy, plugged in a URL to a repository of XBRL instance documents, put in a few configuration settings, and I could have all that literally for pennies.
What if there were a service similar to say YouTube or Flicker where you did not upload videos of photos, but rather you uploaded data feeds to some public or private set of business information? People do this today. But since that service does not exist (yet), they use Excel spreadsheets, email, and expensive human effort to fit all the pieces together. For example, a friend of mine is the financial officer of a university which exchanges benchmarking information with 25 other private universities. Another friend is in sales at a big company which benchmarks their information against other companies.
What if there was an iPhone or iPad or web browser application where you could do all this? You set the URL to some publicly available or private spot on the internet and share the boatloads of information we share the applications were as easy to use a an iPhone of Flicker or iTunes or Picassa.
Perhaps that will be the second XBRL iPhone app. What sort of application can you imagine?
XBRL for Non-financial Information
Many people I talk to are surprised when I tell them that XBRL is not just for financial information, that it can be used for other business information, any information in fact. While there are pros and cons to using XBRL and it is not right for everything, its utility goes beyond financial reporting.
I talked about XBRL's sweet spot in another blog post, I will summarize that sweet spot here:
- Larger transactions which tend to change (i.e. such as a 50 or 100 page regulatory report with perhaps thousands of facts exchanged, as opposed to a small transaction with 10 data points)
- Zero tolerance for errors in the information (i.e. everything must tick and tie and if things don't add up, bad things happen)
- Information which needs to be reconfigured(i.e. not a form, although XBRL can be used to expressed what amounts to a form, it excels when that "form" needs some flexibility)
- Business people changing the metadata, no IT involvement required (i.e. XBRL has a good balance between power and ease of use)
No why are the examples I createmostly related to financial reporting? Well, a couple of reasons. First, I am a CPA so that is my domain of expertise. Second, I am a CPA and I want to help the financial reporting domain figure out XBRL in order to use it effectively within that domain. Third, it does have a lot of uptake in terms of using XBRL.
I do create non-financial reporting examples. See the "State Fact Book Prototype" which I created. Also, this may seem strange but have a look at it. Here is a non-financial reporting example. Visualize this by looking at the PDF. I am using placeholder text use for prototyping marketing information for the concepts expressed in the XBRL taxonomy and reported in the XBRL instance. It still works. No debits or credits, no balance sheets or income statements, not financial reporting related.
When you look at the business use cases forget about the specifics of what you see in the use cases. Just like mathematics is used in accounting and engineering and physics and medicine and whatever domain; those patterns of what I am expressing goes beyond financial reporting. Look at the examples in more general terms. I thought about creating 100 non-financial reporting uses for XBRL, which I still may do one day. For now, I am focused on financial reporting and figuring out how to best use XBRL in that environment.
Business Reporting Use Cases Updated
I have reached a big milestone in updating the business reporting use cases which I am putting together. You can get to those from this index page which contains the use cases plus some other things relating to the use cases. This is a direct link to 31 business use cases.
Several points about these business use cases.
- You can download the complete set, see the download link on the page.
- Each use case has been validated by 4 different XBRL validators and all of those validators report no errors. (The XBRL Formula stuff used is only validated by one validator.)
- I would consider these use cases "very safe" areas of XBRL. This is because of the consistency in the validation across 4 different validators, each provides the results expected, XBRL extension works as expected, and all approaches used come from years of fiddling around with different approaches to articulating these use cases in XBRL. (Considers techniques use in the most current US GAAP taxonomy, IFRS taxonomy, COREP, etc.
- All the visual stuff in the taxonomy such as the "[Fact Group]", "[Member]", "[Measure-Concepts]", "[Roll Forward]", "[Roll up]" (and so forth) is only visual eye candy and is unnecessary. Those things appended to the concepts and labels only helps one visualize the taxonomy given the lack of assistance provided by software these days.
- While I did provide a presentation linkbase, the presentation linkbase is not necessary. Basically, the presentation linkbase can be autogenerated from the definition linkbase.
- The presentation, calculation, and definition linkbases are consistent.
- While I did use the substitutionGroups of the business reporting logical model schemaand doing so is very helpful in creating a consistent XBRL taxonomy, doing so is not necessary.
- While I did use the measures of the financial reporting logical model schema, I really did not have to because these taxonomies are only demos. However, the technique of using those measures does enhance comparability across XBRL taxonomies if that is desired.
- These XBRL instances and XBRL taxonomies do follow the useful practices of the Financial Reporting Instance Standards (FRIS) and Financial Reporting Taxonomy Architecture (FRTA), they do not necessarily follow the useless syntactic constraints imposed by FRIS and FRTA. On the other hand, the XBRL instances and XBRL taxonomies do follow a number of best practices which would be a good idea for something like FRIS or FRTA (or whatever replaces them) should make use of. So, don't expect that these comply with FRIS or FRTA validation.
I do intend to provide additional documentation which explains the subtle characteristics of these use cases which one can miss if they are not pointed out. Not sure when. My next goal is to create a comprehensive example which tests these use cases by seeing how they interrelate with one another within one larger business report.
Rather Challenging Business Use Case: Restatements
Still churning away at the business use casesI am trying to express using XBRL. Creating these is a lot like solving a sudoku puzzle. There really is only one right answer (which should be the case for XBRL, but it is not quite there) and the answer needs to follow the rules (in XBRL's case the business rules which helps you make sure things foot, cross cast, and otherwise tick and tie.)
The restatement use case is vexing. I have been shown a number of different approaches to expressing what amounts to accounting related prior period adjustments (corrections of an accounting error or a change in accounting principle). Most of the solutions are not particularly elegant which is a clue they are wrong. Each time I think I have the answer correct, one more moving part needs to be dealt with which makes everything fall apart.
From an accounting perspective, this explains the situation. If you look at the PDF. You will see three financial statement fragments: the balance sheet, the income statement, and the statement of changes in equity. The three different pieces interrelate with each other, that is what makes this challenging. The balance sheet contains retained earnings which is also shown in the statement of changes in equity. Net Income (Loss) is on the statement of income and the statement of changes in equity. The prior period adjustment flows through the income statement and is shown in the prior period adjustment portion of the statement of change in equity. The retained earnings balance connects the prior period adjustment and the changes in equity portions of the statement of changes in equity. Accountants get all these pieces. Technical people might not.
From a technical perspective, these are the moving pieces. Within this one use case you have several roll ups (balance sheet, income statement, total prior period adjustments, total changes in equity), a roll forward (changes in equity), an adjustment (prior period adjustment). The challenging thing to piece together is the XBRL instance. The XBRL taxonomy is a less of a challenge, as long as the architecture is correct. You can view the XBRL taxonomy here. That will give you a sense for the strategy I have used to create the XBRL taxonomy. This Fact Group visualization allows you to get a sense of the information being expressed.
The tricky part is this:
- Getting all the calculations to work.
- Getting the XBRL Formulas to work, the business rules of the information.
- No duplication of concepts or contextual information. Doing this is basically a hack, it is not elegant and you will run into data integrity issues. Basically, the different sections (balance sheet, income statement, statement of changes in equity) all need to properly relate with one another properly.
- Everything needs to be logical and easy to explain.
Today, doing this is a lot like building a proper database schema unfortunately. Longer term, this will not be the case because (a) an elegant solution will exist and will be well articulated and (b) software will implement that solution in the background and will not let you make any mistakes.
Regretfully, software does not work like that today. Software is still dealing with the XBRL syntax level, not hiding XBRL and properly implemented solutions behind the software solution. So, users have to figure all this stuff out, user by user.
Don't worry, that problem will go away. These business use cases will contribute to that, that is part of the reason for creating things like these business use cases, the metapatterns upon which the business use cases are built, etc. (These are basically patterns or design patterns.)
Currently, I cannot get all the pieces to fit together correctly. Right now only one piece of the puzzle is out of sync. That could be an easy fix of an error I am making, or it could mean a fundamental flaw in the architecture of how I am trying to solve the problem. I cannot tell which right now.
The primary piece of architecture being used here to solve the problem is the notion of a "Report Date [Measure]" (or report date dimension). This is implemented as an XBRL Dimensions explicit dimension. Others have suggested that this Report Date [Measure] should be implemented as an XBRL Dimensions typed member (an implicit dimension, see this example). Whether this is an explicit dimension or an implicit dimension will not solve the problem I am having; they are both dimensions and work the same way.
Do you have ideas on how to articulate the XBRL instance information and the resulting XBRL taxonomy to make this work elegantly (i.e. I don't need a hack, I have plenty of those)? Send me an email.
Enabling Ease of Use Using Business Reporting Logical Model
I had mentioned Quantrix before (see the last link in the blog post). Here is another demo of how they approach articulating business information.
Now, I don't know if they support XBRL. But imagine editing an XBRL taxonomy using that interface. The interface hides XBRL, abstracting it out leaving the user to focus on business semantics rather than having to struggle with the XBRL syntax.
Watch that demo. Then have a look at the business use cases here. Look at the "Rendering" for each of the business use cases, seeing how it might fit into the demo you saw. What I call a "slicor" on the renderings, they call a "filter". What I call "Measures", they call "categories".
More later on this...stay tuned!