Evaluating Different Approaches to Implementing XBRL

In This Chapter

Implementing XBRL using different strategies Discovering the right approach for you Examining the realities that drive your decision
You already know what XBRL is. (If you don’t, see Chapter 1.) You know you want to do something, but you’re not sure what. You could use some clarification on your options for making use of XBRL. Guess what: You’re in the right place.
This chapter covers the different approaches to implementing XBRL so that you can look at your specific environment and pick the approach that is right for you. We inventory the various approaches, breaking them into categorie: We explain each approach and tell you their pros and cons. We don’t tell you which approach is best for you: That decision is your job.
There is no right or wrong answer to implementing, or not implementing, XBRL. There are only mismatches between your desired result and the path you take. In this chapter, we help you understand the different paths and what is at the end of these paths. That way, you can decide what’s right for you and your organization.

The Many Ways to Implement XBRL

We take all the different approaches to implementing XBRL and group them into categories. Here are the fundamental approaches that you can generally employ to implement XBRL:
‘ Do nothing. Taking no action is, of course, an action.
‘ Outsource the task of generating XBRL to an XBRL service provider.
‘ Bolt on the ability to generate or receive XBRL to an existing process.
Purchase XBRL-supporting software that you can use with an existing or new process.
Integrate XBRL into your existing business systems.
Create entirely new systems to fully leverage what XBRL has to offer, unconstrained by legacy systems.
You most likely have a lot of different systems, and you’ll therefore probably be taking a lot of different approaches. Using only a one-size-fits-all general approach is unlikely to be right for every department, business system, and process of an organization. Each unique situation typically calls for a different approach. (We don’t talk about software applications here. Chapter 14 has information on vendors who can help fulfill your needs from a software or services perspective.)

Do nothing

Doing nothing is always a potential option. If you’re mandated by someone else to provide them with XBRL-formatted information, it’s hard to get around that. In that case, doing nothing may not be a viable option. But if someone else isn’t requiring you to implement XBRL, you may be able to just do nothing. Of course, doing nothing is easy, but you may miss the boat and be left in the wake by your competitors who are leveraging what XBRL has to offer.
Doing nothing does have its costs. If you took Economics 101, you may remember the concept of opportunity losses. If your competition gains efficiencies from XBRL and you don’t, it may have an impact on you.

Outsource

Another approach to meeting a requirement to provide XBRL is to outsource the whole deal. This approach is similar to the bolt-on approach (see the next section) in that the approach supplements an existing process. But unlike the bolt-on approach, which is internal, this process is external to your organization.
The only pro of this approach is that it causes the least disruption. You don’t have to learn about XBRL; you don’t have to do anything differently.

The cons, however, are many:

You have the least amount of control over how your information is tagged, but you’ll likely be involved to some extent.
You’ll experience a marginal cost increase with little or no marginal benefit because you’re not leveraging the characteristics that XBRL offers within your organization. Also, it’s time consuming because effort, and therefore additional time, is tacked onto the end of an existing process. Fundamentally, all you’re doing is adding more work to the end of an existing process rather than using XBRL to improve the process.
Outsourcing is likely to be more costly than other approaches to implementing XBRL over the long term. (The fact that this approach yields a net increase in cost will become clearer when we discuss your other alternatives.)
You can’t really leverage XBRL internally for other things or use it to improve internal processes.
All in all, you can really look at outsourcing XBRL work just like other work that your organization outsources. Typically, the same or similar pros and cons exist.
An example of this approach is a company that outsources the creation of XBRL U.S. SEC filings to its existing financial printer who already creates its SEC filings. In addition to providing the current services of rendering the filing in the required SEC format, the financial printer also provides the company with the XBRL format that it needs to fulfill the SEC’s requirement for providing them with XBRL. Creating the XBRL format requires more of an understanding of the financial information contained in the filing because rather than simply reformatting information, you need to make decisions regarding tags, contexts, and other information required to prepare the XBRL submission.

Bolt on

Perhaps you don’t want to outsource, but you want to minimize disruption. You may consider the option that’s often described as a bolt-on solution. With this type of an approach, you bolt on a new process to, most likely, the end of some existing processes. The result of the bolted-on process is your XBRL-formatted output. Using this approach may mean buying software or creating software that, say, takes a spreadsheet or word-processing document, creates a mapping, and then generates XBRL using the input document and the mapping.
Alternatively, you can create internal systems that output the XBRL formatted information. You have to consider how the existing system is integrated with the new process and whether that new process uses off-the-shelf software or internally developed software of some sort. Table 11-1 outlines the pros and cons of the bolt-on approach.

If you use consultants to achieve everything, the bolt-on approach can look much like an outsourced approach (see preceding section). If you do take the bolt-on route, consultants can be quite useful in showing you the correct approaches to use XBRL.
Use consultants wisely and in the right roles. For example, hire consultants with XBRL experience to bring XBRL expertise into your organization. If you don’t know any more about XBRL after the project than you did when you started, you miss an opportunity to internalize what you’ll eventually realize are important skills your organization needs to have internally.
Examples of the bolt-on approach are the many new software products (see Chapter 16) created to work with XBRL. Many products try to serve specific niches, and some may meet your needs.

Purchase software

What if you didn’t have to do anything to use XBRL other than install an upgrade to a new version of your current vendor’s software product? Another less attractive alternative along these same lines is to buy a different off-the-shelf software product because your current vendor won’t upgrade its product. A third alternative in this category is to purchase what would
amount to an add-on product specifically designed to be integrated with a software product you already have via, perhaps, an import/export process. Perhaps it’s semi-integrated into your other systems, having a relatively low marginal cost. Table 11-2 outlines the pros and cons of purchasing software.

You can mitigate lack of control over your vendor’s implementation schedule if your vendor communicates when XBRL features will be implemented and if your vendor is good at meeting its commitments.
The difference between the software purchase option and the integrated approach, described in the next section, is really who is doing the integrating — you or your software vendor. Probably the biggest difference between the two relates to control and cost. Purchased software will likely cost significantly less; however, you have little control as to when (or if) XBRL features are implemented and what features appear.
Examples of this type of an approach are customers of SAP. SAP, an ERP vendor, has announced XBRL support. Customers of SAP will eventually get many XBRL benefits out of the box.

Integrate

One way of getting an integrated solution that fully leverages the characteristics of XBRL is to purchase or upgrade your off-the-shelf software. If you’ve internally developed systems, you can either switch to purchased
software (unlikely) or integrate XBRL into your internal business systems. Another integrated option is all those subsystems that exist for various specialized purposes. A big category of this type of system is spreadsheets and other ad hoc-type systems.
To obtain the most benefit from XBRL, deeply integrate XBRL into your systems, leveraging its characteristics within your existing workflow or even using XBRL to dramatically improve your workflow. Use XBRL to reduce the friction within your information-supply chain (see Chapter 7). Table 11-3 covers the pros and cons of this approach.

The best way to summarize this alternative is to talk about risk. The question isn’t how to get rid of risk because you can never get rid of risk. You can pick the type of risk you deal with, but you can’t reduce risk to zero for all categories of risk. Also, internally developed legacy systems are a reality. Many times, you wish you could throw them out and start over, which is the approach we discuss in the next section. However, most of the time, throwing out legacy systems and starting over simply isn’t an option.
The great example of an integrated approach to implementing XBRL was used by FRS Financial Reporting Solutions Pty Ltd (FRS). FRS created an accounting engine called Virtual Chartered Accountant using a single, global, IFRS-compliant accounting language. The accounting engine basically enforced rules that guided system users through the process of creating all accounting entries entered into the system. The system, mapped to the XBRL taxonomy, needed to generate reports as an XBRL instance. The Virtual Chartered Accountant accounting engine was applied to reporting of retirement fund information. For more information, see the case study at www.xbrl.org/Business/Regulators/SA%20XBRL%20Case%20 Study%2 0-%2 0Success%2 0Story.pdf.
To avoid having to type these long links,. This takes you to a landing page where you can click the link you need.

Create

Imagine if you could use XBRL from scratch. This option isn’t realistic for many, but it is an option for some. If you’re starting a new business or if you’ve been thinking of scrapping what you have because it’s at the end of its usefulness, starting over may be a viable option. If it is, when you re-architect your system, be sure to take a look at what leverage XBRL can provide.
Another alternative in this category is building a super system, or layer above your existing systems, kind of like an internal semantic Web. You can even build a super-system layer above the one or more business-information supply chains you participate in to operate your business effectively and efficiently, to stay on the edge of the competitive envelope.
You know if you fit into this category because you think of processes in different ways than most other people do. You really think outside the box. Your business systems tend to be state of the art and viewed as strategic weapons you use to compete in the marketplace.
Idealistic, maybe. These ideals are more something to strive for and attempt to achieve, but because technology is such a moving target, almost no one ever gets to business system nirvana. Table 11-4 lists the pros and cons of this approach.

The risks can be huge if planning is poor, but if you have the capabilities to pull this off, the rewards can be great. What is the value of Wal-Mart’s information-supply chain? If you don’t understand this question, you definitely don’t want to take this approach. (See Chapter 7 for a discussion of the value of Wal-Mart’s information-supply chain.)
An example of this type of approach is the NBP — see Chapter 7. The NBP’s vision is to significantly reduce system friction between state agencies and the constituents they serve. Legacy systems are integrated with a state-of-the-art information-supply chain.

How Vendors and Regulators Fit into These Approaches

You may think we’ve overlooked two additional categories of approaches to implementing XBRL: software vendors implementing XBRL in their products and regulators mandating XBRL. However, these two use cases really do fit into one of the implementation approaches we cover in the preceding sections.
Software vendors implementing XBRL in their product: If you’re a software vendor, you have some choices to make about when, or even if, you’ll support XBRL within your software application. Either you support XBRL within your product, or you don’t.
If a software vendor chooses to implement XBRL within its product, the vendor needs to pick how it will implement it from the list of options we cover in this chapter. One thing the vendor looks at is whether it wants to purchase components, such as an XBRL processor, or if it builds its own XBRL processor. Perhaps the vendor needs additional infrastructure. The software vendor may even outsource, using a service that does any necessary XBRL processing and simply returns the XBRL output back to the software application.
The bottom line here is that software vendors that provide the applications most people use actually do fit into the previous categories.
Regulators mandating XBRL: Another small group of XBRL implement-ers is regulators. “Now wait a minute,” you ask. “Didn’t you say earlier that regulators are one of the primary users of XBRL?” Well, yes and no.
Regulators will implement XBRL. However, for every one regulator implementing XBRL, hundreds, thousands, or even millions of businesses will use XBRL as a result of some regulatory mandate. So, compared in terms of volume of implementations, regulators will eventually be a small number of total XBRL implementations.
However, those implementations tend to be quite large. These regulators have to choose from the aforementioned variety of different implementation strategies and probably use different approaches to different aspects of the systems they’ll be building.

Choosing Your Approach

Certain realities of life will likely directly impact your choice of an approach and should be in the forefront of your mind as you select your approach:
‘Net benefit over the long-term: The net benefit of a solution over the long term should be the main driver of most decisions. You can take that further and look at the present value of future cash flows, a standard approach to measuring the value of a project. Another term used to describe this concept is ROI. We could go into an entire dissertation here about how the ROI needs to be considered relative to other potential uses of resources, but any good businessperson already knows this information. Suffice it to say that you need to factor these things when choosing your approach.
‘ Short-term realities: Although the best long-term option is the best theoretical driver, short-term realities also come into play. For example, you simply may not have the cash to pursue some approaches. Further, you have to keep your systems up and running 24-7 because you have a business to run. You need to factor these short-term realities into the equation.
Total cost: A solution’s total cost is always a consideration. Cash flow may be even more important. If you don’t have the cash, your options may simply be limited.
Big picture: In Chapter 7, we talk about the information-supply chain. Don’t lose sight of the forest by looking at only one of the trees. Keep the entire chain in mind, not only one or two of the links.
Change-management capabilities: Your capabilities to manage change in your organization are a consideration. With change comes the potential for disruption, risks, resource utilization issues, and so on. Can your organization handle a revolution, or do you need to evolve?
Submission of XBRL to multiple regulators: If you are, say, a financial institution in the United States, you’ll probably be submitting XBRL to two different regulators in the near future: the FDIC and the SEC. These two regulators use two different XBRL taxonomy architectures that aren’t really interoperable, but the data you submit to both systems is the same data.
Differing implementations between software vendors (interoperability): One software vendor will implement XBRL differently than another one does. For example, some may implement all the XBRL modules (XBRL Dimensions, XBRL Formula, and so on), but other vendors may implement only the base XBRL specification, not any modules. Others may be somewhere in between. These different software applications may not be interoperable. Some software applications may never need to interoperate, but some will.
Differing dialects of XBRL: XBRL is a general-purpose specification (see Chapter 2). Certain XBRL taxonomies will likely use some XBRL features, and while other XBRL taxonomies will use other features. In other words, taxonomy architectures will vary. System architectures will also vary. This situation creates what can best be described as different dialects of XBRL. Many of these different dialects may never have to inter-operate, but some will.