Recurring Invoices:

Using Solomon AR feature: generate invoices is a great way to easily create an AR invoice when you are billing on a month or greater frequency. Clients use this feature for monthly billing of rent for their sub leased tenants, monthly billing of school tuition fees, monthly billing of janitorial services, and monthly billing of real estate access fee to a multiple listing web site. The potential applications for this feature in Solomon are virtually unlimited. Commonality in most of the user’s applications is that the amount to be billed is constant over a fixed period of cycles / time. The software allows you to bill in increments of one month, or multiple months (i.e. quarterly billings). You will need to be creative when you use this feature to bill for periods which are multiple billings /month (i.e. billing cycle is less than 1 month).

The use of the recurring invoices is a two step process. Step one is to set up the template for recurring invoices. This is done through screen: 08.270. The second step is generating the recurring invoice through screen: 08.500.

Here is a copy of the screen used to set up the recurring template.

Basically this screen is easy to comprehend and use. The special points I’d like to cover are; 1) make you Invoice/memo nbr field a meaning name so you can easily recognize it (I recommend using alpha word descriptions within the 10 character length of this field)

2) the cycle field is: The length of time, in moths, between generations of the recurring invoice 3) Number of cycles: Total number of times Solomon IV should generate a regular invoice from the recurring invoice; the maximum number of cycles allowed is 999, and 4) Always check that the two fields : 1) Total and 2) Amount are always the same value. (bad things can happen if you incorrectly save a recurring invoice which is out of balance).

Please note when you leave this screen there is no batch handling (i.e. release later, release now) options; and upon release no batch control reports are generated. This is because the processing of the recurring invoice is only after running the screen: generate recurring invoices.

First: the generate date is critical, because only through recurring templates which have their next generation date equal to or before this date will be processed. Second: You choose how batches are to be released after processing with the options of release now or release later. Third: The display invoices needs to be clicked to populate candidate recurring invoices , which in turn need to be selected for the begin processing step.

There is a major “I got you” with this process. If you fail to run generate recurring invoices for a month or so, then the next time you run the process you will get multiple invoices when generating recurring invoices; and all invoices point to the current period to post, as defined in the screen 08.500.

I have had clients who process over 18000 invoices every month using this process, and Solomon works like a champ.

What about Revenue Recognition:

Many companies sell support/ maintenance contracts which get invoiced and paid for at a single time, but there is a multi month spread over when the service is delivered (i.e. think of an annual service contract for Solomon). This brings up the challenge that the recurring invoice system is not designed to handle this challenge. For companies that have few support contracts, the work around is to create the recurring invoice so it updates your deferred revenue liability account and create a separate recurring General Ledger journal which reclasses the deferred revenue to recognized revenue.

Fortunately Solomon uses have several third party add on module which handles the deferred revenue situation. Here are two of many that exist:

Tectura software: http://www.tectura.com/DocumentCenter/ReQlogic/RevenueRecognition_factsheet1.pdf

CEP Systems; (Max Q)

http://cepnt2.cepsystems.com/downloads/Acrobat/Recurring%20Billing%20Rev%20Recog.pdf

In addition, if you are doing your billing through the Solomon project controller module, you can easily handle the deferred revenue problem with the Project controller series of modules. Alternatively, for Solomon users who are using the service series for billing, they have a Solomon solution to handle deferred billing when they use the service contracts module.