[Advacs-discuss] International flavours.

[Oliver Elphick]

On Wed, 2004-08-11 at 11:43, Helmut Wollmersdorfer wrote:
> David Palmer schrieb:
> 
> >>  I do feel it needs its own module; and doing it like that makes the
> >>  whole thing more flexible for use in countries which don't have
> >>  VAT.-:Unquote.
> 
> > Perhaps in this way the different international packages could be 
> > defined for downloading.
> > Other countries have their own particular quirks, e.g., G.S.T., goods 
> > and services tax. The VAT module may well only need renaming for that 
> > purpose.
> 
> I think, that for most cases a default logic can be used and only a 
> table of tax codes needs to be configured.
> 
> E.g.
> tax.code
> tax.percentage
> tax.description
> tax.expenses-account
> tax.earnings-account
> tax.valid-from-date
> tax.valid-to-date
> 
> Sample records:
> T10  10%   reduced VAT  2210  3210  1994-01-01  9999-12-31
> T20  10%   normal VAT   2220  3220  1994-01-01  9999-12-31
> 
> Accounts
> ID    Description
> 2210  VAT from incoming invoices 10%
> 3210  VAT from outgoing invoices 10%
> 8010  Earnings 10%                   default-tax.code=T10
> 7530  Expenses books 10%             default-tax.code=T10
> C1234 Customer example
> 
> Sample of an outgoing Invoice transaction
> Doc-ID/Date/Amount-brutto/debit/credit/Tax-ID
> AR4711 2004-08-11 110.00 C1234 8010 T10
> 
> This internally generates
> AR4711 2004-08-11 100.00 C1234 8010 T10
> AR4711 2004-08-11  10.00 C1234 3210 T10

I think your example demonstrates several differences between common
practice and my thinking, which it is worth explaining, because it will
help with understanding my design.  It may be that there are sufficient
differences in the practice of other countries for problems to arise:
let us see.

1.  VAT (and sales tax) attaches conceptually to the movement of goods
and services, not to invoices, although invoices are of course the means
by which the amount of VAT payable is notified to the customer.  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.

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).  In
your example I would see:

Sales ledger:
Ref    Date        Amount  Code     Other sales ledger fields...
AR4711 2004-08-11  110.00  C1234    ...such as open-item matching...

General ledger:
Ref    Date        Amount  Code   Tax-rate
AR4711 2004-08-11 -100.00  8010   T10

VAT Record:
Ref    Date        Amount  Code   Tax-rate      Net  Input/  Date
                   (=VAT)                            output  declared
AR4711 2004-08-11  -10.00  2210   T10       -100.00    O     NULL

Credits are represented by negative numbers.

Since all three tables inherit from ledger, I could expect to be able to
say:

  SELECT SUM(amount) FROM ledger;

and get back 0.00, thus demonstrating that double entry is correct.

On the other hand, I can get all the information I need for the VAT
return by selecting the VAT Record table alone:

  SELECT      IO, taxrate,
              SUM(CASE WHEN IO = 'O' 0-amount ELSE amount END) AS "VAT",
              SUM(net) AS "Net"
    FROM      VAT_record
    WHERE     date_declared IS NULL AND
              date < '2004-08-01'   -- end of return period
    GROUP BY  IO, taxrate
    ORDER BY  IO, taxrate;

Those results would then need to be processed in case of the need to
restrict the claim of input tax when there are exempt outputs.

Your example expects to use different account codes for different tax
rates.  I can't see the need for that; since I record the tax-rate code
in the VAT record, I can easily separate the amounts by a simple
SELECT...GROUP BY.  Similarly, I don't need separate codes for input and
output VAT, since all the necessary data is recorded in the VAT record. 
(But you can use separate codes if you *want to*.)

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

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.  The great
benefit of PostgreSQL's inherited tables is that I can put those extra
fields in the VAT account records (the VAT account table will inherit
from the generic account table) and be able to ignore them when I simply
want a list of all accounts.

> > I note in the project description that the aim is to meet international 
> > accounting standards, but does this provide the necessary compliance 
> > requirements for acceptance by the multitude of national tax departments 
> > for their respective endorsements?
> 
> 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.

> The main things are:
> Basics:
> - conformance to usual account rules ("good practice")
> - technical aspects of archiving and data security
> 
> 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?

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

What does that mean?

> AT: mandatory fields of an invoice (date, addresses, details, VAT-ID, 
> TAX-ID, Company-ID ...)
> AT: rules for electronic invoices

EDI?

> > Just my take, but I think that this would be the fastest way to gain 
> > market acceptance if these respective tax departments were to list the 
> > future Advacs package as approved goods, as this is generally the first 
> > place accountants look when determining their software requirements.
> > I have already emailed the Australian tax dept. re their compliance 
> > requirements, but perhaps a little further research might pay dividends 
> > with regard to acceptance within the U.S. and other markets?
> > Regards,
> 
> All this will need local volunteers or sponsors. At least, somebody 
> needs to understand the local language and have access to rules and 
> laws. For some (most?) countries this information is available in www, 
> but needs time to understand if somebody is not a local expert. I 
> experienced this yesterday, as I tried to read the GB business-law and 
> VAT-law;-)

I wouldn't attempt to build a module for another country without local
guidance and specifications.

> In the EU a lot of rules are very similar, but details can vary.

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

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "Be still before the LORD and wait patiently for him;
      do not fret when men succeed in their ways, when they
      carry out their wicked schemes." 
                            Psalms 37:7