[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]