As mentioned elsewhere, it is not intended that ServiceDesk will replace whatever system you have used (or, if you’re a new company, will use) for writing checks, documenting miscellaneous operating expenses, figuring depreciation, and compiling financial reports such as Income Statements and Balance Sheets. It is not designed, in other words, to fulfill the functions involved in financial accounting—at least not mostly. However, you should note that it does, nevertheless, collect and process and compile several of the items of information that will need to be inputted into whatever method of financial accounting you otherwise use (primarily it collects information that’s associated with the revenue side of accounting). In particular, it collects and compiles information on your sales, accounts receivable, funds collected, sales tax liabilities and inventory (this last being an exception from its “revenue-side” focus). This information will need to be inputted into your system of financial accounting as often as you compile financial statements (most likely once every month, but perhaps only once per year, depending on your company’s preference and policy).
With but one exception, your ServiceDesk Sales Report (see page 172) collects and compiles for you all the information that needs to be moved from ServiceDesk into your separate system of financial-accounting. It even blue-highlights, for you, the particular figures that need to be so moved:
As you can see, there are only a few such figures. These figures concern, in particular, items related to the revenue side of your accounting, and exclude the one cost-side element that must be handled separately (specifically, cost-of-goods sold). The figures are such that, if you use an outside accountant and simply provide this report to him or her, he or she should understand precisely how to handle it.
Regardless of whether you do such a simple hand-off to another party or not, the general concept is you will run this report at the end of each accounting period — so as to provide a summary of the activity that occurred during that period, for feeding into your full-accounting system.
If you do not in fact employ an outside accountant, you will need to do that feeding-into-full-accounting-system process yourself. If your full-accounting system is QuickBooks, you may notice there is an “Export to QuickBooks” button (see above illustration, and look for the hot-pink colored button toward its lower-right). It’s designed to do that “feeding into” process for you. If you use some system other than QuickBooks, you’ll need to do the “feeding into” manually. Since there are only a few figures, there is little labor involved. However, you are likely to need conceptual assistance, which we’ll here provide.
Of course, there is that other, expense-side element (cost-of-goods-sold), and it must be dealt with as well. In the following sections, we’ll discuss each of these matters in greater detail.
We’re discussing this first, because the vast majority of ServiceDesk users (and of North American small businesses in general) use QuickBooks.
Aside from that single, expense-side, cost-of-goods element, integration with QuickBooks is eminently simple.
Just run that Sales Report (as above described) at the conclusion of each accounting period, then click on the button to Export to QuickBooks. Then, from within QuickBooks, click on File, then Import, then pick the file you created by exporting from ServiceDesk.
In result of the above, QuickBooks will create a set of internal accounts, each designed to appropriately receive the same values as are blue-highlighted on the face of ServiceDesk’s Sales Report. And it will make internal Journal entries, inserting values as applicable to each such account.
As an example, QuickBooks will create an internal account called “SD-Tallied Sales.” When you then run an Income-Statement report from within QuickBooks (and for a period that includes when you did such an export/import data movement), the report will show (as a direct-identified Sales-Income item) the appropriate amount from SD-Tallied Sales.
For the main part of your joining ServiceDesk-to-QuickBooks work, all you must do is the above. It is truly that simple.
One small detail involves entering into QuickBooks when you’ve made a bank deposit — specifically, of monies that ServiceDesk managed the collection on (hopefully, you will have indeed used ServiceDesk’s deposit-preparation machinery to manage building the deposit tape, and to internally document each items’ disposition, etc., but this discussion remains relevant to how the entry needs to be made into QuickBooks, regardless). When you enter a bank deposit into QuickBooks, QuickBooks will demand to know the source of the money being deposited (i.e., the “account” that should credited as the source). Where the money was indeed managed via ServiceDesk mechanisms, you should indicate the source as “ServiceDesk-Tallied Funds Received” (this is another of the accounts that the ServiceDesk-to-QuickBooks export-import process will have created for you).
As you do the above, you may note a small oddity. It stems from the fact that you will typically be making these deposits on a periodic basis throughout any accounting period, yet the transfer of reckoning from ServiceDesk to QuickBooks (i.e., ServiceDesk telling QuickBooks what funds it tallies itself as having received during a period) will not occur until the end of that period. For example, suppose that in a given month you collect $40,000. In each of four Fridays of that month, you deposit $10,000 of that $40,000. Each time you make such a deposit, you claim the funds came from “ServiceDesk-Tallied Funds Received,” yet it’s not until afterward that the entry of $40,000 is made into that account. For this reason, it is normal that, during the course of any accounting period, your deposits will have the effect of drawing that account into the negative. It will naturally be brought back to zero by virtue of the export-import transfer, at the end of the period. This is normal.
The cost of your parts used (and of merchandise sold, if you are also a dealer) is the one element of financial accounting information (and as managed by ServiceDesk) that is not on the revenue side, and which requires handling outside the Sales-Summary and/or its export-import movement of data to QuickBooks.
In fact, ServiceDesk does not manage cost-of-goods-sold in any direct sense. Actual outflow of funds, to “pay” for these costs, is indeed managed directly by QuickBooks (or other separate system if you use something else), as you write checks to your vendors, typically as dictated by month-end statements, and usually paying for purchases as made in each preceding month. However, just because you are paying for a part via QuickBooks does not mean you are simultaneously, via such action, registering a cost-of-goods sold. In a typical scenario, it is indeed quite otherwise. Most often, such a payment converts cash in your bank account into an added inventory valuation in your inventory account. Both are equal-value assets so far as accounting is concerned, and the conversion has no effect at all on cost of goods sold.
So, though the money is being spent via QuickBooks, it does not mean QuickBooks directly possesses what it needs, for the sake of calculating cost-of-goods-sold. For that (and at least if it’s to do so with precision), QuickBooks needs information from ServiceDesk. Any of several methods may be used.
If you are using any accounting system other than QuickBooks, general principles remain the same as described in the prior section. The one and major difference is there will be no export-import facilitated transfer of information for you, from ServiceDesk into your other system. So, you’ll need to make these entries manually, as opposed to automatically. Since there are only a handful (or so) of figures, this is not laborious, and it only needs to be done at the conclusion of each accounting period. In principal, it’s particularly easy, since all but one of the relevant summary figures are nicely flagged for you in the ServiceDesk Sales Report (please review the prior section for details on such flagging).
The one challenge you are likely to encounter, if you are not an accountant, will be in understanding precisely how this handful of figures should be entered into your accounting system. The main purpose in this section is to assist you in such understanding.
Particularly since we do not know what other system you will be using, we cannot give you precise details. At best, we can assist you in understanding such general principals as are involved. Thus, what follows here is designed to give you at least minimal acquaintance with some general accounting basics.
Every accounting system has a “Journal” or “General Ledger” (terminology varies). This is where entries are made that describe each event that changes the general accounting picture (e.g., earning money by completing a sale). Your basic purpose will be to make entries to this Journal (i.e., as exists in your own accounting system) to describe the summary information that needs transferred from ServiceDesk.
Whether it’s apparent from the surface or not, all modern accounting systems (“modern” here means since Columbus) have as their foundation what is referred to as “double-entry bookkeeping.” In this context, double-entry does not mean entering the same info twice. It refers, rather, to the fact that every accounting-significant event has an effect in at least two different areas of accounting interest. When you earn money by completing a sale, for example, you’ve added to your sales (one area of accounting interest), and simultaneously have increased either your cash (if the sale was paid for at the time) or have increased your accounts receivable. It’s possible you did even a little of both. All accounting events have this dual-effect attribute (though, depending on circumstances, on different areas of accounting interest, and in difference ways). The double-entry system was developed to assure every entry properly balances across both sides of this inevitable dual effect. It was a great invention.
Anyhow, we explain that as a foundation because, depending on the nature of your accounting system, you may need to make an entry in the general ledger where this double-entry mode is directly evident. Alternatively, your system may offer you an interface that somewhat hides or disguises the underlying double-entry foundation. Regardless, you’ll be better enabled to understand the ultimate information that needs to go in, by reading onward.
Suppose that in a given accounting period you produce a Sales Report with the following figures (the ones underlined are the ones that need moved to your system of financial accounting).
Again, though your system may have an interface that presents you with a different path for the purpose, the following are entries that will ultimately be going into its general ledger:
If you’re not an accountant, please try not to be troubled if some of the above seems mysterious. It may seem odd, for example, that an increase in cash is recorded as a “debit” rather than as a “credit.” Regardless, it’s how it works (in beginning accounting classes they repeatedly drum into your head that the words “debit” and “credit” have no inherent meaning; they are simply titles given to the two different columns).
Now, for some explanation:
In the first rectangle/entry above, we are simply documenting the fact that $47,187.83 has been fed into our Cash on hand (whether in the bank or otherwise it does not matter so far as financial accounting is concerned, please look at the example Sales Report to see where these figures were pulled from), and that our Accounts Receivable has decreased (based on the net of amounts going in and out from it) by the amount of $1,134.20.
Plus, we are indicating the amount of $44,854.30 should be credited to our Sales account, and $999.32 to our Sales Tax Payable account. Thus, with these four entries (all of which in sum balance) we’ve input all the information that is directly related to our sales for the month.
Regardless, there are a few other matters the ServiceDesk Sales Report compiles, besides those so directly-related to sales. This is, in particular, because it also manages your accounts receivable and your funds collected. In either area, other events may occur. For example, some of your Accounts Receivable will prove to be uncollectible, and thus will need to be written off as bad debt. There’s provision within ServiceDesk for doing this (see page 177), but naturally, the fact of having done so needs to be input to your system of financial accounting. Also, it will occasionally happen that you’ve collected funds, yet they turn up missing, or otherwise cannot ultimately be collected upon (rejected bankcard numbers, bounced checks that can’t be remedied, etc.). In such cases, ServiceDesk again provides an internal method for documenting such losses (see page 158), and a summary of such activity is likewise included in its Sales Report. And again, the amounts in summary must be inputted to your system of financial accounting.
The second and third example entries, above, illustrate such needed entries. Again, you may compare the numbers shown to their source from within the example Sales Report. In the first such entry, basically, we are reporting having incurred $75.00 as a Bad Debt Expense, along with a corresponding reduction in Accounts Receivable. In the second such entry (last in the above examples), we are reporting having incurred the loss of $45.00 in Missing or Unreedemable Funds, and a corresponding reduction from our Cash account.
Again, regardless of the system you use, our point is these are kinds of entries that must ultimately go into its general journal. Your system may present you with an interface, by which to provide the information, which essentially hides that journal. But this is the fundamental information it needs, regardless.
Other entries may be needed as well, depending on circumstances. For example, if you grant discounts to some of your clients for more rapid payment (see page 158), the ServiceDesk Sales Report will similarly highlight the amount thus granted (its designed to show and highlight everything as relevant, on the revenue side). Suppose, for example, you’re looking at an inclusion which shows that, during the relevant period, you granted $158.32 in discounts. A suitable resulting entry, to your system of financial accounting, would look something like this:
.png)
You should notice the same principles apply, as with the other entries. We are indicating the simple fact we’ve incurred an expense of $158.32 as a discount granted, and that it reduces our cash in the same amount.
Again, there is nothing complex. The general idea is to get information regarding these financial activities—as recorded and summarized by ServiceDesk (plus highlighted there for you)—into the particular system of financial accounting that you use for everything else. Though particular principles of financial accounting might seem a little weird, it’s just a few figures, and the basic concepts of simple information flow are very simple.
There does, of course, remain the matter of accounting for cost-of-goods sold. Again, cost-of-goods-sold matters are not tabulated for you in the ServiceDesk Sales Report, and must be handled separately. In general, the options for such handling are precisely the same as if you were using QuickBooks (see prior section). The one difference, as relevant to the present discussion, is you may want to specifically know how an entry reflecting cost-of-goods-sold would look, when entered to the general ledger.
Suppose (using whichever basis is preferred), you have calculated that within the accounting period cost-of-goods sold summed to $17,000. In such a case, your general ledger entry would need to look something like this:
.png)
Again, it’s rather simple, at least if you avoid allowing it to intimidate you.
If it nevertheless feels even slightly intimidating, try to remember that accountants require four years of college. Also remember that, regardless, the items of information that need transferred from ServiceDesk are very few and simple.
If the accounting end in itself seems too difficult regardless, perhaps you should hire an accountant, to at least help you get setup on the accounting end. He or she can read this section to learn what ServiceDesk has to input on its end of things, and teach you the process that’s involved within your own accounting system. Once so taught, it should be a very easy (on a once-per-accounting-period basis) to make the entries needed.
