On Thu, Jun 21, 2012 at 7:09 PM, Peter Dolding
<..hidden..> wrote:
Chris Travers <..hidden..>
> The problem which no single business can address as such is the fact
> that all these different jurisdictions are, well, different. They
> change their regulations on different schedules, the regulations may
> be somewhat nuanced, and so forth. This means that this is not a
> problem which is well suited to a single player in the industry to
> solve, and it really requires local voices who know the regulations
> both in theory and practice, and can act as a voice helping the
> community figure out what we need to do to meet the regulatory
> requirements.
This is another reason for having a list. Australia has a very fixed
schedules. Tax system changes between june 30 and july1 at midnight.
No official tax change can be applied at any other time in the year.
Information about proposed changes are released before that and is
basically locked in 2 months before the date so software can change.
Also that gives you 12 months to implement the change fully for
anything other than bas reporting. Business activity reporting is 1
month for large companies 3 months for medium companies and 12 months
for small companies. Yes those 3 months reports are all at exactly
the same time. So small business you have 12 months to implment mid
range business you have 3 months to implement. So yes there is a
bias to get large businesses to chip in. Since they will require it
first. This should make getting partners that can pay simpler.
Ok, I see two problems with a lot of this. The first is that while something like sales tax is relatively straight-forward, a lot of things do depend on implementation, and there may be nuance there. For example, I don't really know what the effect of HST on the question of whether a muffin sold in a coffee shop in Toronto (Ontario, Canada), and if HST hasn't greatly affected the rules there, I wouldn't want to be in charge of making sure my interpretation of the rules were correct.
As I say I don't know what the current state is after HST was implemented, but before then, the tax rate depended on what else the customer bought. As I understand the previous rules:
If the muffin is not individually wrapped and you buy fewer than six then it is taxable if and only if the subtotal of all prepared foods and beverages is greater than $4 CAD. On the other hand if it is individually wrapped then it is always taxable unless another prepared food or beverage is purchased and the subtotal is less than $4 CAD.
I see this as a classic example of where someone on the ground really must address the sales tax directly, or at least work with us to do so. I am not sticking my neck out there interpreting rules like that.
>
> Also a lot of regulatory compliance work is a bit difficult to pay for
> in a standard pay-for-development open source model since it leads to
> one person paying for compliance for everyone else, over and over. I
> think paying for it will require a local party offering support
> subscriptions. (I can partner with you on these if you need
> development help etc).
True but there is a catch here. There is a chance that between
regions there are common tests. Without a list of the regulation
requirements those common tests cannot be found.
Not like Australia sales tax system is 100 percent unique.
Certainly with sales tax there is a most common scenario, which we can support internationally. This is that for a given customer and good purchased the tax rate is constant. Note there are an increasing number of places where this breaks down (the US for example) and so we have to decide when and where to make adjustments to what's supported as part of the overall offering and what's a local party's responsibility.
>
> I think this is one thing we are both trying to address. I would like
> to see however the idea that we create a place for local players in
> helping get this through.
>
> So I guess I would turn the proposal on its head and suggest:
>
> 1) We look at seeing what we need to do to pass these tests if we
> don't do so already
> 2) We look into the registration process
> 3) We look for local partners in Australia who can help with things
> like payroll regulations.
>
> Looking through the set of tests:
>
> 1) We don't currently automate a capital gains reporting, or AIIR reporting.
> 2) We don't try to handle franked dividends
> 3) The sales tax scenarios would apply
> 4) The income tax withholding may be necessary as we get further.
> 5) Some of the other reporting stuff is not handled yet but would be
> an area where a local partner might have a role in getting that going.
>
Areas that package don't handle at all that is something a local
partner can deal with by adding extension or other solution to cope
with. So reporting bits missing or capital gains reporting or AIIR
reporting or franked dividends these all can possible go to partner.
There is a catch. There must be a safe way for partners to plug this
stuff in next to other partners plugins doing the same thing but
configured for different region. The night mare of multi regional
accounting. So if I am operating in Australia and NZ I would have to
report to both tax departments.
The concern I have is that when you look at sales tax reporting requirements in states in the US and you compare to state income tax reporting requirements, it's pretty clear that the sales tax requirements are more complex and more burdensome, and that it is becoming more complex faster than any other tax form around. Sales taxes don't have to be simple, and I see a number of reasons why they might tend towards great complexity and variety.
Items like sales tax in the pos part kinda have to work exactly right.
Not something a partner should be attempting to fix. Areas you do
like sales tax you might have to provide a interface that is clean for
partners to add location conditions and adjustments for current rules
in there area. Remember big catch here is not all companies operate
in one country. So the partners need to be able to apply there
regional alterations without altering the core applications code and
be able to operate along side each other without stomping on each
other.
Sales tax in a POS tends to be often, in the US at least (I don't know elsewhere) the least complex aspect. For example, in most states in the US, sales tax only becomes complex once you start delivering things to customers. Of course in Ontario, Canada, at least prior to the HST compromise (I don't know the situation currently) POS sales taxes tended towards great complexity.
Really to work out what has to be modules what has to be common.
Requires making a list of the rules and regulations globally.
There are also questions of interpretation and nuance and there's no reason to think that the same general requirements in two places won't have corner cases where the interpretation is different. So a list of regulations only gets you so far.
Basically there needs to be a map. So we know what functionality is
region particular and what functionality is truly generic. Regional
particular stuff mixed into generic cause lot of pain.
Unfortunately, sales tax is highly regional. Also prior to HST, the way it worked in Quebec was that the national sales taxes were taxed by the province. The requirements were such that we decided to handle this in LedgerSMB, but we decided not to handle the Ontario coffee shop scenario directly (and not getting into rules in Ontario about sales tax and coupons, where the effect on sales tax is dependent on who issued the coupon).
I think that the best we can do here is to document the situations which we handle natively and provide hooks for other cases not supported. We provide several kinds of hooks in 1.3 for this.
John Hasler
> I run a business in Wisconsin, USA. The tax authorities (state and
> federal) I deal with do not interest themselves at all in what
> accounting software I use. They merely require that I "keep records".
> This was also the case in Minnesota and Michigan when I did business
> there.
This is one of the reasons we need a list. Yes the list could include
an area mapping out all the places without government regulation as
well and possible work out what is core functionality. Since these
are areas the project could go after for developers and users now.
Like possible doing simple thing like contacting http://ntaa.com.au/
equal in those countries and areas. And if we knew it matched
Australia we could go after ntaa and other accountants boards to get
presence known. Yes its even possible at times to demo new software
at there conferences for free. So we are not talking large expenses
to advertise. There is most likely other bodies around the world the
project is not providing notice about itself to that its ready to be
used by.
Again, I think that this is a case where we need to be working with people on the ground regarding understanding what the tests are and getting listed.
That doesn't mean we don't have a set of lists. It does mean those lists are driven by folks on the ground. It also means that we have to work with people on the ground, providing help and support in order to make this happen. I think that as we show we can do this, more regions will end up with partners who know their stuff and can help in these areas.
To be used accountants and small business have to know the project
exists. Unfortunately being just on source-forge does not work for
that.
Agreed there.
This is one of the big problems accountancy software works the other
way. To get into the market you program have to match the functional
requirements of that area. So you need start up investment but once
its started in a market you will be able to get on going support
payments.
Agreed there also.
This is why the project needs a map of what the regulation frameworks
look like. Because if one year you match a requirements in an area
that might be enough to kick start partners in that area to maintain
it so expanding developers working on the project. You can only
take advantage of that if you know you matched that year.
Information is power and the current problem is that the information
about accountany software requirements is spread to to four corners of
the earth.
I am very suspect that a lot of regulation requirements world wide
will be just minor reinventing wheel over and over again. Most
governments are not what you call bright when it comes to tax law.
Again, I would like to see this sort of thing be local partner driven rather than centrally managed. There are huge problems in interpreting rules in complex legal frameworks, and the only way I think we can expect these to be both maintained and accurate is with boots on the ground, so to speak.
Best Wishes,
Chris Travers
Peter Dolding