Class.net Help >
Accounting/Ledger
PreviousNext

Accounting / Ledger

General

The Class Accounting Ledger has been designed to produce a controlled ledger, but with specific emphasis on debt collection.
The layout and approach is different from most accounting ledgers to allow the specific requirements of schools to be incorporated.

The suggestions set out below are those of Infospeed, and represent only one view. As with all financial issues, you are advised to seek the advice of your accountants.

Set Up

Before starting to use the ledger, please ensure the following settings are complete, especially exchange rate values.

Set up items in the sequence below:

Currencies - Exchange Rates

Typical setup for GBP to other currencies:

Typical set up for other currencies - to GBP:

A normal setup will show "Base to Euro" (example immediately above) and "Sterling to Euro" (example further above) as the same value of 1.548143.
Please double-click these values before proceeding.

The reciprocal value of each currency is automatically set eg. GBP to EUR = 1.548143, then EUR to GBP is automatically set = 0.645935 (as per above example). If you alter 0.0.645935, then 1.548143 will automatically change etc.

Account Code Structure
Maintenance/Settings > General Settings > Company > Company

The top section (Accounting Codes) establishes whether Cost Centres, Department and Nominal Codes are in use.
You will need to set at least the Nominal Codes to be in use.

Larger school setting:
Cost Centre = Company
Department = School/Admin
Nominal = Specific items such as tuition, accommodation, overheads etc.

Set whether codes are to be purely numeric or not, and the maximum length of code.

Trust Accounting
(mainly Australia/New Zealand)
See "Company Settings - ledger" for parameters

Default Allocation Rule
Set the default allocation rule (Maintenance/Settings > General Settings > Accounting > Allocation Rules)

Also set your Cost Centre and Department Codes if in use:

Nominal Codes
Maintenance/Settings > General Settings > Accounting > Nominal Codes

Set up the Nominal Codes (mandatory).
If Class has been in use prior to the introduction of the ledger, you will need to create the accounting codes already in use in your price lists.

Transaction Types
Maintenance/Settings > General Settings > Accounting > Transaction Types

Note: numbers have been used to prefix descriptions to show items in logical order. They are sorted in most displays, alphabetically.

You are now ready to start using the ledger, but you may find the rest of this section useful to read before you start, especially the section dealing with "opening balances".


Accounting Principles / Issues

The ledger has been constructed to provide information for schools based around "Cash Accounting" or "Invoice Accounting". 
The first uses actual receipts as the basis for determining income, whereas the second uses invoices/credits as the basis.
Both are discussed in more detail below.

Cash Accounting

As a receipt is entered, Class will allocate the value across the enrolment elements, ie. tuition, accommodation, transfers etc. according to a set of rules.
The rules are defined by the user, for example money can be spread evenly across the enrolment, or it could be allocated to accommodation first, and tuition second. The rule mechanism allows a wide range of options, or if required the user can specify the allocation manually at the point of entry.

Income can easily be monitored, day by day, week by week, or month by month etc. At the end of an accounting period, a report can be produced to give an approximation of any "forward" income, ie. receipts from enrolments which complete after the period end.

Money received after a period end for an enrolment within the period (eg. late payment) is considered as income in the period of receipt.

Example: only tuition and accommodation are considered.

Year 1/1/2012-31/12/2012

Enrolment value £12000 covering period 1/3/2012 - 1/3/2013
If all had been paid, then 3/12ths would be considered "forward" income.
If £9000 has been paid, then no "forward" income would apply.

Invoice Accounting

This is the preferred and most accurate way of accounting for a language school. Income is derived from invoice/credit note values, not receipts.

Invoices/credits for the period are analysed by the system, by nominal code, for posting to the accounting system, by journal.
(The Nominal Ledger report is in Excel and it may be possible for the accounting system to directly import the values from the spreadsheet, alternatively, it can be manually posted).

Invoiced sales are reduced by forward income. This is calculated by producing an Invoice Statistical report, which analyses the income of all booking elements spread over their duration, eg. the income for a 12 month booking would be spread over 12 months.

The recommended process is for "registrars" to produce proformas which are sent with a booking confirmation, with finance responsible for producing invoices. (For information, there is a permission which can block users from producing invoices).

In practice, this means an agent receives proformas all the time (although he thinks they are invoices!) and the invoice is produced only by finance (batch process) and acts purely as an accounting document and generally not sent to the agent. (In value, it is the same as the proforma).

Example processes:

1.
Enrolments entered and proformas (not invoices) sent to agent/student, generally by email, directly from Class. The proforma is often called a "Booking Confirmation" and has a reference number (agent/student number) as its identification - not an invoice number!

2.
On a weekly basis (or less frequently if decided by finance) an invoice batch run is completed, which converts all proformas into invoices for arrivals up to dd/mm/yy. The date here is normally "last weekend".

This weekly invoice print (printing may also mean emailing) run might be done on a Thursday following the weekend's arrivals. This allows initial booking changes to be completed before converting to an invoice. It is useful to minimise the number of invoices/credits produced and this can be done by delaying conversion to an invoice. Some schools may decide only to convert to invoices when required to do so for accounting purposes, this can be after the accounting period end.

If agents are set with Finance rule, "Print Invoice if same as Proforma" = No, then generally no invoices will be sent to the agent/student during the batch invoice run.

In summary, we recommend proformas are sent to the agent/student and converted to invoices only after arrival, via the invoice batch print run.

3. A few points to bear in mind:

a) Debt collection is not dependent on an invoice (or a proforma) being produced. Debt values occur directly from the booking itself and receipts are entered against the booking (not the invoice/credit, as in a traditional sales ledger system).

b) If the agent will not accept proformas (unusual) you can set the agent finance record to "Send Customer Proformas" = No, this will force only invoices/credits to be produced.

c) After the student arrives and then makes further changes to his enrolments, we suggest the registrar continues to produce proformas, which would be regularly converted to invoices by the batch invoice print run. This provides a simple single rule for registrars - "Only Produce Proformas". Although no harm occurs if invoices are accidentally produced by the registrar.
 
If you would like to discuss these principles, please contact Support.

Deferred Income

As Class (from invoices) creates the sale in the "invoice created period", it is necessary to reduce the sales value in the accounts by the amount of the forward sales (often called deferred income).
This is done via an Excel report as follows:

Reporting/Statistics Generator/Invoicing:
These are normally sample reports already set up for this purpose, but if not, contact Support for examples.
The report is normally set to show income (for future periods) by Nominal Code, to allow a prepayment journal to be prepared.

It is recommended that deferred income (invoices/credit notes) from this Nominal Analysis be posted on a monthly (or whatever accounting period is in operation) basis. The accounting entry would be reversed out for the next accounting period.

Foreign Currency Issues

Foreign currency paid into a base currency (eg. Sterling) account could have the following accounting entries.

Example:

$1000 received and credited to the account @ 0.67 = £666.67.
Actual credit on bank statement £665.00

Accounting:
Ledger - debit bank £666.67
Ledger - credit debtors - £666.67

Bank Statement:
In reconciling the bank statement with the cashbook, a £1.67 difference will show. This would be rectified by writing off the variance as follows:

Debit Exchange difference - £1.67
Credit Bank - £1.67

What if the difference is to be charged to the ledger account?
A negative *receipt can be entered and charged to the appropriate ledger/student enrolment.

(*Alternatively, a new receipt transaction type could be set up - "Exchange Differences". The Nominal code would credit bank/debit debtors. This would be cleared by a receipt of £1.67).

What if a foreign currency ($) bank account is used to settle a £ account instead of paying into a base currency (Sterling) account?

Example:

$1000 received and credited to the ledger account @ 0.67 = £666.67

(It is likely that the exchange rate used will not be the rate used for valuing the $ account in the nominal ledger, ie. the rate is likely to be a "current" rate).

Accounting:
Ledger - debit bank £666.67
Ledger - credit debtors - £666.67

Exchange rate differences will occur when revaluing the dollars at the accounting period end (in total).

The $ bank account = $20,000
The nominal ledger balance = $13,000

If the exchange rate for $'s at the period end is 0.68, then a provision would be made for the exchange rate difference as follows:
$20,000 x 0.68 = £13,600

Debit $ bank account - £600
Credit Exchange Rate gain/loss provision - £600


Copyright 2013 Infospeed Limited