[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: RE: Review of "UBL Submission from TAX ML technical committee"]
As discussed on the call here are the comments from the Swedish government
on the Tax XML paper. -------- Original Message --------
FYI
/Martin
Forsberg
To
whoever may be interested
With reference to inquiry by Martin:
Re General
In the end, there were just a couple of hours for looking at the model
- presumably a lot in it was not properly understood. These comments are
given with a limited Swedish VAT perspective, so take these comments for
what they are.
This model is impressive in that it tackles
a wide variety of provisions for taxation.
VAT simplification/harmonisation/complication is
an issue in some EU member states as a consequence of the EU VAT directive.
The model should be checked by some user
groups. Odette could be one of them having the international perspective.
And tax authorities - but I know of only
one (in UK) that have the interest and competence to deal with these matters.
Re over-generalised models
We generally support the process-oriented
view of data exchange, processing and monitoring. In the case of VAT it
could well mean that the information on tax status of a legal person is
exchanged in a party information document and that applicable article VAT
data are exchanged as contract or price list documents - and that subsequent
invoices merely refer to the previously exchanged party, contract, article,
etc "static" information rather than repeating it in each individual invoice.
Of course this approach has implications on how parties are to process and
store the invoices.
This differs from the view put forward from
those who see invoice documents as insular, self-contained and stand-alone.
This is often linked to seeing the document as "record" but which gives
little understanding of the process where it is used.
The differing views can easily be bridged
by models sufficiently generalised, but users are not helped by this - they
have to operate one or the other environment.
Re EU VAT directive and its implementations
The model seems poor in distinguishing between
the information about tax for commercial assessment purposes on the one
hand and tax liability and mandatory reporting of tax on the other. In the EU VAT perspective indirect taxation is a matter
between the seller and the seller's tax authority, and between the buyer
and the buyer's tax authority. The trading partners are only to some extent
expected to keep trace of each other's tax status (one such case is when
the business transaction is set up so that the buyer is to pay the VAT).
Nationally taxation rules may apply to the parties in differing ways, for
example, VAT added by the seller may or may not be (fully) deductible by
the buyer (depending on the buyer's situation or who the procured goods
is used). In cross-border trade differing
legislation can create additional differences in rules.
Instead, the directive/law defines
what has to be state on the invoice/self-bill/credit note/debit note. Liability
to tax is linked to the issuing of these documents, which in turn is linked to the delivery of goods/services, or to the invoice
issue date in case of periodic billing. In case discrepancies a correcting
credit note, new invoice (etc) has to be issued. A common view would be
that VAT recording in the parties system is done in the ERP system trough
certain accounts in the bookkeeping process.
There is no obvious VAT
link to the payment sub-process - the "total" is paid/debited/credited (although
it potentially may implemented so in some country?). The quotation sub-process
is also special in this aspect; tax data are given for commercial information
and total cost evaluation, but there is no liability aspect.
In other sub-processes
there would be little merit in introducing handling of VAT.
The proposal, listing
all commercial messages as potential indirect tax messages is prone to sub-set
proliferation. Users are more helped by a model
guiding them to operational solutions, rather than by a model over all theoretical
options. Tax authorities should be concerned if
it is not clear where in the model tax liability sets in - and that also
the seller and buyer understand it in the same way.
Re self-billing
In the EU directive it
is the seller that is responsible for a correct invoice, also in the case
of customer-generated invoices. There has to be a reconciliation process
agreed between the parties for this; each member state determines its terms
and conditions. Self-billing is just a special case of out-sourcing of invoice
production. Of course, it has implications on how the business process is
organised.
The VAT details in the
model
The EU VAT directive
requires VAT to be reported per tax rate or exemption (combinations of rates
and/or exemption in one invoice is possible). It is not known how the member
states have implemented this but in Sweden, at least, the interpretation
is strict: merely figures calculated from invoice line data are not acceptable
- the appropriate figures have to be stated. On the other hand, there is
no requirement to present VAT information per line event though it may be
used for control purposes. There are suppliers who refuse to present VAT
data on line level in invoices as long as requirement is "per rate" only.
Regards,
Sören Lennartsson
-- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services (coming soon from MIT Press) http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]