Re: EU VAT

[Nigel Titley <..hidden..>]

On Mon, 2011-08-08 at 13:07 -0700, Chris Travers wrote:

> > In my country (The Netherlands), two tax rates apply for goods sold within
> > the country, based on the type of good sold. When delivering intra-EU I have
> > to deliver the services (I'm a services company) free of VAT, stating that
> > the VAT has been deferred to the receiver. I'm assuming this is the same
> > situation as the situation with the goods sold where the receiver submits
> > their VAT number.
> 
> Ok.  As I understand it, you don't currently have to report the services?

Yes, he does. Goods and services both have to be reported (for example I
buy services from a French company that calibrates equipment for me).
They deliver it VAT-free and I have to do the reverse-VAT trick on it.

> > Outside the EU, no VAT charges apply to services. I'm affraid I never looked
> > up the case for goods, but I can do so, when further investigating the VAT
> > reporting requirements.
> 
> Ok.

Well, buying in services from outside the EU does attract VAT and you
are supposed to report it.

> So on the simple case, tying a transaction to a country would probably
> be helpful but that seems like an awefully location-specific approach.
>  I am trying to think of a better one.

No, unfortunately that doesn't work. If I supply goods to one customer
in France for whom I have the VAT number then I don't charge VAT but I
have to report it on the ECSL form. On the other hand for his neighbour
next door, for whom I don't have the VAT number, I charge VAT at the UK
rate and *don't have to report it on the ECSL form (but I do have to
report it as VAT). 

> Would it be helpful to require that a transaction be tied to a
> location (either store or shipping address)?  Then reports could be
> generated using some sort of location-specific logic.  It would also
> help with things like the SST insanity that seems to be sweeping the
> US.

No... it is customer specific... hence our solution using Sales
accounts. You *could* use rough logic like

if (tax amount != 0)
{
	VAT-payable
}
elsif (delivery address within EU AND tax amount == 0)
{
	VAT-free
}
else
{
	Export
}

But this only works for us because we don't sell zero rated goods like
baby clothes.

> > Same here, with regard to regulations. I have tried (succesfully) to work my
> > way around intra-EU delivery of goods and services for the time being, so I
> > can't speak from personal experience.

It isn't too difficult, but you have to keep track of things

> >>
> >> People get really excited about VAT, but for most businesses it's really
> >> simple. Accounting software tends to present the numbers at the press of
> >> a button at the quarter end (nice, but not essential), but it's simple
> >> to do with LedgerSMB reports anyway.
> >
> > Unless, of course, you need to report which countries you delivered your
> > goods to at the VAT free "rate".

Which you do...
> >> Goods being permanently exported out of the EU are VAT free.
> >>
> >
> > As far as The Netherlands is concerned: reporting (and payment!) for very
> > small businesses is on a quarterly basis, but the tax authorities can
> > require monthly reporting and payment if the volume of the payments
> > increases.
> > The reporting (and payments) are on accrual basis; I'm not aware of a
> > cash-based option.
> 
> Ok.  Accrual is easier to do anyway.

Cash is an option in UK, and can be helpful with cashflow

> > Although my personal needs would probably be served by a solution like
> > Nigel's, I'd like to warn for the explosion of a chart of accounts, if too
> > many information requirements are encoded into the accounts. I've worked for
> > a company where 2 accounts have been blown up into 64 accounts, simply
> > because they encoded required reporting information into them.
> > The information encoded into the accounts was derived classification from
> > the customers. As a result, the accountant was forced to redo the derivation
> > regularly, finding differences and creating reclassification postings to
> > keep accurate reporting information.

I agree... it's a pain, but I can't think of any other way to do it in a
general and portable fashion.

> Just to be clear, in the end we would want to support whatever ways
> people in the community find most helpful.  The larger issues have to
> do with inventory tracking items and the fact that sales accounts
> don't admit readily of this sort of default that Nigel is doing in
> that case as a generally applicable approach.

I'd really like to understand what the issues are with inventory
tracking and multiple sales accounts.

> > The solution we put into place was to record the customers the transactions
> > were executed with (posting onto a single account) and running the
> > aggregations on the classifications in a reporting environment.
> > In the end, the above proved to be much more robust to requirements changes:
> > all the basic information regarding the transaction was available (country
> > of shipment, customer and hence its country, etc), so when additional
> > requirements were put forward, we were able to quickly adapt to these new
> > requirements without restructuring the chart of accounts and doing mass
> > reclass postings.
> 
> So we have to record all information relevant to the tax system and
> the transaction together.  Then the reporting side can work properly.
> 
> What additional information do we need to record?

You need to record whether the delivery was made under the intra-EU
reverse VAT scheme, but in my view that's a less general solution.
> 
> > Nigel, does the above sound like what your perl script for ECSL form
> > submission is doing?

Yes, roughly. What my perl script does is searches for all invoices to
EU countries (which, I must say, would be easier to do if the country
fields were constrained to a list) and which have zero VAT. But as I
say, this only works because we don't sell food and baby clothes.

If we could set general attributes onto transactions then this would
work in the general case and we could extract the appropriate reports.
I'd be very happy to go down this route rather than the sales account
route.
 
> > Anyway, these are my thoughts and experience. I'd like to explain that I'm
> > not a bookkeeper or accountant; I'm an information analyst with experience
> > in the finance field who is self employed and therefor needs to keep his own
> > books :-)

Thanks

Nigel