Table of Contents
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.
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).
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.
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.
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.
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.
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|
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|
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 recored 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.|
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.
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 Acocunt 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|
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|
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.|
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.|
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.
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.
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.
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.|
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.
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.
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
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.
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.
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.
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 4 methods you can use to extract / examine financial information within onCourse;
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.
Here are a few simple examples of data comparison that will enable you to verify the accuracy of the financial information; Account Summary = Invoice Total Payment In = Banking Report Payment In = Cheque Account Balance
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.
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.
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.
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.
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 an 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.
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.
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.
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.
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.