Companies that have filed data-tagged quarterly and annual reports appear to be handling the task fairly well, even as the overall number of errors continues to pile up.

About 500 of the largest companies were required to use XBRL, or eXtensible Business Reporting Language, to tag data in their financial statements for periods ending on or after June 15, 2009. As of June 15 of this year, approximately 900 more companies had to do so, and the first group of filers additionally had to tag all amounts and tables in their financial-statement footnotes.

XBRL US — the consortium of accounting firms, software companies, and consultants that develops the taxonomy (or digital dictionary) for XBRL and supports its implementation in the United States — has not yet quantified the prevalence of mistakes by the year-two filers. But the initial group made thousands of incorrect tags in their year-one filings, and both XBRL US and the Securities and Exchange Commission say they expect that errors will continue to be commonplace in year two, when the number of elements required to be tagged increases from 300 to 3,000.

Still, to date there have been fewer errors than expected, and in year two companies are doing well at clearing up problems that cropped up in their initial filings, say both XBRL US and the SEC.

Using an automated tool called the XBRL Consistency Suite that detects many types of incorrect tagging, XBRL US has identified a total of 18,695 mistakes in about 3,400 filings, from both year one and year two, made through September 29. That number may seem large, but Campbell Pryde, chief standards officer for XBRL US, notes that the filings contain more than 1.6 million tagged facts.

But are the errors made so far enough to negate the chief purpose of XBRL, which is to enable investors to make company comparisons more easily? “There is definitely utility in the data,” says Pryde. “But for complicated analyses, such as might be done by hedge funds, the problems might start getting in the way.”

David Blaszkowsky, who heads up the SEC’s interactive-data effort, agrees that the tagged data is usable now. But there must be more of it before it can fulfill its potential, he notes, just as a CFO who had only a few quarters of data on competitors would find it difficult to do meaningful benchmarking.

Of the 18,000-plus mistakes XBRL US has quantified, approximately two-thirds are of one type: a negative value for an element expected to have a positive value (see table). Often that occurs when amounts appear in parentheses, such as when the intention is to show that a value subtracted from another value equals a third value. Companies are supposed to use a “negated label” to make positive values render in parentheses in XBRL-tagged financials.

The second-most-common type of error, of which there are five times fewer, is not reporting a required value, such as earnings per share or assets. The only other error identified in more than 1,000 cases is reporting a value for an element that should be zero or show as an empty space in a table.

The Consistency Suite doesn’t flag instances in which companies create extensions — tags for elements that are particular to a company — when an appropriate tag is already in the XBRL taxonomy. While the number of such errors is unknown, they likely are occurring much more frequently in the year-two filings, when filers are creating many more tags than they did the first year, says Pryde.

A company’s proclivity for error could be influenced by its approach to the tagging. The vast majority of year-one filers have been letting their financial printers do the tagging after financial reports are completed (the so-called bolt-on approach). But in their second year of filings, many switched to using report-writing software that builds the taxonomy mapping into the reporting process (the “built-in” approach.

The built-in approach is less manual, less costly, and more efficient than the bolt-on approach, says PricewaterhouseCoopers partner Mike Willis, a founding member of XBRL International (a global consortium to which XBRL US belongs). On the other hand, companies doing their own filings for the first time are more likely to encounter problems, says Pryde. Financial printers make errors, too, but since each applies its particular tagging process to all of its clients, each has common threads of problems. That makes it easy for XBRL US to point out the shortcomings and influence the printer to do things differently.

For Mary Hoeltzel, chief accounting officer at Cigna, which made its first quarterly filing with tagged footnotes in August, there’s no question that the built-in approach is superior — and for reasons beyond efficiency and cost.

First, Hoeltzel says, it’s simply preferable to “control your own destiny” rather than rely on a third party, and also a plus to really learn XBRL for yourself. Second, she’s looking ahead to a day when XBRL, currently just a compliance requirement for Cigna, could be used to make financial analysis more robust by tagging data in the general ledger.

But her most important reason for using the built-in approach is the turnaround time for financial printers to return the tagged filing. “You need to give them your report several days before your filing, and I just don’t have the luxury of that time,” says Hoeltzel. “I’ve got an audit committee meeting within that time frame, and if they want to make changes, I might have to change my tagging. We were better off learning how to do this ourselves.”

The software Cigna bought, from Clarity Systems, is easy to use, says Hoeltzel. It just takes time and effort: her team started the work to implement the detailed tagging in January for its August 5 filing of its second-quarter report.

Regardless of errors a company may make, it won’t have to worry about SEC enforcement for the foreseeable future. “At this stage, it’s not about rapping knuckles,” says Blaszkowsky. “It’s about working with filers to help them get it right and to make the process easier so that users [of financial statements] will have a better product.”

Correction: An earlier version of this article made references to specific XBRL software vendors that created a misleading impression about which software packages are most commonly used. Those references have been removed.