Standard issue

It can be safely said that the panacea of standardisation in the technology
world is even more of a pipedream than it is in the accounting world.

The history of business application development has been one where individual
vendors went their own way and did their own thing. No one spent any time
looking over their shoulder wondering how competitors were writing code. The aim
of the game was for each vendor to corral their own stable of users and
interoperability of systems was nowhere on the agenda.

The cost to business of this individualistic approach to systems development
has been enormous. Every time a company thinks about acquiring another, for
example, the acquiring management team and its funders have to work out the
likely costs of integrating the two organisations’ IT infrastructure – and in
many instances, IT incompatibilities can demolish the business case for an
acquisition.

The problem of incompatible systems also impacts companies who want to
collaborate by sharing information on their IT systems. One thinks here of
manufacturers and suppliers in a supply chain. Unless they each use the same
version of the same vendor’s systems, before they can collaborate they first
have to figure out how to transfer information between their different IT
systems.

However, if standardisation was simple we would not have the mess of
incompatible systems we have today, and large organisations would not have to
spend millions on technology integration exercises. Instead, the IT sector would
have come up with a “nice, simple” standard way for all applications to talk to
each other and the problem would be solved.

XML standard

In fact, the sector is in the process of solving this problem through a
standards-based approach. The standard in question is XML, or Extensible Markup
Language (see box), but agreeing and implementing the standard is a laborious
and time-consuming process and we are not anywhere near the end of it yet.

One of the main thrusts pushing businesses and IT vendors in the UK to adopt
XML is coming from HM Revenue and Customs. As Dennis Keeling, chief executive of
the Business Application Software Developers’ Association says, the government
is enthusiastic about online filing of company reports for corporation tax
purposes.

The government is very keen to have all accounts, whether they are corporate
or individual, filed electronically and it wants the numbers in those electronic
documents to be machine readable. At a stroke, this will cut out the need to
re-key and allows all kinds of machine-based analysis and checking of accounts
to take place. The potential savings for the government are enormous.

Lord Carter of Coles recently completed a report for the government into the
online services of HMRC, where he looked closely at XML as the mechanism for
enabling online filing. As a result, he has recommended that for returns due
after 31 March 2010, all companies should be required to file their company tax
returns online using XBRL, or Extensible Business Reporting Language, an
XML-based format for financial reporting.

XBRL is being developed by an international, non-profit consortium of
approximately 450 organisations and already there are numerous implementations.
The basic approach is to provide a computer readable identifying ‘tag’ for each
individual item of data. An example would be company net profit, which would
have its own unique tag. Financial data is transformed into XBRL by suitable
mapping tools or by appropriate software.

Mixed opinions

But despite the government’s enthusiasm, there are still differences of
opinion over the benefits that XBRL can bring in the business world. Both the
Financial Services Authority and the US Securities and Exchange Commission
embarked on wide-ranging XBRL projects. However, while the FSA decided to shelve
its plans for regulated companies to report using the language due to a lack of
interest, the SEC is taking a more proactive approach and firing ahead at full
speed.

As recently as May this year, SEC chairman Christopher Cox put his weight
behind the reporting language in a speech before the Congressional Committee.
“Interactive data is a concept that I know has been of long-standing interest,”
he said. “Bill Donaldson, my predecessor at the SEC, also saw the promise of
interactive data and got the ball rolling by launching our internal efforts to
investigate the technology.

“Under his watch, we launched the XBRL voluntary filing program. I, too, see
the promise and potential that this concept holds for consumers of financial
data, particularly individual investors and believe that it will someday soon
transform the way we as individuals interact with information about our
investments.”

Although XBRL has been mandated by Lord Carter as the format for delivering
accounts for corporation tax purposes in future, there is a real problem with
it. The source of the problem lies in the enormous number of ways in which
companies can define their chart of accounts. As Keeling notes, charts of
accounts change constantly even within the same company from one year to the
next and no two charts of accounts are the same. It is one of the fundamental
reasons why FSA-regulated companies did not enthusiastically adopt the standard.

“Unfortunately, those responsible for the XBRL standard have chosen to tackle
this problem by defining a vast library of taxonomies of possible items of
charts of accounts. Since businesses have to take on the task of mapping their
present chart of accounts to XBRL tags themselves, it is just too difficult to
do and the project has stalled. The result is that very few people use it for
financial reporting,” says Keeling.

Lord Carter has tried to overcome this by suggesting a more limited subset of
about 100 chart account headings for corporate tax filing. Companies House has a
project underway where dormant companies, can file today using XBRL. The project
is going to be extended to embrace small companies, which do not need to be
audited.

It is important to stress that XBRL, as the name suggests, is about business
reporting and is not designed to be an e-commerce transaction-enabling language.

Universal acceptance

There are already several XML variants of electronic commerce languages, but
thankfully everyone seems to have thrown their weight behind what’s known as the
Universal Business Language (UBL); a standard developed by the US-based
Organisation for the Advancement of Structured Information Standards (OASIS).

Ken Holman, chief technology officer of the US consultancy Crane Softwrights,
has been involved with the UBL standard from the beginning. “The whole point of
UBL is to come up with XML document models with which businesses can express
their transactions,” he says.

UBL has so far described seven key documents, including things like an
invoice, a sales order and so on. It is then a relatively simple matter for
accounting and e-business software vendors to adapt their applications to
recognise and to output UBL-conformant and machine-readable documents.

The UBL committee is currently developing version two of the standard, which
will define around 28 documents, providing a wide suite of e-capable and
universally compliant documents that will enable companies to transact just
about any business they want on-line.

“There is a real parallel here with HTML,” says Holman. “In the web world
there were many experts in hypertext in the early days who said that HTML was
far too unsophisticated to express the world’s needs. But the World Wide Web
Consortium (W3C) standardised a vocabulary for hypertext and it is now the
standard for the Web. People who have a problem to solve can adapt their
solutions to a system that is standard and easy to use – this is what UBL is
going to do too,” he says.

Holman points out that Denmark is the first country to mandate the use of
UBL. Anyone wishing to send the government an invoice has to submit a UBL
document. Other countries in Scandinavia are now considering taking similar
steps.

For Holman, a standard like UBL is an enabler, not a suppressor of initiative
(one of the common criticisms of standardisation efforts is that they dumb down
a solution and suppress innovation). For Holman there is nothing in UBL that
stops an accountancy software vendor, for example, from being innovative where
it counts. But no one wants them to be innovative to the extent of trying to
reinvent what it is that an invoice does or how it should be described to be
“machine agnostic”.

And machine agnostic really is the panacea of IT as far as business people
are concerned. Or, in other words, being allowed not to worry about it.