OpenVPMS includes only enough financial processing as is necessary.  Whilst it keeps track of invoices, payments etc for the veterinary side of the business, it does not keep full track of your bank accounts. Hence you will almost certainly need to run a separate accounting system.

However, since it does handle all the customer and supplier invoicing and payments, there is no need to export the detailed invoice and payment information to your accounting system.  Your accountant should be quite content with the data from the Bank Deposit Report. (This shows the total of the cash and all the detail of the EFT, credit card, and cheque payments.)

On the supplier side, since you need to make payments to the suppliers, you will need to enter the individual supplier invoices into your accounting system so that they can be paid and it can track the payments. However, you can omit the line item detail because OpenVPMS will handle this as it tracks the orders and deliveries.

The Accounting Cycle
Typically this proceeds as follows:

• at the end of each day the till is balanced using the Reporting|Till Balancing screen and the appropriate amount of cash and all the cheques, credit card slips etc removed from the till - note that you do not actually have to stop the business - you can do a till balance and still continue operating
• when appropriate (maybe immediately after the till is balanced, maybe every couple of days) use the Reporting|Bank Deposits screen to generate the Deposit Report, and then take this and all the money to the bank and deposit it
• when desired use the Reporting|Work In Progress screen to check that things are moving along and that no invoices have been stalled for some reason
• when desired use the Reporting|Debtors screen to check on overdue customer accounts
• at the end of the month (or whatever your accounting period is), use the Reporting|Debtors screen to do the Period End processing and then generate and print or email statements

Note that the system does not support multiple accounting periods.  That is, you cannot have a group of customers with monthly accounts and another with quarterly accounts.

Period End Processing & Statement Generation
These two facilities (invoked using the Reporting|Debtors screen) look at all or selected customer accounts and do as follows:

• period end: process all accounts. For any account with an overdue balance (see  Administration|Customer Account Type), check whether accounting fees should be applied, and if so generate the required Debit Adjustment transaction. For any account with transactions since the previous Opening Balance transaction (if any), generate both a Closing Balance and an Opening Balance transaction for the current account balance.
• statement generation: process the selected accounts. Statements will be generated for accounts:
  • which match the selection conditions (which allow selection by customer account type, name and overdue status)
  • with transactions in the period between the statement date and the previous Opening Balance transaction (if any),
  • if there is an outstanding balance
  • if the statement has not been already printed - however a 'Reprint Statements' option allows this to be overridden. This can be used for example to first print the statements of accounts overdue for more than 60 days so that you can include in the envelope a note suggesting that the account should be settled - and then printing the statements for all customers with no selection conditions.  The 60 day overdue customer statements will not be printed again on the second run.
     

Payments and Invoices
Since the system allows you to receive payment for an invoice after it is finalised, there is a tendency to think that the system marks indivual invoices as being paid.  This is not the case: payments are applied to all outstanding invoices, starting with the oldest and allocating the payment to each one until all of the payment amount has been allocated. This follows standard accounting practice.

Thus consider a customer with an invoice for $100 and an account balance of $100. If we now create a new invoice for $150 and the customer pays $150, then when the $150 invoice is printed, it will show the Amount Paid as $50 (because $100 got used to pay the older $100 invoice) and the account balance will now be $100 (ie $100+$150-$150).

Error Correction
The system has a concept of 'finalising' transactions so that they cannot be altered.  To correct a finalised transaction (for example to change the payment type on a payment), you have to Reverse the erroneous transaction (which creates a reversing transaction match the reversed one) and then enter a new one containing the correct data. This reversal facility is only available to users who are categorised as Administrators.

Hidden Transactions
In many cases the above correction procedure can be safely hidden from the customer.  That is rather than the statement showing the original erroneous transaction, its reversal and the new correct transaction, the system allows the first two to be hidden so that the statement shows only the correct transaction.

This hiding of the erroneous transaction and its reversal is only possible when correcting a transaction in the current accounting period (ie since the last Opening Balance transaction). If you reverse an earlier transaction then the hide flag will not be set for either of the reversed and reversing transactions.

For administrators, the Customers|Account screen has a Hide and Unhide button so that, if necessary one can adjust the hide flag for individual transactions.  This needs to be used with care so the statement appear correct in the sum of all the amount shown matches the outstanding balance, ie that all the hidden transactions balance one another out.

Transaction Dates
When a transaction is created, it is timestamped with the current date (and time). When it is finalised, the timestamp is updated. This ensures that the account's finalised transactions are in the proper order for statements and balance calculations. Note that transactions that have line items (such as invoices) then the line item timestamps are not updated at finalisation time and will retain their initial value.