In This Chapter
Finding out about XBRL instances
Knowing what to look for in an XBRL instance
Examining the XBRL instances of others
Identifying the characteristics of a good XBRL instance
In this chapter, we drill into additional important details of the XBRL
In this chapter, we drill into additional important details of the XBRL instance. We also look at important big-picture considerations, consolidating your knowledge of XBRL instances. We explain the relationship between an XBRL instance and its XBRL taxonomies. We walk you through a thought experiment, which helps you see how XBRL instances work. We examine various approaches to looking at the business information contained within an XBRL instance. We point you to sample and example XBRL instances and their related XBRL taxonomies, which you can use to expand your understanding of them. We also point you to real production XBRL instances. We end this chapter by highlighting the characteristics of a good XBRL instance.
To avoid having to type the long links in this chapter, This takes you to a landing page where you can click the link you need.
Consolidating Your Knowledge of the XBRL Instance
XBRL taxonomies express a body of knowledge of a business domain in a standardized electronic format (see Chapter 17). Those XBRL taxonomies contain the insights, rules, conventions, and other insights and understandings of professionals that have expertise within a particular domain. These collections of professional expertise become the basis for expressing information within an XBRL instance, which you can think of as a new type of business report. XBRL instances are, however, really about the broader category of business information exchange, of which the business report is a part.
Although looking at XBRL instances as business reports helps turn something that is abstract and challenging to understand into something tangible and easier to understand, don’t let the term business report limit your perception of what XBRL instances are and do. After all, XBRL is about exchanging all sorts of business information, not just reports.
These new business reports are intended to provide characteristics that improve upon their legacy paper versions and the electronic versions, which are little more than digital paper. (Electronic spreadsheets have their good points but also disadvantages.)
One key characteristic of an XBRL instance is an ability to automate some business process. If a business process is automated — and not all business processes should be automated — then the conclusions reached by such an automated process should be no different than the conclusions reached by the previous manual process.
Another key characteristic of an XBRL instance is flexibility, often times called interactivity. XBRL separates the information from the presentation of the information allowing for increased flexibility when it comes to presenting business information.
You can think of an XBRL instance in many ways. Here’s a summary of the important things that an XBRL instance is:
Standard structured publishing format: An XBRL instance is a standard physical format for publishing business information. Some people like to think of it as a standard database of sorts because you can query the XBRL instance and extract information you need from it. Another way to look at it is as a standard publishing medium. The key word, though, is standard, which is the magic in the XBRL sauce.
Standard transfer protocol: You have to be able to physically get the information from the person who creates it to the person or persons who will be consuming the information. XBRL instances also perform this role. A transfer protocol is a physical means, a medium, for getting information from one point to another.
Enabler for standard query approach: Because the published format of XBRL instances is a standard, you can create a standard query approach and query across multiple XBRL instances. A standard query approach is critical because many consumers of XBRL instance information want to compare information from multiple XBRL instances.
Independently usable facts: An XBRL instance is also a bag of facts. Applications can effectively grab the values of facts within an XBRL instance and use those fact values. Users can use one fact, or they can use multiple facts because the facts exist in a form that enables one fact to be used independently without regard to other facts within the XBRL
instance. Sometimes, certain information makes no sense unless it’s used with other information, but where you can use information independently, XBRL provides the mechanism for doing so.
An often overlooked fact is that you can combine XBRL instances and use them together — for example, when comparing information, such as a five-year time series. Or, you may want to combine information for one period for several companies in a specific industry to do a comparison.
Distinguishing the Important Aspects of an XBRL Instance
XBRL taxonomies have a significant impact on how XBRL instances are created; after all, they do define the information model that an XBRL instance uses. But an XBRL instance also defines certain information. We make you aware of this flexibility in this section. We also look at several approaches to creating XBRL instances, as well as the categories of XBRL instances.
We then do something that helps you appreciate the subtleties of XBRL instances. We use one of Albert Einstein’s tools, a thought experiment, to help you understand a few important things about XBRL instances.
The relationship between the XBRL instance and the XBRL taxonomy
A question that people often ask when working with XBRL is, “What goes in the XBRL taxonomy, and what goes in the XBRL instance?” Although most of the time the answer to this question is clear, in some cases, it’s not quite so obvious. You have flexibility in determining the architecture of your XBRL taxonomy. Certain approaches to architecting your XBRL taxonomy can provide necessary functionality within your XBRL instance. However, that same approach can cause more problems than it solves if not architected correctly, or if the architecture is good but the required functionality was misinterpreted. We want you to be aware of this flexibility — it can help you, or it can cause you problems.
We can’t go into every detail of the question of where you should define what amounts to metadata, but we do want to provide you with a taste of what we’re talking about by providing examples:
Concepts: An XBRL taxonomy is typically the best place to define concepts. The creators of XBRL instances define concepts once in an XBRL taxonomy and then use them many times within their XBRL instances. For example, Sales may be a concept you define within an XBRL taxonomy. Comparability is maximized if a concept is defined within an XBRL taxonomy. However, there are approaches to defining concepts within an XBRL instance. This makes it so that you can add concepts without creating a taxonomy extension. However, a ramification of this approach is usually reduced comparability.
Periods: An XBRL instance is normally the best place to express period information. For example, consider the concept Sales. You can create the concept Sales2009 and Sales2010 in an XBRL taxonomy. But in subsequent years, you’d have to add concepts for future sales amounts, such as Sales2 011. Design of the XBRL instance allows for period information within a context to be associated with fact values. However, you can define period-specific concepts within an XBRL taxonomy.
Building a usable, maintainable, well-designed XBRL instance and XBRL taxonomy takes some thought and understanding of data modeling; it’s not something that you should do haphazardly. These rules always have exceptions. Good judgment, knowledge of data modeling, understanding how the components of XBRL work, and thorough testing can help you get to your desired result. You can only know the impact of all these decisions by seeing how XBRL instances created against your XBRL taxonomy actually function as a combined unit.
An XBRL taxonomy drives the XBRL instance. You never should look at an XBRL taxonomy and an XBRL instance separately. They’re an inseparable pair, each impacting the other. (Chapters 4 and 17 tell you a great deal about how to build an XBRL taxonomy.)
For example, the relations networks defined within an XBRL taxonomy serve somewhat as a filtering mechanism for pulling specific facts from an XBRL instance. You can have different types of filters: presentation, calculation, definition, or others you might create. Those creating XBRL instances can create and provide these networks that serve as filters, but those consuming the information in the XBRL instance can also create their own networks to serve as filters in the form of an XBRL taxonomy. Each relations network provides one view into the bag of fact values that an XBRL instance makes available, allowing you to focus on those specific facts. For example, a balance sheet presentation network allows for the identification of all facts that exist in that balance sheet. Working in conjunction with other information, such as the period portion of a context, you can render the XBRL instance information using the network filter and the period context information.
If you don’t like the XBRL taxonomies you get from an XBRL instance creator, create your own! Generally, people think that the creator of an XBRL instance creates or provides the only XBRL taxonomy that can be used with an XBRL instance. This isn’t the case. XBRL instance users can provide their own metadata for use in organizing an XBRL instances. For example, if you don’t like the organization of a certain network or if you don’t like the labels the creator of the XBRL instance provided, no problem. Create your own, add it to the DTS, and enjoy the interactivity of XBRL!
Approaches to creating XBRL instances
You can take many different approaches when creating an XBRL instance. We distill these approaches down to three general approaches:
‘ Generate from some system: Under this approach, you export information from within an existing business system to XBRL in some manner. Usually, you use a mapping to help convert information from the existing system to the desired XBRL instance. Many times, these systems store their data within a relational database.
‘ Map to existing document: Under this approach, you map information from an existing document (such as a spreadsheet or word-processing document) to XBRL and then use the document and mapping to generate an XBRL instance. An example is mapping the financial information from an existing word-processing document to generate an XBRL instance. (In Chapter 11, we call it the bolt-on approach.)
‘ Enter information into XBRL instance-creation tool: Under this approach, you enter information directly into an XBRL instance-creation tool, which then generates an XBRL instance. This approach is a lot like filling out a form; it’s just that the form output is a standard publishing format, XBRL.
Which approach you use to create an XBRL instance depends on your specific situation. Furthermore, you might use one approach in the short term and a different long-term approach. Software vendors, budgets for modifying existing systems, and other such constraints have an impact on the alternative you use. (Refer to Chapter 11 for additional information.)
Categorizing XBRL instances
As with XBRL taxonomies, for the sake of convenience and to help you get a sense for XBRL instances, we categorize XBRL instances into three groups:
Financial-reporting instances: This group includes financial statements created using XBRL. For example, an SEC filing falls into this category.
XBRL Global Ledger instances: These types of XBRL instances can provide information that you’d aggregate into financial-reporting-type XBRL instances. Or, you can see these types of XBRL instances as the detailed information you’d drill down into from a more summarized financial-reporting-type XBRL instance. The key point is the connection between the more summarized financial-reporting-type and the more detailed XBRL Global Ledger-type XBRL instances.
All other instances: This category basically represents everything else and crosses many different domains. We don’t go into this group in detail because it’s a bottomless pit, but examples include employee expense reports, tax returns, sales reports, sales commission calculations, many of the spreadsheets you create and exchange with others, CSV listings you create, and business-intelligence reports you use and want to share with others external to your organization. Like we said, it’s a bottomless pit of opportunity!
A thought experiment
Albert Einstein was famous for the thought experiments he used to explain complex situations using simple stories. We have a thought experiment for you. The purpose of the thought experiment is to help you better understand how XBRL instances actually work. The first thing the experiment shows you is the important pieces impacting the usability of XBRL instances. The second important aspect the thought experiment shows is that the way business users implement XBRL determines the results received from that XBRL-based information.
The ultimate goal you’re trying to achieve with XBRL is to automate some process. You many times reap significant benefits from realizing this goal. We’re not saying that all business processes are automatable or that all processes should be automated. What processes to automate and where to include humans is up to those creating business processes. Errors, inconsistencies, ambiguities, and other such factors sometimes keep processes that can and should be automated from being automated, requiring human intervention to execute the process. This is not because you want to involve humans; it’s because you have to involve humans due to errors, inconsistencies, ambiguities, and other factors.
Think of the Web. Imagine that every company in the world created quarterly and annual financial information and put that information in an XBRL instance on its Web site. Forget about whether you could get every company to make this information available or even if they should make it available.
(It’s a thought experiment, so just play along.) Imagine that you wanted to analyze all that information for some purpose — say, to find a good investment. Here are the challenges you’d run into:
‘ Finding the XBRL instances: You need to find those XBRL instances. How do you do that? You have two possibilities:
• Push means that in some way, perhaps via an RSS feed that pushes this information to you, you’re made aware of each of the XBRL instances.
• Pull, for example, is when you discover the XBRL instances via a search engine and then pull the information to where you can use it.
But somehow you need to discover the complete set of XBRL instances you need for your analysis. For our experiment, say that a search engine finds all the right XBRL instances, and only the right XBRL instances, and makes them available to you. So, you have all the information.
‘ Having comparable concepts and relations: You have all the XBRL instances, delivered somehow by your search engine. If each XBRL instance uses a different XBRL taxonomy, comparisons between XBRL instances are more challenging. You can still compare information by mapping each company’s XBRL taxonomy to an XBRL taxonomy you create as a master comparison taxonomy. You’d have to create this mapping for every XBRL instance in this case.
An alternative is that every company agrees to use the same XBRL taxonomy. Say they did that; in fact, say every company used the IFRS XBRL taxonomy for financial reporting. But now say that companies are allowed to extend the base IFRS XBRL taxonomy. Thus, in effect, now each company is using a unique XBRL taxonomy, and you’re back to having different concepts and relations again. However, for this experiment, say that extension isn’t allowed, so you have perfect comparability.
‘ Putting all the instances together: You have a complete set of XBRL instances, and you have only one XBRL taxonomy with no extensions allowed, so you have perfect comparability at the XBRL taxonomy level. You now put all the XBRL instances together into one massive, combined XBRL instance containing all information for all companies in the world. Easy enough: After all, XBRL’s purpose is to achieve this sort of result.
Resolving entity conflicts: You pull all the XBRL information together into one XBRL instance. Do you have conflicting contexts? Theoretically, no. Each company reports only its information, not the information of others. Each context should be of the reporting company; therefore, each company provides its own entity identifier within its context. Again, say that every company had one unique identifier, and that every company can be uniquely identified and identified only once (meaning no duplication). So, we can have no entity conflicts.
Dealing with period conflicts: What if companies had different fiscal year-ends? We all use the same calendar, right? Well, you may run into the situation where different companies use different fiscal year-ends, not ending on the same calendar date. A fiscal year is some financial period (say July 1 through June 30); it may not be a calendar year. But for this thought experiment, say that every company has the exact same fiscal year-end, which is December 31.
Handling unit conflicts: Different countries use different currencies; therefore all this information is reported in all sorts of different units, from U.S. dollars, to UK pounds, the euro, Japanese yen, or Chinese renminbi, or something else. But say that you can convert to some standard currency — say, the euro for this comparison. For the sake of this experiment, assume that this conversion was done in real time and accurately. As such, you have no unit conflicts.
Agreeing on standard metadata: For this perfect world thought experiment, say that you’ve standardized industry sector identifiers (identifying companies as being a bank, an airline, in retail, and so on), geographic areas (used to differentiate operations in Europe, Asia, and so on), standardized entity information for identifying parent companies as opposed to a subsidiary, and any other thing that can cause a comparability issue. Your metadata is perfect. As such, you can identify parent companies and which industry sector a company is in, you can differentiate between budgeted and actual information with XBRL instances, and so on. You use XBRL Dimensions to construct this dimensional information, which is totally standardized across all companies reporting information. (Remember, it’s a thought experiment. Einstein pretended he was riding on a light beam, for Pete’s sake!) So, all this metadata is standardized enabling comparability.
Coming up with an analysis interface: You have a huge set of information, all in XBRL, for all the companies in the world. All the companies are uniquely identified. All the companies use exactly the same XBRL taxonomy to report their information, and no extensions are allowed. Everyone uses the same fiscal period for reporting their information. All the numeric values use one standard currency. All parent companies are clearly identified, and all actual information is differentiated from any budgeted information. Basically, everything is perfect: You’ve achieved information nirvana. You have an easy-to-use business-user interface that’s even better than the popular Apple iPhone in terms of usability. It’s the perfect business-user application.
So what is your point, you ask? One point is that reality can be messy. Reality isn’t perfect. All the issues pointed out in the list do exist. Another point is that many things are possible technically but maybe not politically. Technically, you can do everything we mention as we walk through the issues to resolve each issue in some way with XBRL. In fact, that is typically quite easy. The harder part is actually doing it — for example, agreeing on a standard format like XBRL, standardizing how entities are uniquely identified, standardizing on industry sectors and geographic areas, and so on.
Some agreements are already being reached in the area of financial reporting. XBRL itself is a step in that direction. IFRS is another step. But financial reporting is only one business domain.
This experiment points out the major moving parts of working with XBRL instances. We use financial reporting only as an example in our thought experiment. Each different business domain will decide how to employ the technology of XBRL within their domain.
Looking at XBRL Instances
As with XBRL taxonomies, XBRL instances are XML files, and you don’t want to read them in that form unless you’re a computerized business system; in that case, XML will be your preferred format. Another thing to consider when making use of an XBRL instance is that you’ll definitely want to also be able to examine the XBRL taxonomies (the entire DTS) upon which the XBRL instance is based. Again, as with XBRL taxonomies, XML tools that read XML but don’t understand XBRL won’t satisfy your needs.
In this section, we list various approaches to making use of the information within an XBRL instance.
The physical XBRL instance files
One option for looking at an XBRL instance is to look at the physical XML files that make up the XBRL instance. Figure 18-1 shows the XBRL instance of the “Hello World” example (see Chapter 15), which you can find at http://
Figure 18-1 isn’t the only physical file needed to understand the XBRL instance. You can see the reference to the XBRL taxonomy HelloWorld.xsd. That taxonomy schema further references linkbases, and all these pieces of the DTS work together to help you use the XBRL instance information. In most cases, you need an XBRL processor to put all these pieces together for you. So, we’re only showing you one of many files that you’ll need.
Fundamentally, every approach to using XBRL instance information actually uses the XML files that express the XBRL information. Software applications read these files and reorganize this information in some way. To explain this concept better, in the next section, we wrap a software application around the
XML files and take a look at XBRL.
Figure 18-1:
Looking at the tags within a physical XBRL file.
Instance viewer
Figure 18-2 takes the exact same XBRL instance file shown in Figure 18-1, feeds it into a basic XBRL instance-viewer application (UBmatrix Taxonomy Designer), and renders the information that the XBRL instance contains. (See Chapter 14 for more info on instance viewers.)
The first thing you can see is what was meant by the term interactive data. If you notice the menu options, you can see that the application allows the user to reorder the XBRL instance facts into various orders. In Figure 18-2, we see them sorted first by entity, then by period, and then the actual fact. You can see other sort orders that the application offers.
In addition to the ability to reconfigure the fact values, XBRL viewer applications generally provide for the ability to validate XBRL instance information to be sure that the XBRL syntax is correct and that the information within the XBRL instance conforms to specified business rules. You can also include new ways of looking at the information by adding XBRL taxonomy pieces to what the XBRL instance viewer has so that you have more metadata to work with. For example, suppose that you read Chinese. If you find a set of label resources that someone has created expressing labels for concepts in Chinese, or if you create such a label resource, you simply add that label resource to the DTS, and the XBRL instance viewer can show you the information within the XBRL instance using the Chinese labels. XBRL instance-viewer applications know how to do this and many other things that are useful to users.
Figure 18-2:
Looking at an XBRL instance using an instance viewing application.
Rendering of XBRL instance information
What if you just wanted to look at the information within the XBRL instance on paper? No worries. Figure 18-3 shows what it would look like.
Figure 18-3:
An XBRL instance styled for human consumption using an XSLT style sheet that generates a PDF.
What you see in Figure 18-3 is the “Hello World” example with a rendering application applied to the XBRL instance: an XSLT style sheet.to see the style sheet we used.)
Figure 18-3 should look pretty familiar; it’s pretty much what you get today. We show you the XSLT as one approach to rendering XBRL. The approach is rather basic, and you do have to create those style sheets somehow. But many software applications walk you through the process of creating such renderings in several different output formats (see Chapter 14). Many software development tools, such as Windows Presentation Foundation, Adobe Flex, microformats, and AJAX widgets (see Chapter 7), can also help you render XBRL. The point is that because XBRL is interactive, you’re not locked into any one format. The sky is literally the limit!
XBRL instance creator
When you create XBRL, you want to view the information within the XBRL instance (and don’t forget the related XBRL taxonomies) as you create your XBRL instance. Figure 18-4 is the basic application for creating an XBRL instance.
Figure 18-4:
AnXBRL instance using an instance creator application.
Chapter 15 walks you through using the XBRL instance-creation application shown in Figure 18-4. You can also see where to download this application from that chapter. Our point is that XBRL instance-creation tools are also tools for looking at and using XBRL instance information and the related DTS that supports that instance.
Instance rendered with OLAP cube or pivot table
None of the previous approaches to viewing the XBRL instance information are particularly interactive, except for the XBRL instance-viewer application. One drawback of the nicely formatted information within a document, such as a word-processing document, is that changing the format becomes challenging. These applications basically lock information into one format for the user of the information, typically determined by the information preparer.
But you can use other options, such as business-intelligence (BI) software. BI applications make use of the multidimensional model and allow for reconfigurable views of business information. Another term for this is OLAP, or Microsoft Excel pivot tables. Figure 18-5 shows a simple Excel pivot table for the “Hello World” information set.
Figure 18-5:
An XBRL instance using a Microsoft Excel pivot table.
Although Figure 18-5 is a simple example, if you’ve ever played around with Excel pivot tables, you know how flexible, yet readable, they can be. OLAP cubes are similar to pivot tables, except they’re typically even more powerful and provide more formatting options.
If you haven’t yet read Chapter 16′s discussion of XBRL Dimensions and the multidimensional model, it’s worth doing so now.
Feeding XBRL instance information into an Excel pivot table or a BI application in order to make use of the information in the XBRL instance is easy. Applications simply take the XBRL formatted information and reformat the XBRL syntax into some syntax the BI application understands, the information is imported, and the BI application takes everything from that point using existing functionality. The more about XBRL the BI application understands, the less you have to do outside the actual BI application to make use of XBRL.
Software vendors are better understanding the connection between BI platforms and XBRL. As more BI applications support XBRL, the easier this process of using XBRL within these applications will become. But these BI applications do have limitations.
Interactive information hypercube viewer
Although BI software is quite a powerful rendering solution for lots of different types of business information, it does have two potentially limiting factors: OLAP tends to prefer numbers over textual information, and it likes to aggregate those numbers. The same is true with Excel pivot tables.
However, a lot of business information, such as the descriptions of accounting policies relating to those numbers, is textual in nature. Some of this textual information, such as financial-disclosure narratives, can be complex. Further, textual information isn’t aggregated, and other numeric information doesn’t need the aggregation abilities of OLAP cubes or pivot tables. Yet, the fact that OLAP cubes and Excel pivot tables not only expect to perform aggregation, but, in fact, are optimized to perform such aggregations can get in the way of what business users actually want to use the OLAP cubes for. You can find ways around these issues, but you may need a new approach to looking at OLAP cubes: Remove the OLAP part and keep everything else.
We’d like to introduce the notion of the (drum roll, please) interactive information hypercube. Now, no software vendor has put all these pieces together yet, but several software vendors (see Chapter 14) have implemented pieces, so we’re confident that something like the interactive information hypercube, which put all the correct pieces together, will one day exist. We believe that the interactive information hypercube will play a major role in business reporting in the future for three reasons:
A lot of information should be interactive. You simply can’t reconfigure information presented within a fixed document format. For information to be interactive, flexibility is needed, and hypercubes provide that flexibility.
Information is more than numbers and aggregation. OLAP cubes were built to handle numbers and aggregation of those numbers. They’re not sufficient for XBRL as they are today because they don’t support textual information and narratives, and they’re optimized to aggregate information.
Multidimensional is about flexibility. The multidimensional model is what would make the idea of an interactive information hypercube work. It provides the flexibility and the metadata that drives that flexibility. Business information is multidimensional.
Figure 18-6 shows an prototype of an interactive information cube. Figure 18-6 takes the earlier “Hello World” example and modifies it to use XBRL Dimensions (see Chapter 16) via the information model used by XBRLS, an application profile of XBRL (see Chapter 12). Then, using information model metadata, the contextual information from the XBRL instance, and other XBRL taxonomy information, an interactive information hypercube is generated. This human-readable rendering of the information contained within the XBRL instance is reconfigurable. The creators of the XBRLS application profile created the prototype in order to help determine what that information model of XBRLS needed to look like to obtain interactivity. For more information, see http://xbrl.squarespace.com/xbrls.
Figure 18-6:
Looking at an interactive information cube.
Knowing What to Look for in an XBRL Instance
The previous section covers approaches to looking at information contained within an XBRL instance. But what exactly are you looking for within an XBRL instance? What you’re looking for has a great deal to do with what you’ll be doing with the XBRL instance information. Some people may want to review an XBRL instance that they’ve just created. Others may want to look at an XBRL instance someone else created. Yet others may take several XBRL instances and analyze the information across multiple periods for one entity (a time series) or for a number of different entities (cross-entity comparison).
The processes you can use these instances in can be totally automated, or humans can be involved between different stages within a process. When working with these XBRL instances, you’ll need to consider the XBRL taxonomies upon which the XBRL instances are based. You may even want to reconfigure the XBRL instance information by modifying the XBRL taxonomy.
A business user should be able to use an XBRL instance and reach the same conclusions as someone using the same information expressed in some legacy reporting format, such as paper, HTML, or PDF. The information really hasn’t changed; only the efficiency, and perhaps the effectiveness, of how you can use that information are different. The information’s format really shouldn’t impact the information itself. Humans and computers should reach the same conclusions, whether information is being pumped through some automated process without human involvement enabled by XBRL or whether the process is implemented using humans at each step.
You can use computer software to automate the decision-making process, but the conclusions should be the same ones reached by their human counterparts using older, human-intensive processes. The efficiencies — and perhaps the effectiveness — of reaching the conclusions may have changed, but the actual conclusion shouldn’t change just because you’re using a new format.
So how do you achieve this objective? Here’s what you need to consider as you look within your XBRL instance, using your view of choice:
Appropriateness of XBRL taxonomy: The XBRL taxonomy, or rather the set of XBRL taxonomies in the DTS, should be appropriate for the needs of the XBRL instance user (see Chapter 17). But because the XBRL taxonomy plays such a crucial role in understanding the XBRL instance, you can see why its appropriateness is important.
Information integrity: Just like its legacy counterparts, information expressed within XBRL instances needs to add up correctly. If you can’t rely on the integrity of the information contained within an XBRL instance, you certainly can’t send it through some automated process.
Ability to find the information you want: The fundamental piece of an XBRL instance is the information the XBRL instance contains. That information is expressed as the values of facts, or fact values. Those facts are related to concepts within some XBRL taxonomy: contexts, units, and perhaps footnotes provided within the XBRL instance. You’ll want to find the fact values you need within the XBRL instance, so you need to be able to search, sort, filter, find, and otherwise discover the information within the XBRL instance. A key to this task is organization of the information that describes the fact from within the XBRL taxonomy. This XBRL taxonomy information includes the definition of a concept and helpful information, such as human-readable labels and other resources. For example, if you want to know about Sales, you have to find that concept and be sure that you’re working with the right concept, wading through potentially thousands of other concepts.
Relation of information to other information: Looking at individual fact values is sometimes okay, but generally, the fact values you’re working with are associated with other fact values you need to use. The order of these fact values makes a difference; they often flow to a set of business information. For example, a financial statement has a flow to it: balance sheet, income statement, cash flow statement, statement of changes in equity, policies, and disclosures. Understanding one piece of information outside this flow can be challenging or even impossible. Because flow is important, information is organized in the form of statements in the first place. Imagine trying to read a balance sheet that was an unorganized list of fact values. Information needs to be used with other related information.
Fact values within a context: Users of information contained within an XBRL instance need to understand the context of the fact values they’re making use of. The business user must be able to somehow understand and differentiate the contexts of XBRL instance information, whether by visual presentation or another method of understanding the context. For example, putting different periods into different columns, as today’s reports do, is one approach to working with different contexts.
Additional needs for numeric fact values: The units required for numeric type fact values are just another type of context information; users need to understand the units being used. Information needs to be scaled as the user desires. Scale relates to whether the numeric information is expressed in thousands, millions, or maybe billions. XBRL instances don’t have scale information. All information within an XBRL instance is expressed as their actual values. Scaling is likewise true of the polarity of the information. Polarity means whether the information needs to be added or subtracted relative to other information. Also, is that polarity expressed as a positive or negative in the human-readable rendering being used?
Information flow fits your needs: The flow of information contained within an XBRL instance is important in many cases. Consider a financial statement as an example. Perhaps the order of the different statements or disclosures is important, or maybe a human needs to read two separate paragraphs of textual information in a certain order.
Interactivity of the information: We talk about XBRL making information interactive, but are you getting the interactivity that you desire? XBRL taxonomies drive much of this interactivity. If the creators of the XBRL instance don’t provide what you need in terms of interactivity within their XBRL taxonomy, you may need to provide it.
XBRL Instance Samples and Examples
As with XBRL taxonomies, the complex gargantuan XBRL instances that are filed with regulators for some hard-to-comprehend domain aren’t the best place to start. Instead, start small and then use those first small steps to grow your well-grounded foundation. Then, when you get to the bigger XBRL instances, instead of feeling overwhelmed, you can apply this sound base of understanding to working with them. You can definitely apply the examples to these larger XBRL instances.
Just as when you explore XBRL taxonomies, you should explore the XBRL instance; the reverse is likewise true. When you’re looking at samples and examples, looking only at an XBRL instance is a mistake. The XBRL taxonomy is the information model for the XBRL instance: You definitely need to understand that model. (Chapter 17 points you to good samples and examples of XBRL taxonomies and related XBRL instances.)
If you look at one XBRL instance in isolation, you’ll miss a lot about what you’re trying to achieve with an XBRL instance. We point you to a unique additional sample — a small repository containing a number of XBRL instances. This repository example allows you to examine issues related to the use of multiple XBRL instances. This repository has five XBRL instances
all created using one taxonomy. Testing comparability across multiple XBRL instances is the reason for the creation of this example. This example also covers issues relating to locating XBRL instances so that you can use them together. You can get the XBRL taxonomies, XBRL instances, and documentation via the RSS feed located at http://xbrl.squarespace. com/storage/samplerepositorymini/rss-RepositoryMini.xml.
Exploring Real Production Financial-Reporting-Type XBRL Instances
The filings of public companies to the U.S. SEC are one good set of publically available XBRL instances. All these XBRL instances are publically available and free to use at www.sec.gov/idea/searchidea/webusers.htm. They do tend to be large, relatively complicated XBRL instances because of the use of sophisticated extensions, and the domain of public company financial reporting is complex and may not be familiar to everyone. However, these XBRL instances are a great resource for learning about XBRL. The more you put into understanding these XBRL instances, some of which are bound to be good and some likely not so good, the more you get out of the process.
For an RSS feed of the last 100 XBRL filings to the SEC’s Next-Generation EDGAR system, see http://www.sec.gov/Archives/edgar/usgaap. rss.xml .
By starting with the smaller examples and samples mentioned in the previous section, you can get more out of tackling these larger, more sophisticated, commercial-strength XBRL instances.
Chapter 15 shows you how to view an XBRL instance using the U.S. SEC XBRL instance-viewing application. You can find these instances at http:// viewerprototype1.com/viewer. Figure 18-7 shows you what one of these XBRL instances looks like when rendered by the SEC’s systems.
Figure 18-7 looks a lot like a typical financial statement you may have run across prior to XBRL. That’s the idea. But, because of the XBRL publishing format, you’re not locked into only one format.
Figure 18-7:
An XBRL instance for a financial report filed with the U.S. SEC.
Identifying a Good XBRL Instance
An XBRL instance is a standard publishing format and a transport medium. The ultimate judgment of whether an XBRL instance is good or not is whether it meets your needs. XBRL instances have general characteristics that contribute to them either working well or being less suited for typical tasks. This list helps you evaluate an XBRL instance’s characteristics, whether it’s the ones you create for others or the ones others have created that you’re using:
Communicates information: Fundamentally, XBRL instances communicate information. The baseline from which an XBRL instance will be judged is how that same information is being communicated today. A business user should reach the same conclusions using the business information, whether he’s using business reports of today or an XBRL instance. Using the information may be more efficient and the information may be more reconfigurable, but the same conclusions should result from the same information. If an XBRL instance doesn’t achieve this baseline benchmark, it’s not a good XBRL instance.
Enables comparison of information: XBRL’s role isn’t to determine what should be compared, but if information is deemed comparable and it still can’t be compared, the XBRL instance isn’t performing its function. The issues may be with the XBRL taxonomy, with the contextual information being articulated, or some other reason. No technical reason exists for something that can be comparable to not be comparable. Poor metadata management is generally the culprit if information isn’t comparable.
Possesses data integrity and accuracy: All the i’s should be dotted, and the t’s should be crossed. In accounting lingo, everything should tick and tie, as well as foot and cross cast. You achieve this goal by expressing every possible relationship or business rule within the metadata of the XBRL taxonomy that supports the XBRL instance. If an error exists, one of two things must be true: It’s either not possible to express a business rule, or it’s possible, but the XBRL taxonomy creator neglected to do so. Expressing these relations in an XBRL taxonomy is the first step. The second step is validating the XBRL instance against those rules. Computers, not humans, should be enforcing business rules when possible.
Operates like a good database: XBRL taxonomies are data models, and they need to be a good one (see Chapter 17). An XBRL instance is a lot like a database. A good XBRL instance is like a good database. Techniques for creating good databases are well understood from years of using relational databases, so we don’t go into them here: Those who know databases understand these techniques.
Carries no excess baggage: Unused components of an XBRL taxonomy shouldn’t be connected to an XBRL instance. Many times, XBRL taxonomies express more than one option for relations. The creator of the XBRL instance may use only one of those options. If so, don’t connect both networks to the XBRL instance. For example, in financial reporting, a company will either be a corporation or a partnership, not both. In the US GAAP taxonomy, presentation and calculation networks exist for both types of entities. Connecting both a corporation and a partnership’s networks to an XBRL instance makes little sense. Doing so adds no value to the user of the information, so don’t connect the excess networks. XBRL instances should connect only the networks that they use and need. Less is more. Don’t burden XBRL instance users with useless networks and resources.
Has taxonomies that work: One important key to a good XBRL instance is a good XBRL taxonomy. This advice includes extension taxonomies. One characteristics is that the XBRL taxonomy has been proven to work correctly, and the secret to proving that is proper testing. (Be sure to read about the characteristics of a good taxonomy in Chapter 17.)
Has extensions that are consistent with the base and that work: Any XBRL taxonomy that extends a base XBRL taxonomy should work in a manner consistent with that base XBRL taxonomy. You should look at all XBRL taxonomies from the point of view of the entire DTS, not individually in isolation. Again, testing is key to achieving this characteristic.
Is internally consistent: The XBRL instance should be internally consistent. For example, if in the entity identifier, the scheme in one place is http://www.sec.gov/cik, in another it’s http://sec.gov/cik, and in yet another it’s http://www.sec.gov/CIK, a computer application doesn’t understand that you’re talking about the same entity, even though you used the consistent identifier of, say, 123456, because the schemes don’t match. (Look carefully; each one is different.) Both the number and the scheme must match, not just the number. This mistake, although obvious, is a common one made in the U.S. SEC’s early XBRL voluntary filings. Our example is only one place where inconsistencies can exist; there are many other places.
Is consistent across instances: As with the previous characteristic, XBRL instances should also be consistent across instances. To use the same example as in the previous bullet, if a company used the entity identifier scheme of http://www.sec.gov/cik in one XBRL instance, http://sec.gov/ cik in another XBRL instance, and http://www.sec.gov/CIK in a third XBRL instance, even though they provide the identifier 123456 consistently in all three XBRL instances, a computer won’t recognize the combined identifier and scheme as the same entity. Remember, computers are really dumb!
Is interactive: If the XBRL instance you’re creating or using isn’t interactive, the reason is typically poor taxonomy design, poor instance creation, or a combination of both. Using the XBRL instance is where the rubber meets the road. If a user of the XBRL instance can successfully do what he needs without breaking things, the XBRL instance is good one. Usability is the ultimate test for an XBRL instance.
Automates processes: Take this one step further and consider multiple XBRL instances being used within some business information-supply chain; a good test of XBRL instances is the successful automation of some process that was previously a manual process. If you can achieve this automation, you can’t argue with that result: You’ve done everything right! But if you can’t effectively automate that manual process, you can’t characterize the XBRL instance as a good one.
Follows best practices: As with XBRL taxonomies, following best practices, such as FRIS, can help you create a high-quality XBRL instance. For example, FRIS prohibits the pathological case where duplicate fact values (same concept, same context, two values that can be either the same or different) exist within an XBRL instance. Good XBRL instances follow FRIS and other best practices.
Is elegant: As with XBRL taxonomies, good XBRL instances give you a sense of elegance when you use them. If they don’t seem elegant, look deeper — there’s usually a specific reason for it. This list is a good starting point for helping you figure out the reason the instance isn’t as elegant as you think it should be.
