TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Business Friendly Reporting via XBRL: It is Not Just a Pipedream

Wouldn’t it be great if there were an open, extensible business reporting language? The good news is that such a standard already exists. Sort of.

• By Stephen Swoyer
• January 3, 2007

Pssst: Wouldn’t it be great if there were an open, extensible business reporting language? The kind of thing that could help standardize things such as basic ledger transactions, accounts receivable (AR), and accounts payable (AP) for all companies everywhere? And wouldn’t it be better still if a standard of this kind—a pipedream of this kind?—was flexible enough to support reporting requirements for a range of different business processes and activities, outside of the financial loop? The good news is that such a standard already exists. Sort of.

That’s the raison-d’etre of the eXtensible Business Reporting Language (XBRL), an XML-based standard which provides a common means to define and exchange business and financial performance data. It’s the scion of the not-for-profit XBRL International Inc., a consortium of approximately 450 organizations, in almost every country, that is working to develop taxonomies which define the information exchange requirements for common domains.

Proponents champion XBRL as an open, flexible solution which can replace legacy financial data collection methods, including not only paper-based, but also proprietary reporting systems, too. XBRL already has traction, to some extent: in the United States, the Securities and Exchange Commission (SEC) is sponsoring a pilot program whereby organizations can opt to use XBRL to report financial information. The Federal Deposit Insurance Corp. (FDIC) also mandates the use of a form of XBRL reporting (which involves XBRL taxonomies) for quarterly financial statements, or Call Reports, from more than 8,000 U.S. banks.

Elsewhere, XBRL figures prominently in the Netherlands, where the Balkenende government is currently spearheading an effort to promote the use of XBRL for private and public sector reporting alike.

It’s the latter use case—or, rather, the sheer scope of the latter use case—that might cause enterprise BI professionals to sit up and take notice.

Because even though XBRL itself is championed primarily as a means to standardize and open up the reporting of financial information—admittedly a niche-use—a subset of the XBRL standard, or XBRL General Ledger (GL), has much greater potential applicability, at least for enterprise users.

"XBRL GL is in many ways far more relevant to [BI professionals] than traditional XBRL—which focuses on end reports—as it is a standardized, generic and holistic way to represent the business facts that flow from transactions and business events," says Eric Cohen, XBRL Global Technical Leader with PricewaterhouseCoopers (PwC).

Cohen has a dog in the race, of course: he’s XBRL GL’s creator and chief architect. But—because it starts with generic representations of business documents (such as orders, invoices, and checks)—he says XBRL GL provides a single framework for representing data as it flows from system to system.

"The goal [is to have] a seamless audit trail for financial reporting, tax reporting, statutory and statistical reporting, and management reporting," Cohen continues. "It is not just about accounting and tax, but also about operational and business information." Nor does Cohen hold up XBRL GL as a replacement for conventional (data warehouse-driven) reporting: instead, he says, XBRL GL can complement or facilitate to an even greater degree the use of DW-driven reporting schemes. "[It can standardize] the flow of data into data warehouses, and [standardize] the flow of data from the data warehouse," he points out.

Nor is that all, says David vun Kannon, a director with PwC’s Financial Services Advisory practice. Vun Kannon has been involved with XBRL "since the very beginning"—1999—and has helped edit every version of the XBRL spec. He’s currently a member of the XBRL Standards Board, which helps chart the overall technical direction for the XBRL consortium's work.

PwC’s internal work with XBRL does not conform to common or traditional use cases, vun Kannon acknowledges. In this sense, he argues, it’s a textbook example of the flexibility and adaptability of the XBRL standards.

"Since PwC doesn't report its financial statements—it's a partnership --our internal uses are non-conventional," vun Kannon explains. "We use XBRL toretrieve data about public companies as part of our due diligence onclients—what we call acceptance and continuance." In addition, he explains, PwC is exploring ways in which it can embed XBRL in its own core audit processes: with the ultimate goal being the use of XBRL-enabled platforms to power PwC’s primary, multi-billion dollar accounting business.

PwC currently advises its clients to participate in the SEC’s XBRL Voluntary Filing Program; it also champions the use of XBRL for compliance processes. In the latter case, there are already several products which integrate financial and compliance reporting in XBRL, vun Katton says—with more on the way.

The key takeaway, he argues, is that XBRL—or any of its associated subsets, including XBRL GL—has the potential to become pervasive. And once it achieves pervasiveness, its flexibility could drive it deep into the enterprise.

"It can be used for operational reporting, KPIs, feeding dashboards, ‘triple bottom line’ or social responsibility reporting, and even multi-dimensional reporting—as in Basel II compliance processes," vun Katton indicates

This is in spite of the fact that XBRL—at this point, anyway—is still seen mostly as a tool for accountants. This could and should change, proponents argue. "[A]lthough it was primarily designed for financial reporting and basic information in the business reporting supply chain, [XBRL] … [comprises] a formal framework for not only describing areas of business reporting, but also [for] defining it," says XBRL GL architect Cohen. "XBRL provides for the association of human readable labels and definitions, links to authoritative and practical references and guidance, presentation and calculation relationships, and emerging business rules and formula definitions."

There’s a further wrinkle here, too, says Cohen: Just as XBRL promises to bring additional openness and some degree of standardization to the financial reporting process, it can also inject some degree of control into the often haphazard state of business process reporting. "The vision is that spreadsheets and programs won't need to have their data and formulas [or] macros built-in, but available instead from centralized and more auditable [and] controllable sources."

In this respect, Cohen continues, XBRL GL can function as a generic tool to provide drill-down details from any report, or as a bridge from transactions to reports, serving—in the process—as a standardized data consolidation, migration and archival tool for operational, business, and accounting data. "XBRL GL can capture information related to business metrics and processes. It is certainly my hope that XBRL GL will help facilitate the flow of all manner of data to XBRL supporting end reporting in and out of the financial loop," he concludes.

That being said, XBRL isn’t a silver bullet, vun Katton concedes: it isn’t at its best when used with time series data, for example. "XBRL 1.0 was [okay] for that use, but 2.0 and 2.1 are biased towards reporting many facts at a single point in time instead of a single fact at many points in time," he acknowledges.

Many reporting and performance management vendors are also represented in the XBRL consortium: Hyperion, Oracle, Microsoft, and SAP, just to name a few. And while proponents are working feverishly to foster the adoption of a widely implemented standard that allows for the exchange of data between and among disparate systems—from Hyperion to SAP to Oracle and back again—the reality, for now at least, is somewhat more sobering.

"We are still a long way from people choosing to use XBRL to transfer data from SAP to Hyperion, instead of Excel and CSV files, but awareness of the SOX compliance issues around using Excel in the financial reporting process may change that," vun Kannon says. "Certainly, more needs to be done!"