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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tax message

[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