Making the Case for Inline XBRL
by Diane Mueller, Chair, XBRL International Technical Working Group on Rendering

Web 2.0 technologies like XML, web services and social networking have taken off like wildfire and have caught many accounting professionals off-guard. The accounting profession only recently put down their pens and made the move from paper to spreadsheets and electronic forms for processing and visualizing financial data.

With Accountants and regulators alike require a visual representation of the financial reports before approving their release or attesting to the authenticity of a financial document. There is an almost gut-level need harkening back to the days of the abacus and stone tablets to an almost instinctual need to touch and see the numbers in order to believe and trust in their authenticity.

Both preparers and consumers of business reports work with human readable documents containing a very broad range of formatting decisions. Some of these formatting decisions — such as presentation order of the information or accessibility — even have legal ramifications. There is still a clear need to be able to refer to the “hard copy” — even where the “hard copy” refers to an on-screen document.

Professionals responsible for the production and dissemination of business reports are generally concerned that the information they release is carefully formatted. Accounting documents (particularly financial disclosures) attract special attention from preparers, auditors and securities regulators. The manner in which the reports are formatted — from ensuring that figures are correctly aligned, to making sure sub-totals and totals are suitably emphasized all the way through, to considering the font-size of footnotes — is important. Individual preparers have different preferences and these, too, need to be taken into account.

On the other hand, computers and consuming applications of financial data prepared by accountants care very little about the visual representation of the incoming content. Computers are only concerned with number-crunching, comparability, searchablity and further processing of the data. Most consuming applications have alternative visualizations of financial data in mind rather than the staid financial statements prepared lovingly by the accountants. Dashboards, charts and graphs, and 3-D representations of complex models fed by streams of financial data from multiple sources are the charge of consuming applications with distribution to multiple channels — mobile devices, browsers, desktops and just about anything with a display screen that hosts a picture rather than a financial report.

Why Do We Need Inline XBRL?

With the widespread adoption of XBRL (eXtensible Business Reporting Language) as the de-facto standard for delivery of financial data, a clear design issue quickly became apparent — XBRL instance documents contain well defined facts but no formatting. XBRL was designed to support the machine-to-machine transmission of financial data, and as such, has succeeded beyond its originators’ wildest dreams with adoption moving forward on a global scale.

The XBRL technical community assumed that the accounting and regulatory community would move more quickly to a world view that ‘trusted’ machine-to-machine transmission — letting go of this seemingly archaic need to “see” some form of visual representation of a financial report for review prior to submission to regulators or publication to shareholders.

However, early on, there was a push from both the accounting and regulatory communities to publish XBRL-tagged financial and business information for display in situations where the producer wants to preserve a specific visual presentation of the information. This is necessary because the order and presentation of the information can often have legal interpretive ramifications for the consumers of that information.

It became necessary to create an extension to the XBRL 2.1 standard to enable the machine-readable data to co-exist with human-readable formats. Inline XBRL was developed to make it possible to deliver structured, machine-readable data inside a human-readable rendering of the data.

It is easier for software developers — especially accounting software vendors — to create reports in HTML, the universal language for web browsers, and add hidden metadata which can be used to construct a machine-readable copy of the same information.

Inline XBRL makes it possible to extract an XBRL instance document on demand. This means that the technique makes it feasible for regulators, exchanges, banks and others responsible for the collection of business reports in XBRL format to ask preparers to merely submit their information as an Inline XBRL document. This is a human-readable XHTML file that can be stored and redistributed in this original format. At any time, an XBRL instance document can be extracted from the XHTML document, validated and passed on to relevant analytical and consuming applications and processes.

This means that vendors need only work out how to create XHTML documents and can adapt their existing report rendering capabilities to format business reports. The Inline XBRL specification defines the syntax for such documents and describes how the syntax maps into an XBRL instance.

Inline XBRL in Action

Recently, a normative stylesheet was developed by the XBRL International consortium as an implementation reference and released on SourceForge as an open source project. The stylesheet enables users to reliably and predictably strip out the unstructured information from the XHTML, then extract and create a valid XBRL instance document. This approach to financial content delivery is simpler, provides more control and flexibility in report formatting, and can be fairly easily implemented. The extracted XBRL instance document is now machine-readable and is fully compliant with the XBRL 2.1 standard for use by regulators and other consumers of financial information. The recently released project can be found on SourceForge at http://sourceforge.net/projects/inlinexbrl/.

The first large-scale use of Inline XBRL is being rolled out in the UK as the outcome of communication minister, Lord Carter’s Report’s recommendations to make the use of XBRL for online filings mandatory. The HM Revenue & Customs (HMRC) is rolling out a phased implementation for Tax Computations and Accounts (CT600 filings) as part of the its annual self-assessment regime for Company Tax reporting. By 2012, all filings will be online and using Inline XBRL.

Inline XBRL addresses XBRL’s rendering issues by putting it back in the hands of the producing applications — where it belongs. Currently, production applications control layout, look and feel, and branding for paper, web and PDF output. Why should XBRL be any different? With Inline XBRL, both preparer and consumer are guaranteed the same rendering when either party views the document in any browser. To find out more about Inline XBRL, please visit http://www.xbrl.org.

###
Diane Mueller has been actively involved in the development efforts of the XBRL standard for the past decade. She is the Canadian representative to the XBRL International Steering Committee, serves as Vice Chair of that body, and chairs the XBRL Working Groups on Rendering and Software Interoperability. She currently serves as vice president of XBRL development at JustSystems, the largest independent software vendor in Japan and a worldwide leader in XML and information management technologies. Learn more about JustSystems at http://www.justsystems.com, and contact Diane at diane@justsystems.com. You may also follow Diane on Twitter at @XBRLspy.