The federal government has a hard time keeping track of its money -- especially money that goes from one agency to another. In fact, agencies often can't agree on how many dollars they transfer among themselves. Year after year, the Government Accountability Office declares intragovernmental transactions a material weakness in its annual assessment of federal finances.
This is one reason Samuel Mok, chief financial officer for the Labor Department, wants his colleagues to adopt a standardized way of exchanging financial data. It's called Extensible Business Reporting Language (XBRL), and now is the time to initiate it, Mok urges. Many federal agencies are updating their financial systems, so they're well-positioned to adopt new technologies. But Mok recognizes that educating people about XBRL's benefits can be difficult. "It's not a software, it's not a hardware, it's not a programming language; it's a new concept," he says.
XBRL is metadata. It's data that gives context to data. Any two numbers of the same value are alike, except when they're placed in a context. Human beings naturally look for wider meanings -- wanting to know whether a particular number refers to net profit or net losses, for example. Computers are terrible at context. By themselves, they never know whether a number represents gains, losses or cuckoo clocks. Which is where metadata comes in. XBRL is an invisible tag virtually hovering behind the numbers in a database. It tells machines in their language what the thing being counted is, why it's important and where the data comes from.
Metadata is transferable between software programs, too; XBRL is an open standard managed by a nonprofit consortium, XBRL International in New York. "Open standard" means that data from one proprietary software program can transfer automatically to another software program. Without metadata, that process is difficult, if not impossible. The government spends a lot of money massaging financial data before it's ready for analysis -- a wasteful and mistake-laden process, Mok says. Accounting and timing errors are among the reasons the government has such a hard time reconciling intragovernment transfers.
When federal agencies start transmitting their data in XBRL to the Office of Management and Budget, the Treasury Department and to each other, "There will be savings, and I'm also convinced it will reduce errors," Mok says. The financial sector spends up to 80 percent of its processing time merely whipping data into shape and only 20 percent doing actual analysis, according to New York-based PricewaterhouseCoopers. XBRL can flip the ratio around, the company contends.
There are hurdles to adoption, however. XBRL has existed as a metadata specification since 2000, but the private sector hasn't rushed to embrace it. So far, only nine companies have signed up for a voluntary Securities and Exchange Commission program created in 2005 allowing submission of annual financial reports in XBRL.
XBRL is difficult because it requires common definitions for data elements. A seemingly innocuous task, it actually provokes what veterans of metadata fights call "religious wars." And assuming everybody concurs on a catalog of data elements, organizations must manually map their pre-existing data definitions to the new XBRL definitions. Metadata also just about doubles the size of data, although that's less of a problem than it once was since storage is so cheap these days.
Proponents acknowledge that metadata has upfront costs but say that maintaining the status quo is more expensive. Still, it's notable that the nation's largest implementation of XBRL has come about at the behest of a regulatory agency with the power to demand adoption, rather than ask for it. The Federal Deposit Insurance Corporation, the government's banking watchdog, now requires all banks to submit their quarterly balance sheets, or call reports, in XBRL.
The FDIC says it managed to avoid heavy disagreement over the definitions in its XBRL taxonomy partly because call reports already were a well-defined data series. But, "This was a luxury that not every potential XBRL project has," notes Martin Henning, the agency's XBRL project manager. Individual banks also did not take part in the definition phase. "From the banker's perspective, the use of XBRL is built in; they don't even know they're doing it," says CIO Michael Bartell. The metadata is embedded on the back end of the software programs that banks use to prepare call reports.
In the banking industry, at least, the brave new world promised by XBRL is apparent, FDIC officials say. Agency analysts used to spend a great deal of time checking numbers; now XBRL does it for them. Reports requiring manual review are down by about half, and the agency is releasing its quarterly bank profile reports weeks earlier.
The benefits aren't just for bureaucrats either, says Walter Hamscher, a key architect of XBRL, now a private electronic commerce consultant. With better data processed more quickly, "The reduction of the overall risk and uncertainty in the market around those banks and around lending is a dramatic difference," he says.
This is where Mok sees perhaps the biggest advantage of XBRL, from a chief financial officer perspective. Government CFOs, he has long argued, have failed to make themselves indispensable to agencies' missions. "We are really just compliance officers," he laments. The proper place of a CFO is inside the decision-making process, he says. But Cabinet secretaries mostly make important decisions without the CFO at their side, in large measure because most government financial data "is a lot of gobbledygook," Mok says.
"XBRL will make the information more uniform, more useful and, at the same time, more accessible," he says. Mok's model of government XBRL adoption would be voluntary, however. If people can be shown it's good, they will ask for it, he predicts. But for now, government isn't quite at the tipping point. Without guarantees of good results, it might take some nudging and coaxing to gather a critical mass of federal XBRL adopters.