In This Chapter
Peering into XBRL’s future
Looking at specific ways to use XBRL
Envisioning XBRL killer applications
Considering what can go wrong (so you can avoid it)
Predicting changes to XBRL
M BRL has existed since 2000, yet it’s still a maturing global supply chain /\ standard for business information exchange. As we experiment with using XBRL to solve business-information-exchange problems, we learn more about XBRL and how to effectively use it. We know where we are today, but where will we be tomorrow? In this chapter, we go out on a limb and make predictions about the future of XBRL, its usage, and even potential problems. We even make predictions about probable changes to XBRL itself, based on ten years of experience from building and working with the XBRL standard.
The Future World with XBRL
Many technologies have come and gone. XBRL doesn’t look like it’ll be a passing fad; rather, it will probably be a key characteristic of the business systems of organizations large and small around the globe in the future. Eventually, XBRL will reach the point where it’s fulfilling its intended destiny, but it’s not there yet. XBRL solves problems that need to be solved in order to exchange business information. XBRL has been proven to work, and strong evidence, from its use by regulators and the organizations they regulate, indicates that XBRL will be with us for some time in some form or another. But what form? If XBRL isn’t around solving your business-information-exchange problems, something certainly will be. You need relief from the information overload that you’re experiencing now.
Islands of yet another information format will serve little purpose and not take you beyond where you are today. Today, businesses can exchange business information with, or without, XBRL. However, XBRL does have its advantages. Yet, the problems that XBRL has solved thus far are generally the problems of big regulators, and highly skilled technical people alongside business users with domain expertise are implementing the technology.
But technical people solving problems for regulators isn’t the vision XBRL aspires to achieve. The objective of XBRL is the automated exchange of business information from one business user to another business user with no direct assistance from the IT department. Technology folks will offer plenty of assistance, but it should be in the form of software applications that let business users achieve their goals. Business users should be operating their own information-supply chains (see Chapter 7).
Is this goal achievable? The people at XBRL International believe that it is, and we do, too. It’s certainly a goal worth trying to achieve. Only time will tell if it’s possible.
Facts and Assumptions
Big regulators are successfully making use of XBRL today. But take a look at XBRL from the vantage point of where many of you are — in the enterprise. Your enterprise may be big or small. (Chapter 5 breaks “you” down into a number of different categories.)
We use provable facts, and we make assumptions, based on evidence, to look into the future for areas where opportunities exist or where missteps can occur. We use these facts and assumptions to make our case for the future, providing you with useful information you can use to plan your course of action. You can use our facts and assumptions as a basis for creating your own assessment, if you want.
Known and generally indisputable facts
Here’s a summary of what we believe are some generally indisputable facts about our future as it relates to XBRL:
You exchange information.
Garbage in, garbage out.
Computers are dumb and need certain specific things, such as formally defined formats and no ambiguity, to exchange business information effectively using automated processes.
XBRL does work. Big regulators, such as the U.S. FDIC and regulators throughout Europe and Asia, have shown that XBRL works.
Automated business information exchange is a broad category. Different parties who exchange business information have different needs.
Your company or organization commonly has more than one business software application.
Your business exchanges business information with more than one party, but you don’t exchange information with everyone.
The quantity of information that businesses exchange will only continue to grow.
Assumptions about XBRL’s future
What assumptions can we make about XBRL’s future? We call these assumptions rather than facts because you can dispute them. We do, however, provide justification for each assumption:
XBRL is a global standard and will remain a global standard. The pace of adoption by regulators and those they regulate is strong evidence that the market will likely continue to embrace XBRL.
XBRL won’t always work perfectly. This assumption is easy to justify — nothing ever works perfectly.
You like options, but you’re willing to give up certain options if you gain simplicity, effectiveness, or efficiencies. But, you can give up options only to the degree that your use cases are being met. You can’t compromise on certain things.
XBRL will change. Everything changes. Exactly how XBRL may change isn’t clear, but it’s a sure bet that it will continue to evolve.
Not every business information-supply chain will have the resolve to become what it could possibly become. Politics, human nature, and other things will cause some, perhaps many, business information-supply chains to not realize what they could realize. On the other hand, other business information-supply chains will achieve their potential. The determining factor is the business domain itself, not XBRL.
The global market will come up with new, interesting, unexpected, and exciting uses for XBRL. That assumption is easy to make — that’s why free markets are so great!
XBRL Means New Types of Software
A lot of software vendors will add XBRL as an import and/or export feature within their existing business software products. Other software vendors will create new XBRL-specific products. Taking another approach, other software vendors will fundamentally change the type of software they build, how they build that software, and how that software works within business processes that those software applications serve.
Software vendors will build this new software — some new and some that already exist. Some new startup companies will move boldly and quickly; other established, and perhaps larger, software vendors will move slowly, methodically, but deliberately. Look at the list of XBRL International members as a clue to who is moving and who is not. This list isn’t the only clue: You don’t have to be a member to implement XBRL, and not all members are implementing XBRL.
You can think of XBRL’s impact on software in another way as well. Rather than thinking of XBRL as a means of exchanging business information, think of what business software can do because of XBRL and because we can automatically exchange business information leveraging this standard approach. Also, think of the standardized metadata expressed in XBRL, such as the US GAAP and IFRS financial-reporting taxonomies. What new types of business software can you build as a result? What new types of software will need to be built to make use of XBRL effectively?
XBRL as part of an enterprise service bus or XML pipeline
People disagree as to what exactly an enterprise service bus (ESB) is, but few disagree as to what it’s trying to achieve — information flow.
Information flow, as we use the term in this case, is the effective automation of business processes. The desired theoretical coefficient of friction of such a system would be zero, but just like in physics, some sort of friction will generally always exist; you can only minimize friction.
Think of an ESB as middleware. You can look at an ESB or XML pipeline as software that sits between business systems and enables the exchange of information between those systems. The business systems can be internal or external to your organization.
If you start thinking about XBRL within your organization, it won’t take long to realize that if, say, a number of your business systems make use of XBRL, either one of two things have to be true: Each software application provides the required XBRL infrastructure, or all those applications share one common XBRL infrastructure. If organizations share their XBRL infrastructure, you’ll have fewer interoperability issues between the multiple implementations of XBRL within the different business systems.
More and more organizations are using XML to exchange all sorts of information within their organization and with outside parties. It’s highly likely that XBRL will need to be a part of these XML pipelines of information. (Chapter 2 covers what XBRL brings to the table.)
Integrated functionality
A lot of XBRL software today is standalone as opposed to integrated. By standalone, we mean that you must use multiple software applications, instead of just one application, to complete a task. For example, you can find many standalone XBRL taxonomy-creation tools, but few accounting systems have the integrated features to create an XBRL taxonomy for two reasons. The first software applications to support XBRL were newly created applications rather than existing software applications modified to support XBRL. This reason makes sense. Software vendors are reluctant to implement every new “next great technology” right away. Before they modify their systems to support technologies like XBRL, the market needs to accept the technologies to some degree. For XBRL, that acceptance is now here. More and more software applications are beginning to support XBRL within those business systems.
The second reason products tend to be separated appears to be the need to focus. For example, many software products are either XBRL taxonomy-creation applications or XBRL instance applications. But when you start building an XBRL instance and then realize that you need to extend the XBRL taxonomy you’re using, you have to exit your XBRL instance-creation application and move to your XBRL taxonomy-creation tool. In that situation, you’ll quickly understand why XBRL instance-creation applications need to have integrated XBRL taxonomy-creation functionality.
Improved search and discovery of business information
One thing that XBRL provides is a structured publishing format for information. That structured publishing format improves search capabilities and gives you the ability to more easily discover the information you need.
XBRL will be part of the Semantic Web (see Chapter 6). You’ll likely learn a great deal about the Semantic Web from the U.S. SEC’s Next-Generation EDGAR system (see Chapter 13), which makes use of XBRL. By the time you read this topic, that system will be up and running, and you’ll be able to see what the Semantic Web is all about.
The Semantic Web in general, and XBRL more specifically, will greatly improve your ability to search for and discover information you might need. The Semantic Web will likely change the job you do and how you do it — for example, by allowing you to spend more time analyzing and less time looking for information and rekeying information.
Growing use of application profiles
Today, each XBRL taxonomy is created using a somewhat different architecture. The general-purpose nature of XBRL makes it too complex for business users to use in this general form. Each different XBRL taxonomy implementation picks different pieces, parts, and approaches of XBRL to use in expressing the XBRL taxonomy. All are 100-percent XBRL-compliant, but each is different. These differences cause two things:
Interoperability between each XBRL taxonomy is harder to achieve. We’re not saying that each XBRL taxonomy really needs to be interoperable: They don’t. But if you do need to make them interoperate, just the fact that two taxonomies are both based on XBRL isn’t enough to achieve the interoperability.
Each implementer of XBRL has to figure out pretty much the same things for each implementation, repeating the same effort over, and over, and over.
Application profiles are a common approach to solving this sort of problem, and they have a side benefit to boot: They make XBRL easier to use. We believe that several application profiles will be created, and they will be the implementation patterns for XBRL. No one will use just general XBRL. No one really uses general XBRL today; each XBRL taxonomy uses different pieces and parts within their XBRL taxonomy architecture. In effect, each XBRL taxonomy is, today, its own unique application profile. (To better understand application profiles, see Chapter 12, where we cover them in detail.)
Groups are already working together to create application profiles for XBRL implementations. XBRL Global Ledger is basically an application profile. The US GAAP taxonomy is an application profile; it even calls itself such within its architecture documentation. A number of governments around the world are starting to talk about SBR as an application profile or an approach for governments to implement XBRL in a consistent manner. XBRLS (see Chapter 12) is an application profile.
However, most application profiles aren’t documented formally enough to be as useful as they can be. None of them work out of the box. No software applications leverage the application profiles to make using XBRL easier. But soon they will. After business users realize the practical nature of using application profiles to make their life easier, they’ll gladly give up a small amount of flexibility in order to gain significant reductions in implementation complexity.
Specific Uses for XBRL
Don’t think of XBRL as only a way of exchanging business information. Instead, think of what software applications will now be capable of doing because of XBRL. We’ve put together what can best be called a wish list of such applications. This list contains applications that don’t exist today, but we wish did. These specific financial-reporting examples can help you see ways that you can leverage XBRL’s existence for other business-reporting needs.
Automated disclosure checklist: Today, preparers of financial disclosures use disclosure checklists when they create financial statements to make sure that they don’t forget something. This disclosure checklist is a lot like a pilot’s checklist for taking off or landing an airplane. For an audited financial statement, these disclosure checklists can run around 100 printed pages. You can automate many, but not all, of these checks, letting a computer application check that the financial statement has been created properly.
The disclosure checklist is basically a set of business rules. Disclosure checklist business rules are for creating a financial statement. You can create similar rules for other types of business reports. Because XBRL expresses the information within the business report in a structured manner, you can make a computer tick and tie things in the report to ensure that everything adds up and to check for other requirements that the report must meet. Computers are good at checking things like, “If this exists, you need to disclose these three things also.” These automated checklists will revolutionize business reporting. In fact, another way to look at creating financial reports is that the software application you’re using won’t let you do the wrong thing; it will only let you create the report correctly. Now, a computer will never be able to check certain things, and humans will still focus on those sorts of things. But, a computer can handle lots and lots of mundane tasks currently performed by people.
Financial-reporting disclosure templates: Most accountants who create public company financials are familiar with AICPA’s Accounting Trends and Techniques. The publication is a summary of best practices of financial reporting and disclosure, a comparison of the reporting practices of about 600 organizations, which the AICPA has been publishing annually for many years. This summary of reporting best practices contains basically high-quality disclosure templates. The publication is put together with a lot of manual effort. But the new method of examining the disclosure practices of public companies will be easier than ever with XBRL, thanks to the SEC’s Next-Generation EDGAR public filing database. Accountants and attorneys already use public filings with the SEC EDGAR system to help them figure out the best approaches to articulating disclosure information. With the Next-Generation EDGAR system, you’ll be able to query the system and find specific disclosures by looking for specific reported concepts, filtering, sorting, slicing, and dicing until you get what you need. The SEC’s new system will be a comprehensive database of practices from which you can glean best practices, making disclosures easier and improving disclosure practices. You can access this best practices in disclosures without all that manual effort required to put together the 600-company summary. Thanks to XBRL, you can make computers do this work for you.
Post entries to an XBRL instance: Imagine an XBRL instance with its supporting XBRL taxonomy providing a business rule for every computation within that XBRL instance. Imagine what would amount to posting a transaction to that XBRL instance and the business rules of the XBRL taxonomy updating subtotals, totals, related computations, and so on as you make the adjustment in a transaction you’re posting. Imagine being able to post that or any other entry to an XBRL instance and all the values that are impacted by that adjustment being updated to their adjusted values using the business rules that express the relations. Sound like magic? Not really. Have you ever used Microsoft Excel’s goal-seek functionality? Posting an entry to an XBRL instance works in a similar way. Anyone who has ever created a complex report and then had someone request a last-minute adjustment to that report, requiring them to recalculate all the numbers impacted by that adjustment, will certainly appreciate this feature. Further, imagine being able to create an XBRL instance in this manner: transaction by transaction with business rules keeping the information in balance throughout the entire process.
Interactive information hypercube viewer: Imagine an implementation of an interactive information hypercube (see Chapter 18) where you can exchange a business report with anyone else, and they could interact with that information. Every computer desktop would eventually support interactive information hypercube viewers. What would be different is that the interactive information hypercube viewer would behave something like a Microsoft Excel pivot table, allowing the user of the information to adjust the report flawlessly (not like copy/paste). You’ll be able to add XBRL instances to the viewer, creating a comparison between multiple XBRL instances for multiple periods or multiple companies.
Remember, interactive information is leveraging all the functionality of your computer, not a PDF that leverages all the functionality of paper.
Leverage taxonomy information: Charlie, by his own admission, is a pretty average accountant. But using an XBRL taxonomy makes him a significantly better accountant. Here’s why. Financial-reporting experts created the information contained within the XBRL taxonomy. If you gave ten accountants a blank slate and had them create, say, the US GAAP taxonomy, many couldn’t do it, the results would certainly be inconsistent, and not all of them would be right. You can leverage a significant amount of information within XBRL taxonomies.
These XBRL taxonomies are a new way of articulating information that has never existed in this form. If you look at an XBRL taxonomy, such as the US GAAP XBRL taxonomy or the IFRS XBRL taxonomy, you’ll begin to realize what we’re saying. Furthermore, an accountant who understands the information contained in the XBRL taxonomy and who also understands how to write Excel macros will be able to achieve interesting and useful approaches to putting that XBRL taxonomy information to use. Things are different because the taxonomy information is in a computer-readable format that has never been available, particularly in a global standard format. These new interesting and useful approaches will become increasingly valuable as more and more metadata gets added to XBRL taxonomies.
Another interesting financial-reporting use of XBRL taxonomies will be the conversion of the United States from US GAAP to IFRS. We expect that XBRL taxonomies for the US GAAP and IFRS will play a major role in this conversion process. We know that at least one Big 4 public accounting firm has a mapping, or association, between US GAAP and IFRS. What having this mapping means is that the company has created computer-readable associations between the pieces of US GAAP and IFRS. You can use these mappings for all sorts of different things.
What Can Go Wrong
XBRL isn’t perfect, nor is any consensus-based standard. Making XBRL do the things we want it to do isn’t without its challenges. Here are some of these potential challenges and reasons why they’ll likely occur:
Too many XBRL taxonomies: Just like the case where financial reporting is done with three different XBRL taxonomies (US GAAP, IFRS, EDINET), each of which uses a different XBRL architecture, this situation can occur within other business domains, too. Many times, coordinating different efforts is too hard, there’s an unwillingness to do so, or people are unaware that they’re duplicating what someone else is already doing. Further, business interests may be perceived to, or actually do, conflict. Having too many XBRL taxonomies isn’t the end of the world. Mappings can usually resolve this situation, but many times, mappings are time consuming to create and maintain. The market will eventually dictate what it needs. Politics becomes a factor as certain groups try to control XBRL taxonomies. Eventually, things will end up where they do, and the situation won’t be perfect.
Poor-quality taxonomies: You can construct XBRL taxonomies in many ways, sometimes resulting in less-than-optimal functionality within the system in which they’ll be used. Many times, what suffers is comparability of information and analysis. Bad XBRL taxonomies are a lot like bad database schemas.
Poor software interoperability: Many things contribute to poor software interoperability, including shortcuts by developers, short-sightedness, and ambiguity within the XBRL specification. The biggest loser here may be the business user as what could be one global standard (which would benefit the majority of business users) gets fractured into proprietary fiefdoms. Business users have a big interest in what XBRL becomes and should exercise their right to vote by demanding what they need from XBRL.
Lack of motivation to maintain XBRL: For XBRL to work, someone needs to maintain the XBRL specifications. The specification is the basis of the promise of what XBRL can offer. There has to be resolve to make XBRL work, keep it working, and change it to meet the changing needs of its constituents. Maintaining XBRL takes time and costs money. XBRL is just a technology created by a group who cooperated in the past. Problems need to be resolved as they come up. These issues may or may not get resolved. Users can drift more and more toward proprietary solutions, defeating the purpose of XBRL. But if the XBRL standard can’t meet their needs, business users really have no choice but to go with what works for them.
Inappropriate expectations: XBRL won’t do everything for all people. It has its place. Using it for the wrong reason or in the wrong way doesn’t produce an effective result; it’s like trying to put a square peg into a round hole.
No mass-market adoption: EDI and SGML are two examples of standards that never really achieved mass adoption. The simpler and more internationally usable XML, a subset (application profile) of SGML, did achieve critical mass and mass adoption. Many predict mass-market adoption of XBRL will occur, but nothing is certain.
Changes to XBRL and Usage of XBRL
We really go out on a limb here and predict possible future changes to XBRL and how XBRL is used. These predictions aren’t groundless, but rather based on ten years of watching XBRL evolve, discussions within XBRL International members, and involvement with XBRL implementations. Here are some predictions we can make and our reasoning behind the predictions:
Definition relations will be used more. Definition relations are one of the most underutilized but powerful features of XBRL. Definition relations have a great deal of potential that currently isn’t exploited by most XBRL taxonomies. XBRL taxonomies will grow, in many cases, to be more like ontologies with the use of definition relations. (See Chapter 14 for more information.)
Calculation relations may vanish. There is no real need for both XBRL Formula and XBRL calculation relations. Both are syntaxes for achieving an end. XBRL Formula is significantly more powerful than XBRL calculation relations. Calculation relations can provide nowhere near what XBRL Formula can provide. As such, we believe XBRL calculation relations may become obsolete.
Precision attribute may be deprecated. The precision attribute that is used within facts in XBRL instances will likely be deprecated. The decimals attribute and the precision attribute serve the same purpose. The FRIS suggests using decimals. The XBRL specification provides an algorithm for converting from decimals to precision, but not from precision to decimals. You don’t really need both. We believe precision will be deprecated. Stick with using decimals on facts in XBRL instances.
Contexts will move to a multidimensional model. If you look at the contents of a context element within an XBRL instance (see Chapter 4 for more information), you’ll notice that four things are packed together: entity information, entity segments, periods, and scenarios. Each of these pieces of a context is really a dimension of a fact value. This approach to articulating dimensional information has its drawbacks. First, you can’t establish a hierarchy of the context information. Second, packing four different things into the context element (as opposed to separating each) leads to duplication. Third, you don’t really need some of these dimensions. For example, XBRL Global Ledger doesn’t make use of the period portion of a context. Further periods may have different hierarchies; for example, consider the difference between calendar periods and fiscal periods. If you were to go back and look at XBRL 1.0, you’d see that all this contextual information was, in essence, separated into individual components. The bottom line is that it seems obvious that all context information should work similar to XBRL Dimensions; why not simply use XBRL Dimensions for all contextual information rather than have two approaches to articulating dimensional information?
RDF/OWL used to express XBRL. They may not be created by, but we feel it’s highly likely that someone is going to create a way to use RDF and OWL to represent information that XBRL currently represents. Today, XBRL is viewed as a syntax. We propose that the most important characteristic of XBRL isn’t the syntax, but rather its semantics. XBRL has no logical model, but it needs one. RDF and OWL are logical choices for expressing such a logical model of business reporting. Some other syntax, even perhaps RDF and OWL, may conceivably replace the XBRL syntax. We believe that there will eventually be a lossless approach to moving between the XBRL syntax and the RDF/OWL syntax of expressing the semantics of business information.
Standard XBRL logical model will be created. The creation of a logical model for XBRL goes hand in hand with the previous prediction. Although agreement exists for XBRL’s syntax, agreement doesn’t exist for XBRL’s semantics. A physical model for XBRL exists, but not a logical model. Whether it’s created by XBRL International or an ad hoc standard created by the market, someone will create a logical model for business information exchange. Alternatively, you can create several logical models. The benefits of a logical model are too great for this not to occur. The question is really will it be a global standard or multiple proprietary solutions and therefore different as each vendor implements their own logical model.
Standard XBRL API will be created. Discussions relating to creating an API for XBRL have taken place within XBRL International on several occasions. We believe that the creation of API for XBRL will eventually occur, either by XBRL International or as an ad hoc standard API created by the market.
