In This Chapter
Explaining key technical ideas to business readers Grasping how XBRL actually does what it does Seeing what XBRL will do
This chapter has one specific focus: explain key concepts in terms that you, a business reader, can relate to. You don’t need to understand these concepts to use XBRL. However, for those who are curious or who like to understand how things work, this chapter is for you.
Syntax Is Fairly Unimportant, Except Where It’s Critical
Syntax is fairly unimportant to business users, but of critical interest to technical people. The following examples of different syntax all say the same thing — namely, that John Doe’s salary is $145,000:
Plain text: John Doe’s salary is $145,000
CSV (comma separated values): John, Doe, 145000
HTML: <p>John Doe’s salary is $145,000</p>
XML: <my:salary name=”John Doe”>145000</my:salary>
RTF (Rich text format): {\rtlch\fcs1 John Doe’s salary is $145,000}
Syntax really doesn’t matter much to business people except for two important things:
The entire world is moving to one agreed-upon syntax for exchanging information, which is XML.
The syntax needs to be able to do what you need it to do. If it doesn’t work for what you need, what good is it?
XML provides a couple of critical things:
Multilingual support: A big problem with exchanging information is all the different characters that have to be expressed. XML was built in a manner to solve this problem.
The ability to express a hierarchy of information: Compare and contrast XML to CSV. CSV is basically a flat list of things; you can’t express a hierarchy. XML can express hierarchies; you can nest tags within other tags. Also, you can’t define the information you’re expressing (basically, the column headings) within the CSV information. XML solves this problem, too: It’s self-describing. (In other words, you can describe the metadata.)
Syntax is critical to certain technical things, which is why XML is so great: It solves those technical problems. Business people just use it and don’t have to worry about a lot of technical things getting in the way. You, as a business person, care way more about semantics than you do about syntax.
The Power of Semantics
Fundamentally, XBRL is a method of expressing semantics or meaning. XBRL expresses these semantics using the XML syntax because the XML syntax provides all the technical things that XBRL needs. Here are some examples of meaning that you can express within an XBRL taxonomy:
A concept’s name, such as Cash And Cash Equivalents
A concept’s definition, such as “An asset which is in the form of currency or can easily be converted to physical currency.”
Whether a concept is a debit or a credit
Whether a concept is “as of” (like Trade Receivables on a balance sheet) a point in time or “for a period” of time (like Net Income on an income statement)
A concept’s English label, such as Cash and cash equivalents
A concept “contributes” to the value of the sum of the related concept Assets Current
The concept Cash And Cash Equivalents on the balance sheet and cash flow statement
Meaning exists, whether computers and XBRL exist or not. However, because computers and XBRL exists, both humans and computers can understand the meaning expressed. This meaning, which business people deeply care about, is expressed in the form of metadata within an XBRL taxonomy.
Metadata Expresses Meaning
Metadata is data about data. Technical people love to debate about what is data versus metadata. Definitions of metadata abound; the term is overloaded with meaning. Semantics is a form of metadata. Metadata is information that describes or classifies other information. Just think of metadata as data, but at somewhat of a different level. Consider an invoice. Data on the invoice may include
The invoice number of I-10001 The invoice date of July 1, 2005 The invoice total amount of 9000
The metadata for the invoice may include
Every invoice must have an invoice number, an invoice date, a customer number, at least one line item, and a total amount.
The amount is expressed in U.S. dollars.
The sum of the line item amounts of the invoice must equal the total invoice amount.
All invoices that are 90 days past the invoice date are considered past due.
Business Rules Can Change Processes
Business rules are semantics. Business rules help keep information correct; they help manage what people commonly refer to as data integrity, or the relations between one piece of information and another piece of information. Maintaining data integrity is critical to exchanging information effectively.
Everyone has heard the saying, “Garbage in, garbage out.” Business rules keep garbage out of your business systems.
For example:
A business rule might express an assertion such as “Assets MUST equal total liabilities plus total equity.”
A business rule might express an If-Then type of condition, such as “If property, plant and equipment (PPE) exists on the balance sheet, then a PPE policy and a PPE disclosure MUST exist and they MUST contain. . . .”
A business rule may provide a definition, express calculations, articulate process-oriented information, articulate regulations, or be instructional in nature.
Business rules are extremely helpful to business people. You have many business rules, whether you refer to them by that term or not, because you have lots of information, and that information has many relationships. If information is structured, a computer can do many things to help a business person make sure that information is correct.
Unstructured Information Is Impossible for a Computer to Use Effectively
Consider the following example of unstructured information:
Although the information may be structured in terms of being, say, a paragraph within a financial statement, a computer application sees it as a blob of text. For example, a computer can’t automatically go in and grab the value for inventory as of December 31, 2005, from this blob of text.
Okay, a computer could grab that information. A programmer could hard-code something that goes to a specific set of characters and returns that value. But if that paragraph was created even slightly differently than the example, the application would break and not be able to automatically and, more importantly, accurately grab that specific value. If you had ten people create similar blobs of text, retrieving that specific piece of information would get even more complicated to. This solution obviously isn’t a good one.
To a degree, computers can grab specific useful information from within a larger chunk in a process referred to as parsing. If a computer can effectively parse information, other processes can effectively reuse that data. Computers use parsing because information is structured for presentation, not meaning, so a computer really has no idea what it’s looking at.
A great example of parsing is the process of screen scraping, a computer process that tries to glean information from a Web page, but it’s expensive, brittle, requires lots of programming, and isn’t reliable.
Why Information Shouldn’t Be Structured for Presentation
Have you ever used your Web browser to view the source of an HTML Web page? If you do, you’ll see tags such as <html>, <p>, <b>, or <bold>, and so on. HTML provides structure to Web pages. Consider this simple example:
You can see the following from this code:
The information is structured.
Some information is specifically identified.
Instructions on how to present that information is provided.
Using the tags provided, the information is presented in the form of a Web page:
Could a computer grab the inventory amount as of December 31, 2005, from this code? Sure, it could, and it could do it more easily than with the pure blob of text without the markup. But a human would have to figure out whether you need the first <bold> tag or the second one.
What if two different companies created their financial statements in this way? Could someone write a computer application to grab that information? Sure, but again, nothing helps make sure that both companies expressed the information consistently, so programmers must construct computer applications to deal with the inevitable inconsistencies. As such, companies can spend millions of dollars trying to parse information, but the parsing still isn’t really that accurate. Parsing is brittle, and the smallest changes can cause problems, so only companies with big budgets can even afford to try to grab the information.
Structuring information for presentation just doesn’t do the trick for getting at the information and enabling a computer to do something with the information in a reliable way.
HTML is a common way to structure information for presentation to a human in, say, a Web browser. But this information is less useful to a computer trying to do something else with that information, something other than that one presentation format that was provided. In fact, the information generally isn’t understandable to a computer in terms of meaning, only in terms of how that information should be presented.
Information Structured for Meaning Is More Useful
Computers can uniquely identify each piece of information expressed using a syntax structured for meaning. Consider the following example of structured information, which is structured at a finer level of detail and for meaning:
If you understand how an XML parser works, writing a rather simple query, such as getItem(”/Inventory/Value2005M), that “walks the tree of information” and reliably gets to the exact tag with the value $34,456 is easy
to do. The query is intuitive and works much like finding a file in a subdire tory on your computer.
Writing such a query is way easier than trying to ferret through the blob of text to find the value for 2005. Additionally, you can easily structure those pieces of information into the form of a paragraph of text, which looks exactly like what you see in a financial statement today:
Generally, taking information structured in terms of meaning and further articulating how it should be presented is easy. Taking information that is structured for presentation and further determining its meaning, however, is less likely, much more costly, and less reliable. So, are we saying that you have to deal with those funky tags when you work with a business report? Not if you don’t want to.
But using the text within the preceding two blobs is nearly impossible and prohibitively expensive, too, if everyone created their own “tags,” and one company called what we all refer to as Inventory different things, such as Inventory, Inventories, El Inventory, la Inventory, and so on. Sure, you can get information from your structured financial statement, but when you try to compare two different financial statements, you’d need to go through a mapping process and tell the computer that Inventory and Inventories and El Inventory and la Inventory all mean the same thing.
What if a global standard definition for Inventory were created? Well, there already is. That is what IFRS is all about: one global set of meaning. And what if we expressed that IFRS term in the form of a dictionary that a computer can understand? Well, that is exactly what XBRL is all about.
A Global Standard for Information Structured for Meaning
With a syntax, semantics, metadata, business rules, and information structured for meaning, we have everything we need to automate the exchange of business information. Everyone could, individually, create their own syntax, their own semantics, and their own business rules; express their own meaning; and, within one organization, do all the things XBRL offers, except for one thing:
easily exchange information with others who use a different syntax, different semantics, and different business rules. Further, software would be more expensive because different software applications would be created for each different syntax.
If everyone took this approach to making business information available, it could still work. You’d simply need to map one approach to each other approach where you wanted to use information created using different approaches together. Although more expensive, this task would be possible. You’d do this mapping for everyone you want to exchange information with, basically doing what people do today: Creating many one-to-one mappings between different approaches to structuring information to make it reusable.
However, a better way is to create a global standard approach and get everyone to use that approach, which is exactly what XBRL is.
You can see that that the following syntax really looks quite similar to the structured syntax from the previous section — it’s just that everyone agrees to use the same structured syntax.
