[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [tax] Tax XML Suggested Direction
Registration is an interesting case. The Canada Customs and Revenue Agency has a "Business Number" or "BN" that it employs as the identifier for businesses and which is assigned at the time the business registers with us. I thought a short description of the BN structure and registration process might be helpful. The BN is a two part number - a 9 digit root BN or BN9 which identifies a legal entity, with an additional 6 characters/numbers which combine with the 9 digit root BN to form a BN15 for each tax program. We do not allow a business to register for just the root BN9 - it must register for a specific program. We have multiple programs that use the BN, and have now had the BN adopted by half of our provinces to use in the delivery of their business programs. It is also used by other organizations such as banks (in limited circumstances such when they are issuing tax receipts) and other federal departments/ministries. To give you an example of how a BN might work, one could consider a bank: The bank would have one BN9 assigned to it and that BN9 would remain the same for all programs. The bank could decide that for the purposes of its Goods and Services Tax (our value added tax), it would identify each of its 1000 branches separately, so 1000 BN15s would be assigned. Each one of these BN15s could have 2 addresses (a street address and a mailing address). In addition, there could be contact information for a third party such as an accountant or lawyer. For the purposes of payroll taxes, the bank could identify an employee in each of 10 provincial offices and have separate contact information for these (and again have a third party registered). This would result in an additional 10 BN15s. For purposes of corporate tax, the bank could choose to register only its tax accountant - another BN15 with contact information. And this goes on. My point in providing this example is that registration is actually far more complex than it appears. We have some companies with thousands of registrants and thousands of addresses. In some cases, the consequence of error in names and addresses can be considerable. We issue very large cheques (multiple millions of dollars) for rebates of our Goods and Services Tax. If this is sent to the wrong address, it is serious, and even more serious if it goes to the wrong name, so we attach a great deal of important to controlling any changes to the name and address. The issue of the reason to register for taxes has been raised. Ideally, an organization registers at the time it is created. We have a number of processes in place to try to ensure this happens. But we also encounter the situation where someone walks into one of our offices with a payment and asks to register for one of our tax programs. We may not be able to obtain all the information we would like for the company at this time and may have to add to the registration information later. We also have many businesses that operate as sole proprietors or partnerships. The registration process and information collected is slightly different in these cases. Certainly registration would be an interesting case to use. We might want to ensure that we have a couple of practical situations where the use of Tax XML for registration would provide benefits to tax jurisdictions. Leslie Scott Canada Customs and Revenue Agency -----Original Message----- From: Andy Greener [mailto:andy@gid.co.uk] Sent: January 14, 2003 9:51 AM To: tax@lists.oasis-open.org Subject: Re: [tax] Tax XML Suggested Direction At 8:43 am -0500 14/1/03, John.Glaubitz@vertexinc.com wrote: >Some good dialog has started around the Tax XML direction and some good >points raised. Andy's assertion that we need to answer "why" to any of the >initiatives we pursue will certainly be a critical aspect of our analysis >and prioritization. In addition, Andy summed up well some of our thoughts >on what we may need to deliver when he said, "our job may simply be to >apply the domain-specific expertise to extend a set of business-oriented >standards into the taxation domain" (although "simply" may be an >overstatement). Undoubtedly! ;-) > To accomplish this end will still need some rigor and >organization and the staged approach proposed by Rod (or was it Bruce) >seems well thought out and articulated to meet that purpose. It should >provide a good framework for us to organize our efforts. > >To continue the discussion, we thought we might focus on the business >context of one area of tax compliance as an example to identify how we >might approach it and to determine whether a Tax XML standard may provide >value. Since Andy identified tax registration as an example of a process >that may not benefit from standardization it may be a good choice to >dissect for this purpose. Hmm ok! Well, there's registration and there's registration! I was thinking more along the lines of 'registration to file', rather than 'registration to collect' (I'll admit to a bit of a blind-spot with regard to 'registration to collect', since IR don't administer VAT in the UK - we have no such thing as sales tax - and the only activity we might regard as third-party tax collection is the PAYE payroll tax deduction system operated by just about every corporate entity. However, like VAT, PAYE registration is something that a corporate entity will probably only do once in its history, at the outset). Registration to file (by which I mean providing the means to authenticate one's self so that authorised tax filings can be made in future) is something else again. It was this I was thinking about when I made my original assertion. In the UK, "Registration & Enrollment" (for all Govt services, not just tax filing) is handled centrally by the UK Govt Gateway. The fact that in our particular case, and possibly in others, the registration is not solely tax-related, led me to the conclusion that standardisation efforts in this area by a tax-oriented standards group alone might be difficult to achieve, making other areas more attractive to tackle first. However, you make the case well for standardisation of 'registration to collect' scenarios from a tax solution provider standpoint, and I have no problem with the template/context/component approach that you are suggesting. I must go off and investigate how our PAYE Scheme registration works!... -- 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] | [Elist Home]
Powered by eList eXpress LLC