OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tax message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [tax] Comments on XML Position Paper


In the position paper I read that the tax community is looking for
standardized and re-usable interfaces. Re-usable is just a word, be if you
ask people what this means, you will get different answers.
For me, it is does not only mean that we use the same computer, the same
cabel (Note: i am of course exaggerating here), but also the same semantics
(not just for tax, but other regulators too), AND re-usable reliable - may
be audited-  information. That is in my opinion real re usable information,
re usable on every level of the interface.

I liked your comments on the differences between accountants and computer
scientists looking at data differently. But the assessement and certifying
of information is still an accountants job (I am not sure if they are
really capable of doing this, but this is another topic). That gives us a
reason for meddling, I think.

Your comment on :
>And this standard is just for tax purposes, we have more regulators who
>need information. If they all invent their own XML solutions, I am not
>this is less complex then implementing XBRL, as Andy suggests.

Response Andy: If the information that other regulators need falls within
an existing
Taxonomy then you may have a point.

But this is exactly my point. What I said ealier: re-usable on as much
levels as possible. We need regulators who understand that there is a need
to converge data needs to possibly one ultimate set (let call this taxonomy
'taxutopia'). But yes, we are very aware of the fact that there is no
one-size-fits-all solution. But I agree fully with Harm Jan as he says: tax
is a part of the total financial reporting chain.

Another key point of the reaction of Harm Jan:
 >In our administration we are starting discussions whether it is not                                                 
 more efficient to leave as many data as we can in the company and audit it                                           
 when needed.<                                                                                                        
 This means that the information demands for the tax paying organizations is not always the same. The reusable        
 interface should be flexible. Tax regulator can ask for condensed reporting information, but a year later they need  
 all the transaction details for futher inquiry. My idea is that XBRL GL is close to 'taxutopia'.                     
 Marc van Hilvoorde                                                                                                   
 Global Risk Management Solutions                                                                                     

----- Forwarded by Marc van Hilvoorde/NL/ABAS/PwC on 16-03-2004 09:49 -----
                      Andy Greener                                                                                                     
                      <andy@gid.co.uk>         To:                                                                                     
                      14-03-2004 20:03         cc:                                                                                     
                                               Subject:  RE: [tax] Comments on XML Position Paper                                      

At 3:29 pm +0100 14/3/04, marc.van.hilvoorde@nl.pwc.com wrote:
>I like to add to the current discussion:

Please - the more the merrier. I must say that this list has become
much more interesting now that we have some real issues to debate!

>I already mentioned the Dutch XML audit file; I did not mention that we
>also have a separate payroll audit file. Not all the information suppliers
>consider this the same 'standard', they need extra work to implement this.

This sounds similar to the UK PAYE End of Year Return, which summarises
payroll deduction information for Tax and National Insurance (NI = social
security, health and state pension 'tax') so that benefits and pensions
rights can be accumulated and apportioned correctly (effectively auditing
the employers who are making the payroll deductions and paying over
composite contributions of tax and NI).

>And this standard is just for tax purposes, we have more regulators who
>need information. If they all invent their own XML solutions, I am not
>this is less complex then implementing XBRL, as Andy suggests.

If the information that other regulators need falls within an existing
Taxonomy then you may have a point - defining a straightforward grammar
in XBRL (using groups and tuples) may be no more complex than doing it
in XML Schema, but real life is seldom straightforward. XML Schema quickly
surpasses XBRL's limited abilities in this regard, and XML Schema is not
even the most powerful schema language available. Whether a particular
solution is more or less complex in XBRL depends on the grammar and
vocabulary requirements, and every situation will be different. There is
no one-size-fits-all solution.

Taking the UK PAYE EOY Return as an example, our National Insurance
'vocabulary' is unlikely to appear in any existing XBRL Taxonomy (even
UK-specific ones, since it is of no interest to corporations), so as well
as doing at least as much work to represent the structural complexity
(assuming it could be done), an extension Taxonomy would have to be built
to incorporate the NI vocabulary. This is at least as much work, if not
more, than building a pure XML Schema in the first place, and what you end
up with is something more complicated than it needs to be (note that I
said "more complicated" not "too complicated" :-).

I have a sneaking suspicion that we are getting down to the fundamental
issue of how accountants and computer scientists "view" data differently.
The former take a tabular view and layer structural information on top,
whereas the latter see grammar (ie structure) as an integral aspect of
data. This debate takes other forms too: procedural programming vs object-
oriented programming describes a similar dichotomy in programming circles.
The tie-in is that pure XML is an excellent way of serialising object data
in an OO environment, and guess which programming paradigm is most often
used these days when building complex systems...

>An official key factor in making Dutch government decisions is the
>reduction of administrative burden (I am just translating here) for
>companies. The Dutch tax regulator uses the phrase: "we can not make (tax)
>more pleasant, but we do can make it easier".

Yes, here too. Every time we add new regulation we try to make it as
easy as possible ;-)) (Cynic? Me?!)


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

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]