XBRL Debate

XBRL made impractical by its complexity for the end-user organisation

Imagine if a technology existed that automatically identified financial data in a report and directly compared it with similar data from other sources? This is certainly no pipedream.

About five years ago, the accounting community took up the task of finding a common electronic financial reporting language that would allow stock exchange analysts to compare like-for-like results in large company accounts.

The result was XBRL (eXtensible Business Reporting Language).

It is based on XML (eXtensible Mark-up Language – the format for electronic submissions over the internet) and uses approved accounting terms related to the local GAAP or IFRS to pinpoint and compare data from disparate sources.

But unlike XML, which has been widely used for electronic submissions around the world since 1998, particularly by tax authorities and governments, XBRL was designed for large multinational companies and its complexity has so far prevented its take-up by other than a determined handful.

That hasn’t stopped the government recommending the use of XBRL for all financial reporting electronic submissions in the UK.

We can expect to see XBRL used for filing corporation tax returns to the Inland Revenue, annual accounts to Companies House and VAT returns to Customs & Excise.

It will be a major benefit to these organisations, offering them the ability to identify data submitted to them for comparison purposes. But at what cost to the sending organisation?

Having worked with the government and the private sector for the past 10 years on defining electronic standards, our experience tell us that, for take-up to be successful, there must be benefits for both the sender and the recipient of the electronic data.

Feedback from early adopters of XBRL shows that, rather than reducing the burden on those submitting the information, it actually increases their workload, adding a higher level of complexity to a relatively simple operation.

XBRL’s downfall is that, in order for direct comparison of financial reports to be achieved, the end-user organisation must map its general ledger chart of accounts to the associated taxonomy. And because each national jurisdiction may have its own taxonomy, the ability of XBRL to compare results suffers.

With simple XML, software developers can map the core data directly to the XML output, requiring the end user simply to hit the send button for the information to be transmitted.

All of the data formatting and testing can be done in advance.

With XBRL, all we can provide is a mapping program for the end-user organisation to map its unique general ledger structure to an exceptionally long and complicated XBRL taxonomy (which can be up to 7,000 different items).

This is a complicated, skilled process, offering no opportunity for pre-testing and a long way from a simple ‘one-touch’ solution.

At the moment, few organisations are using the Revenue’s indirect electronic corporation tax submission – the XBRL stage for the profit & loss and balance sheet is still in development, and the FSA’s proposed XBRL regulatory submissions have recently hit the buffers due to the complexity of the task.

Meanwhile, the Revenue’s self assessment and PAYE electronic submissions, using standard XML, have been widely taken up and more than one million orders and invoices were exchanged electronically last year using Basda’s eBIS-XML standard.

XBRL is a great idea, but its forced introduction will impose unacceptable burdens on businesses that have to learn how to format these highly complex outputs.

How can normally cautious accountants be hoodwinked into using a software technology without good reference sites and the backing of the software industry?

I can see no ‘win’ advantages for the sender of XBRL, only for the government and the middlemen.

Dennis Keeling is chief executive of Basda Organisations are increasingly overburdened by the multiple and changing reporting requirements from management, investors, creditors, regulators and other stakeholders.

The short-term response is to treat each requirement separately and then modify or upgrade existing systems, or re-key, reformat and reconcile data semi-manually, with the aim of obtaining different reports in the formats specified by the various users.

This is about integrated standards-based reporting – it is by no means a trivial issue and cannot be compared to simply agreeing upon an invoice format.

Quick fixes are akin to putting a bandage on a broken leg – they only do well in the short term, and better suit technology providers.

As political commentator HL Mencken once said, for every complex problem there is an answer that is clear, simple and wrong.

Simple proprietary solutions – based on EDI – fall within that category and lead to ‘spaghetti’ reporting processes, involving different proprietary solutions, spreadsheets and workarounds.

Each of these has its own merits and raison d’etre, but makes the reporting process poorly integrated and expensive to maintain.

Enter XBRL. Initiated by the auditing profession to assist companies and accountants in dealing with electronic financial data, it has evolved into a market-driven solution that addresses corporate reporting issues of transparency, accuracy and integrity.

XBRL International is a 250-strong neutral consortium representing the entire business reporting supply chain.

Progress has, perhaps, been slower than expected.

But change is rarely easy, especially in a voluntary collaborative environment relying upon win-win-win solutions and consensus among all parties.

Technology solutions are seldom perfect on day one.

At such times, it’s much easier to be critical than to come up with solutions.

One criticism is that XBRL is complex, but the same can be said about most automation initiatives.

Websites were complex in 1992, but now it’s just a ‘save as’ function in Word or Excel.

The long-term benefits far outweigh the short-term difficulties, and progress to date has exceeded our expectations.

XBRL activities now span 32 countries.

Taxonomies are available or under development in jurisdictions including the US, UK, Germany, Netherlands, Belgium, and for credit risk, IFRS, Basel II, and ledger-level content.

# XBRL is already supported within software applications from Microsoft, CaseWare, DecisionSoft, Fujitsu, Hitachi, J2R Technologies, Semansys Technologies, Software AG and UBmatrix.

Such XBRL-enabled applications select, analyse, store, exchange tagged data with others, and display it automatically in various formats.

XBRL thus significantly improves processing efficiency, reduces errors and enhances automated rule-based validation capabilities, freeing up precious management time for more value-added tasks.

And it doesn’t take a technical guru to use XBRL, because tools take care of the technological complexity, and XBRL data tagging simply becomes a drag-and-drop exercise.

XBRL helps credit institutions streamline their credit assessment processes, which in time reduces the cost of credit.

Credit insurers have therefore developed the credit risk taxonomy.

Many European organisations are already adopting XBRL: the UK Inland Revenue and Financial Services Authority, Dutch Water Boards, German Bundesbank, Banco de Espana, the European Commission, Eurostat and the Danish Commerce and Companies agency to name a few.

Reporting requirements are complex but, once implemented, a standardised and integrated process has obvious benefits.

Lindsey Domingo is director at PricewaterhouseCoopers in Belgium.