XBRL at the crossroads: Dodo or the future of financial reporting?

The commercial viability of developing XBRL compliant software seems yet to be proved at the volume end of the market, where pressure on licence revenues is the highest. That is not to say XBRL is not being catered for in other parts of the market. For example, Oracle's Hyperion XBRL Manager and SAP's XBRL Publishing and Benchmarking tools are already in the marketplace.

However, those with vested interests on either side must appreciate that eventually commercial reality and the market will prevail. There is therefore a fantastic opportunity now for XBRL-UK, HMRC, Companies House and the software companies to work together to make XBRL a success. As David Forbes points out, the technology isn't complex to negotiate. Entrenched views, dogma and "all stick and no carrot" could however be fatal. Working together entails co-operation, discussion and the appreciation of each other's viewpoints.

At present, the benefits of XBRL as a medium are perceived as being weighted in favour of regulators and the authorities. It therefore falls on HMRC, XBRL-UK and others to assist with improving the standing of XBRL across the full spectrum of software vendors. In this context, Peter Calvert's comments are less than helpful. Likewise, software houses need to appreciate that the authorities are trying to achieve more within tight constraints and improving the services they offer will inevitably involve pushing further costs out to the business community. This shifting of cost may be acceptable if XBRL does indeed support greater efficiency in Government.

Irrespective of whether XBRL is a success, an unwanted but necessary obligation or an unmitigated disaster, I believe that an unwelcome outcome of the current movement will be further consolidation in the software market and the consequent loss of choice for the consumer.

Nigel Rainer
Technical Director
Tax Automation Limited

I detect a campaign by some software companies to avoid the bother of implementing XBRL rather than a serious criticism of the introduction of the language for business reporting.

SMEs should be unaffected by the change, provided software companies implement XBRL properly.

The benefits come in much more efficient processes and cost savings at HMRC and other consumers - which tax payers should be glad to see - and better targetted HMRC enquiries - which all should be glad to see.

The chances of incorrectly allocated tags are actually low and will fall further with experience. (How difficult is to apply a tag labelled 'operating profit', with all the correct accounting references, calculation links etc. to the correct line item in the accounts?)

You bet some software companies are cynical - they don't see enough profit in it for themselves. Other software companies are more sensible and see opportunities - as well as the public benefits which will flow from XBRL adoption.

David Turner is right that SMEs won't see a lot of benefit at the outset. That will come later, when banks start to tie credit facilities to provision of XBRL accounts.

The move to XBRL is happening all over the world because the regulators are all looking for transparency in corporate accounting. With the events of the last few weeks, that isn't going to change for a generation at least.

As David Forbes points out in his comment, tagging accounts is always going to be difficult - but SMEs should be the last people to worry, because their software will handle the problem. HMRC has mandated XBRL and a number of the leading firms in the UK are already working on their XBRL implementations. I would be very surprised if any of the major packages don't support XBRL when the time comes.

Philip Allen
DecisionSoft Limited
Editor, Specification for Inline XBRL

I see three questions:- what is the point in computer readable accounts, is XBRL the right technology and why the lack of enthusiasm from the software development community ?

At present there is little incentive to produce computer readable accounts. The benefits are predominantly there for the consumer of the accounts rather than the producer (who unfortunately is the one that pays for the software). After HMRC mandation it might become of interest to other parties. If you can get a mortgage or car loan approved quicker when you send your company accounts to the bank in XBRL the pressure will come.

Is XBRL the right technology ? Whatever technology you choose csv files, excel spreadsheets, XBRL or some other xml dialect the problems are essentially the same. You need to come up with names for all the different things that come up in accounts e.g. Turnover, AdvertisingCosts. To be comprehensive many thousands of items are needed. At the end of the day XBRL is just xml. Element names are very long winded e.g.

<AccountsAreInAccordanceWithSpecialProvisionsCompaniesActRelatingToSmallCompanies>yes</AccountsAreInAccordanceWithSpecialProvisionsCompaniesActRelatingToSmallCompanies>

.. but it this is read by computer - humans won't look at this bit. The actual size of an actual XBRL instance is tiny by modern standard. Our own company abbreviated accounts filed in XBRL only came to 12 kilobytes ( a kilobyte is 0.001 megabyte for any too young to have heard the term. My mobile phone has sufficient storage for over a million sets of abbreviated accounts !).

The XBRL documentation's primary purpose appears to be to keep consultants in jobs. XBRL is basically an (unavoidably) large collection of xml elements with very long names (i.e. a text file) wrapped up in terminology that is designed to make it sound much cleverer than that. Once you get passed the intimidating jargon it is essentially tedious rather than straining on the IQ. This is inherent to the problem of computer analysable accounts rather than the particular solution language used (XBRL).

Software companies generally produce software because they think people will pay for it. With XBRL there is not currently much demand.

David Forbes
Forbes Computer Systems Ltd
(filing in XBRL since 2005 !)