Business Case For XBRL

Purpose and Audience

The purpose of this document is to communicate the business case for XBRL (eXtensible Business Reporting Language) in terms that a non-technical business manager can understand. The document cuts through the hype and rhetoric often associated with XBRL, mostly because XBRL is so technical. This document communicates solid business reasons as to why XBRL is important to your business.

The reader's perspective may be that of:

A regulator or some other data collector which collects business information from submitters who are using paper-based methods or unstructured electronic methods, such as PDF or HTML filings.
A regulator or some other data collector which collects business information from submitters who are using structured electronic methods other than XBRL, such as a proprietary electronic method they have developed themselves and must maintain.
An entity or other data provider which submits electronic business information to a collector of data in some required format, whether structured or unstructured.

In this document, we first look at the evaluation criteria applicable to a business reporting system. We then provide a summary of the benefits. We provide a bit of background information to help business managers understand the concepts of "reach" vs. "richness" of data, metadata, and business rules, as these concepts are important in understanding business reporting systems. We compare quantitative data of business systems prior-to and post-XBRL adoption. Then, we elaborate more about the benefits of XBRL to business reporting systems, expanding on the summary of benefits in the beginning of this document. Lastly we provide four specific examples of XBRL common use cases in business reporting.

Business Case for XBRL

XBRL is not a new need. It is clear that businesses exchange information and that to effectively exchange information there has to be some level of agreement on how information is exchanged. There are literally hundreds of ways to exchange information, and that is actually part of the problem: having to be familiar with lots of different ways, having to use one way to exchange information with one organization, and a different way to exchange information with another organization. The fundamental reason for a business to use any technology, or anything else for that matter, is to compare benefits and related costs of each option and pick the best option. Sometimes the option is to stay with an existing solution, while in other cases a new set of alternatives are available.

Sometimes the quantifiable data is easy to get and deciding between the options is relatively easy. Other times the data is harder to quantify calling for more judgment in making a decision, or politics plays a central role and data is not relevant.

The need for something like XBRL is fairly obvious if you exchange information with others which are external to your organization. If you cannot control another organizations IT infrastructure, organizations have to come up with some agreed upon format for exchanging data. Over the years 100s of different formats have been tried with varying degrees of success. Each option has its set of pros and cons. Until now there has been no standard that everyone has agreed on. However, XBRL is beginning to stand out from the pack.

In this white paper we will take a look at the evaluation criteria which are appropriate for evaluating a business reporting solution. We will provide some background information in order to effectively understand these criteria and evaluate business reporting solutions. Details of how the benefits are achieved and examples of the benefits are also provided.

Evaluation Criteria

There are several criteria which can be used to evaluate the effectiveness and efficiency of a business reporting solution. Some of these criteria are easy to quantify, others are more difficult. Here are the primary criteria:

Cost of Capturing Data: How costly is the system to operate and maintain - what are the life cycle costs? There are many costs to consider such as training, maintenance, multiple software tools, etc. It is important to realize that most of the time it is more cost effective to use one standard method of exchanging data, such as XML, than to use 10 different methods if each method is basically doing the same thing.
Timeliness of Data: How important is timeliness of the data? How much more valuable is data received in 2 days versus 30 days, or 90 days?
Flexibility of Data Collection: How flexible is the system? If you want additional data points, or drop some data points collected, how easy is it to do within your systems.
Quality of Data: There will always be errors in data. Errors can likely only be reduced. What is the error rate of your data, 1% or 2% or 5%? What is the marginal value of dropping the error rate from 2% to 1%, or a 50% reduction in the error rate?
Reuse of Data: How easy is it to reuse the data? Is re-keying required in order to reuse the data? What is the likelihood of errors when the information is re-keyed?

Obviously, your business reporting solution can be better when you optimize the above criteria. But how? To answer this question, you need to understand just a little about XML and XBRL.

Summary of How Benefits are Achieved

There are many characteristics of XBRL which contribute to its overall benefit. The following is a summary of the features of XBRL. Each of these features is further discussed and elaborated later in this document:

XML Standard: One way to solve a problem, rather than 100s of different ways of transferring data. Lowered costs of training staff (only have to learn XML). XBRL is XML. Lots of standard software for working with XML. Reduced training costs.
Open Standards Provide Leverage: Open standards provide leverage. You can get for free things you would typically have to buy and you are not locked into one specific vendor.
COTS Software: Commercial off-the-shelf software can be used, rather than building custom, internally created and supported applications.
Cheap Business Rules Engines Improve Data Quality: Robust, validation engine and validation infrastructure moves the creation of business rules from programmers to business users. One-to-many validation rather than one-to-one programmatic validation.
Flexible, Extensible, Comprehensive Solution: XBRL is quite comprehensive in what it can achieve. Its flexible, extensible nature makes it extremely effective.
Structured versus Unstructured Data: People often miss the fundamental reason for XBRL/XML: structured versus unstructured data, meaning and "context" attached to data, truly can be exchanged effectively. Exchanged between trading partners, between entities and regulators, exchanged internally. Properly structured data is fundamentally easier to reuse between automated applications. Unstructured data is fundamentally difficult to reuse unless manual intervention is used.
Automated Exchange of Data: All the above adds up to the automated exchange of data within a single organization (subsidiary to parent, one application to another), or within a supply chain (between one company and another, between a company and its regulators).

More details of how these benefits are achieved are provided later. First, we would like to provide a bit of background information.

Background Information

There are a few rather technical concepts which are important to understand in order to properly evaluate a business reporting solution. We will take the time here to provide a non-technical explanation of these rather technical concepts. Business managers need to understand these concepts so they can talk to IT managers and be sure that the IT managers also understand these concepts and are considering them in their decisions.

Reach vs. Richness of Data

In their book Blown to Bits: How the New Economics of Information Transforms Strategy, Philip Evans and Thomas Wurster explain the concepts of "reach" and "richness" of data.

There are tradeoffs experienced between "reach" and "richness" of data, where

reach refers to access to data and
richness to quantity, timeliness, accuracy and type of data

In the past, you could have reach or richness, but typically not both at the same time. With XBRL you can have both.

Before we get started, it is helpful to point out how we are using the term "regulator". We are using the term more broadly as a party which can mandate certain actions from another party. Clearly the US Security and Exchange Commission is a regulator. Laws are passed, companies have to follow the laws, the SEC ensures that they do. But a bank is also a "regulator" in that if you want to have a loan with the bank, you have to abide by certain rules which the bank imposes on you. Subsidiaries are "regulated" by their parent company in that the parent dictates certain processes, procedures, etc. Keep this view of regulator in your mind.

One more thing to keep in the back of your mind is that XBRL imposes no burden on what information one party must provide to another. XBRL is simply a tool, a means of exchanging information if you are required to do so. It does make a few new things possible, but XBRL is not about imposing any specific reporting burden.

The highest quality data for internal auditors, regulators or external auditors as far as accuracy, quality, and type of data is most accessible only "on site". However, this data is the most costly to collect as you have to physically travel to the client's site and the data quickly becomes "stale" as time passes. Also, on site examination of data can be more disruptive and burdensome on the entity and the entity's personnel you are collecting the data from.

Data submitted to a regulator, an auditor, a parent company by its subsidiary, or a company applying for a commercial loan using paper or electronic forms on a regular basis is more current, but accuracy is often questioned and the type, quantity and therefore quality are less. Also, the more often the data is received, the more it costs to re-key the data so that the data can be processed by the receiving systems.

But what if you could have both reach and richness? What if every entity could generate electronic audit schedules of data in XBRL. What if regulators, external auditors, internal auditors systems could read this data whenever they want from their location. What if a secure web service could be provided by every company and used by external auditors, regulators (the SAME systems used for internal audit of the data, NOT different systems) rather than the endless paper, spreadsheets, Word documents, etc. How would that impact business reporting?

This type of system would never totally eliminate travel, but it would certainly reduce it. Transparency would be greatly increased. The technology exists to build such systems today, and they would be very useful for internal purposes, today, right now, and internal users would not be resistant to such systems. Now, having a business open up such a system to a regulator, well, that may give rise to a little more resistance. Until, that is, businesses realize that it is in their interests to do so.

Bottom line - end users get better information to make better business decisions. This is similar to what occurred in the automotive industry several years ago. It used to be the case that the job of a quality control department was to detect products which were defective at the end of the assembly line. That approach was expensive as you had to build something, spend money to make sure it was built correctly. If it was not built correctly, you had to spend money to fix it. Today, quality control is about not making the mistakes in the first place. You detect the reason for the problem occurring and fix that. This saves money that was spent on fixing the defects.

From a business reporting perspective, this is about detecting errors before they go into the system, or as early as possible; rather than introducing lots of errors into a system and fixing them once a year during the external audit.

Metadata 101

In order to understand some of the major benefits of XBRL one needs to understand the concept of metadata. Metadata is a commonly understood term within information technology, not so common in business.

In short, metadata is data about data. Everyone knows what data is typically, but the meaning of metadata is a bit harder to grasp; however the concept is critical to understanding the benefits of XBRL.

You use metadata driven applications every day and you may not even realize it. A good example is Microsoft Excel or Word. These programs are "localized" for different languages. The metadata for the menus, dialog boxes, all the stuff you see in the application is changed by applying a specific local's language to Excel or Word, which drives the display of information in "English" if you are in the US or in "Japanese" if you are in Japan.

Consider an invoice. Data on the invoice might include:

the invoice number, "I-10001"
the invoice date, "July 1, 2005"
the quantity of each line item, "500 boxes"
the amount of each line item, "$ 3000"
the total amount of the invoice, "$ 9000"

The metadata for the invoice, which is data which expresses the information the invoice must contain, might be things like:

the invoice number must start with the letter "I", be followed by a dash, and must be a 5 digit number,
the invoice MUST contain an invoice number, an invoice date, at least one line item, and a total
the relationship on the invoice that the sum of the amounts of each line item must agree to the total amount of the invoice, "SUM (Amount for Line Item) = Total Amount"

If the metadata can be expressed in a consistent, standard way, it can then be read by a computer application and other applications can use it. The metadata can be exchanged automatically between applications along with the data being expressed, resulting in new and better ways to transform and evaluate data.

One advantage of metadata driven applications is that they can be updated more cost-effectively than "hard coded" applications. Computer programmers must change hard coded applications. Business users can update metadata driven applications. This makes updates faster (whenever the business user wants to update them, not having to wait for the programmers to get around to it) and it allows the business users to update the applications without having to communicate with the programmers and articulate the business problem, the business user can do this directly.

In terms of financial reporting, you will see applications driven by XBRL financial metadata (a standardized set of financial terms, or taxonomies). These XBRL taxonomies have already been developed for US GAAP financial reporting and IFRS (International Financial Reporting Standards).

Computers can do some VERY interesting things with the metadata and data. First, if the metadata is communicated in a standard way, it can be exchanged by computer applications which understand that standard, reducing the need to build lots of individual proprietary solutions to the same fundamental problem.

Second, you can build a method of expressing and therefore use the expression of the semantic meaning which can be used to evaluate the data; but more importantly to drive the functionality and workflow of computer applications.

The fact that data can be defined in an organized way (structured) rather than unstructured, semantic meaning can be expressed as metadata, and XBRL is a global standard that allows for the creation of business reporting solutions which have functionality the likes of which have never been seen before. And at a relatively low cost because the applications are useful, flexible, and therefore used by so many.

A key to improving business reporting is metadata driven computer applications using open standards to express that metadata.

It is not the case that these types of applications have not existed before, they have. It is just that they were extremely expensive to create and therefore not really available to the masses. And they were not as beneficial as there was no global standard for the metadata.

Business Rules 101

One of the most powerful features of XBRL is its business rules capabilities or "formulas" as they are called in the actual XBRL specification. We will use the term business rules.

Business rules can be defined in many ways, and rather than using just one definition here, we will provide several:

The Business Rules Group (http://www.businessrulesgroup.org) defines business rules as "a statement that defines or constrains some aspect of the business which is intended to assert business structure, or to control or influence the behaviour of the business."
Or, business rules can be thought of as a way of expressing the semantic meaning of data.
Or another definition, "A formal and implementable expression of some user requirement".
Or "The practices, processes, and policies by which an organization conducts its business.

Types of business rules might be:

Definitions such as "Assets = Liabilities + Equity"
Calculations such as "Total Property, Plant and Equipment = Land + Buildings + Fixtures + IT Equipment + Other"
Process oriented such as "If property, plant, and equipment exists; then a property, plant and equipment policy must exist and property, plant and equipment disclosures must exist.
Instructions or documentation such as "Cash flow types must be either operating, financing, or investing.

What business rules are is quite important because they are extraordinarily useful for financial reporting. But what is even more important is HOW business rules were created and used in the past, and how they will be created and used in the future. You may, or may not, remember the day when someone building a computer application had to also build a place to store the data which that application used. Well, those days are over with the advent of the standard relational database management system (RDBMS) and structured query language (SQL). Basically, the data is separate from the actual application and you can go buy a standard SQL database, rather than everyone building their own. This separation between the database and the application occurred in the 1980's.

Another separation which has taken place is the separation of the business rules which drive the processing of the application from the application itself. This is a bit more recent, occurring in the 1990's.

What is important to understand is the efficiencies and effectiveness which can be achieved with business rules separated from applications themselves:

Rather than paying programmers to update rules (which is expensive and time consuming), business users who actually understand the rules can update them, saving both time and money.
Rather than having programmers create validation for each thing they wish to validate (called one-to-one programmatic validation) a business rules engine can be used to do validation (many-to-many rules-based validation).

And what if the business rules are also in a global standard format? You can exchange the rules with others. You can, for example,

use the rules to explain the data you are collecting,
which data needs to be collected,
validate the data prior to it being submitted, and
which data collection forms should be used by the type or quality of entity submitting data.

All this promotes an understanding of business policies and procedures, facilitates consistent decision making, forces order to rules and policies because they are clearly expressed; all with increased flexibility because of the separation of the processing logic from the rules, the ability of the business users to control the processing logic easily without understanding programming.

One Real Case

A good way to evaluate reporting solution options is to look at what others have done, why, and the experiences they have gained. Consider the following information from the US Federal Financial Institutions Examination Council (FFIEC), an early adopter of XBRL, which used this information to evaluate whether XBRL was part of a potential future reporting solution. This is publicly available information from the FFIEC. (see http://www.fdic.gov/news/news/press/2003/pr6503.html)

The same data exists inside multiple agencies in different formats increasing the probability of inconsistent data (Quality of Data). FFIEC wanted to store the data in one central location and used by at least three US agencies.
It took an average of 60 to 75 days to make data available. The process included receiving data, validating it, and then publishing it on the web. (Timeliness of Data). The goal was to reduce the time to publish the data as much as possible.
Estimated processing costs over the next 10 years were going to be $65 million (Cost of Capturing and Processing Data). They desired to keep costs to a minimum.
As an example, the March 2003 reports received had nearly 18,000 errors that needed to be corrected. These included approximately 1,000 basic math errors and 17,000 errors in semantic meaning (business rules) such as the beginning balance cannot exceed the ending balance. (Quality of Data). Desired to reduce the number of errors.
The reporting format was not flexible, it could take many months to get new data points which were desired to be collected into the system, and old data points which were no longer needed or desired persisted as they were hard to remove (Flexibility of Data Collection). They desired to have a more flexible reporting system.
Software vendors which provided tools to prepare bank Call Reports submitted to the FFIEC were provided reporting requirements in a variety of formats including Excel, Word, and PDF, which contained the metadata of the reports. Call Report software vendors spent much time and expense wading through these various formats manually to update their systems. The metadata includes data points collected, labels, instructions, formulas (called edits), etc. (Flexibility of Data Collection). They desired to make it easier for software vendors to update their systems for changes in reporting metadata.
Data was made available to others was hard to reuse; there was no real specification other than providing a CSV file (Reuse of Data). They desired to make the data available to others in a standard, reusable format.

Below is a table which provides the key characteristics of the FFIEC's system, a quantification of the characteristic in the existing system, a quantification of the characteristic in the new system, and a statement of the benefit:

Detail of How Benefits are Achieved

Now we will elaborate on the statements made above, explaining the statements in order to allow the reader to understand why the statement is true.

XML Open Standard

One way to solve a problem, rather than 100s of different ways of transferring data. Lowered costs of training staff (only have to learn XML). XBRL is XML. Lots of standard software to work with XML. Reduced training costs.

Fundamentally, XML is like a big "time out". Why do we exchange data using the 100's different ways we exchanged data before; why don't we take a step back, create a standard which works over the internet, and does all the things all those processes did. That is what XML is.

A great deal about exchanging data was learned between the 1960's and the 1990's. XML takes what was learned and created one fundamental way of exchanging data. Literally, the entire world is moving to XML for all sorts of things. And XBRL is XML.

Open Standards Provide Leverage

Open standards provide leverage. You can get for free things you would typically have to buy and you are not locked into one specific vendor.

Open standards are generally taken for granted, but you use them every day:

Obtaining cash from an ATM (Automated Teller Machine) any where in the world,
Using the internet which is a collection of open standards such as TCP/IP, HTTP, HTML, SMTP, FTP, and so forth,
Making a telephone call to anywhere in the world or taking your cell phone to any country and it works there just like it works at home (ok, we are not quite there, but you see why open standards are important)

XML is an open standard, as is XBRL. With the XML open standard:

The standard itself is free,
High quality XML software editors are free,
Lots of different vendors use XML, or support the standard.

Will 100% of your data exchange needs be met by standard solutions? Probably not. But standards can sometimes get you very close and reduce the reliance on proprietary software. The remaining portions of what you need for your specific systems can be built precisely as you need them.

Can proprietary software solutions be built that are better than open standards? Absolutely. That is just the nature of an open standard, there are compromises to get wide base of users to accept it. However, many times an open standard may meet your needs. And if the open standard will not meet your needs totally, it will certainly get you closer to the end result so you don't have to build a solution from scratch. For example, you need XML parser software in order to efficiently process XML, but how much has your organization paid to build an XML parser? While an XML parser will not get you 100% there, it does save you a lot of time and therefore money to have the fundamental level of working with XML provided for you.

The same goes with XBRL. And while there are no free fully functional XBRL processors now, if you surveyed the members of XBRL International, you would be hard pressed to find someone who will tell you that there will not be a free XBRL processor in the near future, probably open source. In fact, there are at least two groups building such XBRL processors.

Fundamentally, open standards are good for users as they provide leverage and they force software vendors to build better software because they cannot use the proprietary "locks" to keep you using their systems. So, users benefit because software vendors have to "lock" users by providing better features.

COTS Software

Commercial off-the-shelf software can be used, rather than building custom, internally created and supported applications.

COTS (commercial off-the-shelf) software can be created using open standards, or individual organizations can create, and maintain, independent solutions for basically the same problem. The latter is often more costly in the long run for the end users.

Fundamentally, if it cost you $1,000,000 to build a piece of software, and you have one user, that user has to pay $1,000,000 for the software. Two users, $500,000 each. Economies of scale. XBRL as an international standard can expand the number of users and therefore reduce cost.

Internal software will still need to be developed, but this will be mostly weaving together components provided by others. The quantity of internal development will likely be significantly reduced and the skills required of your internal software developers will be reduced as the "heavy lifting" was done by experts, for example XBRL experts will build XBRL processors.

Let's look at a specific example, the FFIEC. The FFIEC has business rules it enforces on its data, about 2000 of them. In order to enforce those business rules, they needed the following software components:

A way to build the rules
A way to evaluate the rules
Error messages
Other stuff, but you see the major pieces here.

For their older system, the FFIEC must have paid somewhere between $100,000 and $500,000 to build these pieces. You know how many users they had for their system: one; the FFIEC.

Part of the FFIEC's savings was that they could purchase a way to build the rules, a rules engine, and all the other requirements they needed to perform the data validation they needed: it all existed within XBRL, and there are several XBRL software vendors that support that standard. The cost of that tool; roughly $3000. What is really cool is that not only can the FFIEC buy it for $3000, so can you. It is standard, off the shelf software.

Now, this is a bit of an exaggeration as the FFIEC had other needs such as the ability to manage user rights to change rules, workflow, etc. But it is the case that the basic stuff costs that little, because the number of users will be larger, because it is an open standard.

Low Cost Business Rules Engines Improve Data Quality

Robust, validation engine and validation infrastructure moves the creation of business rules from programmers to business users. One-to-many validation rather than one-to-one programmatic validation.

Business rules were discussed previously to give you a sense for what they are. In summary, using business rules (as opposed to imbedding validation in software) have been proven to save 15 to 50% of a typical annual IT budget for making, testing, implementing, and changing business rules.

OK, so you can get relatively low cost rules engines. But that also means that you can USE the inexpensive rules engines to do things which accountants with green eye shades had to do before, because they are so inexpensive! For example, a company or CPA firm which prepares a financial statement has to verify the data on that statement, which can be 100 pages, is accurate. What do they do today? Give someone a calculator, the green eye shades, a desk, and then they go to town "footing" and "cross-casting" those number to be sure everything adds up. That means two things. First, this will be expensive because it takes time and accountants are not cheap. Second, there will be errors because no matter how good the person is, they are still human and humans make mistakes.

XBRL-based software can do a lot of this. Not everything, but certainly a significant amount is quite achievable.

Flexible, Extensible, Comprehensive Solution

XBRL is quite comprehensive in what it can achieve. Its flexible, extensible nature makes it extremely effective.

Imagine you already have an electronic system for exchanging data. How easy is it to change that system; adding data points you desire to collect, or removing data points you no longer wish to collect?

In the FFIEC's case it was somewhat difficult to change the data collection forms. Consider the following details:

If the data changes, clearly the data collection form changes.
In the FFIEC's case, the vendor software had to be updated for the new data point, or a data point had to be removed. The FFIEC communicated this metadata to the software vendors using Word, PDF, Excel, etc. It was a manual process to update the metadata because there was no standard format. The process could take days.
The business rules had to be updated if the data changed.

Normally it can be difficult to update metadata; but XBRL makes that process easy. It is flexible and extensible.

XBRL is very sophisticated and comprehensive. It provides many features now and a few more are in development.

Structured versus Unstructured Data

People often miss the fundamental reason for XBRL/XML: structured versus unstructured data, meaning and "context" attached to data, truly can be exchanged effectively. Exchanged between trading partners, between entities and regulators, exchanged internally. Properly structured data is fundamentally easy to reuse using automated applications. Unstructured data is fundamentally difficult to reuse unless manual intervention is used.

XBRL boils down to the value of structured data versus unstructured data. Unstructured data is simply a bunch of data that is not highly categorized. It is difficult to automatically manipulate, query or assign business rules. Structured data is obviously the opposite. To date, financial information has not typically been structured and certainly not in an internationally standard way. XBRL changes that.

In a very good article, a CEO's Guide to eCommerce Using Object-Oriented Intelligent Agent Technology, Peter Fingar points out what software can be used for when the data is structured. Imagine an intelligent software agent scouring the Internet trying to find you a great investment opportunity. This is not science fiction; this is what the "semantic web" is all about - structured data on the web accessible by computer applications without human involvement.

For example, imagine a piece of software interacting with you as you are creating a financial statement, literally guiding you through the process:

Are you using US GAAP or IFRS? (You answer US GAAP)
You are creating a cash flow statement. There are two types: indirect and direct. What type would you prefer? (You answer indirect)
There are three sections to that statement: cash flows from operations, cash flows from investing activities, cash flows from financing activities. Please describe your line item (You answer "Purchase of Property, Plant and Equipment).
The application puts that line item precisely where it needs to go. Yes, that is an investing activity. Have a nice day! (You don't have to go look this up)

Intelligent agent software like the above can make you as smart as the individuals who built the intelligent agent. If, for example, an accounting expert built the XBRL IFRS-GP taxonomy (which they did), that makes you as knowledgeable as them, their intellectual knowledge about financial reporting practices is imbedded in that taxonomy. Not all knowledge, that is impossible. But what can be imbedded, is imbedded. And it is open standard freely available to be used by any software application.

These aspects of XBRL are somewhat difficult to believe or understand, until you use some software which lets you actually experience the benefits. Then you will see it with your own eyes, and believe it!

Automated Exchange of Data

All the above adds up to the automated data exchange within a single organization (subsidiary to parent, one application to another) or within a supply chain (between one company and another, between a company and its regulators).

All the above is about one computer application effectively exchanging data with another computer application, anywhere in the world without human intervention, or only human intervention where it is needed. And while we would like to go into greater detail, it is not in the scope of this document, all the details of security, authentication, non-repudiation, etc. are all assumed to be handled in standardsbased ways.

But to do this exchange effectively, a lot needs to happen to ensure the data is accurate, the connection is secure, you are exchanging with the correct party, etc. All these pieces work together to provide value to a business who wishes to exchange business information with someone else next door or literally anywhere in the world.

XBRL actually can reduce human intervention in this data exchange process, not all human intervention; but even if 20% is reduced, a lot is gained. The more human intervention which is eliminated, the more timely the data, the fewer the errors, and the lower the costs, etc. It is highly unlikely that all human intervention can be eliminated from all data exchange transactions. Humans will be doing what computers cannot do, things like handling exceptions and other anomalies which computers point out.

XBRL is often referred to as a disruptive technology. The way business information is exchanged will change significantly. This will likely lead to changes in the way business is done.

Examples of Benefits

Another good way to understand XBRL and its benefits to business is to look at how other businesses use XBRL today and how they could use XBRL in the future. The following will provide some examples. This will give you an indication of how you might use XBRL. More details follow after this introduction.

Spreadsheet Hell: Literally millions, if not billions, of spreadsheets exist within businesses. Sarbanes Oxley will point out the problems with these spreadsheets: hard to see where the data comes from or where it goes, thus hard to see the audit trail. XBRL provides several solutions to the problem commonly referred to as "Spreadsheet Hell".
COREP Basel II Reporting: What do you do if you are one of 25 regulators in the EU, each of the 25 regulators having different laws for financial institutions, different languages, and banks which operate in multiple countries: implement XBRL? This example shows how XBRL could solve the reporting of the 25 central banks in Europe. It points out some key benefits of XBRL.
Commercial and Consumer Loans: Banks loan businesses money. Businesses provide financial information at inception, and during the term of a loan. How is this information exchanged today? Paper, fax, PDF, hundreds of uniquely formatted Excel spreadsheets or Word documents. How is this information analyzed by the banks? They re-key the information, usually quarterly, into their commercial loan analysis applications. Could loan losses be reduced by analyzing the data monthly rather than quarterly? Probably, but the re-keying of data would cost too much.
Forms, Forms, Forms: Businesses fill out many forms. For example, each year businesses renew their health insurance, providing a list of employees and other information (basically a form) to an insurance company. XBRL can be used to automate that process.

Spreadsheet Hell

Spreadsheets... everywhere. A blessing, and a curse. Spreadsheets solved a lot of problems, and they caused some new ones.

XBRL offers three benefits to working with spreadsheets:

A standard format to define data to be exchanged from spreadsheet to spreadsheet, into spreadsheets, and out of spreadsheets.
A set of calculations and business rules expressed as an OPEN STANDARD usable by any application which supports the standard, independent of the spreadsheet, which makes it possible to properly audit spreadsheet formulas.
A method of explaining the metadata of the spreadsheet so data can be exchanged without rekeying to other applications.

Spreadsheets will likely always exist, they are very flexible, useful tools. But like most things, what is a strength in certain circumstances is a weakness in others.

The flexibility of Excel makes them easy to create what you need. But that flexibility makes auditing the flow of information extremely difficult.

Some of the requirements of Sarbanes-Oxley are going to be very challenging to meet if spreadsheets are involved in the process.

What if it was possible to set up formulas in a spreadsheet which you were 100% certain that the user could not change? What if you could clearly articulate the metadata of the spreadsheet and confidently exchange data from your spreadsheet to another user with 100% accuracy and automation? These things cannot be done with spreadsheets, but they can if XBRL is introduced into this process.

Basel II Reporting

The Basel II accords are international agreements which are intended to help understand and communicate capital adequacy requirements in internationally active banks. This effort helps to establish a common language for communicating the risks of banks around the world so that the banks themselves, their supervisors (regulators) and the public markets have a more thorough understanding of the risks in banks and help banks maintain adequate overall capital requirements.

In Europe, 25 countries are implementing Basel II. The Committee of European Banking Supervisors (CEBS, see http://www.c-ebs.org) is leading this effort. Each supervisor in Europe will need to be able to effectively collect information from financial institutions. In addition, supervisors will find it necessary to exchange data among themselves in order to effectively manage banks in Europe, especially those with branches in multiple countries.

How will this be achieved? There are basically four options:

(a) Each of the 25 supervisors creating their own electronic standard for collecting Basel II information. Then, systems can be cobbled together which translate between the 25 different standards. Then, a bank operating in multiple countries would have to use multiple standards for filing Basel II information. Basically, each country spends money to create and maintain their own electronic exchange format using their internal expertise. No leverage basically.

(b) Each of the 25 supervisors getting together and creating a standard which they will all use. This standard will ONLY be used for collecting Basel II data. Basically, the 25 supervisors would have to "reinvent XBRL" or at least a fairly good part of it as each supervisor is free to modify the base filing requirements as they see fit, a feature XBRL can handle.

(c) All of the 25 supervisors agreeing to use XBRL. They create an XBRL taxonomy which will serve as a base. Each country can modify that base taxonomy. All banks report using XBRL in every country in which they operate. In fact, banks can even use XBRL to report to OTHER regulators therefore the banks actually need to understand only one way of reporting to all of its external, and internal, regulators - XBRL. They can use off the shelf software to gain leverage. And leverage the XBRL standard to gather other financial data, such as quarterly financial reports. Banks and regulators can use the same processes to exchange and publish multiple sets of information.

(d) Use some other existing open standard. However, none has been identified which would fit the bill at this time.

CEBS has released a consultative paper recommending XBRL for both risk reporting (COREP) and financial reporting (FINREP) for banking supervision across the European Union. Over the coming months, the course will be determined. However, option "c" above - XBRL - is being strongly supported.

Commercial and Consumer Loans

Banks loan businesses money. Businesses provide financial information at inception, and during the term of a loan. How is this information exchanged today? Paper, fax, PDF, hundreds of uniquely formatted Excel spreadsheets or Word documents.

How is this information analyzed by the banks? They either just store the paper or re-key the information, usually quarterly, into their commercial loan analysis applications. Could loan losses be reduced by analyzing the data monthly rather than quarterly? Probably, but the re-keying of data would cost too much.

In the US there are about 25,000 public companies which are regulated by the US Securities and Exchange Commission (the SEC). There are 8 million private companies which are "regulated" by financial institutions which lend them funds for operating purposes, long-term asset acquisition, etc. The 25,000 public companies also borrow funds from financial institutions and others.

How beneficial might it be to a financial institution to have this information exchanged using an electronic format? Might they be able to collect data more cost effectively? If banks collect the information more often, could it help reduce their loan losses because they can better analyze the businesses they lend funds to? What benefit is this to the companies who have to submit the information in an electronic format? None you say. Consider this. Who do you think absorbs the costs of the loans which are made but have to be written off because it is never repaid? That cost is hidden in the interest rate you pay for YOUR loan and perhaps the amount and type of collateral you provide, even though your business has less risk.

What about the other small private businesses around the world?

Another factor in this is that there are books and books filled with comparative information which the banks use to compare one company with another. The information is so condensed that it is basically little more than useless and banks are basically "going through the motions" as it is the best information they have available.

All this applies to personal loans also.

XBRL can obviously change this by exchanging financial information that will need little to no re-keying. And the financial data can be compared against other companies in the same peer group.

Forms, Forms, Forms

Businesses fill out many forms. For example, each year businesses renew their health insurance, providing a list of employees and other information (basically a form) to an insurance company. XBRL can be used to automate that process.

There really is no standard format for "forms" data. Could XBRL work? Certainly. The FFIEC example discussed above is a regulatory use of XBRL for "forms" data. The steps would be relatively simple:

Create an XBRL taxonomy to express the data on the form. This would include the data points, the calculation relationships, the business rules used by the form, etc.
The user requesting the data could even create a mechanism for filling in the form which then outputs XBRL. This could be an Excel spreadsheet, a PDF form, HTML form, XHTML form, XForms, a simple stand-alone application. Any of these are rather easy to create.

The hard part of XBRL (but also one of its most valuable features) is the extensibility part - being able to add or remove some requirements. If users cannot change the form, there is no need for extensibility, that is how most forms work. They are, well, forms.

And if a business uses XBRL for one thing, how easy would it be to use XBRL for another? The hardest part of XBRL is basically getting the loop started, somewhat of a "chicken or the egg" type situation. Once the cycle gets going, the benefits will be easy to see.

Think of the forms you use today which are exchanged within your own organization or between your organization and a, regulator, suppler, customer, etc. What if there was one standard way to:

Express the metadata of the form. (The data points collected, the calculations, the business rules, in multiple languages, with instructions.)
Validate the data prior to submission to the consumer of the data.
Validate the data prior to consumption of the data (same standard validation as the creator of the data).

Here are some examples of commonly used forms (note that these are US centric examples):

Expense reports.
IRS forms for quarterly taxes.
State taxes
US ICC (Interstate Commerce Commission) and state trucking related taxes and registration.

There is one final thing worth pointing out. Right now these "forms" are filled in manually. In the future, a printed version of the form my never exist at all. Much of this data will be generated from applications where this data already exists. And where exactly the same data is collected by different entities, it can be reused.

Looking at the spectrum of possibilities again, data will be competed in one of the following manners:

100% automated, humans never touch the data and only deal with exceptions.
100% manual, the data is entered into a system (filling out the form); the data does not exist in another application or it is not cost effective to get the data from an application onto the form, it is simply easier to re-key the data.
Some combination of the two: a portion is automated (0 to 100%) and a portion is done manually (0 to 100%), thus resulting in the totally completed form data set.

BUSINESS CASE FOR XBRL