In the very near future, IT managers are likely to receive a phone call from their finance department asking about XBRL. New corporate filing requirements may lead to finance systems and processes having to be re-engineered –­ so are you ready for XBRL?

From April 2011, her Majesty’s Revenue and Customs (HMRC) is making it compulsory for all businesses to file both company accounts and tax returns in an electronic format called iXBRL – ­ inline eXtensible Business Reporting Language.

Most businesses are unaware of the new rules, which apply for accounting periods ending after 31 March 2010. But this requirement will apply to all firms which currently submit a corporate tax return, regardless of size, meaning every company will need to review their internal systems to ensure they can produce the required iXBRL files.

XBRL is a language written specifically for business reporting. It facilitates the electronic exchange of business and financial data, which should allow HMRC to automatically collate and analyse the numbers submitted. The inline version is a format which is designed to be read by people as well as by machines and it is important that this is the version used as opposed to other, non-inline versions of XBRL.

At present, most companies tend to produce their accounts manually using Microsoft Word, Excel or similar applications, along with the associated tax calculation. When this regulation takes effect, both these documents will have to be converted to iXBRL and submitted along with the tax return form itself. The documents that must be submitted in this way are:

l              Corporate tax return form (XML)

l              Corporate tax computation schedules (iXBRL)

l              Legal entity (statutory) accounts (iXBRL) prepared under either UK GAAP or IFRS accounting rules

l              Group accounts (if required) (iXBRL) prepared under UK GAAP or IFRS

l              PDF attachments for other information (if required).

HMRC has said that if organisations are unable to submit both corporation tax returns and company accounts in the prescribed format, it will reject the submission, and offenders will be treated as having not filed their returns at all. This could mean penalties and pressure from the authorities to comply.

So what are the options for business? There are two approaches:

l              Organisations can convert prepared statutory accounts into iXBRL ready to be tagged, or

l              They can redesign the statutory accounts preparation process to produce reports in XBRL.

The first approach may be the best option for smaller organisations. This is likely to be cheaper than opting for a more comprehensive overhaul of their systems and processes.

Larger, more complex organisations may find that such a conversion is only feasible in the short term, if at all. A conversion may be all they have time for to meet the deadline. Looking further ahead, converting accounts from one format into another may become such a burden and introduce such an unacceptable risk of error that it becomes preferable to implement a fully automated end-to-end approach. Either way, the implications of this recent announcement should be factored into IT, finance and tax function plans for the forthcoming year.

What does this mean for the IT function?

The finance and tax departments will involve their internal IT functions to work out the best approach. Many of the larger organisations KPMG is already working with have formed XBRL project teams consisting of stakeholders from the finance and IT departments.

In our view, the real issue will be the accounts production. Where an organisation already uses a mainstream tax return engine, it is likely that the software house will integrate XBRL functionality, so there should not be a significant issue. The software will need to be capable of parsing the appropriate taxonomy to permit the user to tag their tax return numbers.

Taxonomies are key to the adoption of this technology. They represent groupings of elements or concepts. For example, the UK GAAP taxonomy contains elements appropriate for use in preparing accounts under UK GAAP rules.

Where an organisation uses accounts production software to automate the creation of its accounts, it will either have to upgrade its software to support iXBRL tagging or output its final version of accounts to a word processor document or spreadsheet and tag the number using standalone tagging software.

There are limited options in the market for most medium-to-large-sized organisations in terms of accounts production software. Word is by far the most widely used software for preparing accounts. This is because of the flexibility needed to format accounts and deal with preambles and disclosures. So IT projects that either re-engineer existing processes or introduce bolt-on tagging solutions will be common.

How does a business ascertain that it is compliant with the correct form of XBRL?

When deciding on a solution, organisations must ensure that the technology produces iXBRL files. We have seen many cases where companies have bought US software only to find out it does not meet the UK formatting requirements.

They should also look at how the technology rolls forward to the next year and the actual mapping process itself. In particular, how will the system deal with changes in the taxonomies? Remember that HMRC will revise the taxonomies every year, meaning that companies will need to revisit their mappings.

HMRC has given users access to a test portal where they can submit XBRL files and test their validity. Ensuring integrity of the submission is not st raightforward as the data elements need to adhere to a number of rules and relationships, so testing the system the year before is recommended.

For more complex organisations that decide to re-engineer their accounts production processes, it is recommended that a dry run is conducted to ensure processes are bedded down and accurate files are produced in a timely fashion.

How we have dealt with XBRL

To deal with the iXBRL requirement for accounts production, KPMG has developed a number of approaches. The first involves a proprietary bolt-on solution which can directly tag Word and Excel documents and convert them into the iXBRL format. The second approach involves using a single solution to prepare accounts and deal with the XBRL tagging requirements.

However, the right approach for a company is dependent on a number of issues to do with initial cost, ongoing maintenance, risk and controls.

XBRL is coming soon and IT departments need to be prepared so they are not caught out by the deadline. Early preparation and testing are key. There are solutions out there, but careful consideration needs to be given to ensuring the right approach and technologies are adopted.