In This Chapter
- Figuring out your goals and needs
• Establishing your XBRL architecture
• Implementing your XBRL project Finding the right hired guns
What do you do when you’re finally ready to implement XRBL? This chapter helps you get where you want to be with the fewest hiccups. It provides key information to help you understand snarls that others have encountered and how to avoid them. We also cover how to identify good consultants and determine the consulting expertise your project may need. Don’t expect this chapter to show you everything you need to know about implementing XBRL. This topic just helps you get started down the right path.
Discovering Your Vision
If you really don’t care about where you’re going, just start doing something, and you’ll definitely end up somewhere! Now, we don’t subscribe to that approach because most of us do care about where we end up.
The first part of creating a plan is having a vision of where you want to be when you’re done implementing that plan. (See Part II of this topic as well as Chapter 9 to help hone in your vision.) When you decide on a vision, be sure to live within your capabilities. Don’t go overboard right away — we suggest you start with a prototype or proof of concept to get a feel for the waters.
The following starting points can prepare you for creating that grander vision:
‘ Try building a small internal information-supply chain, maybe automating some simple task that currently has some humans gluing the links of the information-supply chain together.
Work with a trusted business partner within your extended enterprise and try automating a small external information-supply chain.
Build an internal semantic Web of business information for your organization or maybe start even smaller and try out the technologies within your department.
If you tackle a small project prior to taking on a larger project, you’ll begin to appreciate what’s involved in an XBRL project.
Planning for Success
Establishing the right requirements and planning, two important keys to success, help ensure that you’re solving the right problems. You may be familiar with things such as relational database technologies; lots of experience has been gained implementing such systems over the past 30 or so years. Although it’s much newer, XBRL is certainly beyond its incubation period when no guidance, best practices, or other helpful information was available. On the other hand, XBRL hasn’t crossed the chasm between early stages and mainstream adoption either. There’s absolutely nothing wrong with exercising caution at this stage of XBRL’s evolution, particularly if you’re new to XBRL.
The following list offers useful, practical advice to help you make good choices that reduce your risk and remove barriers to a successful project:
Stick to best practices. Best practices are a good way to protect your XBRL project from pitfalls that others have already fallen into. You don’t need to reinvent the wheel if you don’t have to. We cover a lot of these best practices in this topic.
Best practices drive discipline. XBRL International provides some information with regard to best practices (see Chapter 3), but a lot of other information is out there from other successful projects. (Chapters 17 and 18 are additional sources for finding best practices.)
Keep it simple. You’ve probably heard the saying, “Keep it simple, stupid” — KISS, for short. You don’t need unnecessarily complex approaches to get the results you want.
Ruthlessly and liberally apply KISS principles in your project to ensure that you can meet milestones and deadlines, pursue focused outcomes, and achieve success. Unnecessary complexity is the enemy of any implementation!
Start with a prototype or proof of concept. Before you go too far, create a prototype or proof of concept to be sure that your requirements will be met. This step is particularly important if you’re venturing down a new path.
An alternative to creating a prototype or proof of concept is to copy what others have done (see the next section). For now, remember that if someone else had similar requirements to yours and succeeded with a certain approach, what worked for them will most likely work for you.
Be sure that you do, in fact, have the same requirements as that other project. Sometimes, visiting and researching others who have implemented XBRL can supplement or perhaps sometimes be an alternative to creating a prototype or proof of concept. You need to provide hard, tangible evidence that what you want to do will work. You have to convince at least yourself that your path will lead you to success. You may even need to convince others. A good, well-thought-out prototype or proof of concept can help you provide this proof.
Borrow other good ideas. Pablo Picasso said, “Good artists copy. Great artists steal.” Reinventing the wheel is okay sometimes, but it’s not always the best approach. Borrowing the proven ideas of others — with their permission, of course — is the ultimate form of best practices. How can you fail if you imitate something that is known to work? As long as your requirements are the same or similar to another successfully implemented project, borrowing someone else’s idea only makes sense. You may not be able to copy exactly, but you can certainly find a lot of things worth leveraging from other successful projects.
The “If it wasn’t invented here, we don’t want it” attitude is an expensive mistake many people make. Besides, imitation is the sincerest and noblest form of flattery!
Architecting Your XBRL Solution
Say that you understand how XBRL provides an additional layer of help in areas where you need it above the XML syntax layer, so you’re sold on using XBRL. But how exactly should you use XBRL? XBRL is a standard: It’s not perfect. It’s a general-purpose specification, but you need to solve a specific problem. How, exactly, should you be using XBRL?
The answer to this question is different for different use cases of XBRL. After all, XBRL is a general-purpose specification, which is generally a strength of XBRL. But sometimes something’s strength can also be its weakness. Using XBRL incorrectly is like trying to fit a square peg into a round hole.
This section is important to both technical architects who have to make decisions but also for business users who provide important information to these architects. Having an appropriate list of what is important is critical to establishing system requirements. A correct understanding of requirements is key to deciding on an appropriate architecture.
As you start to digging into the details of XBRL, you’ll start asking yourself these types of questions:
XBRL is simply too complex for business users, so how do I make it easier while still complying with the standard?
Different regulators who require us to provide data to them seem to be using different XBRL taxonomy architectures — do I have to implement each of these different architectures internally?
How do I keep garbage out of my systems?
How do I control the information model expressed in my XBRL taxonomy?
XBRL doesn’t seem to have many rules around controlling taxonomy extensibility — it seems too flexible, so how do I communicate to those extending my XBRL taxonomy how to do it as I intended?
We’re not understating the case when we say this list of specific tactics for architecting your XBRL solution are keys to reducing implementation costs, maximizing your project’s success, and maximizing the effectiveness and efficiency of your implementation. Applying the following techniques when appropriate provide significant advantages:
Simplify your life by using an application profile. XBRL is a general-purpose specification. Few implementations need all of it. Reducing what you use cuts down on your costs and reduces user options, which makes XBRL easier to use. An application profile is in essence a specific subset of the full XBRL specification.
Maximize consistency, comparability, and usability via an information model. Consistency makes many magical things happen. You don’t get consistency unless you explicitly attempt to create it. An information model can help you achieve this consistency, resulting in the maximum possible comparability and business user usability. An information model is essentially formal documentation that explains how an XBRL taxonomy implements specific business requirements and how taxonomy components relate to one another.
‘ Increase usability using a logical model. Trying to work with XBRL’s physical model is an exercise in futility. Don’t do it. In fact, most business users can’t do it even if they want to — it’s simply too complicated. Usability is vastly easier by working with XBRL at the logical level. A logical model is simply an expression of the business problem in logical and easy-to-understand terms, which is then followed by your information model.
Reduce effort by using someone else’s taxonomy. Why create an XBRL taxonomy when you don’t have to? You can many times benefit from leveraging XBRL taxonomies created by others. On the other hand, using someone else’s taxonomy also has its drawbacks, such as forcing you to give up a certain amount of control over the taxonomy and selecting the architecture you’ll use.
‘ Maintain control with an abstraction layer. Do you really want to give up control of your internal architecture to an external regulator or multiple external regulators who implement XBRL differently and can potentially change their architecture without your input? An abstraction layer can mitigate this risk. Think of an abstraction layer as a buffer between your implementation and the implementations of others.
Note that the preceding tactics aren’t mutually exclusive. If you combine a solid application profile (architecture), an information model, and express a logical model interface to these, your life really can be a whole lot easier. You may choose to take this approach, but others may not be so enlightened. No problem: Just hide behind an abstraction layer, and you’ll not be beholden to the whims of the XBRL taxonomy creation approaches used by others.
The following sections look at the preceding tactics in more detail.
Use an application profile to simplify
Application profiles are commonly used within computer science. An application profile is a set of technical characteristics and guidelines, or a profile that an application stays within. Application profiles can make things easier by establishing boundaries. For example, XML is an application profile, a fully compliant subset of SGML (Standard Generalized Markup Language). Building an XML parser is easier than building a fully compliant SGML parser due to SGML’s complexity. XML took the parts of SGML that it needed and ignored the rest, therefore reducing complexity. XML is taking off, whereas SGML has a specific niche but never received broad adoption.
An application profile of XBRL is, in essence, a subset of the complete XBRL Specification that you use for a specific implementation. Application profiles are 100-percent XBRL-compliant. Application profiles are specific architectures or approaches to implementing XBRL. Rather than supporting all the features XBRL offers, unnecessary features and duplicate functionality are eliminated from your architecture. An architecture document generally communicates the aspects of XBRL that are used and those that aren’t allowed. The architecture document is enforced by a conformance suite, which is a set of tests that allows you to be sure a software application properly supports that application profile.
If you create application profiles correctly, you can substantially reduce the amount of programming needed to support XBRL, your system can work better, and the system can be easier to use. Here are good examples of application profiles:
COREP XBRL Project: This application profile (www.eurofiling. info/corepTaxonomy/taxonomy.html) is sound, consistent, and proven, but it’s rather technical in nature. Documentation is sparse, but it does have many good examples.
US GAAP Taxonomy Architecture: This XBRL taxonomy (http:// xbrl.us/Documents/SECOFM-USGAAPT-Architecture-20080428. pdf) is well documented, and its architecture and application profile is fairly clear.
XBRL Simplified Application Profile: Also known as XBRLS, this application profile (http://xbrl.squarespace.com/xbrls) was built specifically to make XBRL easier to use by business users. It uses many of the best ideas of the US GAAP XBRL taxonomy and the COREP XBRL taxonomy.
XBRL Global Ledger: XBRL Global Ledger (see Chapter 17) is basically an XBRL application profile for specific types of transactions.
To avoid having to type these long links, This takes you to a landing page where you can click the link you need.
Application profiles do have their downsides. One downside is that an implementation of one application profile of XBRL may not work with another application profile of XBRL. Every true application profile of XBRL will always work with software applications that support the full XBRL specification, but those general-software applications won’t provide the ease of use or leverage of a software application tuned for one specific application profile. This drawback is okay if you work only with specific and known application profiles in your business-information-exchange supply chain. It can be an issue, however, if you must work with many different approaches to implementing XBRL.
Application profiles are basically a tradeoff. You give up flexibility, but they can make implementations easier to use and more robust, as well as reduce costs, complexity, the potential for errors, and so on. In many situations,
some application profiles can be better than others. However, a general implementation of XBRL is unlikely to be better than a specific application profile, tuned for a specific purpose.
You’re basically always using an application profile of XBRL. The application profile may be for general XBRL itself: Everything XBRL offers is allowed. Another profile may only allow certain XBRL modules. Every XBRL taxonomy has its own architecture and therefore its own application profile.
Use an information model to be consistent
Similar to an application profile that constrains the pieces of XBRL that you’ll use in your architecture, an information model has to do with how your XBRL taxonomy is structured — in essence, constraining that structure. An information model helps you keep your XBRL taxonomy consistent, and it can also make working with XBRL easier. An information model also articulates how you should extend your XBRL taxonomy. Because an information model describes how your XBRL taxonomy is structured and how to use it, understanding that model is also helpful for anyone who may end up using that taxonomy.
XBRL taxonomies aren’t simply random. Most, if not all, taxonomies use some sort of information model to create the taxonomy. That information model may or may not be formally documented, but it does exist. Formally documenting the information model makes consistently following the information model easier for both creators and users of that taxonomy.
You can take this one step further than formal documentation and talk about testing the information model to be sure that it’s being followed correctly. The best way to test an information model is by using automated computer processes. Manually eyeballing a taxonomy for consistency and adherence to an information model, particularly a large one, simply isn’t effective.
Something worth mentioning is the notion of a generated approach to creating an XBRL taxonomy. A generated approach means generating the actual XBRL taxonomy using software as opposed to keying every concept, relation, and resource into an XBRL taxonomy-creation tool. Many times, people create taxonomies by adding concepts and relations into a taxonomy via the use of a commercial taxonomy-creation tool. But another approach is to collect information in some other form, such as a spreadsheet, and then generate the XBRL taxonomy itself from that information by using a macro or other program. A computer-generated taxonomy can be significantly more consistent than one where humans add concepts one by one. It’s incredibly difficult for humans to do things consistently without computers to help them.
Here are some information models that others have created:
XBRL Simplified Application Profile: A simple-to-use and highly functional information model (http://xbrl.squarespace.com/xbrls) that works together with an application profile.
XBRL US GAAP Taxonomies Architecture: Although it’s undocumented,
the US GAAP Taxonomy (http://taxonomies.xbrl.us/us-gaap/1.0/doc/SECOFM-USGAAPT-Architecture-20080428.pdf) does follow a specific information model.
The advantage of these out-of-the-box information models is that the documentation is made available in the form of a formal specification, the rules are documented and enforceable by XBRL-compliant software, and some XBRL software vendors support validation against these rules and even offer Web services to validate the adherence to the information model rules.
Increase usability using a logical model
The physical model of XBRL is quite complex. Most business users would have a hard time working with XBRL at the physical model level, nor should they really have to. When you implement XBRL using a logical model to which business users can better relate, it makes it significantly easier for the users to use XBRL within the system.
The logical model of SQL (structured query language) is an excellent example of how a logical model provides benefits. The logical model of a database (tables, fields, and rows) is almost universal. Another great example is the logical model of an electronic spreadsheet (workbooks, sheets, columns, and rows).
The XBRL Specification provides a logical model of XBRL at its highest levels, but this high-level model falls significantly short of meeting your real needs. Because the XBRL Specification focuses on the physical syntax of XBRL, many software vendors now use that physical model to implement XBRL within their software applications. Technical people are fine with working with XBRL at this level, for the most part. The typical business user is far less comfortable with XBRL’s physical model. A logical model hides the physical model of XBRL from the business user.
You can work at a logical level instead of the physical model of XBRL in two ways:
Create your own logical model. Although time-consuming, you can get exactly what you need. It takes a lot of specialized skill to build a sound logical model, however. It also takes a good understanding of XBRL to create such a model. Business people and technical people collaborate to create logical models.
Use someone else’s logical model. Others have defined logical models for XBRL implementations, so use their model. Rather than creating a logical model yourself, take a look at the logical models of others, pick one that fits your needs, and use that logical model.
Both the XBRL Simple Application Profile (XBRLS) and the US GAAP XBRL
Taxonomies Architecture in the prior section have defined logical models.
A good, sound logical model pays significant dividends in terms of usability, design soundness, maintenance, and costs.
Use someone else’s taxonomy
You may be required to use someone else’s XBRL taxonomy, which means you may have certain architectural decisions imposed upon you. Or, you can choose to use someone else’s taxonomy; therefore, you may impose certain architectural decisions upon yourself. Consider these situations:
Use a mandated taxonomy. Some regulator may thrust a specific XBRL taxonomy upon you. For example, if you’re a public company and you have to file with the U.S. SEC, you’ll be mandated to use the XBRL taxonomy that it specifies.
Leverage a taxonomy. You may need to implement some capability or system for which you could leverage an existing XBRL taxonomy. For example, if you’re a bank and you want to collect financial information using XBRL from your borrowers, you could use the US GAAP taxonomy to do so because its financial reporting is so similar to your use case. With only a few adjustments, you can easily extend it to meet your needs.
Create a new taxonomy. You may not have a taxonomy that’s thrust upon you, nor is there a public taxonomy you can leverage. Not to worry — you can create your own XBRL taxonomy.
Life is a tradeoff. Using someone else’s XBRL taxonomy is also a tradeoff. On the one hand, if you use an existing XBRL taxonomy, you can significantly reduce your maintenance costs and other efforts. If you can live with an existing taxonomy as it is, your taxonomy maintenance costs may be zero. If you need to make modifications, you have to maintain only the extension. If you create an entirely new taxonomy, on the other hand, you have to maintain and document the taxonomy throughout its life cycle.
If you leverage someone else’s taxonomy, you’re beholden to their whims to some degree. You’ll have to use the architecture they’ve chosen. You have to live with their maintenance schedule. You have to live with their quality level and so on — you get the idea.
When you evaluate your options, consider who is responsible for maintaining the taxonomy you’re considering leveraging. The ultimate question is, “How much do you want things that you don’t have control over impacting your internal systems?” Also, keep in mind that you may be dealing with multiple XBRL taxonomies that have different architectures, different information models, and different logical models.
Use an abstraction layer for control
Think about the ramifications on your business systems if you have to work with multiple XBRL taxonomies, each with a different architecture or application profile of XBRL, different approaches to modeling their information, different logical models, and different ideas about how a taxonomy should be maintained over its life.
Building an abstraction layer between your internal implementation of XBRL and the outside world’s implementations of XBRL can make a lot of sense in the right situations. Company size can be a major driver. The larger the organization, the higher the probability that you’ll be interacting with more than one party using more than one flavor of XBRL-implemented models in more than one different way, both within and outside your organization.
An abstraction layer can protect you from these realities of using XBRL. Abstraction layers are common in computer science and are a way of hiding software implementation details. A good example of an abstraction layer is the Open Systems Interconnection Reference Model (OSI Model). An OSI Model separates the complex task of networking computers together into seven discrete and independent layers that you can implement independently of each other, but they work together in a formal manner. Technical people use this approach all the time.
Although it can be a big investment, an abstraction layer can eliminate many headaches that you’ll run into if you don’t have a plan for dealing with multiple XBRL architectures, information models, and logical models.
Executing Your XBRL Project
Say that you’ve identified the problem you want to solve and have determined that using XBRL could provide some good leverage. You’ve expressed your requirements, and you’ve chosen your approach to architecting your systems and proven that architecture by creating a prototype or a proof of concept. As such, you’ve tested the XBRL taxonomy information model and
XBRL application profile to be sure that your ideas will yield a system that will meet your requirements. Your project should now be on the road to becoming a stellar success.
You likely know how to execute a project, so we don’t go into every aspect of executing projects successfully here. But what we do have for you in the following sections are specific considerations relating to XBRL.
Test your resulting XBRL instances
XBRL instances are where the rubber meets the road in your XBRL project. Probably the biggest mistake made in XBRL projects today is not creating XBRL instances that properly exercise systems that make use of XBRL. Yet, creating these XBRL instances is the key to building your XBRL taxonomy correctly. This is particularly true if users are allowed to extend your XBRL taxonomy. Testing makes sure that your system will correctly handle the XBRL instances coming into it and that your system rules keep XBRL instances with errors out of your system.
We go into the details related to creating XBRL taxonomies in Chapter 17 and creating XBRL instances in Chapter 18. What we go over here is the bigger picture of how to use XBRL instances to test your implementation, including the critical XBRL taxonomy, which, if not created correctly, can yield some unexpected results. You have several possible options relating to XBRL instances as they relate to your project:
You may need to create XBRL instances as part of your project deliverables.
You may not need to deliver any XBRL instances as part of your project, but you need to create them to be sure that your XBRL taxonomy is created correctly.
You may have existing data that you can use to generate XBRL instances to test your XBRL taxonomy.
You may not have existing data that’s useful for creating XBRL instances to test your XBRL taxonomy, therefore you have to figure out some other approach to creating your test bed of XBRL instances.
You can use the following tactics to create XBRL instances to test your XBRL taxonomy. The primary objective of creating these XBRL instances is to help you understand the rules you need to get good information into your system and to keep garbage out of your system:
Monster instance: The term monster instance describes an XBRL instance that includes every concept in an XBRL taxonomy. The benefit of creating this monster XBRL instance is that it can help you detect certain types of errors within your taxonomy relations. One common error detected using a monster XBRL instance is a cycle problem within your XBRL taxonomy. For example, one class of cycle problem you can easily detect by packing every concept into one XBRL instance is calculation relations that are expressed inconsistently.
Another type of common cycle error found with a monster XBRL instance are two calculations that could never work correctly within the same XBRL instance. Typically, all these cycle issues relate to taxonomy-modeling errors. You can use synthesized data to auto-generate a monster instance. Some software applications even offer a feature to generate these XBRL instances.
Fragment instances: Another tactic you can use to test XBRL instances is to create fragments of specific areas of your taxonomy. Whereas the monster instance tests the interrelationships between areas of the taxonomy, creating fragments allows you to test specific, usually complex, areas or areas where the risk of error in the taxonomy is high. This helps you see whether those specific areas are working as expected.
Comparison instances: You’ll want to test how comparisons between XBRL instances work. You can test for two types of comparisons. One comparison instance is information for one submitting entity but for multiple submission periods. Another comparison is submissions of different entities for the same period.
Conglomerate instance: Entities submitting information to you likely use specific combinations of relations networks together. In many cases, the permutations and combinations of these different networks can get rather complex. These specific combinations of relations networks are generally less than the entire taxonomy. The best way to describe this test is that it tests the key permutations and expected combinations to see whether they work together correctly.
Extension instances: If your system allows extensions, you need to test them, too. You should create extension scenarios for all the non-extension instance testing scenarios discussed previously in this list.
Versioning instances: Plan ahead for when the taxonomy changes. Build a new version of the taxonomy and test your versioning strategy to be sure that it works correctly. Build instances against both versions of the taxonomy and test your ability to perform comparisons across taxonomy versions.
Keep in mind that the fundamental goal of your testing is to be sure that your XBRL instances are working as you expect them to work. A well-constructed XBRL taxonomy is the key to an XBRL instance working correctly.
XBRL taxonomies are basically data models, so you should treat them as such. Many of those creating taxonomies aren’t data modelers but are business-domain experts instead. You have to be sure that the business-domain experts who understand their domain are modeling the data using sound data modeling practices. Automated testing of adherence to your specified application profile and specified information model helps domain experts build high-quality XBRL taxonomies.
Building an XBRL taxonomy correctly without building XBRL instances is impossible; correctly documented XBRL instances is the only way you can assure yourself that the XBRL taxonomy works the way you desire.
If you don’t have any tests, you won’t see errors. Seeing no errors doesn’t mean that you don’t have any, though. What have you done to prove everything is okay? When you can prove to yourself that everything is right, most likely everything will be fine. But, you know how that goes: Every now and then, something unforeseen slips in. You certainly want to test known potential problem areas.
Store XBRL
You’re going to receive XBRL instances, and you’re going to have to store those XBRL instances or the information they contain somewhere. Many people think of XBRL taxonomies and instances as physical files, but they don’t necessarily have to be physical files in all stages of their life cycle. The XBRL may simply be a means of transporting the information contained in the XBRL instance and described by the XBRL taxonomy, an interim step in the chain of using the information. All the information may exist within some application, but it exists only as XBRL for the time needed to perform some specific task. You can think of the XBRL instance, or more likely multiple XBRL instances, as a repository containing all the XBRL taxonomies and XBRL instances you need to fulfill your needs. That information repository can physically exist as the following:
Individual physical file: The XBRL you have to work with may simply be an individual physical file. You access that file and do what you need. For example, a consumer of the information contained within the XBRL instance may need to use only one file for the purposes of performing some sort of analysis.
Set of physical files: A repository is more likely a set of physical files. You somehow have to pull that set of physical XBRL instances and related taxonomies that you want to work with together. How will you do that? Your collection of files may be URLs on the Web — say, the financial statements of a set of companies you want to track in order to benchmark. You could use RSS or some other means to pull these separate physical files together into a set.
Existing relational database: By this term, we mean that your repository of information is some existing relational database into which you place information extracted from an XBRL instance. Existing business systems use a lot of relational databases.
XML database: Another type of database that can hold XBRL is an XML database. These databases aren’t as popular as relational databases, but you don’t have to shred the information, XBRL can easily fit into an XML database.
Standard XBRL relational database schema: Another way to store XBRL is to create a standard relational database schema that is optimized to store all your XBRL. This database schema can hold any legal form of XBRL anyone can create.
Application profile-specific standard XBRL relational database schema: Focusing on one XBRL application profile makes storing XBRL in a relational database much easier. If you use application profiles to remove possible options that it outlaws, you can end up with significantly less complex database schemas that are easier to use. The downside to this approach is that your database won’t hold every possible form of XBRL; it will hold only your specific application profile.
For example, the U.S. SEC collects information from thousands of organizations. In one year, it receives millions of filings. Storing these filings as files on a computer hard drive may not scale for the SEC.
Further, users want to run queries against this data set of millions of files, extracting the information they need. Imagine running a query against a set of files trying to find the answer to a simple question you may have, such as “What is the net income of every company in the airline industry for 2009?” It’s a simple enough question, but consider how this query is processed:
1. You need to figure out the set of files you need to work with.
Of the millions of files, you need to somehow get only the files that contain the information you need.
2. You need to go into each of the files and grab the piece of information you need.
3. You obtain your set of information back from the query in some format.
This process is made even more complicated when you change the query a little. Rather than querying all airlines for one year, consider querying one airline across a period of ten years. In this case, assuming that the taxonomy has been updated each year, the taxonomy used to create the XBRL instances has changed ten times.
On the other hand, the U.S. FDIC receives XBRL filings, shreds the information, puts the information into a relational database, and then stores an archive copy of the XBRL instance. You can query the relational database for this information.
Validate for quality and interoperability
Validation is the process of making sure that you created all your XBRL taxonomies and XBRL instances correctly. Another way to think of validation is to think of it as error detection.
Many different types of errors can occur, and so error detection or validation comes in many different flavors. The good news is that computer applications handle the vast majority of this error detection. Computers can’t handle everything, however. For example, if you use the wrong concept to tag a number, a computer, in most cases, can’t detect that error (but in other cases, it can).
Validation occurs at several points for reasons ranging from interoperability to automation enablement to cost effectiveness. To give you a better feel for validation, here are the different types of validation essential to any effective business information exchange:
XML validation: Without a valid document in XML, validation is a non-starter. Business users should be able to take this level of validation for granted and never have to deal with it. All XBRL processors do XML validation under the hood.
XML Schema validation: An XML document can be valid or well-formed XML, but it may not be structured correctly. That structure is what XML Schema validation provides. An XML parser generally performs XML Schema validation. The parser makes sure that the elements comply with the content model of an XML schema. It also ensures that the data types are correct. Most XML languages provide validation only to the extent of an XML schema. XBRL has a number of XML schemas that indicate how the XML syntax used by XBRL must be constructed, but XBRL goes far beyond XML Schema validation.
XBRL syntax validation: Like XML and XML Schema, the XBRL syntax needs to be correct so that any XBRL processor can correctly interpret the XBRL taxonomy and/or XBRL instance (not just the XBRL processor used to create them). XML processors catch some types of errors; XML Schema validation detects other types of errors. The XBRL Specification conformance suite has, however, more than 400 additional tests that are requirements on XBRL syntax, but XML or XML Schema validation can’t detect the errors. XBRL processors detect these types of syntax errors. Again, similar to XML validation and XML Schema validation, business users should be able to take this level of validation for granted and never have to deal with this level of validation. This classification also includes validation related to any XBRL modules utilized.
Best practices validation: XBRL International issues a number of best practices. These best practices supplement XBRL syntax validation. For example, FRIS establishes a best practice that a fact may not be included twice within an instance document because it makes no sense to do so (exactly the same concept and context). This FRIS best practice prevents this problem from being introduced within a system.
Information model validation: An information model is basically how your XBRL taxonomy is structured; XBRL taxonomies aren’t random. Information model validation ensures that the information model is properly constructed. If extension is involved, it also ensures that extension XBRL taxonomies follow the information models of the base XBRL taxonomy they’re extending.
For example, if a calculation is expressed in a certain manner in an XBRL taxonomy, this type of validation ensures that all calculations are expressed in a similar manner and that someone extending that calculation likewise followed that model. XBRL taxonomies aren’t random; they follow some pattern. Information model validation enforces these modeling patterns.
Validation of other system constraints: The system in which XBRL operates may impose other syntactic or semantic rules on how XBRL needs to be created to operate within that system. XBRL itself doesn’t express all the necessary rules to make XBRL work effectively within a system. Best practices validation supplements the XBRL validation, but they’re still not enough. Specific constraints or choices made by a system implementing XBRL still need to supplement XBRL validation and best practices. The U.S. SEC Public Validation Criteria (www.sec.gov/spotlight/xbrl/ publicvalidationcriteria.htm) is an example of this validation category. This category of validation covers enforcement of any architecture constraints a system places on the XBRL used within a specific system, such as that the entity identifier scheme used by the SEC, which is enforced by the U.S. SEC Public Validation Criteria.
Creation-based business rules validation: Business rules validation is the most interesting type of validation to a business user. It helps ensure that the information expressed within an XBRL instance or set of XBRL instances complies with the semantics expressed within an XBRL taxonomy. Business users sometimes call this data integrity. Business rules validation generally fall into two broad categories:
Computations, all those numeric relationships within an instance. For example, “Does the balance sheet actually balance?”
Report-ability rules, ensuring that everything that is supposed to be reported is actually reported. These rules are things like, “If this is reported, then this and this needs to be reported also.”
Analysis-based business rules validation: A consumer of an XBRL instance may have additional validation criteria imposed on an XBRL instance creator. For example, a specific current ratio threshold for a reporting entity is a rule placed, say, on a borrower by a lender. Analysts attach these rules to their XBRL taxonomy.
Feeling a little overwhelmed and perhaps a little concerned that you’ll never be able to get your XBRL taxonomies and XBRL instances to be valid? Fear not! Software will take care of this validation for you. Besides, you already enforce a lot of these rules in your everyday workflow, but humans enforce the rules carefully and diligently by doing a lot of work. XBRL moves a lot of the human validation to computer processes. It doesn’t take care of all the validation and error detection, but it does plenty enough to improve the quality of business reports and reduce the cost of creating the information.
All these different types of validation are important to different participants of an information exchange. Holes in validation result in human intervention to correct issues, which means increased costs and increased time to effectively use the information being exchanged. Good rules and good validation are critical to effectively automating information exchanges.
Maintain your XBRL solution
Things change. The XBRL taxonomy you either provide in your system or use in your system will change, and you need to communicate those changes. You need to remap systems for new taxonomies and their changes. The good thing is that XBRL has a solution called XBRL Versioning. (See our discussion of XBRL Versioning in Chapter 16.)
Collaborating with XBRL Consultants
You’re probably going to be working with consultants who help you with aspects of your project relating to XBRL. You no doubt know how to work with consultants already. You need to pay particular attention to finding the consultant who brings the XBRL expertise that you need.
One XBRL consultant is probably not going to be able to bring everything you need to a project. In fact, finding one person who can is rare.
Look for these skills when hiring XBRL consultants:
Data modeler: Building a taxonomy requires data modeling expertise and also specifically XBRL taxonomy-creation expertise. Not all data modelers have XBRL expertise. Teaching someone who understands data modeling how to understand XBRL is likely far easier than teaching someone who understands XBRL, data modeling.
Specific XBRL processor: Developers may understand how to write code, but just because they can write code doesn’t mean that they understand the best way to develop or use an XBRL processor. Likewise, just because they understand one XBRL processor doesn’t mean that they understand a different XBRL processor.
XBRL architecture: Just because someone is a fantastic software architect doesn’t mean that they understand anything about how to select a proper architecture for an XBRL system. Teaching a good software architect about XBRL is easier than teaching someone who thoroughly understands XBRL about good software architecture.
Domain expertise: Just because you understand a specific domain doesn’t mean that you understand XBRL. And yet again, teaching a domain expert XBRL is vastly easier than teaching an XBRL expert about a specific domain.
At this point in XBRL’s evolution, caution is in order. The number of XBRL consultants popping up these days is incredible! The demand for XBRL is increasing, and everyone is trying to make a buck. Don’t allow them to waste your time or money or unintentionally risk your project.
Not even the best consultants know everything about everything. Good consultants understand their strengths and weaknesses and are comfortable telling you about their weaknesses. If a consultant pretends to know everything, be wary!
Before you hire a consultant, you need to know something about his knowledge and background. Ask a technical consultant the following questions to make sure that he can be effective and helpful on an XBRL project:
Do you understand XBRL? Duh! And as good as we hope this topic is, if the only exposure your consultant has to XBRL is via this topic, you probably need to get a new consultant! You can read this topic without a consultant’s help. If you ask a consultant questions based on what you’ve learned from this topic and he doesn’t seem to understand what you’re talking about, it’s a bad sign.
Do you understand how to use XBRL processors? A common mistake is to not use an XBRL processor or to literally end up building your own XBRL processor piece by piece until you realize that you really should have purchased one. XBRL processors provide a significant amount of leverage for working with XBRL. You need to make use of one. If your consultant is using SQL or XSLT alone without an XBRL processor, she’s racking up a lot of hours unnecessarily.
Do you understand the advantages of an information modeling layer?
Understanding what an information modeling layer is and how you can use it to make a lot of things easier is important for your consultant to understand. If your consultant doesn’t know what an information modeling layer is, cha-ching! You’ll pay. You won’t be able to create a consistent XBRL taxonomy, and you won’t be able test your XBRL taxonomy adequately.
Do you understand XBRL Dimensions? If your consultant claims to understand XBRL but doesn’t understand XBRL Dimensions, she doesn’t really understand XBRL. Look for a different consultant immediately.
Do you understand XBRL Formula? As with XBRL Dimensions, if you don’t understand XBRL Formulas, you really don’t understand XBRL. Get another consultant.
Do you understand XML, XPath, XLink, XForms, and Xcetra?
Nowadays, you can find people who understand XML, but that wasn’t always the case. A good understanding of XML is necessary to understand XBRL. However, beware: Understanding XML isn’t enough to understand XBRL. XLink is a bit of a different animal, and not many people in the XML community really understand it well. So, be careful. XBRL makes a lot of use of XLink.
Do you understand XSLT? XSLT is one of the most useful technologies when it comes to working with XML and is part of the XSL (Extensible Stylesheet Language) family, which includes XSLT (XSL Transformations), XSL-FO (XSL Formatting Objects), and XQuery. All these standards are helpful in rendering XBRL.
Do you understand data modeling? Data modeling is a unique skill set that not everyone has. If you’re building a taxonomy, data-modeling expertise is critical.
Do you understand architecture considerations? You know, a framer can build a house without understanding architecture. When he gets done, it may not be a great house, or even a good one, but he can build one. You definitely want someone on your team who has years of experience at figuring out technical architectures.
Managing an XBRL Project
The biggest secret to managing an XBRL project is that XBRL projects are mostly like other projects. There are more similarities than differences. If you employ good practices on other projects, those practices will work for projects that have an XBRL component:
Be sure to get good (and the right kind of) XBRL expertise. Just because someone is good at one aspect of XBRL doesn’t mean they’re good at all things XBRL. The best XBRL consultants understand this. (For more on this topic, see the previous section.)
The more XBRL instance testing you do, the better the XBRL taxonomy will be. It’s that easy. It’s not just about the volume of XBRL instances for testing; it’s building the correct XBRL instances. Be sure to check out the section on testing we provide earlier in this chapter.
If you find that you’re reinventing a lot of things, one of two things must be true: Either you have some specific requirements that are unique to your system, or you’re making a big mistake. Be sure to check out the earlier section relating to application profiles to see whether you can leverage what others have created instead of unnecessarily reinventing the wheel.
A taxonomy is a data model. If you’re building a taxonomy, you need a good data modeler who has learned XBRL. Teaching a good data modeler about XBRL takes significantly less time than turning someone who understands XBRL into a good data modeler.
Identifying a Successful XBRL Project
Here are signs that your XBRL project is probably ticking like a Swiss watch:
Problems exist, but you have a list of them. Problems always exist. Having a list of problems is actually a good thing. Perhaps an overly long list may have its issues, but having no list is a signal that something else may be going on. (See the symptoms of an XBRL project in trouble in the next section.)
Technical people are making the technical decisions. Technical people should be making technical decisions.
Business people are making the business decisions. Business people should make business decisions.
Good communication exists between technical and business people. A good sign of communication is conflict. Technical people and business people come from two different worlds. With XBRL projects in particular, technical and business people interact a lot. Good, healthy conflict is a sign of communication. Clearly, the conflicts shouldn’t persist but move to resolution, but conflicts are a part of effective communication.
Your prototype or proof of concept proves your system will work as expected. The best way to keep your batting average high is to stack the cards in your favor. A good way to do so is by using prototypes effectively. Prototypes are a great communication tool to help you see whether requirements are understood by all parties correctly, to test ideas to see whether the ideas work, and so on.
Your processes are detecting bugs and issues that get resolved. Bugs and other issues are part of the process, but you don’t want them to get out of control or remain undetected. Mistakes are made on every project. Having a lot of bugs isn’t an excuse to support bad practices; that isn’t the point. Bugs, issues, and other problems are a part of life.
Monitoring an XBRL Project in Trouble
Here are signs that your XBRL project is perhaps in trouble and something may need your attention:
Your project has no problems. Yeah, right! A good sign of problems is thinking that you have no problems. Every project has its issues. If you think your project has no problems, it basically means that people don’t know how to recognize problems or that they see the problems but don’t want others to know about them. A good dose of “management by walking around” and talking to people helps you see where problems may be hiding.
No proof exists that your system will work. If you don’t test your system and you can’t prove that everything will work, some things probably won’t work. Prove to yourself that everything works, and things will work.
No test cases exist. If you have no test cases, chances are you’re not doing any testing. Testing provides the proof that things work.
No tests are failing. Test cases, if they exist, initially fail. As the project proceeds, things will be fixed, and tests will stop failing. If nothing ever fails a test, it means that something is definitely wrong. It may be the case that you have the wrong tests.
No prototype or proof of concept exists. Prototypes exist in order to test an idea to see whether that idea will work. If you’re repeating something that someone else has created, you have less of a need for a prototype. If you’re doing something for the first time, you absolutely want to have a prototype. When you’re building a taxonomy, it should include prototype XBRL instances that users of the system will create. No prototype XBRL instances for a taxonomy means that your taxonomy may not work as you want or expect.
No system requirements exists. No system requirements means that anything is acceptable, right? Well, probably not. Requirements are critical to getting what you want out of any system — even a system that makes use of XBRL.
No architecture document exists. No architecture document means no ability to test whether you’re following your architecture. Or, maybe you haven’t prescribed an architecture. That may cause inconsistent XBRL taxonomies and XBRL instances and is a pretty good bet that you won’t like the results achieved out of your XBRL implementation.
Technical people are making business decisions. Letting technical people make business decisions is a bad idea. Generally, they make business decisions only when they have to because the business people aren’t making the decisions they need to make for some reason or another. Get to the bottom of why business people aren’t making the business decisions.
Business people are making technical decisions. Likewise, you don’t want business people making technical decisions. In those cases, you may have an imbalance of power where business people are overriding or meddling in areas they shouldn’t.
Business and technical people aren’t communicating. It’s bad news if technical people and business people aren’t communicating. If no disagreements occur or compromises are reached, you likely have some sort of communication problem.
