Accounting

Contents

Relationship between the Student and the Debtor within onCourse
Principles of Accrual Accounting
Explanation of Financial Transactions Generated by the System
Financial Transactions generated by Enrolment and Payment Process
Financial Transactions Generated by Enrolment Cancellation Process
Vouchers and Financial Transactions
Contra Payment Types for Refunds
Deferred Income
How Deferred Incomes Works
What Happens If I have to Cancel or Add a Session to a Class?
What if I want all funds to be transferred at the commencement of the Class?
Assigning Account Codes within onCourse
Accessing Financial Information from onCourse
Locating data using related records
Printed Financial Reports
Copying info within list view windows to Excel
CSV Exports
Exporting to MYOB
Running Queries Directly from the Database
Banking and Reconciliation
Banking
Reconciliation

The following chapter provides an overview of the principles of the onCourse financial process, as well as clear explanations as to how you get the information you need from onCourse in order to obtain your monthly / weekly reports.

Relationship between the Student and the Debtor within onCourse

onCourse has a clear separation between financial data and enrolment data. Students enrol in classes. Students may not be a company, since only natural people can enrol in a class. The contact linked to an invoice (the debtor) may however be a company or a natural person. The student and the debtor may be the same person; this often happens for a simple enrolment of one person into one class. The student and the debtor could be two different people, or in fact a debtor could pay for the enrolment of multiple students on one invoice.

In the following example of a basic enrolment, there are 2 students Peter and Amy, and the invoice is issued to the the debtor Geoff (1). Geoff then pays the full amount (2).

Simple Enrolment for Student and Debtor

If an enrolment needs to be cancelled for whatever reason, the cancellation process will generate a credit note to the debtor. It is important to note that although Peter might phone to cancel his enrolment, the credit can only be issued back to Geoff in onCourse.

Student and Debtor refund process

As the credit note is attached to the debtor, it can be applied to another enrolment for the same student or a different student. In the following example, Peter wishes to cancel his enrolment so the credit note is issued to Geoff as the debtor. Geoff is then able to enrol another person (Sue) into another course using the credit note that has been issued.

Original student cancels, allowing the credit note to be applied by the debtor (Geoff) to a new student (Sue)

Principles of Accrual Accounting

onCourse works on the principle of accrual accounting, which means that the income is recorded to the General Ledger (GL) at the point the invoice has been generated, irrespective of when the payment is received. The following diagrams illustrate the difference between accrual accounting and cash accounting and the point at which income is recorded against the GL.

You will note also that the income that is received will initially be assigned to a liability account, then transferred to the income account once the class commences. For further information see the Deferred Income section of the user handbook.

Comparison of accrual and cash accounting standards

Explanation of Financial Transactions Generated by the System

onCourse follows the basic concepts of double-entry accounting: all financial transactions are written to the general ledger in balanced pairs. Asset and expense sit on the left, and liability and income on the right. So an increase in Asset could be matched with an equal decrease in another Asset. An increase in Expense might be matched by an equal increase in Liability.

Basic principles of double-entry accounting

Financial Transactions generated by Enrolment and Payment Process

Within the Transaction window of onCourse, you can clearly see the individual transaction lines that are generated by an enrolment. In this first example, a user creates an enrolment for one student into a class with no GST.

(1) $300 is added to the Pre Paid Fees Liability Account linked to the Class being enrolled in,
(2) $300 is added to Trade Debtors which is a record of the money owed to the college.
(3) Now the payment reverses the $300 in Trade Debtors,
(4) and $300 is credited to the cheque account where your income is receipted
(5) deferred income is transferred from Prepaid Fees Liability account to Income account once the Class commences

Transactions generated by simple enrolment Non GST Class including deferred income

For a class fee that includes GST, this would add 2 x additional transaction lines for the GST component of the class fee as shown.

(1) $350 is added to the liability account linked to the Class being enrolled in,
(2) $350 is added to Trade Debtors which is a record of the money owed to the college.
(3) $35 is added to Trade Debtor which is a record of the GST amount owing,
(4) $35 is the GST amount to be received from the Customer (shown as a liability)
(5) Now the payment reverses the total amount owing (Fee + GST component) in Trade Debtors
(6) and $385 is credited to the cheque account where your income is receipted
(7) deferred income is transferred from Prepaid Fees Liability account to Income account once Class commences

Transactions generated by simple enrolment GST Class including deferred income

Transactions created when a discount is applied

Discounts in onCourse are charged to a Cost of Sale (COS) account called Discounts Given. The transactions processed to this account, and balance of this account allow you to keep an accurate track of the cost to the business of the discounts given during the sales process.

Discounts given do not reduce the income recorded in the income account(s) of your college. To determine the income earned, you can deduct the balance of the COS accounts(s) from the income account(s)

This works in conjunctions with the standard enrolment transaction posting process, and the deferred income posting for income.

For example, for a $300 (GST free) enrolment fee, with a $100 discount applied at time of enrolment, the student owes and pays the balance of $200 in full during enrolment.

(1) $200 is recorded as pre-paid fees liability. This is the income for the full enrolment, excluding the discounted amount
(2) $200 is recorded as owing in the trade debtors account.
(3) $100, the value of the discount, is posted to the classes set income account
(4) $100, the value of the discount is posted to the COS sale account Discounts Given
(5) The student pays the balance of the enrolment fee, $200 and the cheque account is credited with the Trade Debtor account is debited. The student has now paid in full and owes no further money.
(6) When the class commences (or other choice of setting) the remaining income, $200, from the enrolment is debited from the pre-paid fees liability and credited to the income account set for the class.

Transactions generated by simple enrolment GST Class including deferred income

Financial Transactions Generated by Enrolment Cancellation Process

When canceling an enrolment a credit note is issued, this results in the opposite effect to the original invoice. Note that this does not automatically generate a payment out to the student since they might use that credit against a further enrolment or choose to have it paid to them in one of a number of ways.

If you need to cancel an enrolment or enrolments for a Class that has not yet commenced, the cancellation process will trigger the deferred income held in the Prepaid Fees Liability Account to be transferred to the income account. This transfer is the first part of the cancellation process.

Tip

If an enrolment or enrolments are cancelled after the Class has commenced, the remainder / balance of funds will be transferred from the Prepaid Fees Liability Account to the Income account, this is triggered by the cancellation process.

(1) Deferred income is transferred from Prepaid Fees Liability account to Income account
(2) $300 is removed from your income
(3) and $300 is deducted from the trade debtor account since you are reversing the debt this person had to you

Transactions generated by the cancellation of a GST free enrolment including transfer of deferred income

If a refund is to be given to the original debtor, the resulting financial transactions are as follows.

(1) When you pay the debtor their refund, $300 goes out of the cheque account and
(2) $300 of trade debtors is removed

Transactions generated by refund for a non GST Class

Here is an example of the transactions generated for an enrolment cancellation and refund for a class with GST.

(1) Deferred income is transferred from Prepaid Fees Liability account to Income account
(2) $350 is deducted from the trade debtors account since you are reversing the debt this person had to you,
(3) and $350 is removed from your income.
(4) The $35 GST portion of the debt is expunged and
(5) your $35 debt to the ATO for this GST is also removed.
(6) When you pay the debtor their refund, $385 goes out of the cheque account and
(7) $385 of trade debtors is removed.

Transactions generated by a GST inclusive class cancellation and refund including deferred income

Transactions created when a discount is applied

For example, for a $300 (GST free) enrolment fee, with a $100 discount applied at time of enrolment, the student owes and pays the balance of $200 in full during enrolment. When this enrolment is cancelled and the student is refunded, the following transactions are processed:

(1) $200 is reversed from the income account. This is the income for the full enrolment, excluding the discounted amount
(2) $200 is recorded as owing to the student/payer in the trade debtors account.
(3) $100, the value of the discount, is also reversed from the classes set income account
(4) $100, the value of the discount is reversed from the COS sale account Discounts Given
(5) The student is refunded $200 and the cheque account is debited and the Trade Debtor account is credited. The student has now been paid in full and the college owes them no further money.

Transactions generated by simple enrolment GST Class including deferred income

Vouchers and Financial Transactions

Vouchers are a mechanism to pre-purchase access to training before the user has selected a product and in effect, have credit available to redeem at a point of their choosing up until the voucher automatically expires. For more information on creating and selling vouchers, refer to the Vouchers chapter.

All voucher sales are non-taxable supply, as the GST component can not be determined until the voucher is redeemed and onCourse knows if the product chosen has GST applied or is GST free. Voucher sales are grouped on invoices under the heading 'The following items are not a taxable supply'.

When a voucher is purchased, the purchase price of the voucher is held in a liability account until such time as the voucher is redeemed or expired. The choice of liability account is set in your financial preferences, but by default will be called Voucher Liability.

As a voucher can be sold for less than it's redemption value, or given away for free, the difference between the sale cost and the redemption cost will be calculated as a Cost of Sale and charge to your chosen account for Voucher Underpayment.

At the point of redemption, a voucher acts as a payment in method, and behaves like cash, cheque or card. Mixed payments can be made during redemption if the voucher balance doesn't cover the full cost of sale.

(1) In this example a voucher is sold for $200 with a redemption value of $200. When the voucher is purchased, an invoice is raised for the sale price. The Trade Debtors account is increased.
(2) The sale price of the voucher increases the Voucher Liability account by the same amount. If the voucher was given away for free, the sale price would be $0.
(3) When the invoice for the voucher is paid for, the Cheque Account is increased by the value of the payment made.
(4) The Trade Debtors account is reversed by the value of the payment in for the invoice. Vouchers do not have to be 'paid for' to be redeemable. Your invoice payment terms for vouchers can be negotiable as per all your invoice terms.
(5) A student enrols in a class and the cost of the enrolment fee is posted to the Trade Debtors account as per any other invoice created
(6) The income component of the class fee is posted to the Prepaid Fees Liability account if the class has not yet commenced, as per all enrolments
(7) The voucher is used as a payment method. In this example, the total invoice balance outstanding is $264, but the voucher is only valid for $200. The Trade Debtors account is debited by the value of the voucher.
(8) The Voucher Liability account is debited by the sale price of the voucher. There is no Voucher Liability (or credit available to the voucher holder) remaining.
(9) The balance outstanding of the invoice is paid by another payment method such as cash or credit card
(10) The Trade Debtors asset is reduced by the amount paid in the previous step. The amount payable on the invoice created on enrolment is now $0.

Transactions generated by creating and redeeming a voucher for the same purchase and redemption price

(1) In this second example a voucher is sold for $300 with an open ended redemption value of one enrolment (from a pre-approved list of courses). The actual dollar value of the redemption value will depend on what class is chosen. When the voucher is purchased, an invoice is raised for the sale price. The Trade Debtors account is increased by the sale price.
(2) The sale price of the voucher increases the Voucher Liability account by the same amount.
(3) When the invoice for the voucher is paid for, the Cheque Account is increased by the value of the payment made.
(4) The Trade Debtors account is reversed by the value of the payment in for the invoice.
(5) A student enrols in a class and the cost of the enrolment fee is posted to the Trade Debtors account as per any other invoice created. In this example the class fee is $5,200, which is significantly more than the purchase price of the voucher.
(6) The income component of the class fee is posted to the Prepaid Fees Liability account if the class has not yet commenced, as per all enrolments
(7) The voucher is used as a payment method. In this example, the total invoice balance outstanding is $5,200, but the voucher is only cost $300. The Trade Debtors account is debited by the purchase price of the voucher.
(8) The Voucher Liability account is debited by the original sale price of the voucher. There is no Voucher Liability (or credit available to the voucher holder) remaining.
(9) The balance outstanding of the invoice is 'paid for' by charging the difference to the Cost of Sale account for Voucher Underpayment, in this case $4,900.
(10) The Trade Debtors asset is reduced by the amount charged in the previous step. The amount payable on the invoice created on enrolment is now $0.

Transactions generated by creating and redeeming a voucher for a higher value than the purchase price

Unlike in these examples, the entirety of the Voucher redemption value does not need to be used in a single enrolment for a single student. The voucher credit can be redeemed over time or can be used to pay for multiple invoices and/or enrolments.

If a voucher expires before it's value is fully redeemed, any remaining credit in the Voucher Liability general ledger account will be transferred to the Vouchers Expired income account.

You can manually extend voucher expiry dates prior to them expiring, but they can not be adjusted after the expiry date.

Contra Payment Types for Refunds

A contra payment is a special type of payment that debits the balance outstanding on an invoice with the balance of an available credit note. It saves you from having to look at the total balance of a student's debits and credits and works out what their end position is. It may be especially useful for companies who process multiple students in an invoice and have some students cancel and credited.

This works automatically for a credit note and is created through the enrolment cancellation process. For example, if the student had enrolled, but not paid their class, which was later cancelled and you issued them a credit note, automatically both the credit note and their original invoice would have a $0 balance, as they would cancel each other out.

Create a contra invoice via the invoice window advanced function cogwheel

Alternatively, you can do this manually in the invoice window for manual credit notes too. For example, if a student had an invoice for $100 for an enrolment that they have not made a payment against, so have a balance outstanding of $100, and there then issued a credit note for $70 for a manual refund for a different class that they had paid for, you could choose to 'contra' the $70 credit note balance against the $100 outstanding balance on the invoice. This would then show their credit note as having a $0 balance (as though you had refunded them, or they had used the credit note for another enrolment) and their invoice as having a balance of $30 outstanding that they need to pay.

You can only use credit notes to contra invoices for the same contact. You can't take a credit note from Student A and use it to 'pay off' an invoice that was issued to Student B.

Edit view of a Contra Invoice

Invoice detail showing a contra payment

Deferred Income

In this section we provide an overview of how deferred income works within onCourse and how the system deals with adjustments and or cancellations to a Class.

Transfer of funds from Liability Account to Income Account at time of Course Delivery

How Deferred Incomes Works

When an invoice is generated within onCourse, those funds are initially listed within the GL against the Pre Paid Fees (Liability account). These funds are then transferred to the income account of the GL at the commencement of the Class.

As you can see from the above diagram, the method by which onCourse determines how the deferred income is transferred across from the Pre Paid Fees (liability) account is as follows.

(1) First session of class is run
(2) At approximately 1am the following morning, the system will run a comparison between the amount of funds in the liability account and the amount of funds in the income account for that Class. It will also check how many hours of the overall Class have been run and how many are yet to be run
(3) Based on the above comparison, onCourse automatically transfers an instalment of funds from the Pre Paid Fees account to the Income account.
(4) This nightly comparison will continue for the duration of the Class until all remaining funds are transferred from the Pre Paid Fees account to the Income account.

What Happens If I have to Cancel or Add a Session to a Class?

As you would have noted within the previous section, onCourse runs a nightly comparison of the amount of funds in the Pre Paid Fees account against the amount of funds in the Income account.

If for example you have to cancel a session within a given Class, the next time the system does an overnight check of the status, it will allow for this cancellation and transfer all remaining funds to the Income account.

Alternatively, if you have to add additional sessions to a Class, the system will adjust the nightly installment of funds being transferred to allow for the increased number of total hours in the given Class.

What if I want all funds to be transferred at the commencement of the Class?

A College may decide that they do not wish to transfer income incrementally across the duration of a given Class.

If you don't want to use this feature within onCourse, you can easily deactivate this within the Financial Preferences of your onCourse client.

By choosing to not assign funds from liability to income in nightly increments, the system will instead transfer all funds from the Pre Paid Fees account to the Income account the night after the first session of the Class is run.

Please note that this setting is universal, so all Classes are either assigned funds incrementally across the duration of the Class, or the funds are transferred in one installment after the first session of the Class is completed.

Assigning Account Codes within onCourse

The standard onCourse set up comes with a number of generic Account Codes that can be assigned to a given Class within onCourse. An organisation also has the ability to add to that Account Code list and customise that list to your organisations' requirements. There are no limits to the number of Account Codes that can be set up.

You can add to the standard list of Account Codes via the Financial menu of onCourse

Select Account from onCourse Financial menu

Within the Account Code window, you can then add a new Account Code to the System, that new code will then be available to be added to any given Class that you create. When adding the code, you will need to stipulate what type of account code it will be, either asset, liability, equity, income, COS or expense.

Create a new account code

Once you have set up all your Account Codes, you can then assign those codes to a given Class via the budget tab of the individual Class, the following example shows how to select the relevant income account code for the Class.

Select the required income account code for the given Class

Remember also that the relevant expense account for Payroll will be brought across from the Tutor roles and how they have been set up. For example, the role of Helper could be assigned to the expense code of 6000 and the role of Lecturer could be assigned the expense code of 6400.

Accessing Financial Information from onCourse

When running any kind of query against onCourse to extract financial information, keep in mind that enrolment information is attached to the student and all financial information (such as invoices / payments / credit notes) are attached to the debtor within the system. Therefore there is no direct data relationship between the student and the debtor.

There are multiple methods you can use to extract / examine financial information within onCourse;

Locating data using related records

In all onCourse windows, you can track through the relationships between the data using the 'Find related' function in the cogwheel in the top right hand corner. For example, if you wanted to find all the invoices related to the payments in taken on a given day, you can select all the payment in records for the day, go to the cogwheel, selected 'Find related...' and select invoices. This will open all the related invoices in a new window.

In the new Invoices window, you can run additional queries and or print reports. This window has opened in a special state that only ever shows the maximum set of results as being the list the generated from your original find related search, so all your searches, filters and reports will only relate to this subset of data until you close the Invoice list window.

Printed Financial Reports

onCourse comes with a number of different Financial Reports and each of these are looking at one particular aspect or area of the database such as Invoices. You may also wish to analyze the financial information that is being generated and you can do this by comparing information from one report to the next.

For example, a data comparison that will enable you to verify the accuracy of the financial information is that the Cheque account balance = Payment in - Payment out for the same time period.

New Custom Reports can be developed upon request, just bear in mind the rules of how the data is structured within onCourse when considering what kind of information you want to have appear on the Report.

Copying info within list view windows to Excel

Copy and paste list view records into excel. Run your desired query within a given window, hi-light the records you want in the list window and copy. Open excel to paste records.

The benefit of this approach is that it allows you to copy information from a number of different windows on to the same excel worksheet in order to better compare and verify the data.

CSV Exports

onCourse enables you to export data directly from onCourse. As is the case with the printed reports, these exports are essentially flat tables of data, which means that you are only looking at one specific area such as invoices .

For more information regarding exporting financial data from onCourse, refer to the chapter on Importing and Exporting.

Exporting to MYOB

onCourse allows you to generate a text file export of your Financial Data in order to import this information directly into MYOB. For more information regarding exporting data for MYOB, refer to the following section of the Import Export Chapter on Exporting to MYOB.

Running Queries Directly from the Database

It is possible within onCourse to run queries on information directly from the database server. Whether the server runs on Apache Derby or MySQL or MS SQL all of these relational databases allow you to query the database directly.

This allows you write and edit your own custom reports on demand. Instructions are available in the reports documentation for downloading and installing a free SQL tool for writing your own reports. A high level of familiarity with SQL is required to use this function - it is not part of the standard onCourse product support, but an advanced option which is also available for your own use. If you do not have these skills in house, custom reports can be created for you on request by ish. A quote will be provided for each report.

From an accountancy perspective, what type of relational database you use is not important, the thing you want to be clear about is knowing exactly what data you need to see and how you want to see it.

As an example, if your company wants to run a monthly query against the database which tells you all payments received, for which enrolments within a give timeframe, you would follow these 4 basic steps.

(1) Define the data you wish to include in your query. It could be the invoice number, invoice date, course code and enrolled student first name and last name.
(2) Define how you want this query to appear, which is as simple as setting up your columns within an excel worksheet. By defining this, you are determining the relationship between the data.
(3) Define the date range of the query (in other words, set the date range)
(4) Run the resulting query against the database

If you run the same query on a monthly basis, once you have worked out Step 1 and 2, the only thing you need to do to run the query each month is to update the date range. Once this query has been run, you can then import this directly into an excel document and you are ready to go.

Banking and Reconciliation

As funds are received for course payments, onCourse, via the Accounts tab of the onCourse client, allows you to bank these funds in your nominated account. You also have the ability to run a Reconciliation Statement, to verify that the payments into onCourse match your banking report.

Banking

As onCourse is integrated with a credit card payment gateway, the system will automatically settle bank funds received via the credit card gateway. This settlement process is automatically done between approximately 7pm and 9pm each evening and will be settled into your nominated account the following business day. If a payment is processed after the nightly settlement cut off time, the payment will not appear in your nominated account until the day after.

If you have an EFTPOS terminal that you use in conjunction with, or instead of the onCourse credit card gateway, ensure you select EFTPOS, rather than EFT or credit card, as the payment in type. EFTPOS transactions will be marked as banked on creation.

For all other payments received via Cheque, Electronic Funds Transfer, Money Order or Cash, will need to be banked by your accounts department. The 'Deposit Banking' function within the onCourse client allows you to track the date of settlement, method of payment, payment amount and staff member who performs this function. It also ensures that you do not 'double count' any funds to your nominated bank account.

Deposit Banking Window within Accounts tab of onCourse Client

You can see a list of payment in and out transactions grouped together by their banking date, including those banked automatically such as credit card and EFTPOS by clicking on the 'Banking' option in the Financial top menu category. In this list view you will be able to see the following information:

  • The date that each amount of money is banked - The settlement date will either be set manually by you, if you have manually banked the money e.g. cash or cheques. Alternatively if they are online transactions the settlement date will be automatically set as the date the funds where received in you bank.

  • The type or the method of how these funds got banked - There are two options here, the first being 'MANUAL' which is if you physically have to go to the bank to deposit cash or cheques received. The second being 'GATEWAY' which is to do with all online transactions. You can edit the settlement date of all manually banked fund by double clicking on any of those records and changing the date. However, you can't edit the settlement date of any record marked as 'GATEWAY' because this information is being pulled directly from your bank.

    Changing the settlement date for manual banked funds

  • The total monetary value of the funds being banked.

Note

You can get to the 'Deposit banking' window from the 'Banking' list view by clicking on the '+' icon at the top right side of the window.

Banking list view

Cheque payments would of course be subject to your own banks' timelines on the processing of cheques, with the funds not appearing in your account until several days after being banked. For Cash Payments and Electronic Funds Transfers, these settlement times are more immediate, please check with your bank for exact timelines for processing funds.

Reconciliation

The reconcile statement function within onCourse client accounts tab allows you to verify that onCourse payments match your bank statements. The Reconciliation Report that is generated can be run on a weekly or monthly basis, dependent upon your own internal financial procedures. The reconciliation report function will provide a line by line itemization of all funds that have been reconciled, listed by the relevant income account.

Reconciliation Statement Window within Accounts tab of onCourse Client