XBRL: What’s in it for Executives?

Many companies who are currently filing XBRL formatted corporate filings with the Securities and Exchange Commission (SEC) view XBRL as a compliance headache they have to endure. When XBRL was first considered as a potential global standard for business and financial reporting, it was thought to be a useful tool for improving data access, sharing, validation, consistency and transparency. But why haven’t these perceived advantages been realized? Is it because XBRL was first introduced to corporate filers using a compliance model? Is it because the capabilities of a robust XBRL implementation not limited by the SEC’s specifications are not understood? About 10,000 public companies are dealing with XBRL. Shouldn’t those companies that are forced to comply with XBRL technology attempt to benefit from it?

The Barcode Example

When barcodes were first conceived, they were not understood or implemented for many years because they too were misunderstood. Barcodes began to be used in grocery stores when the National Association of Food Chains (NAFC) called for equipment manufacturers to produce equipment that could read barcodes. In 1967 RCA produced barcode equipment that enabled grocery stores to experiment with the new technology. Initially barcodes were pre-printed on labels so that food store employees could attach them to the products that grocers sold. During the initial testing of the technology many lessons were learned, including;

The need for a universal barcode standard with a robust taxonomy of product definitions and attributes

The need for barcodes to be printed on packaging prior to delivery at grocery chains

The need for large-scale equipment production that could read a universally standard barcode

Companies recognized the benefit and value of barcode use and invested capital to implement barcode systems that are now so common that they exist in virtually all retail outlets and many industrial equipment applications.

The XBRL Comparison

The invention and development of XBRL has been far more planned and managed. By contrast, universal taxonomies were developed prior to implementations like that of the Securities and Exchange Commission (“SEC”). This provides a significant advantage to XBRL users, because every public company can use the same U.S. GAAP taxonomy. That translates into a free public source of corporate financial filings that is machine readable, easily understood and very comparable. Further, virtually any software tool is capable of recognizing XBRL because XBRL is programmatically the same as XML, a proven data storage and transfer standard that is widely used in corporate systems and web-based applications.

However, the existence of a universal standard taxonomy doesn’t preclude a company from developing its own internal taxonomy to describe in detail all of the data it uses in its business and financial reporting environment. Further, since private taxonomies can be customized to a single company’s population of data, there is no need for quarterly review of the custom taxonomy elements in use since the same custom taxonomy elements persist from period to period.

The advantage of creating an internal standardized XBRL taxonomy is that it allows “metadata” to be attached to the business and financial reporting facts that a company uses. The attached metadata describes each fact in detail so that any software application can understand the meaning of each fact. For example, a specific fact for oil company revenue concept could be tagged with all of its meaning so that any application can understand when it receives the data that the fact is Refining & Marketing Revenue from a specific subsidiary for a specific period time, in U.S dollars, derived on a U.S. GAAP basis, rounded to the nearest dollar, and defined by any other attribute a company chooses to build into its internal taxonomy.

Describing Meaning is Only Part of the XBRL Story

The value of XBRL does not end with defining the data that is tagged. What most users don’t connect with XBRL is the value of the relationships that can be created between a given set of facts. For example, the SEC version of XBRL creates presentation relationships, dimensional relationships and calculation relationships. The presentation relationships describe which facts belong together in what order and in which disclosure. The dimensional relationships describe additional details for specific line items and date contexts like which segment produced that fact, which subsequent event the fact was related to or which acquisition caused the fact. The calculation relationships describe how a particular set of facts add or subtract to arrive at a total.

The SEC’s application of XBRL is constrained by the rules they implemented for filers. XBRL allows for the creation of formula relationships (via a formula linkbase not in use by the SEC). The power of the formula linkbase allows companies to create user defined formula relationships that can be used to validate data as it is created. This is perhaps the most beneficial part of implementing XBRL internally within an organization. The formula linkbase could also be used to provide exception reporting or to identify data that needs the attention of audit, reconciliation and compliance professionals. Reducing spreadsheet proliferation by eliminating repetitive spreadsheet activities that are prone to user defined application errors would also be enabled by the use of a formula linkbase.

A Single Standard for Sharing Information

Sharing information is an integral part of engaging in business. Unfortunately businesses use a variety of formats for sharing information with their business partners. The need for a universal public standard for collecting and reporting business and financial data is apparent when companies consider all of the formats they use to share information. The advantage of a standard that not only defines the data but also describes the relationship of one fact to another is that business partners can relate the business they share to automate repetitive processes.

For example, suppose a company and its vendor are sharing information about products ordered through a purchase order system, products shipped and received, invoices provided and payments made. Since XBRL can relate this shared data, matching of purchase orders, shipping receivers and invoices to facilitate payment can be largely automated with an open standard that can be understood by a variety of software applications. The advantage of this approach is that it enables automation without significant modifications to hardware platforms and limited modification to existing software applications.

XBRL is a Global Technology

XBRL is globally standardized and in use in many jurisdictions around the world. The Dutch government understood the benefits of XBRL and took the initiative to rationalize the data collected by its various agencies then streamline the reporting used to collect the required data. Their idea was to collect one standard set of data from companies in one central location then distribute that data throughout the various agencies that use it. In Japan, implementing XBRL reporting requirements had the unintended benefit of translating the data being reported into English. In the United Kingdom companies are filing tax returns using a standard set of tax return forms. The forms are linked to XBRL tags that describe the resulting data in detail. By using prescribed forms tax return filers are providing XBRL tagged data without having to deal with the challenges of mapping, tagging and structuring of the XBRL data. This results in highly standardized process that facilitates cross company comparisons.

Since XBRL is a global standard, taxonomies can be multi-denominational and multi-lingual. Such taxonomies allow companies to collect data in one currency and one language and report that data in another currency and another language. This advantage can also be used to present a single set of business and financial reporting facts to multiple audiences in a variety of local currencies and local languages.

XBRL is a markup language and belongs to the same family of languages as HTML. All of us use HTML every time we access the internet. HTML tells websites how to format the page being displayed to the user. Today we are able to gain the benefits of HTML use without having to think about its creation. XBRL tells the computer the meaning of the tagged data. Ideally XBRL should be utilized in a way that imbeds it deeply into applications so the users don’t have to think about creating XBRL but still get all of the benefits of using XBRL. The types of advantages that are possible won’t be realized until companies test implementations to determine what approach works best for the data they need to manage.

The importance of developing a broad data management and utilization approach is especially heightened given the proliferation of Big Data, much of which is being produced in unstructured environments. XBRL tagged data, even if created in or hosted in unstructured environments, can be understood because the XBRL tags provide metadata that brings meaning, context and relationship to the Big Data being managed.

Connecting XBRL with the Last Mile of Finance

One of the largest barriers to delivering business insights is unorganized data. The need for data organization in accounting and finance is most visible in the last mile of finance. Companies have ERP systems, financial reporting systems, BPM systems and many user defined applications created using desktop office software. Unfortunately financial reporting professionals are still forced to manually access and gather the information from a variety of sources for SEC filings and other financial reports they must produce. Most companies have not considered the need for organizing cross application data for end-user use.

These inefficiencies result in a real cost for manually accessing the data needed for reporting and an unseen cost for opportunities lost due to the lack of reliable, real-time information that could be utilized by business leaders. Worse, the last mile of finance is typically a hidden problem with no single owner of the entire process. When the CFO ultimately gets the data he needs, the CIO has his ERPs and other systems in place, The CAE is in compliance with SOX and has compensating controls over spreadsheets, the Controller gets the work done with employees working some overtime and the staff doesn’t want to break processes that have been in place for years, it is not hard to see why no one pays attention to the last mile of finance

Where are the Innovators?

The lack of enthusiasm about XBRL was caused by the SEC’s forced compliance implementation in a relatively short implementation window. Most companies chose to comply by outsourcing the XBRL creation to a third-party. The unfortunate result was that significant XBRL expertise was gained by the service providers at the expense of the reporting entities. Corporate financial reporting professionals have learned about XBRL, but have not gained enough insight to see the benefits if implementing XBRL deeply within an organization’s data management approach. Instead, today’s users see XBRL as a compliance headache that costs them a lot of capital with no perceived benefit.

XBRL was not designed to force companies to comply with a specific reporting regimen, but rather to facilitate access to business and financial reporting data in a consistent, validated and meaningful way. XBRL was intended to eliminate manual intervention, and streamline access to information thereby freeing valuable business and financial reporting personnel to partner with business leaders in utilizing the available information to drive better decisions and improved performance. The benefits of barcode technology were not realized until companies started experimenting with its use. Where are the large institutions that are willing to investigate the benefits of XBRL through XBRL pilot programs?

What Should Executives Be Doing With XBRL?

Public companies are forced into working with XBRL through the SEC’s rigorous filing requirements, so XBRL is a reality that is here to stay. Executives should consider demanding that their current software providers implement XBRL technology deeply into their software applications and database structures. It would also benefit many companies to begin cross functional discussions about how XBRL tagged data could be implemented and utilized within the organization. These cross-functional discussions would be especially enlightening when held by finance, internal audit and information technology groups.

Companies could also benefit by initiating small XBRL pilot programs to explore ways of gaining a competitive advantage by streamlining the access and analysis of business and financial data in a more efficient way while also enabling automated validation and real time testing of the data accessed. By experimenting with XBRL based approaches to managing internal data, companies could begin to benefit from the advantages of XBRL.

Conclusion

The benefits of XBRL use will not be realized overnight. There may be difficulties and delays in gaining benefits from XBRL implementation programs, but unless large entities begin to experiment with XBRL use, no benefits will be gain. In a Big Data era where decisions need to be made more rapidly, doing nothing is not a good strategy. By beginning to experiment with data management technologies like XBRL, the early innovators could gain tremendous market advantages which could disrupt existing business models. Companies have internal resources that understand XML but not XBRL. They also have internal resources that understand XBRL but not XML. By beginning to create internal data management communication opportunities with the key stakeholders in finance, internal audit and information technology, companies may begin to visualize ways of testing internal XBRL implementation models without expending a significant amount of capital. Discussions with external business partners (like customers and vendors) could also yield beneficial results. Finally insisting that existing application vendors imbed XBRL technology to their software offerings could allow companies better opportunities to utilize XBRL to their advantage.

XBRL is not a panacea, but there are significant benefits that may be gained through its use. These potential benefits include, but are not limited to:

Validation of data as its created

Identification of large variances

Elimination of data re-entry

Matching of amounts from different sources

Elimination of manual processes

Creation of standardized and automated user defined reports

Facilitating access to data for ad hoc use

There are significant potential benefits that may be realized from XBRL use due to its ability to define, relate and validate data. For these benefits to be better understood and utilized, companies will need to find ways to begin to test XBRL technologies internally. By taking action today companies may begin to find ways to free valuable human resources for higher value added benefits. In addition, the lesson learned from XBRL experimentation may lead to new ways of managing internal and external data as well as structured and unstructured data. How do you plan to benefit from the XBRL technology that you are forced to utilize for quarterly public reporting?

Related

All the points raised in this article are valid. However, there are still more skeptics of XBRL than there are proponents. And, I believe the majority of skeptics are winning out.

I have been a supporter of XBRL from the beginning and I agree with all of the comments brought up in the article. The major reason why XBRL is slow in gaining traction is due primarily on the lack of access to software.

As the article pointed out, XBRL is indeed open-sourced, but not everyone has access to the XBRL software. Software vendors are taking a page out of the typical accountant’s playbook: “Give me your paperwork and I will do all of the work”.

I have yet to get my hands on a descent XBRL viewer, let alone, a reliable tagging software. Until XBRL vendors truly allow access to their XBRL software, accountants will not be able to learn and develop competencies in XBRL, and XBRL adoption will continue to limp along.