In This Chapter
Discovering how XBRL is changing business reporting
Revealing the truth about XBRL
Figuring out how to make XBRL work for you
Discovering good reasons for considering XBRL
Bridging the information gap between business systems
You may have heard about XBRL, but have no idea what it is — only that you need to start using it. If that's the case, you're in the right place. In this chapter, we journey into the world of XBRL by giving you all the things you need to get your head around XBRL in the form of a conceptual overview. We explain what XBRL is, describe the environment that it fits into, give you some examples of who is using it and why, what benefits it provides, and what it might take for you to start using XBRL. Basically, in this chapter, we define a framework that you can use to get your head around XBRL and leave it to other chapters to drill into the details.
Now that the United States Securities and Exchange Commission (SEC) mandates the use of XBRL, stock exchanges around the world use it, and it's officially supported by the European Parliament as well as the governments of the Netherlands, Australia, Singapore, Japan, India, and China. The Extensible Business Reporting Language (XBRL) is pretty much undeniably a global standard for business reporting. Obviously, XBRL is here to stay.
Your business operates on information, so you need to know the fundamentals of XBRL. This collection of information may be physically separated by artificial boundaries between the different business systems you use to operate your business. This collection of information may not even be in your own business systems, but within the business systems of your suppliers, customers, and other business partners. If you can bridge this gap between different business systems, both those within your organization and other organizations within your supply chain, a more cohesive information set results, enabling you to see your business like you have never seen it before, and vastly improving your effectiveness in managing your business and the supply chains in which your business participates.
Note
XBRL is, fundamentally, a language that helps businesses effectively and efficiently bridge the current gap between business systems by crossing these artificial boundaries.
Figure 1-1 shows the common relationships that most businesses have. Suppose that you work within the parent company shown in Figure 1-1. You'll likely have more than one business system, ranging from a big Enterprise Resource Planning (ERP) system and Corporate Performance Management (CPM) system to perhaps small but important spreadsheets that contain information. Those business systems are generally internal to your organization. You may need to exchange business information with subsidiaries, which also have business systems. The same is likely true of customers, suppliers, regulators, and a plethora of others with whom you interact and exchange all sorts of information. These systems are generally external to your organization. In the past, no standard for exchanging information between these internal or external systems existed, so you created homegrown, automated, one-to-one approaches or one-to-many approaches, or used approaches requiring a lot of human involvement that have been the norm to exchange information between business systems. With XBRL, more of these information exchanges can be efficiently automated by using one globally standard approach.
Warning
Don't be fooled into thinking that because XBRL is now used mostly for financial reporting or by regulators that you don't need to pay attention to XBRL. Assuming that XBRL is not applicable to you is like assuming that HTTP (Hypertext Transfer Protocol, one of the key ingredients of the Web) is not applicable to you. You may not care about the nitty-gritty details of XBRL or HTTP, but you care about using what they enable.
Managers at all levels of business need timely, complete, accurate business information that is relevant to their purposes. The vast amount of human capital that is currently expended to integrate this information manually, commonly using point solutions (such as entering data into spreadsheets), clearly demonstrates this need. (Point solutions solve a problem for a specific limited situation, but don't do anything to resolve related issues.)
Before the ubiquitous and now almost free (or certainly low cost) connectivity of the Web, integrating these various systems, using human capital and point solutions, such as spreadsheets, was the only real solution to this problem for most businesses. However, thanks to the Web and technologies such as XBRL, any organization now has at its disposal better, more effective, and more efficient methods to solve these types of problems. No longer do you have to be a gigantic multinational corporation to afford these types of integrated solutions.
Note
It's not that business systems weren't interconnected before: Certain business systems that had to be interconnected were interconnected, regardless of the cost, because the benefits were so critical or the cost savings were so huge. For example, the ticketing systems of airlines are interconnected, allowing you to book flights from one location to another even if you're on different airlines for different legs of your journey. Today with XBRL and other enablers, however, the cost of bridging these types of gaps can be so low that the cost-benefit equation has shifted, meaning that more gaps can be bridged because the net benefit of doing so is so much larger. Smart businesses take advantage of these opportunities and become better, more competitive businesses.
One of the most confusing things about XBRL for those new to it is that it means so many different things to different people. Business reporting is a broad area. We want to cover all the bases in this book, so we want to be careful to include all the different views of what XBRL is. Depending on the situation, you can look at XBRL as
A freely available, market-driven, open, global standard for exchanging business information
An XML language
A global consortium of more than 600 members
A means of modeling the meaning of business information in a form comprehendible by computer applications
A mandate from regulators from around the world
A revolution for small investors, the most important shareholder initiative in a decade, and a leveler of the investment playing field
A global agreement on business information concepts, relationships, and business rules
One of the more successful Semantic Web metadata formats (we explain more about the Semantic Web in the upcoming section "Making life or easier")
A better approach to exchanging business information
A new way for companies to distribute their financial and other relevant business information
The fact is that all the preceding statements are true; they appeal to different audiences who have different focuses on different aspects of business information and the process of exchanging that information. The business community is generally concerned with making business information exchange the most effective that it can be at the minimum cost. Depending on your role in the business community, the term "effective" can have different meanings. Everyone understands what "minimum cost" means, however. (In Chapter 5, we look more at how XBRL affects different kinds of users.)
We do want to get one thing straightened out: When people look at XBRL, they think of business reporting because, well, business reporting puts the "BR" in XBRL. In reality though, XBRL is actually broader than what most people think of when you say "business reporting." From our perspective, XBRL is really more about describing business information and enhancing that information's exchange across internal or external business systems. One aspect of business information exchange is business reporting. For example, exchanging data or information between two business systems (computer to computer, no humans involved) isn't really seen as business reporting by many. However, that type of business information exchange is definitely within XBRL's scope. So basically, business information exchange includes what many know as business reporting. Business reporting is a subset of business information exchange. In this book, we use the term business information exchange, which includes but is not limited to business reporting.
One approach to understanding what something is, is to understand what it is not. Here are some common misconceptions and how they tend to get in the way of understanding XBRL:
XBRL is a standard chart of accounts. In reality, XBRL is exactly the opposite. The first letter in the acronym XBRL stands for the word "extensible." Extensibility, or the ability to "tweak" an XBRL taxonomy is one of the primary values of XBRL. (An XBRL taxonomy is like a dictionary that specifies business concepts — we explain in the upcoming section, "Getting a Grip on XBRL Fundamentals.") If the data you're reporting is fixed (that is, a form that can't be changed), you may not need to use XBRL (although it can still provide significant benefit). Many of those adopting XBRL (such as the United States SEC) do so because of its capacity to be dynamic and to allow changes to the XBRL taxonomy. A standard chart of accounts is generally fixed, not allowing for changes of any kind.
XBRL is a language for expressing concepts; creators of XBRL taxonomies decide which concepts they want in the XBRL taxonomy. It's not about data standardization (in other words, mandating one chart of accounts for everyone). In fact, XBRL itself doesn't define any concepts at all; users of XBRL do that.
XBRL requires companies to disclose additional financial information. Nope, incorrect. What XBRL does is simply take what is being reported now and report it in a different format, in a format that is readable by automated computer processes. Remember, XBRL itself defines no taxonomies; the users of XBRL do.
XBRL is just about financial or regulatory reporting. Oops . . . that's not right. XBRL is sometimes thought of as only for regulators or just for financial reporting because some of the early adopters were regulators who were using XBRL to collect financial information. Those industries were early users of XBRL, but they were only leading the pack. For example, XBRL Global Ledger is a canonical, or standardized, information exchange format for cross business system information exchange both internally and to external business partners. XBRL taxonomies also exist for exchanging nonfinancial information.
To learn XBRL, business users have to learn about angle brackets, XPath, XLink, and a lot of other complex scary technical stuff. Whoa! Hold on there. Just because business users had to learn to use e-mail and a browser to be more effective doesn't mean they had to learn about all the technology standards underlying the Internet. Good software vendors hide the complexity of XBRL within their software, just as an Internet browser shields business users from HTML, HTTP, TCP/IP, and numerous other elements of technical infrastructure.
XBRL is still maturing, as is the software being developed to make use of XBRL. Software vendors are still exploring very clever and creative ways to get all the benefits without exposing the wiring under the hood. Much of the XBRL software that exists at the time of this writing is for technical users. The software, such as XBRL processors used by technical people, needs to be built first, and then the technical users create software for the business users. Be patient — business-user-friendly software is on the way.
Users of XBRL don't need to learn anything new. Many people marketing XBRL say that business users don't have to learn anything new, which may not be fully accurate. Business users do have to think about things differently as XBRL enables process enhancements to current processes. Think of when the world moved from paper spreadsheets to electronic spreadsheets. Did business users have to learn new things? Certainly. Did it kill them? Certainly not.
XML is easier than XBRL, so I can just use XML. XBRL is XML. You have the choice of using the freely available standard that is XBRL, or you can spend your resources to create your "own" version of XBRL, which does everything that XBRL already does in terms of additional functionality. That is exactly what the people who created XBRL already did . . . using XML. XML is a syntax (a set of technical rules governing the appropriate arrangement of symbols and words): XBRL provides additional business semantics (or business meaning) not provided by XML alone. With the XBRL standard, these semantics can be communicated to and used by others, effectively transferring business meaning.
If you did create your own version of XBRL, what you would have would be proprietary (as opposed to a global standard), so you would have no off-the-shelf software supporting it, and you would have spent a lot of time creating something that already exists. (Chapter 2 discusses XBRL and XML in more detail: Be sure to have a look at that discussion if you're trying to understand the relationship between XBRL and XML.)
You already have a global data warehouse, so you don't need XBRL. Many companies believe that because they already have all their data in a data warehouse or data mart, they have no need for XBRL. If you are in this situation, consider two issues you have:
Getting quality information in to the data warehouse
Getting relevant and complete data out and into the hands of users XBRL enables solutions to both of these concerns by providing a standardized method to solving such common issues, rather than requiring each global data warehouse to individually solve the same problem. This standard method opens up the possibility for business systems to communicate with one another, exchanging important information, such as data models, validation rules, analytical rules, reporting concepts, and so on between business systems such as global data warehouses. Just like other Web standards, XBRL transforms the current producer orientation into an information supply chain in which the providers and consumers of business information collaborate.
You've probably already heard a lot of the hype and maybe even some of the compelling things that XBRL can do for you:
Making business information exchange better, faster, and cheaper
Making financial reporting more transparent and discoverable
Explicitly articulating business meaning and thus enabling the exchange of that meaning between humans or between business systems
Improving data integrity
Integrating business systems
Saving government agencies money and making them more efficient
But all those reasons may seem esoteric and perhaps even too far-fetched for most people to get their heads around. We want to provide you with some pragmatic, down-to-earth ways that XBRL can be good for you today. The following sections highlight what XBRL can do for you. (Better yet, the rest of the book fills in the details.)
Computers are great at handling routine, repetitive tasks for you. They do the hard, boring, complex work for you precisely as you tell them to do it. Here are some of the ways XBRL can make your life easier today:
Document domain knowledge: People have a lot of knowledge about different business domains locked up in their heads. Documenting that knowledge within an XBRL taxonomy is quick and easy with XBRL. The semantic meaning will then be useful to others, not just you. You can see the value of documentation by examining the domain knowledge documented by other domains, such as financial reporting knowledge documented in the IFRS or US GAAP XBRL taxonomies.
Improve an information-supply chain: Start with something simple and easy, but try to put together an information-supply chain making use of XBRL to solve a problem where you're using human intervention to make the connections between the links today.
Create and demand linked data: Linked data is simply connecting one set of data with another set of data to make both data sets more useful. A new mantra of Sir Tim Berners-Lee (inventor of the Web) is "Linked data! Get out there and make it, be sure to demand it!" Create some linked data; if it makes sense, use XBRL. Or, use someone else's linked data. (See
http://www.ted.com/index.php/talks/tim_berners_lee_on_the_next_web.html.) Contribute to the Semantic Web!Tip
To avoid having to type these long links, go to
www.dummies.com/go/xbrl. This takes you to a landing page where you can click the link you need.Build an internal semantic Web: Just as there is the Internet and intranets, there will be a Semantic Web and internal-use (that is, private, limited access) semantic Webs. A semantic Web is an approach to creating a web of information that is more like a computer-readable database (but still also usable by humans) than a bunch of human-readable pages of information, which a computer doesn't understand. Build an internal semantic Web, using XBRL because it's one of the more mature semantic Web technologies, and find out what the technologies can provide to your organization. Building an internal semantic Web can potentially give you an edge over your competition.
Work with business partners to create an extranet-type semantic Web: This suggestions is the same idea as the building an internal semantic Web, but with business partners instead of within your organization.
Say that you're one of those frugal folks. You really don't care about the Web or XBRL, but you do care about saving time, and saving time is saving money. Here are some of the ways you can employ XBRL to save money on tasks you probably already perform:
Improving integrity of information: When you create a business report, try to leverage XBRL to improve the integrity of your business information by allowing XBRL to help you check computations and reportability rules to make sure that things add up and that you're properly providing all the correct information. Helping business information creators be sure their information "ticks and ties" is an often missed benefit of XBRL.
Collaborating with business partners: If you're receiving information via fax, spreadsheets, or some other nonautomated means, try automating the process (no matter how small) by using XBRL.
Making business systems interoperable: Rekeying information is an inefficient and error-prone process, but it's amazing how much rekeying still takes place. Prior to XBRL, the cost of automating some processes exceeded the potential benefits. XBRL flips that cost model on its ear. Today, you can achieve for pennies what would cost hundreds of dollars before XBRL existed.
Looking for good investments: Scour the Web for companies that may have been overlooked in the past. Let search engines help you discover these investments. More and more companies are reporting their financial information by using XBRL, so take advantage of it!
Analyzing information: Rather than gathering information into your analysis models by rekeying information, try to automate the process and grab the information you want to analyze from an XBRL instance.
Making your system more flexible: XBRL makes your systems more flexible because XBRL was built to allow for changes to your information. XBRL isn't a fixed standard chart of accounts; XBRL is built to be dynamic, and flexibility is built into XBRL. You can leverage this flexibility within your system.
At times, you might simply have a tactical need to improve a process or help a business project move along faster. XBRL vendors, and many companies using XBRL, are looking to make completing projects faster and easier by
Leveraging a global standard: One of the major benefits XBRL provides is leverage. The global standard XBRL may not always provide everything you need to completely create an end-to-end solution to any specific problem in and of itself, but it does offer significant leverage. XBRL provides is the common components that you need in creating many different types of solutions. Building these common components by using the global standard XBRL provides significant leverage to these similar, common problems, therefore arriving at a solution faster, easier, and cheaper.
Empowering your workers: Every employee today is a knowledge worker, powered by information. Workers depend on the information in your business systems. Much of this information has been stored in spreadsheets and other mediums that make reusing that information extremely challenging. XBRL changes all that. XBRL enables workers to collaborate on how they use, analyze, and relate to business information and related processes.
Standardizing information exchange between systems: Many times, the information format doesn't really matter. When it doesn't matter what format you use to exchange information between business systems, use a standardized (often referred to as canonical) format like XBRL that offers a one-to-many type of exchange that works for many problems, rather than building one-to-one solutions for each specific information exchange between systems.
Building a system, not a point solution: Rather than building one point solution after another (a solution that solves a specific problem but not related ones), build a system that allows for the easy of creation of a category of business information. Using a standardized information architecture can facilitate a wide range of process enhancements.
Fundamentally, XBRL is a language that lets you effectively and efficiently bridge the perceived artificial boundaries between business systems, exchanging business information between those systems, be they internal or external to your organization. After all, there is only one Web, and we're all connected to it. Why should exchanging business information be so hard? How does XBRL make this information exchange process easier?
A simple example of exchanging information can help you understand how XBRL works. Chapter 4 dives deeper into the details, but for now, we keep this simple and focus on what's important in understanding the big picture. Figure 1-2 shows an example business report.
The figure shows a condensed set of financial highlights with which you should be comfortable. The information in the report is for Example Company. Two periods are shown, 2009 and 2008. Information is expressed in thousands of dollars. Two line items are shown: Net Income (Loss) and Sales, Net. Although this example is simple, it helps keep you focused on what is important.
Simply put, XBRL is a language that lets you build what you probably typically think of as a report. This report is a physical document, just like other documents you're familiar with: a word-processing document, a spreadsheet, or maybe a PDF file. Like these reports, XBRL also has a document. The XBRL document, also called an XBRL instance, is built in the form of an electronic file and contains business information.
Note
You may hear this type of XBRL document called an XBRL instance, instance, instance document, maybe XBRL instance document, or even XBRL report. In this book, we refer to it as an XBRL instance. Within this introductory section, we may use the more familiar term report at times.
An XBRL instance has four main parts:
Values: The values are the text (individual values or entire narratives) and numbers in the report, the business information. Generally, the text and numbers come from some sort of business system, such as an ERP system or a spreadsheet. For example, a value would be a number like "5347" or text, such as "Inventory consists of finished goods and work-in-progress" or even a paragraph or so of narratives.
Context: The context explains important information about the values. You need to understand what entity the value relates to, what period the values relate to, and if the values are actual, budgeted, and so on. For example, you want to be able to say that the information relates to your company and not some other company, and that the period is for 2009, not 2008.
Concepts: By concepts, we mean technical representations of business terms. For example, "Net Income (Loss)" and "Sales, Net" from Figure 1-2 are business terms. These business terms are associated with the text or numbers contained on a business report, the values. You can represent these business terms as technical structures and give them unique names, such as "NetIncomeOrLoss" or "SalesNet." You don't want confuse one concept with another; the unique names help to differentiate concepts and the associated business term. The concepts are basically a controlled vocabulary of precisely defined business terms. These can be financial reporting terms, accounting terms, or even nonfinancial terms; they really can be any terms, but they'll likely be business terms of some sort. Values (like "5347" in the example) are reported for concepts and are reported within a specific context.
Dictionary: Concepts are expressed within a dictionary. In XBRL, these dictionaries are referred to as taxonomies, but we want to use the more comfortable term, dictionary, for a moment. The dictionary doesn't necessarily define the concepts, but it does either define them or point to the definition or provide a definition in some manner. The important thing here is that the dictionary is the central location where concepts are pointed to information that defines that concept. The dictionary gives a precise definition about the meaning of each term (semantics), including references and examples. Other information helpful in making use of the concept is also provided, such as labels in any number of languages, relations of a concept to other concepts, and such. For example, a dictionary may contain the concept "NetIncomeOrLoss" or "SalesNet," express that the concepts have labels of "Net Income (Loss)" and "Sales, Net," respectively, and communicate the specific ways the concept relates to other concepts in the dictionary such as "SalesGross," "Taxes," and "Expenses."
Note
You may hear what we have referred to as a "dictionary" above referred to as a "taxonomy" or "XBRL taxonomy" or maybe sometimes even "schema." For this initial explanation of XBRL, we will stick with "dictionary" a little longer allowing you can become comfortable with this new term. Throughout the rest of the book, we will use the term XBRL taxonomy.
Does this discussion sound familiar? Sure, you do work with these ideas every day, even though you may not think about it in this way. But all this XBRL stuff is not for the benefit of humans, at least not directly, but rather for the benefit of computers, to allow them to communicate with each other. What a computer needs to achieve effective communication is provided by the structure within the XBRL instance and XBRL taxonomy so that the computer can figure out what is a value, what is a concept, what is a context, and such. This structure is achieved by using the XML syntax, creating something many people refer to as a tag.
Within the XBRL instance, the business information, or the value, is expressed in the form of what is often referred to as tags. Tags are the names of concepts defined in the dictionary, called an XBRL taxonomy. Each value has a specific tag, and that tag connects to the concept and its definition and all the other information contained within the dictionary. For example, one tag may be "Net Income (Loss)," while another tag may be "Assets."
Tags are used in many places. XBRL instances and XBRL taxonomies are collections of these tags. A tag's fundamental function is to add structure that enables computers to understand the pieces of an XBRL instance and XBRL taxonomy. People can still understand and work with this information. People don't work with the information at the tag level, but because of the tags, computers can work with the information and help people do all sorts of new, interesting, and helpful tasks.
Although you probably won't work at the level of the tags, understanding what tags are and how they work is helpful in understanding how the tags, and the structure they provide, enable computers to achieve this understanding. Tags look like this within the XBRL instance:
<gaap:NetIncomeOrLoss contextRef="Period-2009" unitRef="US-Dollars" decimals="INF">5347000</gaap:NetIncomeOrLoss>
The preceding code expresses the value 5347000 as being for the concept gaap:NetIncomeOrLoss. The other tags help explain the context of the information.
Concepts used within the XBRL instance are specified within the dictionary in the form of other tags, or elements, and look like this within the dictionary. (Keep in mind that the dictionary is referred to as an XBRL taxonomy.)
<xs:element name="NetIncomeOrLoss " type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="duration" xbrli:balance="credit">
The preceding code specifies a term as a tag within a XBRL taxonomy, which is then used within the XBRL instance to express a value. In our example, the term Net Income (Loss) is specified in the dictionary as the element "NetIncomeOrLoss. The definitions of terms specified come from accounting rules, regulations, laws, international standards, other written specifications, or from whatever governing body (a government, a regulator, a company, and so on) that wants to exchange information in this manner. Definitions may also come from your internal corporate data warehouse information models.
The dictionary, expressed as an XBRL taxonomy, isn't included within the business report; it's separate and referenced from the report (XBRL instance). This separation allows dictionaries to be shared by multiple reports. The dictionary may live on the Web, or it may live only within a company's intranet, but it has to be in a location where all the people and software that make use of the report can find it.
An XBRL instance is always connected with an XBRL taxonomy, the dictionary of what is contained within that XBRL instance. If your business information includes concepts not within the XBRL taxonomy, you can add your own concepts by using a formal process. Software can then use the custom information you add because the customization is prescriptive, meaning there is a prescribed, and therefore predictable, way these new concepts are added. Adding concepts to an XBRL taxonomy is called extension. You don't have to use this extension feature, but it's available if you need it.
Note
XBRL doesn't itself define an XBRL taxonomy, which serves as the dictionary everyone must use; rather, different areas of business (called domains) usually create them. If a domain has created a dictionary that you like or that you're mandated to use, you can use that dictionary. You may even use multiple dictionaries. Or, if you don't find a dictionary that fits your needs, you can create your own dictionary. You can even modify the dictionaries of others, if the system you're using allows for these types of modifications.
If, say, the accountant (CFO, bookkeeper, controller) of a company has added new concepts to the dictionary, the accountant simply creates his own new dictionary and links it to the existing accepted dictionaries. This ability to extend the dictionary for each report and fit those new terms into the existing dictionary is one of the unique aspects of XBRL. For example, if your organization is in a specialized industry such as airlines or shipping, your company can add its unique subcategories of properties, plants, and equipment that may not exist within a general list of such assets.
You may wonder, "Well, if everyone adds their own unique stuff, then how do you understand others companies unique concepts?" The answer to this question is threefold:
First, the concepts are defined in the extended dictionary provided so that you'll understand what the concepts are.
Second, the extended concepts are clearly highlighted by the extension itself. Humans need to be involved in this part of the process, and this is where they should be involved, focusing on the unique aspects of a company, not rekeying all the information.
Third, specialized industries and other groups will get together and agree on concepts specific to their industry or group. Over time, more and more concepts make their way to the public dictionaries and fewer and fewer extensions are needed. This continues to push human focus to the unique areas, allowing computers to help out with the agreed-upon, standardized areas of a business information exchange.
The dictionary is actually more than an alphabetical list of terms. The dictionary can also specify rules and relations between concepts, and you can even include additional information about a concept. As we describe in Chapter 17, this is why a dictionary may not be a dictionary at all, but rather something called a taxonomy. You can go even further and create what is called an ontology. (See Chapter 17 for an explanation of the differences between dictionaries, taxonomies, and ontologies.)
The dictionary with a hierarchy, which is commonly referred to as a taxonomy, is commonly presented as a tree structure within software applications, looking much like the outline of a book. This setup helps dictionary creators categorize concepts. Categories can have subcategories that show relationships between concepts. Concepts can have many different relations, and the relations can be of many different types. For example, the category "Current Assets" may contain subcategories, such as "Cash," "Receivables," "Inventories," and so on.
An XBRL taxonomy can specify rules. For example, the XBRL taxonomy can specify that "Current Assets" is equal to the sum of "Cash," "Receivables," "Inventory," and all the other concepts defined as a component of "Current Assets." Other types of rules it can specify are if-then type rules. For example, if "Property, Plant, and Equipment" existed within the report, you'd expect that related concepts that express the depreciation method, asset life, categories of assets, and other policies and disclosures would likewise be in the report (if the report is a financial statement). Specifying rules not only helps to verify that the report is correct, but it also helps in the process of creating the report. Literally, the XBRL taxonomy can help guide you through the process of creating the report. It also helps those who specify what information the report creator must provide (such as regulators) in the report and do so with clarity. This formal process enables a computer to understand the report and dictionary and helps minimize errors, omissions, and miscommunications. This formal process allows for both people and computers to better work with these reports and the processes used to create the reports.
When predefined XBRL taxonomies are used, the tags in the reports are consistent. If the tags in the reports are consistent (as opposed to every organization creating their own XBRL taxonomy), the report's consistent structure greatly assists users in the process of comparing the information, if they choose to do so. Fundamentally, users can spend more time on the actual analysis and less time figuring out what data is comparable.
In XBRL, the creator of a report, such as a financial statement, tags it. These tags add structure, which helps computers understand and do things with the information within the report. The report includes all the numbers and narrative text, individual text, and any other values within the report. The creator uses an XBRL taxonomy, either one they pick or one they're required to use by a third party.
If someone using the report (or XBRL instance) doesn't like the way the creator organized the report, the user of the report can simply reorganize the report by creating his own relations and perhaps even his own concepts within an extension XBRL taxonomy. For example, you can compute EBITDA (Earnings Before Interest, Taxes, Depreciation, and Amortization) in many different ways. Analysts, or even creators of the reports, can combine concepts that add up to totally new concepts the user may choose to create. Or, analysts can move numbers, policies, and detailed disclosures together to help with their analysis. Hiding information is a thing of the past. This ability to reorganize a report is achieved by using the structure provided by the tags.
In other words, if all companies in a given industry use the same XBRL taxonomy for creating their reports, these reports are basically a little database of reported information that anyone can easily use to perform comparisons or do other types of analysis. Users have more time available for doing the analysis because they don't need to spend as much time rekeying or mapping information. The tag structure provided by the report creator makes this time savings possible.
Further, the tags also provide efficiencies for the report creators. Report creators use those same tags to allow computers to check the report to ensure that everything adds up, the correct information is included, and so on. The XBRL taxonomy sets the verification rules, which are also available to the report users. These verification rules enable the automation of the information exchange process.
All these things working together — the tags, the dictionaries, the rules, the contexts, and so on — enable the automated exchange of business information across business systems. This arrangement sounds complex, and it is. Add to this complexity the flexibility that you have to add concepts and change relationships, and it becomes even more complex. The needs of business information exchange are why businesses use software to simplify the process.
You can create XBRL instances and XBRL taxonomies by hand or even by using rather simple macros. You can use an XML parser (application designed to work with XML documents) to read and create XBRL information. After all, XBRL is just XML.
Sometimes you may want to do all this creating by hand, but generally you won't. Enter a special piece of software called an XBRL processor. This handy tool understands the logical and the physical models of XBRL and how all the pieces fit together, and they can help you make sure that everything is correct, including the rules that make sure that the values in the XBRL instance (report) follow the rules specified in the XBRL taxonomy (dictionary).
Tip
And guess what? You can find many open source XBRL processors, free XBRL processors, and commercial XBRL processors. (Chapter 14 points you to these and other handy software.)
Computers can read (meaning import or export information) XBRL instances and XBRL taxonomies easily because all that they need to do so is contained in those files. If a human needs to read them, no problem: Apply a style sheet (information that helps a computer understand how to present the information for humans to read), use an XBRL viewer-type application, or simply import the information into your favorite brand of spreadsheet. You're not locked into any specific application or even any specific style sheet. Have it your way! The same computer-readable dataset makes the information flexible. And any viewer makes the entire dictionary available to you so that you can understand all the concepts, relations, rules, and so on from which the information in the report follows.
Tip
Many organizations can, and do, simply use Microsoft Excel spreadsheets to create their reports, cobbling together information from various business systems into some sort of business report. Others use specialized report writer software. Currently, these last-mile processes of financial reporting or other business reporting tend to be highly manual in most organizations. These processes will eventually leverage XBRL to streamline business report creation. XBRL will also make reusing reported information significantly easier.
One of the early adopters of XBRL was the U.S. Federal Deposit Insurance Corporation (FDIC), which is a member of the U.S. Federal Financial Institutions Examination Council (FFIEC). The FDIC took the time to collect and communicate information about its implementation of XBRL to help others understand any benefits that existed. (This information is available on the Web at http://xbrl.org/us/us/ffiec%20White%20Paper%2031Jan06.pdf.)
As an example of the benefits XBRL can provide, here is a summary of the advantages of using XBRL that the FDIC found:
Decreased total cost of ownership: The FDIC reduced the total cost of ownership of their system from $65 million to $39 million, a savings of $26 million.
Greater timeliness of information: The FDIC reduced the time it took to make information available from 45 days to 2 days. The FDIC achieved this time reduction by validating information as part of submission, using XBRL's ability to express business rules; providing those rules to software vendors so that those creating submissions could validate their own information; verifying information; and only letting valid information be accepted by the system.
Higher quality of information: Contributing to the greater timeliness of information was the reduction of mathematical errors from 18,000 to 0 in the very first filing period XBRL was used. The FDIC reduced errors by, again, expressing the rules, making those rules available during creation of the information, and then not allowing information that violated the rules to come into the system. This higher quality of information also reduced the number of analysts needed to detect and correct mathematical errors by 33 percent because the analysts did not have to call banks and ask them to correct this type of error in their submissions. There are other types of errors than mathematical errors, so you still need analysts.
Greater reusability of information: The FDIC makes the information it collects for banks available to the other five members of the FFIEC and to the public. Before XBRL, the information was converted to different formats for the different systems of the other members, and the information was made available in a format that was simple but not very usable to the general public. Today, XBRL is the format that everyone, including the FDIC and other FFIEC members, uses, and it's accessible to the general public. Anyone can obtain a standard, off-the-shelf XBRL viewer application and use the information, or computer applications can read the data feeds to reuse the information.
Greater flexibility of information collection: Prior to using XBRL, the FDIC rarely dropped irrelevant information that it was collecting or adjusted the system for new information collected. When adjustments were made, it was a laborious and painful process to not only update the FDIC systems, but also to adjust the software vendor applications. The FDIC used various formats, including Microsoft Excel, Microsoft Word, PDF, and HTML, to communicate changes in information. When XBRL was implemented, changing the system became a breeze for the FDIC. The FDIC could communicate all changes in one format: XBRL. Software vendors could automate the process of reading the changes and change their software applications to support filing financial institutions. Because changing the collected information was so easy, the FDIC could adjust the information their systems collected more often, adjusting as frequently as their regulatory needs demanded.
Although the preceding benefits are specifically for the FDIC's implementation of XBRL, you can see that the types of benefits they discovered are quite general and relate to literally every system used to collect, manage, analyze, and share business information. Although some benefits may have more value for some systems than for others, we think that you can look at what the FDIC achieved and project from it what you may be able to achieve.
Chapter 10 helps you understand ways XBRL can improve your organization's effectiveness and efficiency and how to communicate that to your boss.
By looking at other XBRL users and what they're using it for, you can get an idea of how you can use XBRL:
Wacoal is a company that has 36 subsidiaries operating in 23 countries, with 32 different proprietary business applications running on different platforms such as mainframes, microcomputers, UNIX, and PCs. Wacoal wanted to integrate all these business systems. It didn't really matter what format Wacoal used to transfer the data; it just had to have one. Rather than create its own format, Wacoal used XBRL as the format.
CEBS (Committee of European Banking Supervisors) is a group of the central banks in Europe that regulates financial institutions. The approximately 27 members collect solvency and liquidity information for the financial institutions they must monitor, and they use a standard information set called BASIL II, which is used globally. CEBS picked XBRL as the exchange medium for this standard data set so that the different regulators in the different countries could both collect information from the financial institutions they regulate and also exchange information between the 27 different countries, which would be harder if each country used a different format. CEBS's second option was to build and maintain its own standard for exchanging this information. Rather than create its own standard, CEBS leveraged XBRL.
The governments of the Netherlands, Australia, Singapore, and New Zealand think big! These governments have already implemented or are in the process of implementing what they're calling SBR (Standard Business Reporting) throughout their entire governments! The goal of these efforts is to reduce the reporting burden on those who interact with the government, making the process better, faster, and cheaper for all parties involved. The governments made processes easier by both harmonizing the information between government agencies who use the information (that is, making it so that businesses don't have to report the same information multiple times to multiple different agencies), automating the exchange process by making the process electronic, and improving government outcomes (for example, harmonizing the definitions of the terms different agencies use). Projections by these governments predict that SBR will reduce company compliance costs by 25 percent annually — or more than $1 billion in combined savings per year!
Note
If one regulator mandates XBRL, thousands, hundreds of thousands, or, in some cases, even millions of businesses will be required to use XBRL. In today's world, businesses commonly deal with more than one government agency and many times with government agencies in more than one country. XBRL may become the common language for communicating to government agencies and other regulators. Having that infrastructure allows businesses to experiment with XBRL and realize how useful it is, allowing them to use the same infrastructure for exchanging business information internally and with their business partners.
Chapter 9 provides more examples of how others are making use of XBRL to get you thinking about how you might be able to use it.
No standard is perfect, and XBRL is no exception to this rule. If you do choose to make use of XBRL (and you likely will), you should realize the following:
XML is a syntax; XBRL expresses semantics. XBRL goes further than many XML languages in providing the ability to express semantics or meaning. Understanding this difference is critical to understanding XBRL. (Chapter 2 covers this concept in more detail.) Just realize that comparing XML and XBRL isn't a good comparison.
XBRL is about creating information structured for meaning. Currently, many business reports are unstructured, so reusing the information within the report in an automated fashion is impossible. It doesn't have to be that way. Providing information in a format structured for meaning has advantages. Chapter 21 explains the differences between unstructured information, information structured for presentation, and information structured for meaning. Understanding these differences is critical to understanding XBRL.
XBRL is a general-purpose specification. Being general purpose, it has to serve many masters. No one system making use of XBRL will use 100 percent of its features. Rather, users will pick and choose the parts they need, ignoring the parts they don't need.
XBRL has no standard logical model. As a result, you need to follow the physical model of XBRL, which leads to complexity, or create your own logical model, which makes working with XBRL much easier. However, if done incorrectly, this can lead to interoperability issues. You can solve this situation by creating a proper logical model and making use of a well articulated application profile, which is a constrained subset of the full general-purpose XBRL specification and specifies your logical model. (Chapter 12 discusses application profiles and logical models.)
Specific proprietary solutions are commonly better than standards; standards provide leverage. Proprietary solutions to a specific problem are commonly better than standards because that is how businesses differentiate themselves — by creating a good solution to a very specific problem. But the thing about proprietary solutions is that they can be expensive, and they lead to the minimum amount of interoperability, which doesn't provide what you really need — a standardized way to describe, exchange, and analyze business information.
XBRL taxonomies are data models. Many people understand the benefits of a well-designed database schema and the ramifications of a poorly designed database schema. A database schema is a data model. An XBRL taxonomy may express a data model and can, and many times should, be treated as such. Just as you can have good and bad data models, you can have good XBRL taxonomies and not-so-good XBRL taxonomies. A bad XBRL taxonomy model leads to poor interoperability. Poor interoperability leads to people needing to be involved in information exchanges. When you consider your XBRL taxonomy data model design, you need to consider the extensions others will be creating. All these issues are best dealt with by using an information modeling layer, which can help you create good data models and thus good XBRL taxonomies. (Chapters 12 and 17 discuss information models.)
XBRL taxonomies can have different architectures. XBRL is a general-purpose specification. You can choose from several ways to model your XBRL taxonomies, which dictate what your XBRL instances will look like and how they act. Many times, different architectures aren't as compatible as you might hope. This incompatibility may result in interoperability issues between different XBRL taxonomies, which is important to realize because, in all likelihood, your organization will be dealing with many different XBRL taxonomies. For example, you can report to different regulators, which use different XBRL taxonomies. Further, you may choose to make use of XBRL internally within your organization. Managing the interoperability of your internal business systems and various XBRL taxonomies architected in different ways can be a challenge. One way to deal with these realities is to create an abstraction layer between your internal implementation of XBRL and other implementations of XBRL, which helps minimize the impact of the whims of others on your important internal business systems. (Chapter 12 discusses how to maintain control by using an abstraction layer.)
XBRL is not a complete solution. XBRL is a technology that provides significant leverage, and you can use it within a system. You can string together all the pieces you need, or you can adopt an architecture, an application profile, and an information model created by others. What you can't do is simply pick up XBRL, plug it in, and expect all your problems to be solved.
An island of XBRL isn't an effective goal. Creating an island of XBRL within an organization doesn't serve any real purpose. All that approach does is create additional work and additional cost with no true marginal benefit to the system as a whole.
At first glance, you may not have considered the preceding aspects, the realities, of working with XBRL. But eventually, you'll run up against these issues.
Chapter 2 helps you become well grounded in the realities of working with XBRL. Considering these realities as you figure out how to apply XBRL within your organization can help you minimize false starts, point out dead-end paths, and otherwise learn from the missteps of others so that you don't make the same mistakes.