Attend almost any CPE conference and one will walk away with the perception that XBRL is an unnecessary evil. In fact, you will hear executives describe it as useless and even agents from the SEC, who don’t work in the Office of Interactive Data (OID), won’t be able to provide a good response as to the benefits of XBRL.

However, XBRL has come a long way since last year when it was described as painful. Invariably, changes and new ideas moving from being described as “painful” to “useless,” is very promising and represents progress.

In the next year, this perception of negligible use of XBRL data beyond the regulatory community will continue to change. By April 2013 nearly every public company reporting in the United States will have provided detailed XBRL financial reports for at least one year. Filers’ and regulators’ focus will change from ensuring everything is tagged to focusing on quality. In fact, the SEC has been commenting even more about the quality of XBRL filings and that will only continue to increase. The FASB regularly analyzes how the taxonomy is used and works with filers and service providers in improving the quality of the taxonomy and advising on how specific elements should be used. XBRL experts have learned a great deal over the last few years and are turning this into better taxonomies, software and processes, and suites of automated tests. Once we reach a critical mass of quality production of XBRL-formatted data and business user-friendly software that provides transparency of data, the perception of XBRL will change from “useless” to being an inseparable part of the reporting process.

Progress in 2012

This year brought significant efficiencies in the XBRL reporting process. While there are some service offerings and tools that continue to struggle with efficiencies and user experience, the majority of filers have had a significantly easier time with XBRL. This is due to experience, building time for XBRL in the close process, leveraging of existing tagged data, and software improvements. Some current software even makes aspects of XBRL document creation nearly as easy as authoring the visual document itself.

XBRL in 2013 and Beyond

2013 will be a big year for registrants and investors. The emergence of better consumption tools will provide flexible ways for viewing XBRL documents, but more importantly will also provide visibility into the underlying meaning of the data. In fact, the loudest requests for transparency and comparability come from registrants themselves. Filers want to know how they and how their reports compare with their peers; if they are using similar tags for similar meaning and how their respective extension elements align. New tools are going to readily provide useful answers to these important questions in this next year as the wide availability of both preparation and consumption software that makes creating and viewing structured data easy will continue to grow and improve.

Another improvement that will facilitate greater investor use is the continued improvement of the US GAAP Taxonomy. The XBRL developer community has learned a great deal as a result of dealing with what is considered by some the hardest financial reporting use case. Regulators, standards bodies and filers are all collaborating and succeeding in improving the quality of the US GAAP Taxonomy. In addition, there is work among industry peers to standardize their extensions and element selections rather than each having unique incomparable elements.

Moving forward, more consistent and leveraged use of taxonomy templates—focused on meaning rather than visual presentation of data—will serve to further improve the quality of information for analysis and consequently bring value to investors. Transition to structured digital financial reporting will help resolve another difficulty; that there are too many ways of representing the same concepts, and sometimes no apparent way of representing the obvious. The ultimate step that software and hence the conversation about XBRL will take, is to be focused on consistent models that express information, rather than simply expressing data.

On other fronts, XBRL is going beyond the SEC mandate for public filers and is percolating into other reporting domains. There are groups currently involved in developing XBRL taxonomies for the not-for-profit community as well as for state and local governmental reporting. The Global Reporting Initiative (GRI) Taxonomy brings comparability to Corporate Social Responsibility (CSR) efforts. The U.S. "DATA act" legislation continues to propagate structured digital data because of its clear benefits for reporting and transparency. We are now even seeing the use of XBRL for some internal corporate reporting.

In Conclusion

In the beginning of the Internet, most experts believed that it would only be used by those in academia. For those of us who searched the Internet in the early days, found it to be a novel idea but one that was painful to use and thus useless. We are still in the very early stages of XBRL but the ubiquity of XBRL structured financial data will eventually be met.

Attend any CPE conference in the future and XBRL will be the norm. As we progress throughout the next few years, tagging quality will improve, user experience will develop, and smart data will be inseparable from reporting. Get ahead of the XBRL curve as it will help separate data from information.

The integration, to represent the business reality

This reporting model is based on the integration capacity to represent the business reality through a set of indicator, understanding an indicator as a piece of information refers to a point in time or a period, in the past or in the future, to the company or to its relationships with its stakeholders, and can be framed, by its nature, in the financial, social, environmental or corporate governance field, among others.

Additionally, three levels of complexity of indicators are defined based on the relationship with the between the same or different natures: basic, composed and complex. It is in the composed ones, where it is combined indicators from the same areas and are expressed in relative terms once divided by a reference to its area (i.e. revenue for financial indicators) and in the complex, where it is combined indicators from different nature (i.e. financial vs. environmental). Fundamentally, the composed and complex indicators allow the comparisons between organizations and a high degree of interconnection between activity areas of the company; for example, it is possible to see if the path of sales growth is correlated with polluting emissions or job stability.

XBRL makes possible the correct representation of this integrated model, thanks of the dimensional tools and the Data Point Modelling practice, the indicators are defined as a pieces of information multivalued and it is through formulas implementation how the complexity is established, integrating the indicators using arithmetical rules.

The connection, to nurturing the corporate reporting ecosystem

The financial information that composed the Integrated Scoreboard is connected to the IFRS and Spanish GAAP financial frameworks, offering the entry points for the international reporting of the listed and small and medium-size companies, along the equivalences with this financial regulation, based on the correspondence with their financial statements.

In XBRL technical meaning, it means, for example, that the Integrated Scoreboard taxonomy contains the financial item supplier expenses defined equivalent to the items Raw materials and consumables used + Other expenses in the International Financial Reporting Standards (IFRS). Mainly, this is the connection meaning, one concept from a framework is equivalent in others frameworks.

XBRL gives the tools to make possible the connection capacity thanks of the formula specification to define the equivalences, nurturing the corporate reporting framework and enabled the use of existing financial information reported by legal requirement to complete the financial dimension of integrated reports.

The extension, to align with the solvency management

The Integrated Scoreboard is prepared to manage the risk information for the internal management, aligning it with the loss events defined as operational risk in Basel II, what it means, that the extension capacity comes from employ the COREP concepts, to dimension the risk management and enabled the companies to define their own risk, classified it by strategic objectives according to different natures, financial, environmental, social and corporate governance.

XBRL makes possible this extension capacity according to the XBRL 2.1 specification, offering the tools to aligning the integrated scoreboard with the existing frameworks in the XBRL landscape.

Early future:  towards the Corporate Reporting ecosystem

This is the way of the new Corporate Reporting generation, taking in consideration that the current reporting processes are driven by legal channels and the increased  interest and needs of the companies, in the value creation and transparency that may be considered valuable by diverse groups of interests.

The current and futures availability of financial, solvency and corporate frameworks supported in XBRL standard, make possible to think in this reporting ecosystem, based on the correct integration model through the ice meaning in XBRL and understand the Integrated Reporting as a possibility to anticipate as competitive advantage what tomorrow will be required by regulators.

iXBRL stands for  “inline” XBRL. “Inline” implies the XBRL is included along with the “printed paper” financials, which are filed in HTML. But that’s hard to grasp. So I imagined what else the “i” could stand for. Below I argue iXBRL saves time and money, iXBRL focuses only on the value-add of XBRL, iXBRL avoids redundancies and reduces error, and it can finally start improving the lives of the financial-data creators in the US. But let me start with the most important point; it looks like iXBRL is inevitable -- so let’s get used to it!

i for inevitable

iXBRL has been making XBRL headlines for awhile:

• open-source standard, 2 years of refinement from experts around the world
• successfully implemented in other regulatory agencies, like the UK’s HMRC
• abundant guides and resources, including video-conferences, samples, and Bob Schneider’s thoughtful primer

Current signs suggest iXBRL’s track-record is turning some heads in the US:

• industry experts like PwC’s Mike Willis recognize iXBRL is “increasingly the compliance format of choice”
• regulatory decision-makers, like the SEC’s Deputy Chief Accountant Mike Starr, have been polling XBRL producers to see if iXBRL is feasible
• current Deputy-Chief Accountant Susan Yount is collecting feedback directly from filers about whether iXBRL would reduce the filing burden

Many XBRL software providers are already iXBRL capable. And if iXBRL is implemented properly, consumers can get the same information as with XBRL. Given that US regulatory agencies are flirting with the idea and producers gain efficiencies with iXBRL, we have the perfect recipe for iXBRL adoption in the near future.

i for improve

iXBRL avoids duplication because the same value appearing in your “printed presentation” is tagged with helpful XBRL descriptions. Net income no longer needs to be expressed and cross-checked in separate XBRL and HTML files. Eliminating duplication will eliminate errors and save time. Moreover, it will reduce the number of SEC-Filing Exhibits needed to review.

With iXBRL samples so far, the consolidation of values and extra context into iXBRL eliminates the need for a standalone “XBRL instance document”, which is filed as separate exhibit. Financial data-users can still extract these values into XBRL-format for direct-processing (no costly middle-men.) Depending on the implementation of iXBRL, the 4 additional XBRL “linkbase” exhibits could be reduced to only the definition and calculation linkbase, or avoided altogether, as with the HMRC (who only requires one additional XBRL document -- the extended taxonomy.) That means the filer could review up to 5 fewer exhibits altogether.

Using fewer documents focuses on XBRL’s core value-adds:

• categorization -- using standardized Debit-or-Credit “accounts” to describe data
• clarification -- explicit precision and unambiguous negative values
• and context -- by date, by department, by geographic region, etc

...within a time-tested “printed document” presentation.

This also means the rendering engine could be retired -- XBRL doesn’t need to be “rendered” outside of its HTML. Looking at the HTML will suffice for many of today’s users. But with iXBRL, you can do more than just look! And tomorrow’s users are taking advantage of it.

i for impact

So how will this affect you? First, the benefits:

The AICPA has released guidance on XBRL review. If the presentation linkbase and label linkbase are omitted, then 2 out of 8 steps from SOP 09-1's Appendix D no longer apply. Without these linkbases, the “rendering” is impossible. No rendering means no redundant “tick-and-tie” procedures to check for “tagging completeness” as part of Agreed-Upon Procedures or SEC-recommended best-practices. No rendering might even mean better quality, because fewer filers will submit nonsensical XBRL for the sake of the often-fickle “rendering engine.”

Now, the bad news: Things will change.

Data-watchers like XBRL Competition-winner Alex Rapp, are still observing  “...a lot of companies following a two-step process.” I predict the shift to iXBRL will defeat the two-step processes, once and for all. The single iXBRL file must contain both XBRL and HTML, so filers who use a separate vendor for each of those should seeking iXBRL. The upside: fewer steps. Another upside: iXBRL enhances the structure and reviewability of the document you would’ve filed anyway. CFO’s may not appreciate redundant review inherent in today’s SEC XBRL implementation. However, the whole C-suite could benefit from some financial-account filterability, and value drilldowns. These financial-review essentials are available in free iXBRL tools, today -- and they’ll only get better. This bad news isn’t so bad, after all!

In summary, iXBRL is inevitable. How soon? It’s hard to tell -- I expect iXBRL will hit the sweet spot immediately after the last major XBRL-adoption hurdle: Wave 3 Detailed tagging, required June, 2013. But filers -- rejoice! iXBRL will improve your lives, and the impact is a win-win for producers and consumers. Stay tuned to Hitachi Data Interactive for more developments-- I think something big is on the horizon! What do you think?

Other resources for new learners:

iXBRL in GFM (Section 1.1.10, and 2.9)

http://www.ifrs.org/XBRL/Resources/Documents/GlobalFilingManual20110419.pdf

HMRC XBRL Style Guide

http://www.hmrc.gov.uk/ebu/ct_techpack/xbrl-style-guide.pdf

Inline XBRL Primer (1.0)

http://www.xbrl.org/Specification/inlineXBRL-part0/REC-2010-04-20/inlineXBRL-part0-REC-2010-04-20.html

Recent comments on an email listserv about Microsoft and XBRL got me to think about how early events shaped the financial communities response to XBRL.

Back in the 1990’s, accounting software offerings included the Denver based company FRx, which was acquired by Great Plains Software in early 2000.  Great Plains was subsequently acquired by Microsoft  in April 2001.  According to Wikipedia:

Microsoft FRx was created by the FRx Software Corporation in Denver, Colorado. The first FRx product was a DOS-based application that originally shipped around 1991 and integrated with Platinum DOS. A Windows-based version of FRx was available in 1993. FRx Software was acquired by Great Plains Software, which itself was purchased by Microsoft, where it was run as a wholly owned subsidiary. FRx was integrated with numerous general ledger systems.

The principal owner of FRx software, Michael Rohan and Rivet Software co-founder Emily Huang, started Rivet Software in 2003, long before Christopher Cox began the XBRL compliance era as chairman of SEC.  More on the Rivet Software connection below.

Microsoft was introduced to XBRL through the people who stayed with the FRx/Great Plains software acquisition.  One of those people was Rob Blake, who is now Product Director at Trintech, Inc.   Blake is fond of telling the story about introducing XBRL to Bill Gates and how he immediately “got it” after a short backstage XBRL conversation with Gates at a Microsoft product event.

Microsoft was a partner in the original proof of concept demo along with NASDAQ and PricewaterhouseCoopers. In a white paper published in 2002, it was revealed that the team built a rudimentary XBRL “engine” as depicted here.

The internal tool’s purpose was to allow Microsoft to be able to create XBRL for Earnings Releases and Ks/Qs.  While included in that white paper, it was included to simply show Microsoft’s XBRL expertise.  The actual Excel Investor’s Assistant, which came a bit later, did not utilize the tool shown above.

According to details in the white paper, the demo utilized the“ Microsoft® .NET framework and .NET enterprise servers, which enable information to travel seamless and securely between applications, Web sites and devices, we were able to rapidly implement XBRL. With no training or guidance, one internal developer was able to build our XBRL implementation in only 20 days.”

Microsoft spent internal resources working the tool until it came to a decision point in 2003.  At that time, Microsoft stopped development on their XBRL tool began looking for a software company to donate the software “for the good of the financial community”.  Several companies were looked at and Rivet Software became one of the recipient companies of the technology.  The tool was incorporated into the original Rivet Software Dragon Tag product which operated as a Microsoft Add-on to Excel.

The functionality of the Microsoft Add-on, called Excel Investor’s Assistant, was described in detail in the following Journal of accountancy article:  http://www.journalofaccountancy.com/Issues/2003/Jan/ANapsterForFinancialData.htm

And here: http://www.journalofaccountancy.com/Issues/2004/May/TapIntoXbrlSPowerTheEasyWay.htm

The Excel Investors Assistant was never meant to be more than a demonstration of the power of XBRL.  The functionality of tagging financial statements in XBRL came later.

The first company to leverage the Microsoft platform in a commercial application was Clarity Systems which is now a part of IBM Cognos.  Clarity Systems combined the Microsoft dot net platform, Microsoft Office and the Fujitsu XBRL engine into a user friendly tagging system that imported financial data directly into the tool.  This first generation XBRL tool paved the way for companies like WebFilings, Trintech, CompSci, EzXbrl and others who combine the XBRL tagging activity as an integral part of the close to file process.

In conversation with Microsoft back in 2003 they explained to me that the internal tool they created to assist in the production of earnings report and experimental 10-Q and 10-K filings, they were not in the business of creating and maintaining XBRL software.  They would, however, support and encourage XBRL software vendors who supported the add-on concept for Microsoft Office. While Microsoft offered some code from the original Microsoft Office Tool for XBRL (MOToX), Rivet did not incorporate any of into Dragon Tag.  Dragon Tag was built from scratch.

Today, using Excel after the close as the primary means to tag XBRL is virtually dead. Rivet Software has withdrawn support for the Dragon Tag line. Leading XBRL software companies such as IBM’s Cognos, WebFilings and Trintech have moved to incorporating the XBRL process as an internal integrated part of the closing to file process. The initial attraction of tagging a financial statement as represented in a spreadsheet such as Excel quickly fades when the process comes under scrutiny for accuracy and timeliness.

The Securities and Exchange Commission is looking forward to getting its first glimpse of an entire data set of XBRL detail-tagged annual reports when the smallest public companies begin submitting their first detail-tagged XBRL 10-Ks in early 2013.

At a recent AICPA conference session on XBRL, Susan Yount, an SEC staff member in the Office of Interactive Disclosure, said the SEC is expecting about 7,000 public companies, or 80 percent of all public companies, to submit their detail-tagged 10-Ks in XBRL for the first time with the close of the 2012 fiscal year. So far, the SEC has collected 35 million financial reporting facts from 63,000 filings since it required the earliest wave of public companies to begin submitting financial statements in XBRL in 2009.

Yount acknowledged that companies that are finding it difficult and time-consuming to submit their financial data in both XBRL and HTML formats. “Fortunately, there’s a solution to this problem,” she said. In-line XBRL would allow companies to embed XBRL tags in their HTML financial statements, although currently the SEC doesn’t permit such an approach. Yount said the SEC is exploring whether it should change its rules on that point, and it invites preparers to contact her office and state their opinions.

Yount said her office often gets questions about why the U.S. GAAP Taxonomy must be updated so frequently, forcing companies to study the 15,000 elements thoroughly each year for tag changes. She said the taxonomy is updated annually for changes in accounting standards and routine reporting practices that need to be reflected in the tags. Without annual changes to reflect changes in accounting standards, the Taxonomy would not properly map to the financial statements.

She warned preparers that the SEC will continue with a policy it adopted earlier to retire older, irrelevant taxonomies as newer taxonomies are approved, forcing companies to assure they are using current taxonomies. When the 2013 taxonomy is approved, which she anticipates will occur in early 2013, the SEC will remove the 2011 taxonomy, she said. “We continue to strongly encourage filers to transition as quickly as reasonably possible,” she said. To ease this year’s transition, the Financial Accounting Standards Board provided notes that help show where there are differences, she said.

Finally, Yount reminded companies about the importance of correcting common errors in their XBRL submissions. “Misrepresenting your financial results can lead to a failure in efficient market allocations,” she said. “That can lead to real harm to investors who are relying on your information.” The SEC has provided guidance in the form of interpretations, FAQs and staff observations to try to help companies fix their most common mistakes.

The last couple of years have witnessed an increased pace of adoption of XBRL as a standard for dissemination of financial and non-financial information in digital form across the world. Various regulators and government bodies are increasingly implementing XBRL for regulatory filings with the objective of improving business processes and bringing transparency in financial reporting. The increased adoption of XBRL and its potential to replace traditional formats of financial reporting raises important issues on the quality of information contained in “XBRL Instance Documents” and assurance over XBRL tagged data. Although XBRL is being implemented in various countries, the important aspect of quality assurance has not been given the attention it deserves. It is voluntary. However, the Ministry of Corporate Affairs of India (MCA) http://www.mca.gov.in/ has mandated the certification on fair presentation of audited financial statements in XBRL from accounting professionals.

Many companies that are currently providing information using XBRL, and accounting professionals certifying those XBRL financial statements, are doing so with limited quality assurance due to lack of appropriate guidance on quality. This poses a significant threat to the quality and reliability of XBRL tagged financial data for decision making purposes.

Common Misconception

Many people believe that merely passing the validation test of an XBRL Instance document with the validation tool provided by MCA implies that the XBRL Instance Document fairly presents the financial statements in traditional format, and meets the reporting requirements. Unfortunately, this is not true. The validation tool checks the requirements of taxonomy and business rules framed only. It doesn’t check the completeness, accuracy and consistency of XBRL tagged data with the source documents. Here are some examples of the instances that are not checked by the validation tool:

-       Completeness of all information in the XBRL Instance document;

-       Correct Mapping of a line item with the most suitable taxonomy element;

-       Disclosure of all facts mapped with the residuary tag by a foot note;

-       Accuracy of data which doesn’t affect the arithmetical accuracy of financial statements;

-       Accuracy of information contained in text blocks;

-       Arithmetical accuracy of data contained in multi-dimensional tables;

Importance of quality of XBRL tagged data

An emergent need has been felt to create awareness about the importance of quality of XBRL tagged data among the filers and accounting professionals because:

1)    It is the XBRL tagged data which will be consumed by the regulators, investors, investment analysts and other stakeholders for decision making purposes; and

2)    There is a legal liability attached to the XBRL mandate for the companies and certifying professionals for submissions of incorrect or false information/data in XBRL financial statements at MCA.

Part II of this article includes Learning from First Year XBRL Filings, Guidance & Standards on Audit of XBRL, and Improving the Quality of XBRL Tagged Data... Coming soon!

Continued from Part I here...

At the Financial Accounting Foundation, which oversees the Financial Accounting Standards Board, XBRL-formatted data is being used to conduct post-implementation reviews of certain accounting standards with the same basic objective in mind. Louis Matherne, who is the head of taxonomy development for FASB, said FASB also uses XBRL-formatted data to perform research the board needs as it considers and decides on new accounting standards.

And in a bit of circular improvement, FASB also uses XBRL-formatted data to upgrade the taxonomy. “We review how filers are using the taxonomy for current accounting standards,” Matherne said. “We will make adjustments in the taxonomy to capture their reporting practices so long as they conform to U.S. GAAP.

On the investor front, Matherne says FASB is shifting its focus on how to assure that taxonomy content is relevant and useful to the users of financial statement data. “We have shifted our resources to make sure we are engaging with and responsive to user needs,” he said.

Yount said some data aggregators have been faster to embrace XBRL than others. She wonders how long the laggers will hold out. “Those with an established process might consider that they do not need it, but then might someday find that they’ve been left behind by the advancement of technology,” she said.

Some data aggregators are telling the SEC that the financial statement information is only part of what they need to create the data that they disseminate, so they still have traditional work to do to gather in data from MD&A, business descriptions, liquidity disclosures and the like. “Looking forward to a structured data world, I wonder if, as users start to understand the real utility of having this information in a format that doesn’t need to be re-keyed and that is already tagged by the filer, they would find value in having more information available in a structured format,” she said.

That doesn’t sounds like a regulator who’s thinking about how to ease the burden on companies that are required to produce the data in the XBRL format. But it does give the SEC all the more reason to think hard about whether’s appropriate to continue to require companies to report in two separate formats -- plain text and structured data -- simultaneously. The SEC has said it is considering allowing companies to file their financial statements in a single structure-data version. Perhaps the time has come to at least give companies that option in case they would see it as a way to potentially reduce the burden.

Alex Rapp, co-founder of Calcbench, is working with his partner, Pranav Ghai, to put the finishing touches on the company’s open-source application intended to enable consumers of public company financial information to use and analyze data provided through XBRL. Calcbench won the inaugural XBRL Challenge award earlier this year based on the strength of its user interface and analytics, which allow users to perform multi-company comparisons annually and quarterly.

Can you give us an update on Calcbench?

We built this platform, and then we quickly realized it had some shortcomings in structuring data across multiple companies and industries. So we stopped working on the front end and have put in a tremendous amount of time working on the back end -- the way the database works, how it normalizes data points, how it catches errors and fixes them automatically. It has some pretty cool artificial intelligence things going on. There are a number of process that help catch and fix errors.

Recently we’ve turned our focus back to how people can use all of this cool stuff that we’re working on. We’ve made some improvements to the speed of the website, and we are building benchmarking tools. This is a new way to access information, compare information across industries and companies, and do valuations. It will also allow users to spot trends and to do some benchmarking and economic analysis. It will be fairly basic at first, but it will build and grow over time. We are hoping to launch it in the next few months.

How are consumers of XBRL data using that information now?

Well, that’s the thing -- there aren’t that many choices. You can bring the instance documents on to your desktop yourself, but that’s a waste of time really. You might as well just use the paper documents. We want to provide two different entry points -- a company-specific entry point where you can look at a company in detail, and then an industry or sector. You want to benchmark against other companies or a peer group. That’s the stuff we’re working on now. That’s the work that a lot of people are currently doing by hand.

Investors aren’t really going to use this for investment decisions until it contains three-plus years of history. One year of data in XBRL doesn’t do them much good, but it’s very useful for other purposes -- for people who are doing trend analysis or benchmarking. There’s a lot of information in there that’s very valuable, but we can’t expect every individual to understand how to use it just yet.

You’ve said you spend a lot of time correcting errors. What kind of errors do you see most commonly?

We’re fixing thousands of errors, some automatically and some by hand. We see cases where companies have their entire universe of numbers off by 1,000. It’s a scale error. They’re accustomed to truncating for presentations, but when you create an XBRL filing you don’t do that. A lot of the errors we see are not significant, but some can be very complicated. Sometimes we don’t even know for sure what the intended scale was. Take share counts, for example. It’s ridiculous how many companies get their share count wrong. It’s a little unsettling.

It’s also a schematic problem. There are still a lot of companies following a two-step process. They go through their usual close and filing, and then they hand the paper to someone, often a contractor, to be filed in XBRL. Hopefully that changes over time and people start making the XBRL filing part of the filing process. I’m pretty sure that extra step is the cause of a lot of these mistakes. Preparers just need to double check their work. The Securities and Exchange Commission will eventually lose its patience with these kinds of things.

Susan Yount

The Securities and Exchange Commission is generally pleased with XBRL compliance so far, although its patience for the most common mistakes may be wearing down now that the phase-in period is complete.

Susan Yount, associate chief accountant in the SEC’s Office of Interactive Data, is the heir apparent to Mike Starr, deputy chief accountant who until recently served as the point person at the SEC for everything XBRL. Starr left his position to return to practice with an XBRL services providers. Yount recently answered some questions about the SEC staff’s impressions of XBRL compliance and how it uses XBRL-formatted data, now that the SEC has received more than 50,000 XBRL filings containing nearly 30 million financial reporting data points.

“It’s clear to us that filers and service providers have, for the most part, taken compliance with this rule seriously,” she reportedly said. “One thing I’ve been surprised about: there still seems to be quite a few rumors making the rounds about how to comply with our rules. Some things we hear are just odd.” As an example, she said some preparers are confused about whether calculation link bases are required (they are!) and that passing he EDGAR validation is the only step required to assure an XBRL-compliant filing (it’s not!).

Yount said the staff often hears that the initial tagging was time-consuming and the learning curve was steep, but the staff also hears that subsequent filings are easier and the costs are generally coming down. “At the start of the phase-in, I wondered if a full three years was really necessary,” she said. “But smaller filers really seem to benefit from maturing software and the experience of early filers.”

Generally, the staff is pleased with the filings it has seen so far, said Yount. She is still perplexed, however, by mistakes that persist even after the staff has made numerous attempts through guidance and Q&As to correct problem areas. For example, companies are still struggling with how to present negative values (don’t use a negative sign, just read the definition in the taxonomy!) and using extensions where they aren’t necessary (search the taxonomy again for an appropriate tag!). “I find it confusing that these errors still exist since we’re more than three years into this process,” she said.

Yount offered a subtle suggestion that the SEC’s patience may be wearing thin. “Now that the phase-in is complete and limited liability is ending, and regulators and investors are starting to use the data, this would be a really good time for filers and their service providers to review that guidance and make sure they’re not continuing to repeat those errors,” she said.

Ease-of-use

I think the SEC’s choice of “line number tagging” makes the XBRL harder to use– harder to analyze. Am I contradicting myself? Earlier I said it was easy to go from the tabular format of the SEC rendering, to a powerful PivotTable. That’s true. But it’s even easier to go from the XBRL raw data as seen in my sheet, to the PivotTable as seen in my sheet. I don’t need a “rendering” in the middle. I used a free tool called XBRL Add-On, which creates the pivot-tableinstantaneously on opening the XBRL instance document.  Many XBRL-viewing tools do this, today. This includes XBRL Cloud, Magnify, and others (I’m sure). Since the PivotTable is “built into” the XBRL,  I can immediately arrange the axis like I want, or export to a spreadsheet software to do the same.

If I wanted to analyze the SEC’s tagging in the form of a PivotTable, I would have to build extra software, or go through the “extra step” of the rendering in the middle. I also refer to this “line number tagging” as “inference” tagging (above) because the data-user must infer that values on the same line, are related. Inference can be dangerous, but I don’t think there’s much risk here. However, inference is extra, unnecessary work for the data-user; i.e. harder! This defeats the purpose of XBRL.

Inconsistency

The SEC doesn’t only use this “line number tagging”. After all, as I mentioned above, my spreadsheet is the “raw XBRL data from the SEC Instance Document.” Indeed, the SEC uses “dimensional tagging” for some values. These are the values you see in the resulting PivotTable.

Green (column) is subtotal across Projects, Blue (row) is subtotal across Countries/Governments, but Yellow (intersection) is missing! 

• The value highlighted in green (also $7,000,000) represents the Fees, paid to Canada’s Quebec Minerals Management, for all Projects.
• And the value highlighted in blue (yet another $7,000,000) represents the Fees, for the Anticline Miscible Project, for all Countries and all Governments.

These data were tagged in the “dimensional tagging” style. This is the standard and correct way to tag. It qualifies the data with its relevant aspects. It uses these “Country” or “Project” aspects the way XBRL Dimensionsprescribes. Dimensional tagging is the correct “syntax” to represent this pivot-table “semantics”. After all, that’s why well-built XBRL Software can make the Pivot Table instantaneously; that’s why this flows seamlessly into a [Google] Spreadsheet. That’s why I canskip the written/printed form (with their “line numbers”) and start making insights directly. So the inconsistency with the “line number tagging” is twofold:

1. It is inconsistent with “dimensional tagging”, which is the standard and correct way to tag. In the context of the standards, the patterns, and all observed XBRL, this Form SD XBRL is nonstandard.
2. And it is internally inconsistent, the SEC tags some values with “line number tagging” and other values with “dimensional tagging” in the same instance document.

• Incidentally, it seems like the SEC chose the “line number” style of tagging to express theindividual datapoints; notice how every row in their rendering has specified which Country, Project, and Government relates to each number. The very first row gives us the value I highlighted in “yellow”.
• But the SEC chose the “dimensional” style of tagging to express the subtotals/sum of these datapoints by aspect; notice how the only row with data is the “All Governments, All Countries” row (the value in blue), and the only column with data is the “All Projects” column (the value in green). Notice how yellow (cell E2) is the intersection of the green row (2) and the blue column (E).

This is especially backwards because, PivotTables will figure out those subtotals for you! If you have the individual datapoints, then a PivotTable can sum or average this data across any aspect that is meaningful for you. If you tell a computer, with “dimensional tagging”, that $500 was paid to Canada for Project 1, and $700 was paid to Canada for Project 2, the computer can tell you that $1,200 was paid to Canada for all Projects.

But if it’s provided the subtotals, the PivotTable has no idea how to get to the individual parts. If you tell a computer with “dimensional tagging”, that $800 was paid to Ghana, the computer has no idea how much was paid for each Project, and neither will the data-user.

Hence, “Missing Data”

“Missing Data” is an exaggeration; we noted that the SEC’s tagging did report the data I’d want (with “line number tagging”); it’s just non-standard and inconsistent, so it’s much harder to analyze. If the SEC corrects this, it will simplify the process for XBRL creators, and speed up consumption and analyses of the XBRL data. Isn’t that the point of Form SD? Isn’t that the point of XBRL?