[Advacs-discuss] International flavours.

[Helmut Wollmersdorfer]

Oliver Elphick schrieb:

> 1.  VAT (and sales tax) attaches conceptually to the movement of goods
> and services, 

That is exactly what the AT.VAT-law says. We are both in EU - aren't we?

> not to invoices, although invoices are of course the means
> by which the amount of VAT payable is notified to the customer.

First I should remark, that maybe the word DE:"Rechnung"
http://dict.leo.org/?search=rechnung&searchLoc=0&relink=on&spellToler=standard&sectHdr=on&tableBorder=1&cmpType=relaxed&lang=en 
has not exactly the same meaning as EN:"Invoice". I often tried to find 
out the exact difference of the words invoice, bill and receipt 
(~DE:Quittung").

The main rules of the AT.VAT-law say:
- time (month) of fullfilled contract
- time (month) and _really_ received amount in case of prepayment

The rules of AT.invoice-law specify, that you need to write a 
DE:Rechnung for nearly everything, with exception of small business like 
  e.g. consumation in a pub (in Italy they need writing a document even 
for this).

Common practice is, that the DE:Rechnung-document triggers an 
incoming/outgoing invoice-transaction, accounting to tax.

E.g. for services it is not usual to have a document, if I work as an 
IT-consultant. If my contract says "monthly invoicing based on hours", I 
usally will write the invoice _after_ the end of the month.
Now I have the following possibilties:
- write the date of the last day of the last month on the invoice (date 
back) and use this document date in the ledger, VAT goes to the correct 
month.
- use the real date and have some mechanism to account VAT to the 
correct month.
- use real date and don't care, riscing penalty by tax office (mostly 
zero risk for small companies, small amounts)


> If
> goods are sold for cash or you pay cash or cheque over the counter,
> there is no need for the transactions to be put through Sales or
> Purchase Ledger (though you may *choose* to do so).  Therefore the
> Cashbook and Journal need to be able to handle VAT/Sales tax just as
> much as the Purchase and Sales Ledger modules.

Same here.
In case of a cash-transaction there is a DE:Barrechnung~EN:cash-invoice 
as the document.
Solution - usally - is
cash-account / sales-account
              / VAT-account

Most ledgers here do not have/need an extra Sales or Purchase ledger. 
They define (or let you define) transaction-types:
- Rechnung (Invoice)
   accounts to a personal-account, the appropriate "other" account, VAT,
   and supports
   open items. Adjustments (e.g. for returned goods) can be made by the
   same type of transaction - just put a minus to the amount.
- Zahlung (~cash)
   account to bank or cash, the appropriate "other" account, maybe VAT,
   maybe open items.
- base-transaction
   do what you want, just debit/credit.

At least, VAT can also be triggered by pre-payment (see above). A 
work-around solution is, to create a pseudo-invoice (or you have a 
document like a "pre-payment invitation"), handle this like an invoice, 
account it to "prepayment-revenues" etc. Manage this correctly on the 
customer-accounts, in open-items, VAT and at the transaction of the 
_final_ invoice is not easy. And then the balance sheet ... I was CFO of 
a medium lift-company and experienced all this problems of accounting in 
the building & construction like branches - I can work out detailled 
examples of cases, if you like.

> 2.  I would never expect to see two entries in the Sales Ledger for one
> invoice (though perhaps that is not what your example really means).  

That's a matter of design.
You can have a journal-line like this:
... debit-account credit-account vat-id amount
but
- one invoice-document can have invoice-items going to different
   accounts (sales of goods, shipping, ...)
- one invoice document can have invoice-items with different VAT-IDs
- in case of revision by the tax office, they want to have it traceable
   in detail

> Credits are represented by negative numbers.

Possible.
Usual is D/C (DE: S[oll]/H[aben]) and adjustments or other corrections 
by negative numbers.

> Your example expects to use different account codes for different tax
> rates.  I can't see the need for that; 

That has a practical purpose.
You can find errors more easily.
And it is an easy method, to put all this amounts into the fields of the 
monthly and yearly tax-declaration.

> In a Sales tax model, I would not expect to record the tax on inputs
> (purchases), since that would be part of the cost of the goods (I assume
> that Sales tax paid is not recoverable).

Everything possible happens;-)
- return of goods
- adjustments and corrections
- insolvency
- tax-transfer from supplier to vendor

> The need to restrict input tax on account of exempt outputs (is that a
> requirement in Austria?) illustrates the need for extra data in the VAT
> module.  The Exempt tax rate needs a flag to say that outputs on this
> rate will cause inputs to be restricted and there needs to be a VAT
> return generation program that knows how to handle it.  

Can you explain more verbose? I do not understand exactly, what exempt 
means in this context.

>>The usual way is, to get a certicate of conformity by a - local - 
>>chartered accountant. But this is not a duty.

> Certainly not in Britain; you need to notify the VAT office that you are
> using a computerised accounting system and the VAT people need to
> satisfy themselves that the system will record all the information they
> require.  The Inland Revenue (Income Tax and Corporation Tax) don't
> (strictly) impose any specific requirements except that you have
> receipts for all expenditure.  Any other requirements come from the
> Companies Acts requirement that a registered company should keep proper
> and up-to-date books.

Similar here. But large ledger-vendors like to have certificates, and 
CFOs like to have certificates ...

>>Table of accounts:
>>There exist sample tables here in AT and DE. They are not mandatory, but 
>>save time (training of accountants and all involved people). At least 
>>they support rules of taxation, business law and 
>>reporting/data-exchange. Import of such nationalised example tables 
>>should be supported.

> Could you post an example?

I will try to collect some.

>>Special rules (examples):
>>AT: export interface for tax-revision (mandatory)

> What does that mean?

They - from the tax-office - come with a laptop and import ledger-data 
(details to be investigated) into their check-routines. Piping the 
print-output of account-listings and journal-listing to files or 
something similar is sufficient - I believe.

>>AT: rules for electronic invoices

> EDI?

Yes.
Or e.g. non-EDI must have an secure signature. As the level level of 
"secure" (defined by AT.signature-law) is not possible, sending a 
non-paper invoice is not allowed. In fact, many people do it, and 
customers accept it.

> There's a saying: "The Devil is in the details".

=DE: "Der Teufel liegt im Detail".

Helmut Wollmersdorfer