There is still another area where many small businesses lose shocking sums of money. It's the matter of managing accounts receivable. We need, quite obviously, to police every item of money owed to us, to assure it's promptly paid, or that due and proper notice is sent when it becomes past due. But in most setups, this requires dedicated, ongoing, seemingly constant attention—and with the press of completing new work so demanding, it's common for office personnel to let this need slip. The best solution, obviously, is to make managing accounts receivable into a matter that involves only minimal labor, rather than much. As you might expect, this is precisely the solution ServiceDesk provides.
The primary file that's used to deal with AccountsReceivable is called, not surprisingly, the 'AccountsReceivable' file. As mentioned elsewhere, for every billed sale that you record via the SalesEnter system (see page 165), ServiceDesk creates a unique record, within this file, reflecting the sale and its expected payment. Thus, the file becomes a simple set of records reflecting every past sale on which payment is still expected.
ServiceDesk provides two forms for working with this file.
First is the AccountsReceivable form, which individually displays all the data from each record. It further provides search capabilities between records, various housekeeping and editing functions, and many other capabilities. To access it, press F3 or click on the corresponding MainMenu command button. You'll see that most of its functions are quite self-explanatory.
The second form (accessed by pressing Ctrl-F3) addresses more of an operational need, for aside from keeping our AccountsReceivable records, reviewing and/or editing them as needed, and so on, our real concern is to be sure each is promptly paid—or that appropriate reminders are sent (in the forming of dunning letters or statements) if they are not. For the function of sending such reminders, we use the Dunning form.
In regard to billing reminders (whether you prefer sending them in letter format or as more typical statements), you should note that here is another area where ServiceDesk discriminates between companies you've designated as ‘HighVolume’ types (see page 60) and all others. The reason is because, presumably, your HighVolume-type clients will probably owe on many receivables at one time, while regular clients will probably owe on just one (or certainly not more than a few). In addition, the preferred format of treatment is likely to be a little different for one type than for another.
Regardless, upon viewing the Dunning form (again, press Ctrl-F3), you’ll see that your first option is to specify whether you want to do 'Standard Dunning' or 'Special HVC-type Notices. The methodology for either procedure is almost self-explanatory, but we'll overview here regardless.
We should start by clarifying a matter of terminology, and connected practice. Some companies are accustomed to sending out—as a way of reminding customers to pay what’s owed—what may be thought of, more or less, as standard “statements”. Others have used more of a letter-type format, with each letter explaining in more of a conversational manner what’s owed (with these typically being referred to as “dunning letters”). As another difference, some companies send statements right up front, without waiting for items to become past due. Others just mail a copy of the invoice for initial billing, and don’t send statements (or, or course, dunning letters either) until after that initial request becomes past due. You can do it any way you wish within ServiceDesk, though typically we think it’s easiest to use the invoice-copy method (or, actually, one part of a multi-part form) for initial billing, and send a statement or dunning letter only later, when and if the item remains unpaid. Regardless, whether it’s statement format or dunning letter, we’ll refer to both here, generically, as “billing reminders.”
With that said, you should begin by understanding that, at this time, ServiceDesk is not configured to produce finished billing reminders for your normal (i.e., non-HighVolume) clients. Instead, the idea is for it to produce the raw data that can then be fed, typically, into the mail-merge (otherwise known as “form letter”) feature of a word processing program, such as Microsoft’s Word, for example, which will then take the data and place it into whatever finished context you may prefer. The reason for this design, obviously, is that it allows you nearly infinite flexibility in formulating your billing reminders in whatever manner you most prefer (in fact, you could even use contexts other than word processing for the purpose, such as Microsoft’s Excel spreadsheet program, for example).
If you have not previously been involved in creating merge documents, we'll explain a little here. This is what big companies use to make it look like you’ve received a personal letter, when in fact your name and other information is just inserted at the right places within the text of a letter, in the address area on an envelope, and so on. The text might even vary, from place to place, depending on particularities in your own data. The reason they’re called “merge” documents is because of how it works. Essentially, there’s two documents that are merged together to make the set of output documents that’s personalized for each of maybe hundreds or thousands of individuals. One document (generally called the “Master” document), essentially contains the overall instruction set and common text. The other (generally called the “Data” document) contains the particular data for each of many individuals.
How it works is like this. The master document has the general text along with places, here and there, where essentially the internal instruction says "put the NAME from each individual here,” or “put the FIRST LINE OF THE ADDRESS here,” and so on. The data document, by contrast, has a paragraph of text items for each individual, with separate text items within that paragraph, each containing a particular element of information that’s relevant and available for insertion to the master document. When it’s all setup just right, the word processing program looks at the master document, then at the first paragraph of text from the data document, and inserts each element of text from that paragraph into appropriately-instructed places from the master document, sending the “merged” output to a new document, which you can then print. It then does the same from the next data paragraph (as pertaining to the next individual represented there), and so on through the entire set.
If you’ve not previously setup a word-processing program for this kind of feat, the task can at first seem daunting. That’s why we’ve set it up so you don’t have to. Instead, we’ve created a Word-based master document for you, that will produce very nice billing reminders.
It’s designed to produce them in a format that’s something of a hybrid between a typical statement and dunning letter, hopefully carrying most of the advantages from each. It’s designed to make the letters vary in tone, urgency (and threat level), depending on how many previous reminders have been sent. Though you may need a magnifying glass to make them out, the following three items illustrate the kind of output that the provided Word master document will produce:
Please note that you’d want to print these on paper with your own letterhead, and at the bottom (from within the Masterdocument, of course) you’d need to replace the text, where it says “Name of Sending Person” with a real person’s name from your company. Please also note that you could change any of the other text (from the Master document) in any manner you might wish, though much of it is hidden and conditioned on particular circumstances (one receivable item versus more, how many previous reminders, etc.). Figuring out how to make the whole thing work when dealing with the hidden, instructional text is, again, not easy.
Of course, if you’re up to the challenge, you may produce any kind of master document you wish (it is, in general, a one-timetask, for typically you’ll be wanting to use the same master document over and over again, month after month, year after year). We’ve provided one for you (one that produces the kind of reminders shown), simply to make it easy for those who don’t wish to struggle with producing your own.
Regardless, once you have your preferred master document in place (again, for simplicity we recommend using ours), the task of producing your finished billing reminders, on a monthly or more often basis, is a very easy and simple one. It’s done in three simple steps.
In result of this simple sequence (should typically require less than 3 minutes), you can happily watch as a succession of perfect billing reminders stream from your printer—in whatever quantity as Special HighVolumeClient Notices
Ordinarily (and hopefully, at least) there's much less trouble collecting from the big institutional type of clients that you will have designated as ‘HighVolume’ types. Most pay reliably, within some predictable time frame, on almost all invoices. However, it still happens occasionally that a few invoices somehow fall through the cracks. Some system is needed to regularly remind this type of client of the particular invoices which have so fallen. In this case, a somewhat different format seems preferable, and probably less formality is needed. For such reason, in this context we’ve designed it so that ServiceDesk will generate the reminders for you directly.
To use this feature, begin again by loading the 'Dunning' form (press Ctrl-F3), then select its 'Special HVC Notice' option. Immediately you'll see a list of each company you've designated (from the 'QuickEntries' form) as a ‘HighVolume’ type company (see page 60). Click on any company you're interested in, and immediately you'll see a report indicating what the receivable status is from that company (i.e., how many items and of what value over 30 days, over 60 days, etc.). If you wish to generate a reminder notice to this company, simply indicate when prompted. As you'll notice, you can specify any period of tardiness you wish to include in the notice.
In result of the sequence, ServiceDesk will independently generate a nice little summary for the company involved, which you may then either mail or fax.
As you can see, we've made the process for sending these reminders very easy (easier than for normal billing reminders, for here there’s no need to go through a merge-document type of procedure form a separate word-processing program). Still, if you don't have the discipline to go through it on a regular basis, it will do you little good. To stay right on top of things, you should create and send these reminder notices on at least a monthly basis. Please see that you do.
In case you're wondering how items are taken out of AccountsReceivable status upon being paid, we'll simply mention here that it's done, using a utility provided for the purpose, within the FundsForm (see page 157). You'll notice, in this regard, there's an item of information, displayed in the AccountsReceivable form and pertaining to each record, that indicates how much has been received on the sale in question. Whenever funds are checked in via the process just mentioned, this figure is updated by ServiceDesk for you. Of course, there may be occasions when you need to adjust the value manually. If so, it's easy to do so directly from the AccountsReceivable form (for the sake of security, this does require use of the owner/manager password).
As various AccountsReceivable records are in fact paid off (and their PaidToDate figures consequently indicate an amount equal to the sale), their records obviously don't need to exist within the file any longer (they are, after all, no longer AccountsReceivable). Thus again, we have a place in ServiceDesk where there’s need, to run a routine with some regularity, that purges no longer needed records from the file. This is another of the events that will be done for you, on a nightly basis, if you have the Auto-Archive feature turned on (see page 209). Otherwise, on at least a monthly basis, you should click within the AccountsReceivable form on the button labeled 'Clean-out completed items'. This will run a routine that removes all records from the file which have a PaidToDate amount equal to (or exceeding) the total sale. If this routine is not at least occasionally run, your AccountsReceivable file will grow ever larger, becoming filled over time mostly with items that have been paid and which need no longer to be there. Eventually, ServiceDesk will note the excessive size and alert you to run the routine.
Unfortunately, it’s a sad reality that the path to retirement for some receivables is not by virtue of having been paid. Sometimes you’ll find an item is simply uncollectible, or at least that further efforts to collect are not worthwhile. In such cases, you need a formalized method to "write off" the debt (i.e., to remove its item from the AccountsReceivable file, record the loss, etc.). This function is also addressed from the AccountsReceivable form. Simply bring up the particular record you're interested in, then click on the command button labeled 'Write Off as Bad Debt'. In response, the form will fictitiously change the item's 'PaidToDate' value to equal the sale amount (this sets up the record to be purged the next time you run the 'Purge Chaff' routine), and it will simultaneously make a Paycode "4" entry into the SalesJournal (see page 169), reflecting the loss. That entry (along with any similar ones) will then be the basis, when you later compile a SalesReport, of showing what you lost in bad debt during the period (as is necessary for entry into your accounting program).
In introducing this section, we mentioned that the primary file for managing the various accounts on which you expect payment is the AccountsReceivable file (reviewed and managed via the AccountsReceivable form). This discussion would not be complete, however, if we did not mention another file and its associated form.
It so happens that on some receivables you’ll receive a series of payments before the amount is paid in full (thus, you’ve got multiple payments on one bill). On others, you’ll receive a just one check that applies to several different bills. From the accounts receivable file, the system keeps track only of the total that’s been paid, at any given time, on any given receivable. There’s no history there of how the payment came in (i.e., via what checks, on what date, and applied in what amount, to which receivables?). Sometimes, this latter information can be very useful (as when, for example, a client claims they made some particular payment against a certain claim, and you need to go back and see if you actually received the check, and if so how you actually applied it).
The ApplicationsJournal (a separate file) is intended for this purpose. In one sense, you might say it’s a bridge between the Funds form (where any payment on a receivable should be checked in, see page 157) and journal, and the AccountsReceivable context. Basically, each time you check in payment on a receivable, the system makes entries into this journal, for you, regarding how the fund was applied (i.e., how much on which receivables). Thus, you have a permanent record to refer back to, when needed.
To access and review this information, use ApplicationsJournal form, accessed by pressing Alt-F9. There are self-explanatory search and review features, but aside from that, there’s essentially no work to be done within this form, for its purpose is informational only.