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

[Alex Fiteni <alex.fiteni@oracle.com>]

Some additional considerations......
While the corporate income tax domain may favor an accounting based 
audit approach, there are many jurisdictions that levy taxes on 
transactions at several points where accounting may not occur, or the 
accounting for such is handled much later than the settlement date.  
Such tax methods require reporting and settlement based on a tax 
reporting period, that may or may not coincide with an accounting 
period.  The XBRL-GL assumption is that ALL roads lead to the general 
ledger and taxes or tax computations are based on an accounting view of 
the world, not a legislative view of the world - and this from an 
accountant no less!!  While this may work for countries that tie the tax 
reporting and computations to a common accounting and tax reporting 
period definition, how can we respond to those taxation systems that do 
not?  As well, there are times when a full disclosure of the facts of a 
transaction may be warranted, and the information in SAF and even 
XBRL-GL may not, indeed will not, be sufficient. 

Alex
Harm-Jan van Burg wrote:

>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.
>
>  
>