Xbrl for dummies slide deck chapter 1 23 10 2009 long version

Editor's Notes

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