Digital Financial Reporting

This is a fragment Fragment of the article on MSN Money Central.

A revolution for small investors

Soon all companies will report financials in a programming language called XBRL that will allow you and me to slice and dice numbers like never before.

By Michael Brush
A few years from now, don't be surprised if some blogger in his boxer shorts brings down the next Enron.

That may seem far-fetched, but hold off on the laughter.

That's because individual investors in the U.S. will soon move another step closer to a brave new world of democratized financial information that will put powerful analytical tools on their desktops.

On May 14, the Securities and Exchange Commission will announce the next steps for making all companies report financials using a software programming language called XBRL.

XBRL will eventually put a far superior version of Wall Street's high-priced tools in the hands of regular investors for free and maybe even help them uncover the next accounting scandal.

XBRL will bring such a revolution to investment analysis that any Sherlock Holmes who X-rays financials for clues on a company's health needs to learn about it -- and push the SEC to make companies adopt it as soon as possible.

(More on MSN Money Central)

In a research publication issued last week by Gartner titled "XBRL Will Enhance Corporate Disclosure and Corporate Performance Management" (which can be purchased from Gartner here), the value of XBRL to CFOs and CIOs is pointed out. 

Gartner says, "Extensible Business Reporting Language is an enabling technology that will significantly change the way financial information is reported, internally and externally. CFOs and CIOs need to understand the impact of XBRL, and plan for its adoption during the next three years."

(This is another version of this story published by the AICPA)

Ten years ago this month (April 1998) my personal journey toward what was to become XBRL began.  To me it is pretty amazing where XBRL is today.

For me, it was a Wednesday when I took the first step in this journey.  Why I remember that it was a Wednesday, I really don't know.  But it was on a Wednesday that during a lunch break during a class I was taking I went to the University of Washington Bookstore in Bellevue, Washington in search of a book on XML.  I had heard of XML, but I really did not understand what it was.  At that time I was worked with the public accounting firm of Knight, Vale and Gregory (now RSM McGladery).

The book was published by the W3C and explained what XML was by providing a collection of articles on how people were making use of XML.   I remember one example that described how the chemicals industry had written an XML language and the book described how that all worked, explained the benefits, etc.  I noticed there was nothing in the book about the accounting profession or financial reporting.

I knew immediately that XML was "the last piece of the puzzle".  Over the prior 15 years, I had spent much of my time integrating one system which had some data/information to another system which needed that data/information.  I had (remember, I was a CPA, usually a controller for smaller companies) learned about stuff like relational databases, fixed field formats, comma separated values.  I had gotten quite good at using Microsoft Access as the intermediary application, pulling information from one place, testing it to be sure everything was OK, and then pumping that data somewhere else.  The reason I used Access was that it supported so many different data formats.

After reading the book I called my friend and colleague Wayne Harding.  I got to know Wayne because I read a letter to the editor he had written about something and out of the blue I called him to chat about it.   As  it turned out, several years later I did a lot of work with Great Plains Software (now Microsoft Business Systems or something), the company for which Wayne worked.

I was excited and tried to explain to Wayne that there was this new thing XML which was going to revolutionize the world and we needed to use XML for financial reporting.  Wayne told me to slow down, and that we were both going to be in Chicago in about a month so why don't we talk about it then.  I knew Wayne had a lot of connections at the AICPA.

So we met in Chicago.  I handed Wayne a stack of documents an inch thick which I had photocopied and highlighted for him.  Wayne looked through the documents and said that it just so happened that he was the chairman of the AICPA High Tech Task Force and that they were having a meeting in Sedona, Arizona sometime in September; why don't I come down and explain what XML was.

Before that September meeting I was doing some experimenting with XML.  I built some samples for audit schedules, financial statements, and other things to just dink around and learn how to work with XML.  I even built a little prototype which pulled inventory data (for a candy company, a client of KVG) out of a Great Plains Dynamics SQL based accounting system and rendered live inventory information on the Internet.  As it turns out, what we learned at Knight, Vale and Gregory about this prototype has dramatically influenced the business of another friend and colleague who took this information, learned more about XML, and uses that base in his business today.   (More specifically, see the XML Document Transfer information about eConnect).

In September I took my prototypes and a PowerPoint and went to Sedona, Arizona to present my idea to the AICPA High Tech Task Force which was chaired by my friend Wayne Harding.  Also members of the task force were Karen Waller (with the AICPA), John Woodburn (The Woodburn Group), Dianne Spencer (Deloitte & Touche LLP), Mike Harnish (Dickinson Wright et al), Chris Reimel (NJ Dept of Labor), and Barbara Vigilante (AICPA).  Here is a photo:

On the last day of the High Tech Task Force meeting I gave my presentation.  The meeting began at 8:00 AM.  By 10:00 AM the High Tech Task Force was convinced that XML based financial reporting and audit schedules were important to pursue.  Karen Waller who was an AICPA staffer said that what we needed to do was to put together a "Product Description" to get funding.  We decided that we should build a prototype.  We knew that Barry Melancon, president of the AICPA, had authority to approve projects up to $50,000.  So, we decided that our prototype would cost no more than $49,000 (but really had no idea what we were getting into).  Wayne Harding already had a meeting with Barry Melancon in two weeks, he would present to product description and try to get it approved.

Two weeks later, Barry approved the project. 

Next, I convinced Mark Williams, the CEO of Knight, Vale and Gregory, that I could do the prototype and to agree to accept any cost overruns.  I had built a small prototype for an IBM financial statement and I knew what we had to do.  I knew we needed someone to help us with some aspects of the project but it was hard to find people with XML expertise.  After a few false starts, I was lucky to stumble across Mark Jewett who had started a business which did work with XML, he had recently left Microsoft.   Mark Jewett and his company helped to use XSL (the first version of what was to become XSLT) to create the ability to render.  We decided that the first financial statement we would create in XML was Great Plains Software, a public company, the company for which Wayne Harding worked.

In early January of 1999, Wayne Harding, Mark Jewett, and I went to New York City to present the XML Prototype to the AICPA.  The prototype included the XML financial statement, the beautifully rendering of the statement in a web browser which looked literally identical to their financial statement section of the Great Plains annual report, and a demo which extracted data from the XML document on a web server in the basement of my home in Tacoma, Washington into an Excel spreadsheet on a laptop at the AICPA.  I forget all who was at the meeting, but they were very impressed with what could be done with XML-based financial reporting.  (I still have a copy of the original XML based financial statement prototype, the style sheet, and the Excel spreadsheet.)

Our question: What next?

I flew back to Tacoma and early that next week I met with Mark Williams, the CEO of KVG.  I told him that everything went great and that we were within our budget.  He told me that was great.  Mark said that clearly the CPA firm could not fund taking this any further.  I told him that I realized that and gave my two weeks notice, I was going to pursue this.  I had no idea how.

I proposed to the AICPA that the next step was to put together a business plan.  The AICPA agreed and they agreed to fund the business plan, so now I had a little bit of income.  The AICPA assigned the project to Louis Matherne.  Wayne Harding said he could help out when he had time, but he had a full time job with Great Plains.  I forget if it was Wayne or Louis who asked me if I had heard of this other person who was talking about XML also.  He as a CPA who had a small practice in Rochester, New York and his name was Eric Cohen.

The chairman of the AICPA became aware of and interested in the XML project.  His name was Bob Elliott.  I think the chairman of the AICPA serves a one year term, Bob was a partner with KPMG.

Over the next several months I wrote the business plan with the help of Louis Matherne, Wayne Harding and Eric Cohen.

In May of 1999 I presented the business plan to the AICPA.  (I still have a copy of the business plan.  It is interesting to see what we thought then, and how things turned out.)  The title of the business plan said, "Extensible Financial Reporting Markup Language - XFRML".  Bob Elliott, chairman of the AICPA, was at the meeting.  I had presented the plan focusing on financial reporting.  Bob had the foresight to understand that the scope should be not financial reporting, but business reporting in general.  So our focus changed to all of business reporting.

I was given a contract (funded by the AICPA) to create 10 additional prototype XML-based financial statements to continue exploring concept.

Bob Elliott, who worked with KPMG, gets his assistant, Zack Coffin involved with XML-based business reporting project.  Zack was the first non-CPA involved with the project.  Zack had experience in standards with the entertainment industry.

During the time I was writing the business plan I became aware that the SEC was modernizing the EDGAR system.   They were seeking feedback on their plan to use HTML and PDF.  I sent a letter to the SEC suggesting that they consider using XML as an unofficial format and mentioned that the accounting profession was working on creating a standard for XML based financial statements.

In early July or so I called up Tim Bray, author of the XML Specification.  I learned that Tim lived in Vancouver, British Columbia, Canada..just up the street.  I asked him what his consulting fees were and asked if I could spend a day with him and discuss XML.  He agreed and I spent the day with Tim Bray.  Some of the best money I have ever spent.

Sometime in July I received an email from Tom Howland of PricewaterhouseCoopers.  Tom indicated that he read an email send by Charlie Hoffman to the US Securities and Exchange Commission relating to considering the use of XML as a reporting format, rather than considering only HTML and PDF.  He wandered if I was that "Charlie Hoffman".  I had mentioned that a consortium was being set up to build XML based financial reporting.  Tom Howland called me and I explained what the AICPA was doing to create XML-based financial reporting.

Tom mentioned this discussion to his boss, Walter Hamscher. 

Walter mentioned this to his boss, Mike Willis. 

Walter invited me to come down to the PWC technology center and spend the day with him.  Walter spend the entire day with me, showing me around, talking about what the technology center did and this impressive book they published summarizing trends in technology.  At the end of the day, Walter told me that PWC wanted to join the consortium creating this XML standard for business reporting, Walter wanted to know who to make the check out to and for how much.

I told Walter that I would get back to him with that information the next day.  I called Louis and told him the story and asked Louis what we should do.  Somehow we decided that the fee to join the consortium was $10,000.  I called Walter back, told him that the check should be made out to the AICPA for $10,000 and that congratulations, PWC was the second member of the consortium.

After Walter told me he was sending the check, I immediately told Zack Coffin that PWC was the first member of the consortium knowing full well that he would be livid.   I did this to motivate KPMG to cut the second check.  Zack got his check to the AICPA and we now had three members.

One of the people we wanted to join the consortium was Edgar Online.  I had heard that FreeEdgar of Bellevue, Washington was being acquired by Edgar Online.  Somehow I got the name Mark Schnitzer.  I went up to Bellevue to meet with Mark and he said he would do what he could to get Edgar Online to join the consortium, but his company could not join because it was being acquired.

I finished the 10 prototypes with the help of a Starbucks bistro.  Literally.  I had been talking to this Starbucks bistro, Mitch Dombrausky, about things I was doing.  I had graduated from Pacific Lutheran University and Mitch was a religion major but was taking some time off.  He said he wanted to learn programming.  To make a long story short, Mitch helped create the XSL (again, still not XSLT) to render the prototypes while I created the prototypes.  Mitch eventually quit his job at Starbucks and now works for a little software company in Redmond, Washington called Microsoft.   I don't know if Mitch finished his religion degree, but I hope he went back and finished that.

In September 1999, the first meeting of what was to become the XBRL International Consortium was held in New York City at the offices of the American Institute of Certified Public Accountants.

(Perhaps more from that time on later.)

I wanted to point you to some great examples for learning or teaching XBRL.  For those of you who were (are) fans of "the patterns document" I have created a new set of "patterns".  These are organized differently and broken down into three things.  So, what was "patterns" is now:

• Meta patterns.  These are the real patterns.  These are small things from which bigger things are built.
• Business Use Cases.  This is what I thought of when I started using the word "pattern" several years ago.  Over the years I learned that I was mixing up two things.  So, I broke them out in the current iteration.  The business use cases are what business users would be most interested in.  I tried to make these as small as possible, but also as real as possible.  These are great learning tools.
• Comprehensive example.  One of the down sides of breaking things into little pieces is that they are isolated and you miss issues you would run across.   To solve this problem, I took all the patterns and combined them into one bigger use case (and my favorite), a financial statement.  This is not US GAAP or IFRS, it is an imaginary GAAP which is simple, but has 100% of the characteristics of the US GAAP Taxonomy, the IFRS-GP taxonomy, and any other taxonomy I have come across which provided clues as to what people might run across.

Each of these examples has:

1. A taxonomy.
2. XBRL Formulas examples for each place where a formula can be used to test a relation.  (Please note that as the XBRL Formulas conformance suite is still being worked through, there could be some errors in this…but I think I got these right, I had a lot of guidance from Herm Fischer (thanks Herm, and thanks to the Formulas Working Group in general…this is a great piece of work!).  I built these not for efficiency of formulas, but for easy "reverse engineering".  All the formulas are heavily commented.
3. An instance document.
4. A style sheet which turns the instance document into rendered PDF.
5. The rendered PDF which is very, very readable to a business user.  THIS IS WHERE TO START TO UNDERSTAND THE USE CASES, the PDF.
6. Validation reports.   An interesting addition is the use of Cliff Binstock's validation dashboard.  He build special rules which help detect errors and correct them once they are detected.  There are a wide range of errors and all of these are ABOVE AND BEYOND XBRL validation.
7. Something that I call a "neutral format table" which is a way for a business user to read an instance document.

These are great for learning XBRL by reverse engineering something, for teaching others, for testing software to see if it can handle common use cases which will be thrown at you, and they make great Christmas stocking stuffers!

Here are three links to the ZIP files which contain these "patterns" things:

• Meta patterns - (6 small examples, very focused):  http://xbrl.squarespace.com/storage/xbrls/XBRLS-MetaPatterns-2008-04-18.zip
• Business Use Cases - (about 22 small examples, business focus; all these follow the meta patterns):  http://xbrl.squarespace.com/storage/xbrls/XBRLS-BusinessUseCases-2008-04-18.zip
• Comprehensive Example - (one bigger taxonomy of about 750 concepts, instance document, basically a 16 page financial statement which complies to the meta-patterns):  http://xbrl.squarespace.com/storage/xbrls/XBRLS-ComprehensiveExample-2008-04-18.zip

These will evolve over the months as I add new patterns, correct any errors I detect, etc.  You should keep looking for updates as they become available.

Feedback is always appreciated.  If you have a business use case which is not modeled, I would love to know about it and add it to this collection.

There seems to battle of the bands taking place.

One of the bands is represented by The Motley Fool.  They say of XBRL, "The Most Important Shareholder Initiative in a Decade" (they may be talking about Microsoft's Silverlight, but I don't think so).  You definitely want to check out the link to the Microsoft Key Performance Indicators referenced on that page.

The other band is the FEI.  They say of XBRL, "FEI on Data Tagging: No Benefit to CFOs".