RE: [tax-tasc] Summary of XBRL GL discussion

["Harm-Jan van Burg" <harmjan@vanburg.net>]

Thank you for this useful points. It would be a great opportunity to see
some reflected in the white paper if it could be incorporated in the present
draft.
Because the SAF originated in the Netherlands it is good to elaborate a
little on the SAF.
Although the AF ( presently there are two: AF Financial and Salary) are in
plain XML (originally in ASCII) we are already working with the accounting
community to convert to XBRL. Most of the work was done by the accounting
industry by the way. 
The importance of the AF are the data elements we agree on with the software
industry and the accounting profession.
The problem with the SAF is that the OECD tries to push the SAF as thé one
fits all solution for everybody. In my opinion, and I made that clear to
OECD as well, this will not work. On the other hand the data definition work
in the SAF could be useful for a bigger community although it probably lacks
detail or granularity to fit for many jurisdictions. Besides that it is in
it present state aimed to a large extend to European tax systems.
In an earlier off line discussion with the IRS I came to the conclusion that
pushing the SAF at this time would only enhance opposition among those
companies who fear to much transparency. 
The name SAF should be changed to something without the word audit in it.
The data definitions should be taken separately and expanded so the
usefulness could be bigger in taxonomies and schema's. 

The idea to seek a linkage with the 'industry language' appeals to me.
The fact that BASDA advises against anything does not bother me much. In my
country we have never heard of them and in most other countries they do not
seem to be well known either (except the UK off course).
I think when we remove the political 'payload' there is enough working
ground.

Harm Jan



-----Oorspronkelijk bericht-----
Van: Andy Greener [mailto:andy@gid.co.uk] 
Verzonden: dinsdag 13 april 2004 18:51
Aan: tax@lists.oasis-open.org; tax-tasc@lists.oasis-open.org
Onderwerp: [tax-tasc] Summary of XBRL GL discussion

[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

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/tax-tasc/members/leave_workgrou
p.php.