[Advacs-discuss] Prepayments

[Oliver Elphick]

On Tue, 2004-08-31 at 10:06, Helmut Wollmersdorfer wrote:
> According to a current discussion on sql-ledger-users@sql-ledger.org I 
> want to write down the problems concerning prepayments. I hope we can 
> avoid the weaknesses of other ledgers.

This is how I have in the past implemented and now propose to implement
accruals and prepayments:

1. First, we need to distinguish between accounts that are assigned to
the Balance Sheet and accounts that are assigned to the Profit and Loss
account - this is effectively the distinction between capital and
revenue.

Balance sheet accounts are naturally balanced off and carried down on
the same account; where they appear on the balance sheet is controlled
by the subheading assigned to the account (or to its control account if
it is in a subsidiary ledger); thus the sales ledger control account
will be assigned to the Trade Debtors section of the balance sheet and
so all balances on the sales ledger will go there.  It is possible to
assign debit and credit balances to different subheadings.  (Up till now
I had not considered the problem of negative balances in the sales
ledger - they would have been aggregated with the mass of sales ledger
balances, but I see that this would be incorrect.  I think that control
accounts need an extra flag to say whether balances on different
accounts should be netted off or should be accumulated into separate
debit and credit totals.  In the GL schema, this flag belongs on the
ctrl_ac_type table.)

Revenue accounts are summed and their balances transferred to the Profit
and Loss account, so there is no balance to carry down, except where the
second type of accrual applies.

2. The second type of accrual is used to take account of income and
expenditure in the period to which it relates, even when the actual
transaction postings have their dates in other periods.  In this case
(handled by the accruals module) a note is made of the amount carried
down, the account in which it is carried down and the subsection on the
balance sheet in which it is to be shown; the system can also be used
for balance sheet accounts, but in that case the balance sheet
subsection must be different from the one to which the account belongs,
or the accrual is cancelled out.  This type of accrual is used for
expenditure incurred but not yet invoiced (e.g. telephone), items paid
in advance (e.g. insurance) and for stock and work-in-progress (in
conjuction with the stock and project costing modules if appropriate). 
These accruals are made as notes applying at a particular period end
date and are applied to the account at that date before the account is
balanced off.  For items such as insurance which are paid at long
intervals, we should provide an automatic mechanism for spreading their
cost over the appropriate periods by generating accruals at each
appropriate period end.

An accrual of this type can be regarded as an ephemeral journal entry -
it applies at the period end and is automatically reversed the next day.

> Requirements:
> 
> 1) Prepayments of customers are liabilities and have to be reported 
> under liabilities in the financial report.

This can be handled by distinguishing between debit and credit balances
in the sales ledger as described above.

> 2) Prepayments to vendors (or other business partners) have to be 
> reported under the debit side of the financial report. This has to go to 
> different accounts (in Austria), e.g. "Prepayments for fixed assets", 
> "prepayments for goods and services", "other outstanding money" (e.g. 
> deposit for office or car rental, prepayment of wages, prepayment of 
> taxes etc.)

Again we must distinguish between credit and debit balances in the
purchase ledger.

The fine distinctions cannot be handled automatically without a lot of
work (because there is nothing in a purchase ledger balance by itself to
say to what goods or services it refers) but the mechanisms for handling
them with manual entries will be provided from the start - this can be
done by type 2 accruals.  This should be quite adequate for the small to
medium-sized enterprises who are the first target users.  

> 3) Private law (in Austria) says, that debit and credits to the same 
> business partner can only be balanced, if the payment terms match at 
> date of balancing. E.g. if a customer prepaid EUR 100,- at 2004-07-01 
> for contract B, and has an open item of EUR 100,- for contract A to pay 
> on 2004-08-01. We go bankrupt on 2004-07-15. This means, that the 
> customers has to pay _full_ EUR 100,- on 2004-08-01 for contract A, and 
> gets back only a percentage of the prepayment after some time, e.g. 20% 
> in 2006.

In practice, this is only of interest if there is doubt of the
supplier's viability or when it actually goes into liquidation.  It is
possible that we might consider putting a facility to manage this in the
project costing module, but it would not be sensible to try to
incorporate it in the normal running of the purchase ledger.  If we are
talking of separate transactions by the same person as both customer and
supplier, then see (6) below.

> 4) A business partner can be vendor and customer, e.g we buy materials 
> from him, and we deliver our products to him. According to contract, 
> balancing between vendor and customer account can be agreed.

In English this is termed the right of set-off.  If amounts are to be
set off against different accounts, this is best done by a journal entry
when the set-off is crystallised and by accrual entries (of the second
type) at period ends before crystallisation.

> 5) According to contract money transfer through a third party can be 
> agreed. E.g. if somebody builds a large building, he has large 
> VAT-returns on his tax account, and his suppliers must pay VAT to the 
> tax office. Thus it is sometimes usual to agree transfers via the tax 
> office.

I don't understand this; who is making paynments to whom?

> 6) From 1) to 5) follows, that open items in the same business partner 
> account should go to different parts of the balance sheet, depending on 
> their sign.

Customers and suppliers will naturally have separate accounts since they
will belong to different ledgers, even if the same person is both
customer and supplier.  It would be a good thing to have the concept of
a person to which separate accounts could refer to link them together.

> 7) From 1) to 6) follows, that AR, AP and Cash modules need a logic, to 
> provide the convenience of open item support in all cases of prepayment, 
> overpayment, invoice adjustments after payment, return goods, deposits, 
> transfers, and even the combination of them.

Yes; open-item matching will be provided.

-- 
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
                 ========================================
     " ...Take heed, and beware of covetousness; for a man's
      life consisteth not in the abundance of the things 
      which he possesseth."       Luke 12:15