tax message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [tax] Draft Tax XML teleconference minutes
- From: Andy Greener <andy@gid.co.uk>
- To: tax@lists.oasis-open.org
- Date: Tue, 11 Mar 2003 21:45:32 +0000
Title: RE: [tax] Draft Tax XML teleconference
minutes
At 8:25 am -0500 7/3/03, Lutes Terence H wrote:
First, my biases.
It is not news to anyone that the U.S. does not have a VAT/GST at the
federal level. The states would likely have an interest. I
would not support working on indirect taxes if that means delaying
income taxes. I know a large number of countries are modernizing
or just developing electronic income tax systems. Thus to delay
standards development on the income tax side would be to miss a
tremendous opportunity. If there is a desire to work income
taxes right away, I would suggest consideration of two technical
subcommittees, one for income taxes and one for indirect taxes.
The question is, "do we have the bandwidth for
this?"
From a technical point of view I don't think that it would be
good idea
to carve up the territory into "direct" and
"indirect" taxes. To my mind
these are two sides of the same coin and we would benefit from
dealing
with both together. Let me try to explain....
When we think about "direct" taxation we usually have
in mind transactions
that are primarily designed to report, or even to arrange payment
of, taxes
rendered from some sort of legal entity to a tax jurisdiction in
fulfillment
of some legal requirement. Typically, in the paper world, we have
some sort of
tax form, specifically designed to convey identification
information,
tax compliance information and perhaps actual financial
information, sometimes
accompanied by payment information (a cheque, credit card details
or even
pieces of paper issued by a central bank that "promise to
pay the bearer on
demand...." - ie money).
When you think about this kind of transaction in a logical way,
it really
boils down to a "container" document defined by the tax
authority which carries
a number of well-defined components, some of which have nothing
intrinsically
to do with tax (names, addresses, time periods, financial
calculations,
payments, etc) but which are the subject of other standards
initiatives (e.g.
the OASIS extensible Name and Address Languages - xNAL, or XBRL),
and some
of which are specific to a tax jurisdiction and/or a particular
type of tax.
Now examine the transactions that involve "indirect"
taxation. These are
usually business documents of one form or another (invoices,
receipts, etc),
the primary purpose of which is not to report or collect indirect
tax. Tax
authorities have no direct influence over the design and
construction of
these documents, save perhaps for the legal requirements to show
the tax
information in certain ways. The tax component of these documents
is just
one of a number of components that you'd typically find embedded
therein
(names, addresses, time periods, product descriptions, payments
etc -
spotted a pattern yet? :-).
On the one hand, taxation is the primary purpose of direct tax
"transactions",
and a number of subsidiary "common" components are
required to compose the
"ensemble". On the other hand, indirect tax is a
subsidiary "common" component
in the "ensemble" required to compose a business
"transaction".
When you look at these two aspects together, it becomes pretty
clear that
in all cases there are container "documents" comprising
re-usable "common"
components. In the direct tax case, we (as a tax standards body)
are likely
to have jurisdiction over the document types, or
"templates", and the tax-
specific components (which may or may not be re-usable). In the
indirect tax
case, we may have jurisdiction over the tax-specific components
ceded to us
by the bodies responsible for various types of business
documents. In both
cases we will need to adopt or work with standards already
defined for
non-tax-specific components or document templates.
If we take a coherent view of the problem and tackle both aspects
within
the same fundamental framework then we not only avoid duplication
of effort,
but we also fit right in as a logical extension to existing and
emerging
business standards.
It will probably not have escaped your attention that I'm
referring in a
rather thinly veiled way to UBL/ebXML and their framework of
document
templates and re-usable components (called Core Components in
ebXML and
defined there as abstract entities, and called Business
Information Entities,
BIEs, in UBL where the abstract entities are made flesh in the
guise of
XML Schemas). An awful lot of work has already gone into UBL,
which is
underpinned by ebXML, and it is beginning to look like the only
game in
town (unless we want to re-invent a whole bunch of wheels).
Perhaps, once the technical sub-committee is constituted, it will
be time to
put up a "strawman" proposal for our work, based on the
UBL framework. Then
the technical SC can get to grips with the technical complexities
of UBL
and ebXML whilst the business SC defines requirements that will
eventually
be satisfied by tax-specific UBL document templates and
tax-specific BIEs
cranked out by the techies.
Andy
--
Andy
Greener Mob: +44 7836 331933
GID Ltd, Reading,
UK Tel: +44 118 956 1248
andy@gid.co.uk Fax: +44 118 958 9005
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]