Summary of XBRL GL discussion

[Andy Greener <andy@gid.co.uk>]

[I'm sending this to both TC and TASC mailing lists so that no-one
misses it; apologies if you receive it twice]

During the TASC conference call last week I took an action to summarise
the discussion that Eric Cohen, Philip Allen and myself were having
"off-line" about XBRL GL, SAF and its applicability. I am indebted to
Philip for pre-empting this and undertaking the action on my behalf, and
for producing a well-structured and clear summary of a somewhat rambling
and extended email thread!

I suspect that this may prove to be useful input for the White Paper,
which is conspicuously silent on the subject of XBRL GL and its relationship
to SAF and XBRL generally.

-------------------------------------------------------------------------

Notes on the applicability of XBRL GL
-------------------------------------

1.  Standards

1.1

Conventional XML is often thought of as a "transactional" data format,
that is, the data is described in a specific way in order best to satisfy
the needs of a particular purpose or transaction.  In conventional XML,
the content and the structure of the data are closely tied together.

1.2

XBRL is designed to allow data to be described independently of
structure, in order to make it equally applicable to a range of
transactional purposes.  XBRL can be thought of as a "flattened" type of
XML, where structural or transactional information is abstracted out into
linkbases.

1.3

XBRL-GL is a less flexible variant of XBRL - one which reintroduces the
structural constraints not present in standard XBRL.  It has some
considerable authority in its field, as the result of over four years'
modelling work carried out by the international GL/audit community.

2.  Purpose

2.1

XBRL is intended to meet the needs of the entire business supply chain,
covering the needs of GL, tax, financial statements, audit workpapers,
etc.

2.2

For some of these needs - for instance, GL - the requirement is for a
transactional format which still retains compatibility with XBRL.  The
purpose of XBRL-GL is to create a bridge between standard XBRL and
conventional XML and other transactional formats.  This allows GL to
benefit from XBRL features such as labels (providing multi-language
support) and references (to provide linkages to legislation in different
jurisdictions).

2.3

The general case for XBRL-GL, then, is not that it is the only way
sensibly to encapsulate GL data, but that it allows this to be done
within a business environment where standard XBRL is being used for
financial accounts and business reporting.

3.  SAF

3.1

The SAF (Standard Audit File) is being designed by an OECD working party
and we understand that it is based on an XML structure put together by
the Dutch tax authority.

3.2 

There is a general argument that the SAF, primarily aimed at
taxation-based requirements, should represent only the minimum information
required for taxation, thus providing a lower bar for tax regulators and
developers to cope with.  At the same time, however, it should be
sufficiently modular to cope with extensions that allow it to incorporate
B2G data being sent by companies to other government agencies.

4.  The case for using conventional XML for the SAF

4.1

Existing work on the SAF is currently being undertaken as conventional
XML.

4.2

The general case against XBRL and XBRL-GL is that competent
implementations imply pre-existing familiarity with XML-based services.
It can sometimes be hard to see why a more complex standard (XBRL) is
required when competence has already been reached in the simpler and
standard (XML).  To encourage adoption it is important to be able to make
a good case to developers for the use of the more complex standard.

5. The case for using XBRL-GL for the SAF

5.1

The cost argument.  Although intended primarily for the use of tax
authorities, the SAF should be able to meet the needs of companies for
consolidations, for sharing with auditors and accountants.  If the SAF is
designed purely to meet the needs of tax authorities it will become a
burden for companies and professional firms because of limited
compatibility with other business reporting formats.  This argument
reflects the fact that the main costs will be borne not by the tax
authorities but by the regulated firms themselves.

5.2

The political argument.  BASDA members, for instance, have already
advised strongly against any attempt by the tax authorities to require
audit data. They will find it less easy to resist if the data is already
available in a compatible format in their accounting systems.  It would
be a major (and positive) change for tax authorities to benefit from
existing data instead of simply mandating new implementation costs on
their taxpayer base.

5.3

The commercial argument.  For the SAF to be a success - that is, for
appropriate software to be developed quickly, for quick uptake by the tax
advisory industry, and for widespread implementation by companies - it
would be wise to take advantage of the considerable commitment already
made by the leaders of the accounting industry to XBRL-related formats.
The Big Four will be (arguably) the prime movers in implementing the SAF.

-- 

Andy Greener                         Mob: +44 7836 331933
GID Ltd, Reading, UK                 Tel: +44 118 956 1248
andy@gid.co.uk                       Fax: +44 118 958 9005