In This Chapter
Taking a look at the key role XBRL taxonomies play Knowing what to look for in an XBRL taxonomy Examining XBRL taxonomies created by others Identifying the characteristics of a good taxonomy
In this chapter, we cover additional important details of an XBRL taxonomy.
In this chapter, we cover additional important details of an XBRL taxonomy.
We also look at important big-picture considerations. We explain how an XBRL taxonomy is more than a dictionary. We walk you through approaches to looking at an XBRL taxonomy and what to look for in a taxonomy. We point you to sample and example XBRL taxonomies, as well as production taxonomies, that help you understand XBRL taxonomies better. We also highlight the characteristics of a good XBRL taxonomy.
Consolidating Your Knowledge
An XBRL taxonomy is a body of knowledge for some business domain expressed in a standardized electronic format. The XBRL taxonomy contains the experience, insights, rules, conventions, and other knowledge of professionals who operate within that domain. This knowledge is in a form that both humans and computer software applications can read. Because computers can read this domain knowledge, you can make computers do things they’ve never been able to do thanks to these standardized bodies of domain knowledge that exist in a global standard format that a computer can now understand.
None of these things that computers can do for you with XBRL are magic. What looks like magic is a result of good and proper use of a technology for what it was intended to do. However, if you don’t understand these technological tools or how to use them, you can end up with a dissatisfying outcome.
Fundamentally, XBRL taxonomies are data models, and you should treat them as such. Just as you can have good and bad database schemas (which are also data models), you can have good and bad XBRL taxonomies. XBRL taxonomies impact XBRL instances. You can’t create a good XBRL instance from a bad XBRL taxonomy.
One challenging aspect of using XBRL is what you’re asking XBRL to do for you. Getting two different computerized business systems to effectively communicate with each other, exchanging business information between them, is difficult, even for technical people. Today, millions of people use millions of computers all connected by one network, the Web. The challenges can’t be understated, and the fact that it works so well is utterly astonishing. We salute the technical people who pulled it together.
XBRL’s goal is to allow businesspeople to exchange information in an automated process: Think of this process as an information-supply chain, without involving a technical person. Why no technical person? Well, technical people can do this information exchange stuff with one hand tied behind their back already; they do it every day. But not everyone has technical wizards at their beck and call, and involving a programmer or the IT department makes the process longer and more expensive.
The personal computer and one of its killer applications, the electronic spreadsheet, has been a blessing for business users. But not all IT departments view spreadsheets as a blessing because of the issues they cause (see Chapter 6). But what if business users can get the flexibility they want, and IT departments can also get the control they need in order to keep everything working like a Swiss watch? Properly used, that is what XBRL can provide.
The XBRL taxonomy is the key to achieving this balance of flexibility and control. The key to using XBRL to create a truly effective automated exchange of business information within an information-supply chain is to build an appropriate XBRL taxonomy. XBRL taxonomies are essentially models of the information being communicated, and those models are similar to database schemas. To create a well-articulated XBRL taxonomy information model, business users need to learn about modeling business information. To aid business users in this process, technical people need to understand what business users consider important so that they can build the tools business users need to achieve their goals. Business users shouldn’t need to rely on technical experts to create their information models. Self-sufficient business users are the only way to achieve a true automated business-user-to-business-user exchange of business information.
Distinguishing Between Important Aspects of XBRL Taxonomies
XBRL has some sharp edges, and, if you’re not careful, you can cut yourself. Understanding certain characteristics of XBRL and of the business system in which you’ll use your XBRL taxonomy helps you figure out how to engineer your XBRL taxonomy. Not all business systems that make use of XBRL taxonomies are the same, nor are the XBRL taxonomies themselves. This section helps you make the distinction between these important aspects that influence how your XBRL taxonomy works so that you can create the correct XBRL taxonomy for your system.
An XBRL taxonomy can be more than a dictionary
An XBRL taxonomy is somewhat like a dictionary. This simple analogy is helpful to people during their introduction to XBRL. But actually, a taxonomy can be much more than a dictionary. It can be more like what is called an ontology, or it may fall somewhere in between a dictionary and an ontology. A taxonomy is a body of knowledge for some business domain, so the more information you can provide within an XBRL taxonomy, the more powerful it is, and the more you can do with it.
Most people are familiar with the term dictionary and less familiar with the terms taxonomy and ontology. All these terms are types of classification systems that have different characteristics. The following list helps you understand the important differences between XBRL taxonomies.
Dictionary: A dictionary is basically a list of words and definitions arranged in alphabetical order so that you can find the word you’re looking for. A dictionary doesn’t have a hierarchy. It’s simply a flat list of words. Some XBRL taxonomies can be just that — lists of concepts from some domain and nothing more.
Classification: A classification is a grouping of something based on some criteria. Grouping things together usually serves some purpose. Think of your music collection. Each song in your music collection is a lot like a dictionary. The ability to group your songs by album, genre, or the number of stars you’ve assigned is helpful in finding the music you want. Classifications tend to be lists that you can sort, but they tend to not have a hierarchy. You can look at a classification as a somewhat shallow hierarchy.
Taxonomy: Taxonomies are classifications that have rich, potentially deep hierarchies. Think of your music collection again. A play list that you create is an example of a simple taxonomy. Your play list can have multiple levels, you can search, sort, and filter within those levels, and the levels are usually related in some way — for example, music you may want to listen to if you’re making dinner with your significant other, or the music you might listen to if you’re working out. A taxonomy is a rich classification system, but you can also think of it as a simple ontology. A taxonomy’s hierarchy tends to be less formal and more implicit than explicit, but it also incorporates the characteristics of a dictionary and a classification system.
Ontology: An ontology is a set of well-defined concepts that tends to be more formal and explicit in describing a specific domain. Ontologies are generally defined using class and subclass relations similar to, say, classes and subclasses in object-oriented programming or for, say, members of the animal kingdom. Classes and subclasses have defined properties and relations. An ontology’s goal is to provide a formal, referenceable set of concepts that you can use in communications within a domain. So, an ontology is also expressed as a hierarchy, but the hierarchy is more explicit and much richer in meaning than a taxonomy.
XBRL taxonomies fall anywhere in the spectrum described in the previous list. You can find reasons to create dictionaries and reasons to create ontologies. The majority of XBRL taxonomies that you see today are, well, basically like taxonomies as we describe them in this list. They’re classification systems, they do have a hierarchy, but the hierarchy generally isn’t expressed richly enough for them to be considered an ontology. The concepts in today’s XBRL taxonomies do have properties, but they’re somewhat limited. This limited use of XBRL’s capabilities is due to the rush to get taxonomies created; software limitations; limited experience with XBRL, and therefore limited understanding by many of how to use XBRL’s power to express metadata; lack of understanding of the value of such metadata; and other such factors. More of XBRL’s capabilities will be utilized in the future.
In the future, many XBRL taxonomies will be much more like ontologies, providing a robust, rich set of useful metadata for business domains that you can leverage in many ways. Not all taxonomies need to be ontologies. Two candidates for significant additional metadata are the US GAAP and IFRS XBRL taxonomies.
The XBRL taxonomy is the entire DTS
You shouldn’t look at XBRL taxonomies in isolation but instead consider the entire DTS. There really is no difference between what some people call a “base XBRL taxonomy” and an “extension XBRL taxonomy” (see Chapter 4) In fact, a taxonomy can be both a base and an extension at the same time.
The idea that something is a base or an extension is really relative to something else. For example, consider your parents. Your parents are also someone’s children.
Good XBRL taxonomies are modular components, like Legos, which you piece together to maximize comparability, minimize maintenance, and otherwise meet the needs of taxonomy users. All the components of the set that makes up the DTS work together. If the chain of XBRL taxonomies has one weak link, you can end up with a flawed information model.
Not all business systems that make use of XBRL taxonomies will allow extension of the DTS; those making use of XBRL within some system or solution make this business decision. You can’t state within a taxonomy, “Hey, it’s okay to extend me.” The system or solution in which the taxonomy operates determines whether extension is allowed. However, even if a taxonomy works within a system or solution that doesn’t allow extension, you can actually extend it. Systems that don’t allow extension must communicate the message that extensions aren’t allowed in one way or another, usually within the documentation of that specific business system.
XBRL taxonomies categories
For the sake of convenience, when we look into XBRL taxonomies in this chapter, we put them into four categories:
Financial-reporting taxonomies: You use financial-reporting taxonomies for general financial reporting. Public or listed companies generally use these taxonomies to report their financial statements, such as their balance sheet, income statement, and related disclosures. Examples are the US GAAP, IFRS, and EDINET XBRL taxonomies. These taxonomies tend to be general use, but a regulator can also use them. Many different user groups use these taxonomies for many things.
Regulatory taxonomies: Regulatory taxonomies are specific to a regulator. The regulator, those who file with the regulator, and those who make use of information provided by the regulator are the ones who typically use these taxonomies.
XBRL Global Ledger taxonomies: XBRL Global Ledger taxonomies are in a class by themselves. This taxonomy provides a canonical approach to exchanging business information between business systems that deal with accounting type business information. (Chapter 16 discusses this taxonomy.)
All other taxonomies: This category covers all other taxonomies not defined in one of the prior categories.
Systems that use XBRL taxonomies
Closed systems: Closed systems have strong boundaries. The participants within the system are usually known and can generally communicate easily and effectively with one another. Most regulators have closed systems; in fact, most systems are closed systems. An example of a closed system is the U.S. FDIC. The FDIC collects a specifically defined information set from a specific and known set of constituents: financial institutions regulated by the FDIC. All filers with the FDIC have their own identifying number, and they know what they have to submit and when. The FDIC and the institutions they regulate share a direct channel of communication.
Open systems: Open systems have boundaries that are more vague than closed systems. Generally, you don’t even know exactly who participates within the system. An example of an open system is e-mail. Another example is if all publicly traded or listed companies took it upon themselves to put their XBRL financial information on their Web sites. Investors and financial analysts use financial information directly from the reporting entities’ Web sites. You have no clear channel of communication because you can’t tell who the system participants are.
Making a closed system work is easier than using an open system because closed systems are easier to control, but you can make both types work. Both need rules to govern how the system operates. For example, rules need to clarify where the physical files are located that contain business information, how you find them, how users are notified of new business information, any constraints on XBRL taxonomy extension, and so on. XBRL doesn’t provide all these rules out of the box because XBRL isn’t a complete system; it’s a tool.
Business systems exist to meet some business need. Business systems have certain specific characteristics. Understanding these characteristics can help you choose the type of XBRL taxonomy that you’ll need for your business system, maximizing the utility that XBRL can provide to that system. Building an XBRL taxonomy inappropriately for a given system is like putting a square peg in a round hole. Matching the XBRL taxonomy characteristics and the business system is critical.
Closed and open systems
One way of looking at a business system is to look at how open or how closed that system is in terms of participation within that system. These definitions help you understand what we mean:
Static and dynamic system information models
System information models are typically either static or dynamic:
Static: Allows no extension to XBRL taxonomies. Basically, you can think of the information collected as a form. The form may change between periods, but someone submitting information to the system can’t modify the information model, extending that model with additional information. A good example is tax forms. Tax forms change annually, but the corporations completing their tax filing for a particular year aren’t allowed to change the form they’re filing.
Dynamic: Allows extension to XBRL taxonomies. The information collected is fluid, and those submitting information can change it. A good example is financial reporting as practiced in the United States. Filers to the U.S. SEC can extend the US GAAP taxonomy.
Static systems are easy to make work with XBRL. In fact, in many cases, you may not even need all of XBRLs features for such systems. XBRL can still provide value if the information requires business rules to validate the information or other key features that XBRL provides.
Dynamic systems are exponentially more challenging to implement than static systems. But dynamic systems are exactly the business use case XBRL was designed to handle. It’s your responsibility to constrain the system. If you want system users to be able to extend the XBRL taxonomy only in certain places, you need to define those extension points, communicate that information to system users, and enforce those extension rules within your system. XBRL doesn’t do these tasks out of the box.
Simple and complex system transactions
We want to be clear about what we mean by transaction. We aren’t talking about things like the carefully orchestrated messages passed between, say, two Web service interfaces.
A business information exchange is fundamentally a transaction, a message. Most people don’t think of things such as business reports in this way, but in reality, that’s really what they are. XBRL taxonomies define the information models of these transactions if XBRL is used within a system. The size and complexity of a business-information-exchange transaction, and therefore the XBRL taxonomy, can vary:
Simple transaction: A transaction can be simple in that the information set is small and static, meaning that the user submitting information can’t change it. For example, consider a simple transaction that has, say, ten data points that are set up, users can’t change them, and the same information is collected year after year. This scenario is a simple transaction.
Complex transaction: Think of a complex transaction as a larger set of information, maybe hundreds of data points, that is exchanged. The information submitter has the ability to change the information set, which may fluctuate from one data collection period to another.
Many times, XBRL is overkill for simple transactions. You may have reasons to use XBRL, but you may also have good reasons to avoid the potentially heavy infrastructure load that XBRL brings to bear in order to solve simple business-information-exchange use cases. One use case where XBRL can help with simple transactions is when you have a high volume of different sets of simple transactions, and you need business users to add simple transactions in the future.
XBRL excels at handling complex transactions, particularly if the systems are dynamic, allowing for user adjustments to the information model or for changes to the information model over time.
Further, many types of transactions, either simple or complex, have information models that need to be communicated with a low or even zero tolerance for error. XBRL brings a business-rules engine that provides an ability to express robust meaning far beyond the capabilities of XML to validate only syntax. If you need a high degree of semantic precision, XBRL taxonomies can, and should, contain the expression of these business semantics to rigorously enforce the true nature of the information model, eliminating all chances of miscommunications, misunderstandings, and errors.
High or low level of information reuse
You can categorize business information and the systems that manage that information in terms of the level of information reuse as follows:
Low level of information reuse: You can use information in only one form. This level may be because one information point is highly dependent on another information point, and using the information separately would make no sense.
High level of information reuse: Alternatively, you can use information in a wide variety of forms and presentation formats.
Many times, the facts contained within an XBRL instance don’t depend on other items for interpreting their meaning. Information that is critical to interpreting the facts is organized in such a manner that that information is always available to the fact value. For example, consider the concepts Net Income or Number of Employees for a particular company, for a particular period of time, and for a specific scenario, such as actual or budgeted, and also consider how many times an organization may use those types of concepts in all the information it communicates.
A properly constructed XBRL taxonomy can make reusing such information child’s play, whereas an improperly constructed XBRL taxonomy can inadvertently add the same challenging characteristics, such as the XML content model, that XBRL worked so hard to allow you to remove from your information model’s architecture.
Another way to think about information reuse is the term that is commonly used to describe XBRL: interactive data. How an XBRL taxonomy is created can increase or decrease this potential for interactivity. If you need the interactivity, you need to understand how to create your XBRL taxonomy to maximize the possibility of information reuse.
XBRL taxonomies don’t understand each other
Just because two different sets of domain knowledge are expressed as XBRL taxonomies doesn’t mean that the two XBRL taxonomies will work together or otherwise understand each other. Each XBRL taxonomy is literally a different information model or schema. You can map one XBRL taxonomy to another XBRL taxonomy, and you may definitely have reasons for doing so. But you need to make two different XBRL taxonomies work together; XBRL contains no special magic glue.
Managing Your XBRL Taxonomy
You can implement XBRL using different approaches and techniques (see Chapter 12). Employing the following practical techniques contribute to the creation of a high-quality XBRL taxonomy:
Application profile Information model Logical model
The only way to get your software to work correctly is to test it. A conformance suite is a set of positive and negative tests that help you prove that everything is working as it needs to. Conformance suites can enforce an application profile, an information model, and a logical model. It automates much of the testing that is impossible to manually perform. A conformance suite attempts to cover the entire spectrum of possibilities; it’s disciplined and formal. Individual and unorganized testing may leave gaps that let errors creep into your business systems.
Looking at XBRL Taxonomies
XBRL taxonomies are XML files, and you don’t want to read the contents of the taxonomy in that form unless, of course, you’re a computer. Even technical people have a hard time understanding the concepts, relations, and resources in a XBRL taxonomy by reading taxonomy schemas and linkbases, relying on the angle brackets to interpret the information the taxonomy expresses. Even with a technical tool that reads XML but doesn’t understand XBRL, reading an XBRL taxonomy can be challenging for small taxonomies and impossible for larger taxonomies.
On the other hand, the angle brackets within the technically oriented taxonomy schemas and linkbases express the true meaning of the XBRL taxonomy. That meaning doesn’t come through to a reader of, say, a printout of an XBRL taxonomy. So, what is the best approach to understanding the information expressed within an XBRL taxonomy? Good question! The short answer is that there is no one best way for looking at an XBRL taxonomy to understand what it means. There are good ways to achieve specific types of understanding.
The physical taxonomy files
One option to looking at an XBRL taxonomy is to look at the physical files that make up the taxonomy (see Figure 17-1). You can find this listing of the physical files at http://xbrl.iasb.org/taxonomy/20 0 9-04-01.
Figure 17-1:
Looking at anXBRL taxonomy’s physical files.
Figure 17-1 shows the top-level directory of the IFRS taxonomy set of physical files. You can see the files, open the files, and look at the angle brackets to your heart’s desire. But who would want to look at the files? Well, software developers need to in order to understand the taxonomy components from which the user of a software application may select. (For example, the software developers who developed this next way to look at an XBRL taxonomy had to look at the taxonomy’s physical files.)
Taxonomy viewer
Figure 17-2:
Looking at anXBRL taxonomy using a taxonomy viewing application.
The viewer application may not be the official files, but it’s a rendering of the official files, which is the next best thing. The value of using an XBRL taxonomy viewer is that the taxonomy is interactive. You can change views and show different types of information, and you can even search and filter taxonomy components, getting the precise view you may desire.
Taxonomy printouts
Another approach to looking at an XBRL taxonomy is to look at a printout of the taxonomy. Figure 17-3 shows a paper-based printout of an XBRL taxonomy. Applications can generate printouts, or you can use several approaches to creating PDF taxonomy printouts. Printouts can be easy to read and useful, and you can generate them in a wide variety of layouts.
Take the set of files from Figure 17-1, feed it to a software application that understands XBRL taxonomies, such as an XBRL taxonomy viewer, and you get what you see in Figure 17-2 and at http://tinyurl.com/8b3kz4.
Notice what happens when you place the URL into your Web browser address bar. Not only does it load the XBRL taxonomy, but it also takes you to a specific concept in the taxonomy, within a specific type of network, and within a specific network of that type. Literally, you can link one application to another application using a URL.
Printouts do have a number of downsides. For example, trying to print the entire US GAAP taxonomy yields thousands of pages of paper! In this age of green-friendly thinking, you may not want to kill all those trees. Trying to read all the detailed nuances of the taxonomy can be challenging because many may not appear on the printout simply because they won’t fit on the page. Along these same lines, these paper and electronic paper type printouts aren’t interactive, and you can’t reconfigure the view as you can in software applications. Searching and filtering can also be tough for this reason. All that said, paper and PDF renderings are useful in certain situations.
Figure 17-3:
Looking at an XBRL taxonomy by using a printout.
Alternative rendering formats
A popular format that is somewhere between a software application and paper is taking a look at XBRL taxonomy information within a Microsoft Excel spreadsheet. Figure 17-4 shows an example of such a rendering of an XBRL taxonomy.
Everyone knows how popular spreadsheets like Excel are for pretty much everything. Figure 17-4 shows some of what you can do to customize an XBRL taxonomy printout using Excel macros. Also, you can use the spreadsheet application’s searching and filtering features to get exactly the view of the XBRL taxonomy that you desire. Basically, the only limits you have are your abilities to program and to come up with creative ways to make the information more readable for your specific needs. Using macros to satisfy your specific needs is possible because computer applications can read the XBRL and pretty much do whatever you want, unconstrained by some specific fixed format.
Taking this approach to reading an XBRL taxonomy has one fairly big downside: the possibility of mistakes. You have to carefully read the XBRL and put all the pieces together correctly. Using an XBRL processor makes this task much easier.
Figure 17-4:
Looking at an XBRL taxonomy
information within a Microsoft Excel spreadsheet.
Other useful alternative options for formatting include generating ways to read taxonomies using WPF/XAML (Microsoft’s Windows Presentation Foundation) or Adobe’s FLEX.
Make friends with a programmer if you have a good idea of how you want to see your XBRL taxonomy. Many of these types of alternative renderings are surprisingly easy to create with only a little programming knowledge.
Taxonomy official documentation
The physical taxonomy files don’t contain enough information to help you completely understand all that you need to know in order to use an XBRL taxonomy. Information that an XBRL taxonomy can’t express is generally contained in documentation provided with the taxonomy. Official documentation and other guidance are provided for most taxonomies (see Figure 17-5). This official documentation can be helpful in getting started with an XBRL taxonomy. On the other hand, this type of guidance can also be about as useful as most software application’s user manuals.
As an example of official documentation, you can find the official guidance for the US GAAP XBRL taxonomy at http://xbrl.us/taxonomies/Pages/ US-GAAP2 00 9.aspx in Figure 17-5. All sorts of things, in terms of both technical and user documentation, are available at this site.
Taxonomy user guidance
These days, many XBRL taxonomies create guidance for how to actually use a taxonomy. The US GAAP taxonomy created what it calls a preparer’s guide
(http://xbrl.us/Documents/PreparersGuide.pdf).
Figure 17-5:
The official Web page of the US GAAP taxonomy.
The IFRS XBRL taxonomy’s official documentation (www.iasb.org/XBRL/ IFRS+Taxonomy/Support+materials.htm) is a good example of the extent some taxonomies are going to. The IFRS is literally providing a topic.
For SEC filers, the EDGAR filer manual has user guidance at http://xbrl. us/Documents/PreparersGuide.pdf. See Chapter 6 of that EDGAR filer manual for XBRL guidance provided by the SEC.
Third-party taxonomy guidance
Third parties provide guidance for XBRL taxonomies in many forms. Search the Web by using phrases such as “XBRL taxonomy best practices,” “modeling business information using XBRL,” and “engineering XBRL taxonomies.”
What to Look for in an XBRL Taxonomy
The previous section covers the approaches to looking at an XBRL taxonomy. But what exactly are you looking for? What you’re looking for is typically determined by what you want to do with the taxonomy. Some people may want to create an XBRL instance. Others may want to understand an XBRL instance created by someone else. Others may need to create an extension taxonomy or provide additional metadata of some kind. Those are just a few of the reasons. All use cases for understanding a taxonomy are typically covered within the use case of creating an XBRL instance.
We take that perspective and explain the key things you should be looking for. We use the US GAAP taxonomy to provide examples:
Find the right piece(s) to build your DTS when you have alternatives.
When you have alternatives or options, you need to find the correct pieces of the XBRL taxonomy to use. Many taxonomies cover all alternatives, providing options for each. You’d never use all the alternative options provided by the XBRL taxonomy. You do need to find the alternative applicable or preferred by you. Each alternative adds to the volume of the taxonomy that you have to deal with. You typically won’t use all possible alternatives, but you might like to know what alternatives exist. For example, the US GAAP taxonomy provides information relating to the different industries that might report using that taxonomy. About five main industries exist within the taxonomy; you’ll typically use only one. Even within one industry, you have options. For example, a company creating a financial statement would create a cash flow statement using either the direct or indirect method, never both at the same time. So, to piece taxonomy together, you need to grab the correct components and the correct alternatives. You need to glean this information about taxonomy components and alternatives from taxonomy documentation and from the taxonomy itself.
Find the appropriate concepts. Many taxonomies have thousands of concepts — for example, the US GAAP taxonomy has about 15,000 concepts. You need to sort, search, filter, and use other means to locate the exact concept you want to work with. Finding the right concept isn’t just reading a label, and, in fact, you may not know exactly what the label may be. Information in the taxonomy documentation and references for each concept helps you find concepts and understand whether you have the correct concept or whether some other concept is more appropriate. Looking at concepts relative to other concepts is helpful in finding the ones you’re looking for.
One good place to find the appropriate concepts is in the presentation relations. Another good area is the calculation relations, if you know you have some computation that a concept may participate in. Looking at the business rules of the taxonomy is yet another way to be sure that you have the correct concept in the taxonomy. Also look at the concept’s attributes, such as its data type, balance, or period type.
Find the appropriate networks. Concepts exist within networks. For example, Inventory Policy is most likely within the Accounting Policies network within the network of presentation relations. Other cases, such as the following situations, aren’t so simple or straightforward:
Alternative presentation and calculation relations that are consistent with one another, such as the alternative income statements provided by the US GAAP taxonomy, can exist.
Alternative presentation and calculation relations that aren’t consistent due to the need or choice to express these relations in separate networks can exist, as is the case in many disclosures within the US GAAP taxonomy. This inconsistency can occur because of how XBRL works or how a taxonomy creator decided to model their taxonomy.
You may need to explore to find what you’re looking for. Business users of a taxonomy shouldn’t find this search difficult because they generally have a thorough understanding of the data they’re working with. Making your way around a taxonomy to find it is another story. Be persistent and use the features available within a taxonomy-viewer application.
Find the appropriate relations and resources. Just because you found a concept doesn’t necessarily mean that you’ve found all the relations in which that concept participates that you may be interested in. However, finding the right concept is generally the first step to finding the relations. But it works the other way around, too. Relations can help you find concepts. If you know the general area within a taxonomy where something may exist, look for a concept that can also exist in that relation. Using this approach can help you find the concept you’re looking for, even if you’re unclear what that concept is called. However, if you’ve located the concept, you can generally find relations or resources information easily if you’re using taxonomy viewer software.
Determining whether something you need is missing. You may not find what you’re looking for for two reasons. It does exist, but you just can’t find it, or it doesn’t exist in the taxonomy at all. One of the gravest errors that you can make when using a taxonomy that allows extensions is to recreate an existing concept. This mistake causes all sorts of problems when you create your XBRL instance and for those analyzing that XBRL instance. You need to perform an exhaustive search of the XBRL taxonomy for something before you stop looking. Be patient, be persistent, and use good software applications to help you in your search.
XBRL Taxonomy Samples and Examples
A good place to start when working with XBRL taxonomies isn’t the complex gargantuan XBRL taxonomies that you may have to use because some evil regulator mandated that you use it. Instead, start small and then, as your understanding grows, you’ll gain insight on how to understand these significantly larger and more complex XBRL taxonomies.
When you explore taxonomies, you must explore XBRL instances at the same time. The whole point of creating a taxonomy is to properly express the information you need to express. How can you possibly know whether you built your taxonomy correctly if you’re not looking at the resulting XBRL instance that’s created by a user of your XBRL taxonomy? You need to look at XBRL taxonomies and XBRL instances together as you learn about the information models that exist in the taxonomies.
The following good samples and examples may help you understand XBRL taxonomies and the related XBRL instances. You can apply this knowledge to understanding larger taxonomies that you’ll likely be working with:
USFRTF Patterns Guide: Prior to the creation of the US GAAP taxonomy, the team creating that taxonomy put together a number of small XBRL taxonomies and XBRL instances to help identify what might exist within the US GAAP taxonomy and how these pieces might be modeled. You can see the XBRL taxonomies and XBRL instances at www.xbrl.org/ us/USFRTF/USFRTF-PatternsFiles-PWD-2007-04-17.zip, along with an explanatory document at www.xbrl.org/us/USFRTF/ USFRTF-PatternsGuide-PWD-20 07-04-17.doc.
XBRLS Business Use Cases: This set of small XBRL taxonomies and XBRL instances focuses on specific business use cases and uses a documented application profile, information modeling layer, logical model, and automated tests to construct the XBRL taxonomies. See the examples at http://xbrl.squarespace.com/storage/xbrls/ XBRLS-BusinessUseCases-2008-04-18.zip and the documentation at http://xbrl.squarespace.com/storage/xbrls/XBRLS-BusinessUseCases-20 0 8-04-25.pdf.
XBRLS comprehensive example: The two previous examples are great, but if you look at them in isolation, you can miss many of the nuances of a larger XBRL taxonomy. The different pieces of the taxonomy must work together correctly. The comprehensive example basically takes each one of the XBRLS business use case examples and puts them together into one XBRL taxonomy. It then provides one XBRL instance that shows everything working together. Go to www.xbrlsite.com/ examples/comprehensiveexample/2008-04-18 to see this example and related documentation.
To avoid having to type these long links. This takes you to a landing page where you can click the link you need.
Exploring Real Production Financial Reporting Taxonomies
We want to explain a little about the details of a few XBRL taxonomies to give you a sense what these look like and what they do. We chose the category of financial-reporting taxonomies because they’re generally well-constructed XBRL taxonomies, business people generally understand financial reporting, and because financial-reporting XBRL taxonomies are publically available. We provide brief overviews of the US GAAP, IFRS, and EDINET taxonomies.
The US GAAP XBRL taxonomy
The US GAAP taxonomy expresses financial-reporting concepts that public companies use to create financial reports typically filed with the U.S. SEC and shareholders. The financial information filed with the SEC has gone into the EDGAR system in the past; XBRL filings will go into the SEC’s new Next-Generation EDGAR system (see Chapter 13).
However, because US GAAP relates to all companies in the United States, you can use the taxonomy for any type of financial reporting under US GAAP (for example, private companies can provide financial information to financial institutions that give them commercial loans). The taxonomy covers FASB financial-reporting standards, the U.S. SEC, industry-specific reporting practices, common practices, and other reporting practices that are collectively referred to as US GAAP.
The on-ramp for the US GAAP taxonomy is this Web page on the XBRL US Web site: http://xbrl.us/taxonomies/Pages/US-GAAP2009.aspx. On this page, you can find links to other information that helps to describe the XBRL taxonomy and how to use it. You can find the actual XBRL taxonomy files at http://taxonomies.xbrl.us/us-gaap/2009/index.html.
A better way of looking at the UGT is to use a taxonomy-viewer application, which you can find at http://viewer.xbrl.us/yeti/resources/ yeti-gwt/Yeti.jsp. When you load this URL into the address bar of your browser, you see the Open Taxonomy dialog box, shown in Figure 17-6.
Figure 17-6:
Looking at the US GAAP taxonomy.
The US GAAP taxonomy is organized to be modular; it has about 500 different files. However, you’d never use all these pieces. The UGT is broken down into the following industries or activities that drive how companies report or tend to report:
Commercial and Industrial Companies (CI) Banking and Savings Institutions (BASI) Brokers and Dealers in Securities (BD) Insurance (INS)
Real Estate (RE)
Each industry or activity is organized in the form of an entry point. An entry point is the set of taxonomy pieces that you’d use if you were, say, preparing a report for a specific company in a specific industry or activity. For example, an airline wouldn’t need the insurance or real-estate entry point; it would need only the commercial and industrial companies’ entry point, because this entry point will lead to the set of concepts and relations that are directly relevant to airlines.
There’s a lot to know about the taxonomy and how to use it. Here are helpful pieces of information and tips for starting your journey of understanding the US GAAP taxonomy:
Five entry points pull together information by the financial-reporting industry. Probably 90 percent of you will make use of the CI entry point of the US GAAP taxonomy. If you’re in one of the other specialized industries, you’d use one of those entry points.
The spot that holds the most information about the taxonomy is this Web URL hosted by XBRL US: http://xbrl.us/taxonomies/Pages/ US-GAAP2009.aspx.
The easiest and best publically available view of the taxonomy that we’re aware of is at http://viewer.xbrl.us/yeti/resources/ yeti-gwt/Yeti.jsp.
XBRL US offers classes to help those preparing financial statements to use the taxonomy. For information about these classes, contact XBRL US
(http://xbrl.us/Pages/feedback.aspx).
The taxonomy expresses approximately 15,000 concepts and 20,000 relations and has a total of about 140 networks.
Each industry entry point has between 50 and 75 presentation networks that organize the concepts into logical groupings. These networks fall into two categories: statements and disclosures.
‘ The taxonomy doesn’t express all computations, so be careful. You may need to add computations using XBRL Formula in order to ensure the integrity of your information.
XBRL US publishes a preparer’s guide that helps explain how to use the taxonomy: http://xbrl.us/Documents/PreparersGuide.pdf.
The EDGAR Filer Manual has information about how to submit XBRL information to the SEC at http://sec.gov/info/edgar/edgarfm-vol2-v11.pdf.
The IFRS XBRL taxonomy
IFRS is being adopted around the globe for financial reporting. As you might expect, IFRS has an XBRL taxonomy. The International Accounting Standards Committee Foundation (IASCF) is in charge of XBRL activities relating to IFRS, including creating and maintaining the IFRS XBRL taxonomy. Unlike US GAAP, IFRS doesn’t cover specific industry disclosures. Because the IFRSs don’t cover specific industry common practice disclosures, the IFRS taxonomy likewise doesn’t cover these industry common practices. Hence, you can regard the IFRS taxonomy as a general-purpose reporting taxonomy with concepts representing disclosure requirements specifically addressed within IFRS.
Here’s a summary of the IFRS XBRL taxonomy’s most helpful pieces:
The primary location of information about the taxonomy is www.iasb. org/XBRL/IFRS+Taxonomy/IFRS+Taxonomy+20 0 9.htm.
The best human-readable version of the taxonomy that we can find is at
www.abra-search.com/ABRASearch.html?locale=en&taxonomy=
ifrs_2009-04-01 .
The actual physical taxonomy files are available at http://xbrl. iasb.org/taxonomy/2 0 0 9-04-01.
A human-readable version of the taxonomy is at www.iasb.org/XBRL/ IFRS+Taxonomy/IFRS+Taxonomy+2 00 9.htm.
The taxonomy expresses approximately 2,700 concepts, about 4,000 relations, and approximately 110 presentation networks.
The taxonomy really has only one entry point. These networks have three categories: statements, notes, and dimensional information.
The IFRS taxonomy is available in multiple languages (about 11 languages, meaning 11 XBRL label resources). See www.iasb.org/
Translations/Available+translations.htm.
The IFRS Taxonomy Module Manager at www.xbrl-ifrs.org/ITMM helps you build user specific entry points into the IFRS taxonomy.
An IFRS XBRL taxonomy user guide is available at www.iasb.org/ XBRL/IFRS+Taxonomy/Support+materials.htm.
The EDINET XBRL taxonomy
You can find the taxonomy in both Japanese and English at www.fsa. go.jp/search/200903 09/editaxonomy200903 09.zip.
The summary information of the taxonomy is available at www.fsa.
go.jp/search/200903 09/tsummary_en200903 09.zip.
A human-readable version of the taxonomy appears at www.fsa.
go.jp/search/20 0 9 03 0 9/alist2 0 09 03 09.xls.
The taxonomy expresses approximately 4,800 concepts.
The taxonomy, in its current form, covers only the primary financial statements, but notes of financial statements and other information will be covered in the near future.
The taxonomy is broken down into the 24 industries or activities that have regulatory industry-specific accounting rules or reporting forms.
Although the EDINET Web site (http://info.edinet-fsa.go.jp) is in Japanese, you can click the XBRL link at the bottom of the page to go to https://info.edinet-fsa.go.jp/E01EW/BLMainController. jsp, where you can find recently-issued XBRL data for more than 5,000 public companies and 3,000 investment funds.
International Taxonomy Architecture Effort (ITA)
The financial-reporting community is leading the way with what it’s trying to achieve with XBRL. The three major XBRL taxonomies that exist are the
US GAAP, the IFRS, and the EDINET XBRL taxonomies. However, all three taxonomies were developed independently. As such, the architectures of the XBRL taxonomies are different.
The Japan Financial Services Agency (JFSA) created and maintains the EDINET taxonomy that expresses financial reporting concepts under Japanese GAAP. Japanese public companies typically use the taxonomy to create financial reports that are filed with the JFSA and made publically available within their EDINET system, which is similar to the SEC EDGAR and Next-Generation EDGAR systems. Also, the companies use the taxonomy to create financial reports that are filed with the Tokyo Stock Exchange and the National Tax Agency of Japan. The latest version of the taxonomy is the EDINET Taxonomy 2009.
Here are the EDINET XBRL taxonomy’s most helpful pieces of information:
In the early days of XBRL, some forward thinkers in the XBRL community were pushing for one XBRL taxonomy for financial reporting that everyone around the world would use. Theoretically, this unified taxonomy made a lot of sense. From a practical perspective, it didn’t. At that point, not many countries had adopted IFRS. Furthermore, no one really agreed on how to create an XBRL taxonomy. Those issues, combined with many other reasons, means that today we have basically three XBRL taxonomies for financial reporting. These three different XBRL taxonomies with three different architectures exists in part because all three of these sets of financial reporting standards exist and are in use today.
Much learning about how to best build XBRL taxonomies has taken place since those early days of XBRL. The International Taxonomy Architecture (ITA) is a joint effort to create a common architecture for financial reporting XBRL taxonomies. Members include the U.S. SEC (US GAAP taxonomy), IASCF (IFRS taxonomy), JFSA (EDINET taxonomy), and the European Commission. The IASCF began this process in October 2007. You can find the ITA comparison (Comparison Framework for EDINET, IFRS, and US GAAP XBRL Taxonomies) at www.xbrl.org/TCF-PWD-2 0 0 9-03-31.html.
Theoretically, the possibility exists for the creation of one set of financial reporting standards that would be used globally (IFRS) and one means of expressing that information in an electronic format (XBRL), which could result in an unprecedented ability to compare financial information from around the world. Whether the financial-reporting community has the resolve to pull off this feat is yet to be seen, but it’s trying.
Even if the goal of one XBRL taxonomy that all companies would use for financial reporting never happens, you can discover things from this project:
Different XBRL users can implement XBRL in different ways. That’s why this group even has to go through the process of creating the ITA. The current three different architectures won’t necessarily work together. For XBRL taxonomies to work together, they have to be made to do so — just being in XBRL is not enough.
Even if the financial-reporting supply chain can’t agree on one set of financial-reporting standards to use globally and even if there isn’t a complete agreement of an XBRL architecture, the ability to create comparable financial information is still a possibility thanks to mapping! Mapping one set of financial information to another is a little more complicated than a simple mapping; you’d actually need to reconcile one set of standards to another, somewhat like you can reconcile your topic numbers to your tax numbers. But it’s possible. Topic and tax numbers are reconciled all the time. XBRL does make this goal much easier.
Finally, this group is spending a lot of time and effort trying to agree on a good architecture for financial reporting. Understanding what that architecture is can provide clues as to what architecture you may want to use when working with XBRL.
Looking at Other XBRL Taxonomies
The best way to understand XBRL taxonomies is to look at lots of them. Figure 17-7 shows an XBRL taxonomy viewer (see www.abra-search.com/ ABRASearch.html?locale=en&taxonomy=p_all) that lets you look at many different XBRL taxonomies all in one spot. The XBRL taxonomy viewer shown in Figure 17-7 has about 100 different XBRL taxonomies you can explore to get ideas on how to build XBRL taxonomies, should you need to do so.
Figure 17-7:
Looking at other XBRL taxonomies.
Identifying a Good XBRL Taxonomy
An XBRL taxonomy is a data model. Like any other data model, there are good data models and not-so-good data models. We want to summarize the characteristics of what generally makes an XBRL taxonomy work well. These days, the best results are generally arrived at by having good balanced collaboration between the domain experts and the technical experts responsible for creating the XBRL taxonomy. Many of these characteristics are applicable to all taxonomies; other characteristics are dependent upon the characteristics of the business systems in which the XBRL taxonomy will be used. Here are some of the characteristics of a good taxonomy:
It models data. A good data model, well, models data. Many creators of XBRL taxonomies focus too much on how concepts and relations look in the taxonomy (the presentation) rather than how well they work. Both are important. Further, the best way to be sure that your taxonomy works is not to look at its presentation, but instead to test the data model within an XBRL instances to be sure that they can be correctly created.
It’s modular. Don’t force users to use what they don’t need. Make it easy for them to use what they need but not what they don’t need or don’t want. One part of achieving this goal is to make the taxonomy modular. Create lots of modules so that taxonomy users can easily ignore what they don’t need.
It has lots of small networks. In the spirit of modularity, another thing that helps users take what they need and ditch the rest is to create many small networks rather than a few large networks. Basically, this approach is about making the networks modular so that users can grab what they need and ignore what they don’t. Many times, modularity involves physically separating networks using separate files; other times, it means that the same physical file can contain multiple but separate networks. The specific situation dictates the appropriate approach.
Lots of small pieces are better than a few big pieces because having the computer put pieces together is easier than requiring the computer to take things apart. If you use small networks, you can use the network to identify the piece you want to work with — that information (the network itself) exists within the XBRL taxonomy. But if you want to take one large network and break it into individual pieces, there is no place within the taxonomy to break up that one large network of relations. Maintenance can also be much easier on a small network. This strategy to use lots of small pieces is similar to why computer programs are typically made up of many smaller and reusable subroutines instead of one big program.
It contains no duplication. Good data models express things once. If the same thing is expressed more than once, the two pieces need to be kept synchronized, which can be a hassle. Think, small, modular pieces.
It’s consistent. An XBRL taxonomy’s structures should be consistent unless you have a specific reason. Usually, inconsistent modeling happens because you’re unaware of the inconsistency of your approach. If you’re not thinking about consistency, you can pretty much guarantee that you’re being inconsistent. An information-modeling layer can help you create a consistent XBRL taxonomy.
It uses consistent style. Just like style guides exist for writing manuscripts or essays, taxonomies should use some sort of style guide to keep, for example, labels consistently styled in regard to spelling, abbreviations, capitalization, and so on. A style guide is simply something that helps achieve this goal. One specific example of what a style guide can do is to help you spell words consistently (“Long Term” or “Long-Term” or “Long-term” or “Long term,” and so on). A good example is the US GAAP taxonomy style guide at www.xbrl.org/us/usfrtf/XBRL-StyleGuide-RECOMMENDATION-2007-03-08.doc. This style guide can give you a good understanding of what a style guide is and why it’s important.
It follows best practices. Things like the FRTA have lots of good practices that help create a high-quality XBRL taxonomy. FRTA is definitely a best practice for financial-reporting type taxonomies, but it’s even useful for nonfinancial-reporting taxonomies.
It includes documentation of the taxonomy. It’s impossible to explain all that is needed about how to use an XBRL taxonomy within the XBRL taxonomy itself. Enter good documentation. Further, writing the document forces you to put yourself in the users’ shoes and view the taxonomy from their perspective. Providing sample XBRL instances should be part of your taxonomy documentation.
It has clearly articulated extension guidelines. Extensions, if allowed, shouldn’t be able to break the taxonomies that they’re extending. The first rule of extensions is that they need to follow all the other rules on this list. An extension is just another taxonomy within the DTS. One of the tricky things about extensions is to decide when to create an entirely new network of relations and when to augment an existing network of relations for the changes you need to make. Properly balancing reuse and creation is both an art and a science that takes experience to get the right end result. Further, taxonomy documentation should provide explicit guidance as to how to use extensibility. Finally, sample XBRL instances provided with the XBRL taxonomy should include specific samples of how to use extensibility.
It expresses all computations. When you define concepts within your taxonomy, be sure to define all the computation-type relations that exist for those concepts. You can express many computations using XBRL calculations, but you can’t express many other types, so use XBRL Formula to provide business rules. Either way, articulate all computations within the taxonomy because not doing so simply invites computation errors.
It includes a maintenance plan. If the a taxonomy doesn’t have a maintenance plan, rest assured that its maintenance hasn’t been planned for. When you create a taxonomy, you’re responsible for maintaining that taxonomy, and you need a plan for maintaining it. The time to create that plan isn’t when you need to start maintaining it, but rather when you first create the taxonomy. You’ll make decisions differently after you think through the maintenance process. Part of the maintenance plan should be a versioning plan that includes how you’ll communicate taxonomy changes to its users.
It’s been proven to work correctly. Be sure that your taxonomy works as expected by proving to yourself that it works correctly. Test, test, and then test some more. The larger and more diverse the taxonomy users are, the more important thorough testing is, and the bigger the downside
of an unforeseen bug existing within your production taxonomy. Not proving to yourself that the taxonomy works is a recipe for problems. If you can’t prove that it works, you haven’t done enough testing. (Chapter 12 has information on testing taxonomies.)
It’s elegant. A good taxonomy looks elegant. If the taxonomy doesn’t look elegant, look deeper. There are usually reasons why. Start with this list to help you figure out why you don’t see what you expect to see.
