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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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 --------
Subject: RE: Review of "UBL Submission from TAX ML technical committee"
Date: Sat, 4 Jun 2005 14:55:19 +0200
From: "Martin Forsberg" <martin.forsberg@amnis.se>
Reply-To: <martin.forsberg@amnis.se>
Organization: Amnis Consulting AB
To: "'Mark Leitch'" <ml@tritorr.com>, "'Peter Larsen Borresen'" <plb@itst.dk>, <ubl@lists.oasis-open.org>
CC: "'JOSTEIN FRØMYR'" <jostein.fromyr@edisys.no>, <Emilio.CASTRILLEJO@cec.eu.int>, <amabel.grant@ogcbs.gsi.gov.uk>, <dg@tenorconseil.fr>, <andre.hoddevik@ft.dep.no>, "'Tim Benson'" <tim.benson@abies.co.uk>, "'Tim McGrath'" <tmcgrath@portcomm.com.au>, <stephen_green@bristol-city.gov.uk>


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]