Re: EU VAT

[Chris Travers <..hidden..>]

Hi;

On Mon, Aug 8, 2011 at 12:42 PM, Erik Huelsmann <..hidden..> 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?

> 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.

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.

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.
>
>>
>> If sending goods to other EU countries, UK VAT is charged at the usual
>> rate, unless the customer provides a VAT number, in which case the goods
>> are supplied VAT-free, but sale has to be recorded on a supplemental VAT
>> form. This turns up if you put anything other than zero in the 'Supplies
>> to other EU countries' box, which is for VAT free supplies where a VAT
>> number has been supplied. I just recorded these by keeping the printed
>> invoices in a separate file! Purchasing from another country I'm not
>> sure about, as I never have. You can claim back the VAT paid in the
>> source country if you have paid it, or you have to pay VAT at your local
>> rate if you provided a VAT number to be exempted.
>
> 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.
>
>>
>> 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".
>
>>
>> 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.
>
> 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.

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.

> 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?

> Nigel, does the above sound like what your perl script for ECSL form
> submission is doing?
>
> 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 :-)

As always, very helpful.

Best Wishes,
Chris Travers