Digital Financial Reporting

Merrill posted a good article on their blog, Adoption and Use of XBRL in SEC Financial Disclosure and Regulation.  The article is an interview with Hudson Hollister, executive director of the Data Transparency Coalition.

This is Merrill's summary of the article:

The SEC’s adoption of XBRL for financial disclosure and regulation is part of a wider movement to shift US government information from documents to structured, searchable data. To get a sense of where the SEC’s commitment to XBRL use now stands, Dimensions spoke by telephone with one of structured data’s leading proponents, Hudson Hollister. As the founder and executive director of the Data Transparency Coalition (DTC), Mr. Hollister leads an alliance of organizations trying to persuade policymakers to adopt structured data for the collection, storage, and use of information by all areas of the federal government. Before founding the Coalition, he served as counsel to the Committee on Oversight and Government Reform in the US House of Representatives and as an Attorney Fellow in the Office of Interactive Disclosure at the SEC.

One of the questions asked in this interview was, "What is your assessment of the SEC’s approach to XBRL adoption?"  Mr. Hollister's answer:

"So far, the SEC’s adoption of XBRL, six years ago, has been a failure. Now, I would not call it an unmitigated failure. Certainly, private-sector innovators such as Calcbench have shown that, despite its quality problems, XBRL-tagged information can still be made very valuable and useful to investors."

I disagree with Mr. Hollister's assessment. If anyone failed, it is the entire financial reporting supply chain.  In particular, it is the member of XBRL International that sold the SEC a bill of goods and did not follow through and deliver what was promised.  Besides, I don't think this is a failure.  Yet.

When NASA put a man on the moon, a lot of rockets blew up on the launch pad in the process.  Converting from the current document-oriented disclosures of unstructured information which has been in place for almost a hundred years to a data-oriented disclosure of structured information will be a process.

Contrast what the SEC is doing with XBRL-based public company financial reporting with what the health care industry is doing with electronic medical records.  NPR (National Public Radio) has a story, Sharing Patient Records Is Still A Digital Dilemma For Doctors, about the problems with electronic medical records systems talking with one another.  In that story the following statements are made:

"…most electronic medical records systems can't talk to one another…"
"…cash for clunkers bill…"
"…get the systems in…next thing is to get the systems to talk to each other…"
"…we need to be working of the same standard…"
"…we know how magical it can be…."

There are a lot of parallels between electronic medical records and digital financial reporting.  Both are part of an even bigger reality for business professionals: things are going digital and business professionals are going to have to change some things about how they work.

Business professionals are having a hard time understanding that they are in charge of "going digital" and that they need to make things work the way they want and need things to work.  That means business professionals need to understand their role in making this work.  See this document which I am starting to call Knowledge Engineering 101 for Business Professionals.

I have mentioned this before but I think XBRL-based public company financial filings to the SEC is way, way ahead of electronic medical records.  The SEC has gone through the "get the systems in…" phase and now needs to go through the "…get the systems to talk to each other…" phase.

Does XBRL-based digital financial reporting of public companies to the SEC work perfectly?  No.  Far from it.  However, XBRL technical syntax interoperability is 99.99%.  Fundamental financial reporting semantics consistency is 98% over all, but only about 55% of all public companies meet all of these basic consistency constraints.  That needs to be improved and there are specific measurements which can be made to track progress toward success.  The disclosures are likely in similar condition.

But this is in no way a failure.  Yet.  This can only be considered a failure if the SEC is not learning anything.  I think they are learning plenty.  The truth be known, no one involved (including XBRL International, AICPA, FASB, XBRL-US, SEC, creation tool software vendors, data aggregators) in the process of getting XBRL-based digital financial reporting up and running for the SEC completely understood all of the moving pieces of the puzzle.  Me among them.  I knew a lot, but when we created the US GAAP XBRL Taxonomy Architecture, we did not know everything we needed to know.  That is easy to see now.

Did the SEC make mistakes?  That is hard to say.  Christopher Cox took advantage of a situation and got the SEC to mandate XBRL, probably too quickly.  But here we are.

And here is the deal:  the world has changed.  We now have thousands of XBRL-based public company digital financial reports that have been filed with the SEC to look at.  That is important information which is extremely helpful in figuring out how the supply change wants digital financial reporting to work.  This empirical evidence will show the financial reporting supply chain how to make digital financial reporting work.

Don't be naive.  The world is going digital.  Financial reports need to go digital.  Stop making the SEC the scapegoat and do what you said you would do XBRL International Members; make XBRL work.  Merrill is pointing the finger at the SEC when only about half of the filings they create meet even basic consistency checks?  This is not a failure yet, but if the AICPA and other XBRL International members who got the SEC into this situation don't contribute to fixing the issues and show some leadership with regard to digital financial reporting, then yes; what the SEC is trying to achieve with XBRL (exactly what XBRL International wanted the SEC to do) will likely fail and the SEC will try some other technology.

Further, digital financial reporting is not about the 8,000 public companies who report to the SEC.  There are another 28 million private companies who need digital financial reporting and it needs to work significantly better than what public companies are experiencing.  Otherwise, why should private companies have any interest in a technology which just adds more work for them? If implemented properly, XBRL-based digital financial reporting can save time and money and increase quality.

I would be the first to say that if XBRL-based digital financial reporting cannot be made to work correctly then some other approach should be used for digital financial reporting.  A financial report is an important document and it needs to work.  As I have said before,

Prudence dictates that using financial information from a digital general purpose financial report should not be a guessing game. It is only through conscious effort that the specific control mechanisms can be put in place to realize this intent.  The system that works safely, reliably, predictably, repeatedly, effectively, and efficiently is the desired goal.

All this said, it still seems that financial reporting is leading the way to the semantic web.  XBRL-based financial reporting and electronic medical records are just part of a much more significant trend: going digital.  Business professionals are going to need to adapt.  Rather than forcing a government bureaucrat to dictate what digital financial reporting will look like, it is better for the financial reporting supply chain to figure this out and help the SEC make it work correctly.  Collaboration and cooperation with the SEC is what is necessary.

Ventana Research's article, Putting XBRL to Work in the Mortgage Market, describes, in detail, how XBRL can be used by all the parties involved in the pieces of the mortgage process (origination, servicing and owning the credit).

This same idea applies to many, many other processes besides securitized mortgages. A sweet spot for XBRL is any process where 

• One or more parties are on the other side of your firewall or even internally when different departments have different business systems
• Information transaction are more complex than a basic, simple transaction (i.e. such as a 10 or 100 page regulatory report with perhaps thousands of facts exchanged, as opposed to a small transaction with say 10 data points)
• Information exchanged tend to change a little, requiring more flexibility than that of a form
• Zero tolerance for errors in the information (i.e. everything must tick and tie, cross cast and foot, and if things don't add up, bad things happen)
• Information which needs to be reconfigured by the user of the information (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)

Someone said something to me today which helped me recall something which I had thought about years ago when I had an opportunity to visit a Fortune 100 company to see how they created their financial statement.

The thing which sparked this thought again was a chiropractor who was going through the process of implementing electronic medical records.  She was telling me that her macros were not working how she wanted them to work when she did initial examinations of a patient. She said she needed to make adjustments to her macros. You may not be familiar with the SOAP (subjective, objective, assessment, plan) method of documentation employed by health care providers, and that specific process is not really relevant here.

What is relevant is this.  First, a chiropractor adjusting her macros. Who would have thought a chiropractor would ever even use macros.  Second, there is a process and that process can be converted from manual medical records to electronic medical records.  Third, that SOAP process can make use of templates.  There are thousands of diagnosis codes and procedures employed to treat medical conditions. These can be distilled down to templates.  I would contend that there is a lot of similarity between electronic medical records and financial statements. There are likewise lots of different types of financial statement disclosures which can be distilled down into templates.  (i.e. neither medical records nor financial statements are totally random)

So imagine breaking down a financial statement into its components.  Here is one instantiation of a financial statement broken down into its components.  That is created from an XBRL processor.  Then, once all the components are correct, running a macro to generate a financial statement in HTML and/or XBRL or any other format for that matter. Creating a financial is adjusting templates, running macros, and repeating this until your financial is complete.  Business rules enforce the integrity within and between components.  All that ugly XBRL stuff is hidden deep within the software, but that is what enables the macros to do their job reliably.

I can imagine pretty easily careating something like this in Excel.  Longer term, I don't see Excel as the platform for creating financial statements. I see something like GoAnimate as an example of how the application might work. The point here is to look at the process totally differently than it is being looked at today. Think model based reporting.

That is what seems to be in store for the last mile of finance, generating those financial reports. The process seems to be taking lots of little pieces and putting the pieces together. Why cut and paste when you can have a macro do the work.

Jon Rowden and Mike Willis of PricewaterhouseCoopers have writen a white paper for the Financial Executives Research Foundation (FERF) titled Making Sense of XBRL In the US and the UK. This is a summary of what the paper discusses:

There can be no doubt that XBRL (eXtensible Business Reporting Language) has become a hot topic for financial executives in the U.S. and also overseas. Many are already familiar, perhaps painfully so, with the SEC's XBRL reporting mandate for issuers and the requirements relating to 10-K annual reports and quarterly filings. This article from Financial Executives Research Foundation looks at what is happening in the United Kingdom, where the tax authorities have introduced an XBRL requirement that affects all companies required to file a tax return. In this article, Jon Rowden and Mike Willis from PwC highlight how the UK mandate differs in some key aspects from the SEC requirement, how the UK requirements are being addressed and outline a wider agenda of considerations for financial executives in the U.S. and elsewhere, prompted by the introduction of XBRL by regulators around the globe.

With 1.6 million legal entities affected by this requirement for accounting periods after April 1, 2010, the use of XBRL takes yet another step forward following the lead of the US SEC, US FDIC, and many others around the globe. The white paper is worth reading discussing the "last mile" of reporting processes, why XBRL and iXBRL are a catalyst for change, common pushbacks and the wider agenda for CFOs and audit committees.

My last blog post helps to provide a definition of what I am calling financial integrity. The post before that helps see how financial integrity is achieved differently on the medium paper than it is with the medium XBRL. In this blog post I endeavor to show how financial integrity can be leveraged because it is expressed in a manner usable by software applications.

Imagine having a job on the starship Enterprise and working with James T. Kirk, its captain. Imagine that you were on the accounting staff (I am sure there were accountants in Startrek) and that Kirk needed a financial statement so he could see how he was doing relative to his budget.  What would that financial statement look like?

You may not need to imagine this for long. Consider this Wired story about how the tablet will change the world.

Imagine that some of the knowledge of accounting and financial reporting was in a form that computers could read and understand. Imagine that a computer application could help you read that financial statement, leveraging the accounting information. Think pivot table. Think visualization. Consider the graphic below and how you might move from place to place in a financial report, from summary information to detail information, leveraging the financial integrity of a financial statement. Or if you were comparing financial information between periods or between companies.

From Wikipedia

None of this is done using magic. If you ever used a navigation system in your car or used Google Earth or Google Body Browser or other such tools.  How do those things work? Structured information. Meta data. Standards. No magic involved. Take a look at this page. Look at the geometric diagrams on the page. Notice the red dots in many of the diagrams. Those dots are connections. Computers can leverage those connections to achieve things like the rotating diagram above.  All we need to do is establish the connections.

We accountants are pretty good at expressing financial information with financial integrity on paper. We will learn to do the same thing using the XBRL medium. When we do and when software leverages the financial integrity, we will have new interesting and useful functionality at our disposal.