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: Re: [ubl] [Fwd: RE: Review of "UBL Submission from TAX ML technicalcommittee"]






Tim,

Thank you for making available the comments from the Swedish governement on
the TaxXML paper, and thank you to Martin Forsberg and Soren Lennartsson
for taking the time to contribute this very appreciated feedback.

I forwarded these comment to our work group and have summarized the
comments primarily from myself and Dave Watt of HM Revenue and Customs:

1. In his comments, Soren suggests having the model checked by other user
groups such as ODETTE (Organisation for Data Exchange through
Tele-Transmission in Europe - representing European Automotive).  We are
certainly in favor of having as many user groups as possible look at the
model to solicit feedback.  Dave is a member of the Odette European Invoice
Task Force and could arrange to have the model circulated.  Dave has also
been working with the JAI (Joint Automotive Industry) group on their Global
Invoice Project (GIP), which covers the AIAG (Automotive Industry Action
Group) in the USA, Odette in Europe and JAMA/JAPIA (Japanese Auto
Manufacturers Association/Japanese Auto Parts Industry Association) in
Japan and South Korea.
The work group will determine whether the document is ready to be
distributed more broadly.

2. We generally agree with Soren’s observations on the "two schools of
thought" on the (level of) invoice data content - i.e. the insular/stand
alone (document) approach, where all material data content is
self-contained within each message, and the more process-orientated view,
where some of the "tax-critical" data content may be exchanged, up front,
on other documents (e.g. suppliers VAT registration numbers, item prices
etc.), which obviates the need for further repetition within each invoice
message.

However, it should be noted that our initial analysis was deliberately
limited to some of the basic commercial messages involved in the supply
chain.  While there may be additional messages that could supply certain
information up front, the analysis of messages we looked at needed to
assume a "worst case" scenario where all of the information required would
need to be supplied.  On the other hand, the reference model could be
extended to then draw attention to the fact that derogations may be allowed
by the tax authorities in some countries, that permit the exchange of
certain "static" data, on documents or by means other than in the invoice
message itself.  A detailed analysis of these supplementary messages could
be included in a subsequent iteration of the document.

3. Soren comments "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."  It should
be pointed out that, in the Scope section of the document, it is explained
that (B2G) tax reporting is NOT encompassed in the current model, but will
be included in a future iteration.  The work group chose to limit the
initial scope and focus to the commercial messages.

On the other hand, Soren has provided quite a good view as to how VAT
operates in Europe.  We would like to include any information that helps to
clarify how indirect taxes operate and will consider the inclusion of this
EU-specific information (as well as other jurisdiction specific detail) in
an appendix to the model, to add clarity for the "non-EU- initiated"
reader.

4. Regarding Soren's comment that "The proposal, listing all commercial
messages as potential indirect tax messages is prone to sub-set
proliferation", again, due to the initial scope and focus of the analysis,
the work involved assessing the commercial messages involved in the supply
chain for their relevance to the determination and ultimate reporting of
Indirect Tax, rather than to look at the total process of Indirect Tax and
determine the messages required.  However, we agree that users will be more
helped by a model guiding them to solutions and that there should be clear,
unequivocal guidance as to the point where tax liability is determined.
This, as well, is something that could be accommodated within appendices on
the various indirect taxes.

Thank you again and I look forward to any additional feedback.

Regards,
John Glaubitz





                                                                                                                                        
                      Tim McGrath                                                                                                       
                      <tmcgrath@portcom        To:       ubl@lists.oasis-open.org                                                       
                      m.com.au>                cc:                                                                                      
                                               Subject:  [ubl] [Fwd: RE: Review of "UBL Submission from TAX ML technical committee"]    
                      06/13/2005 10:49                                                                                                  
                      PM                                                                                                                
                                                                                                                                        
                                                                                                                                        




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]