Business Recordkeeping

Next Previous Contents

Accounting Basics
In past columns, we've hit the highlights of general business records. It's now time to turn attention to financial (or accounting) records. This is an area in which I have no particular expertise... I'm an engineer -- not an accountant. So accountant readers -- if I say things in this series that you feel are wrong or misleading, please let me know by phone, note or article and I'll pass them on in subsequent columns. Business accounting causes a great deal of confusion -- if not out-and-out fear and avoidance -- among many beginning entrepreneurs. And needlessly so. It's just not that complicated. Accounting is not rocket science. It's based on a brilliantly-elegant concept from the Middle Ages -- double-entry bookkeeping. Someone way back when recognized: 1) that the "value" of any financial entity could be described in terms of only five "accounts" -- assets, liabilities, equity, and accumulated revenue and expense. 2) that every financial transaction (i.e., "change in value" of the entity) affects at least two such accounts, and can be recorded in the form: assets plus, liabilities minus, equity minus, revenue minus, expense plus, equals zero, and 3) that if every transaction sums to zero, the sum of all the transactions must equal zero! No matter how many transactions you've recorded -- and in a thriving business you'll have many -you'll know you've recorded them correctly -- if and only if they sum to zero. Let's look at an example. Assets are what you own, e.g., cash in bank. Liabilities are what you owe. Equity is your "net worth". Revenue is what you get in. Expense is what you pay out. Suppose you set up a company and put $1,000 into it. We need an asset account -- cash (Cash In Bank) -- and an equity account -- equity (Paid-In Capital). The transaction is cash/1000+ equity/1000-. Your company books now show its equity is $1,000 and it's all in the bank. Note: Your accountant will describe this transaction as "debit cash, credit equity". When you hear

accountants use the words "debit" and "credit", just mentally translate debit to "+ (plus)" and credit to "(minus)". Now say someone pays you $200 to do something for them. We need a revenue account -- revenue -and the transaction is cash/200+ revenue/200-. And you spend $100 to buy something. We need an expense account -- expense -- and the transaction is cash/100- expense/100+. Your company books now show: Assets (cash) Liabilities Equity Revenue Expense Still sums to zero. 0+1000+200-100 0 0-1000 0-200 0+100 => 1100 => 0 => -1000 => -200 => 100

Your "Balance Sheet" is the top 3 lines with Revenue and Expense netted into Equity: Assets (cash) 1100 Liabilities 0 Equity -1100 Your "Earnings Statement" is the negative of the bottom 2 lines: Revenue 200 Expense -100 Net Earnings 100 That's cash-basis accounting -- and that's all there is to it. Accrual Accounting In the real world, most business isn't conducted in cash -- rather you "invoice" them and they "invoice" you. You'd kinda like to keep track of what it is you're owed and what you owe. So accrual accounting is used -- which is really just an extension of the above. We add two more accounts: An asset account -receivable -- that keeps track of what you're owed and a liabilities account -- payable -- that keeps track of what you owe. When you invoice someone for something you sold (for say $200), the transaction is receivable/200+ revenue/200-, and when they pay you, it's cash/200+ receivable/200-. Likewise, when someone invoices you for something you bought (for say $100), the transaction is payable/100- expense/100+, and when you pay them, it's cash/100- payable/100+. If you net these two pairs of transactions together, you'll see that you have the same end result as if they had paid you, or you had paid them, in cash -- but in the interim, you know what's coming in and what's going out.

These last 4 transactions are common to every business and -- for many businesses -- constitute 99% of the transactions you'll ever need. You may add some asset accounts, like Money Market, so you can track the cash in your bank and money market accounts separately... Or some liability accounts, like Bank Loan (what you owe the bank), Accrued Payroll (what you owe employees), and Accrued Payroll Taxes (what you owe the government on that payroll)... Some revenue accounts, like Consulting, Product, Lease Income, etc., if you want to track different revenue sources separately... Some expense accounts, like Rent, Utilities, Supplies, Product Materials, etc., if you want to track different expense categories separately... But the basic transactions are all the same.

Paper Accounting
In the last column, we talked about Cash, Receivables and Payables transactions. Early in your business, these transactions can just be recorded in a General Journal. Essential data is date, acct/amt acct/amt ..., and comments (e.g., who did you pay or who paid you). In the old days (i.e., before computers), the General Journal was just a sheaf of columnar accounting paper where your most-used accounts had their own columns and the last column contained the rest (in acct/amt format). At the end of each accounting period (e.g., at month-end), you'd take a calculator and total the amounts for each account and check that the account-totals totaled to zero -- which they never did -- whereupon you'd have to go back, find the transactions that didn't total to zero, correct them, and re-total the whole thing until they did come to zero. (You'd have to do this even if they totaled to only a penny -- because that penny could have resulted from two large errors whose difference was a penny.) General Ledger After verifying that the account-totals for the period in fact totaled to zero, you'd then "post" (i.e., copy) the account-totals to a General Ledger -- which was just another sheaf of columnar accounting paper, one sheet per account number, from which you could then compile your Balance Sheet and Earnings Statement. (Of course, after posting the General Ledger, you'd have to again total all the amounts you just posted, checking that they still totaled to zero, so you'd know you'd copied them correctly.) As your business grows, just recording everything in the General Journal can get unwieldy. Customer Ledger You now have dozens of customers with dozens of transactions with each of them. The question is no longer "how much do they owe you", but "who owes you how much". So instead of recording customer

transactions in the General Journal, you set up a Sales Journal (to record all invoices going to customers) and a Cash Receipts Journal (to record payments received from those customers). At the end of each accounting period, you total the amounts for each account in these journals, and post them to the General Ledger (adding now a notation of what journal they came from) -- but you also post them to a Receivables Ledger (one sheet per customer) so you have a ready reference of how much each customer currently owes you. Vendor Ledger And you now have dozens of vendors with dozens of transactions with each of them. And the question is no longer "how much do I owe them", but "who do I owe how much to". So instead of recording vendor transactions in the General Journal, you set up a Purchase Journal (to record all invoices received from vendors) and a Purchase Disbursements Journal (to record all payments to those vendors). And at the end of each accounting period, you total the amounts for each account in these journals, and post them to the General Ledger -- but you also post them to a Payables Ledger (one sheet per vendor) so you have a ready reference of how much you currently owe each vendor. Employee Ledger And you may now have dozens of employees with dozens of transactions with each of them. And the question is no longer "how much do I owe in payroll and payroll taxes", but "who do I owe how much to". So instead of recording employee transactions in the General Journal, you set up a Payroll Journal (to record all pay accrued by employees and all payroll taxes owed thereon) and a Payroll Disbursements Journal (to record all payments to those employees and the government). And at the end of each accounting period, you total the amounts for each account in these journals, and post them to the General Ledger -- but you also post them to a Payroll Ledger (one sheet per employee) so you have a ready reference of how much you currently owe each employee and each government entity. Other Ledgers And you might add other Journals and other subsidiary Ledgers (e.g., Employee Advances, Employee Vacation, etc.) depending on the extent to which you need ready reference to their constituent balances. Candidates for subsidiary Ledgers are any asset, liability or equity accounts that you want to regularly break out by the entities (customers, vendors, employees, stockholders, etc.) that comprise their balance. All the transactions in all these Journals needed to be totaled to zero (to be certain you had recorded them correctly) and when they are posted to the Ledgers, they needed to be totaled again (to be sure you transferred them correctly).

Source Documents

The past two columns have talked about accounting -- how financial transactions are recorded (in Journals) and summarized (in Ledgers) and how the number and types of Journals and Ledgers may grow as your business grows. One thing we didn't talk about was what happens to all the pieces of paper that you recorded these transactions from -- the customer invoices and payments, vendor invoices and payments, employee time sheets and payments, etc., etc... You guessed it -- they get bound -- chronologically -- into Manila folders. These pieces of paper are your "source documents". They're the supporting documentation for each financial transaction you make. They're what you'll show the IRS auditor when he questions the validity of a transaction, i.e., was that payment really a valid business expense. Note: If you can't "prove" that the payment was a valid business expense, he can, and probably will, disallow it. Every expense he disallows goes right to your bottom line, increases your supposed "profit" and, therefore, your "tax due" -- which, of course, makes the time he spent with you that much more worthwhile -- and, of course, makes it that much more likely you'll see him again next year. If you don't have a source document for a transaction, e.g., you pay cash to someone and don't get a receipt, make one. Every source document should show what you did and, if it's not obvious, why you did it. It's a whole lot easier to jot that down when you do it (or when you record the transaction) than to try to remember several years later with an IRS auditor hanging over your shoulder. When To Close Another thing we didn't talk about is how often we should "close the books", i.e., post the Journal(s) to the Ledger(s). If you're keeping your accounting records only for the government (e.g., tax records), or to show the bank or investors, a month-end closing is probably adequate. But if you're using the financial records to manage your business -- as you really should be -- you really need to "close" more frequently -- like weekly. Keep in mind the axiom, "You can't manage what you can't measure". Financial recordkeeping gives you the means to manage your finances -- your cash, the monies your have coming in and going out, and when. Of all the things you have to "manage" in a business, how it's doing financially has to rank way up near the top of the list. The only difference between a "business" and a "hobby" is that a business makes money and a hobby doesn't. If you don't diligently manage your finances, it's likely you'll watch your business dream turn into a very-expensive hobby -- and one you can no longer afford. With paper accounting, there's a lot of work in closing weekly (well worth it -- but still a lot of work). With computer accounting, a week-end closing is no big deal. The computer can do all that posting and error-checking -- that used to take hours -- in microseconds. With the computer, it really doesn't matter whether you record your transactions in ordinary text files

and use programs or "scripts" you write to use the data -- or with the spreadsheet or database tools you may be familiar with -- or with full-fledged "accounting packages". In all cases, "closing" reduces to printing out your Journal data (hardcopy record for auditor or tax preparer -- or for your own use if you neglect recommended "computer backup" procedures), and any other Ledgers or summary reports that you find useful in hardcopy form -- a 5-minute job. In subsequent columns, we'll review the Journals we've previously mentioned in much more detail -- but we'll focus on the data that should be recorded and the uses of that data, rather than the actual mechanics of the recording or reporting. This (hopefully) will make it useful whether you choose to use paper or computer -- or how you choose do it with computer.

Chart of Accounts
When we introduced financial transactions (back in the Accounting Basics column), we showed them as, e.g., cash/1000+ equity/1000cash/200+ revenue/200cash/100- xpense/100+ receivable/200+ revenue/200payable/100- xpense/100+ The names (cash, equity, revenue, etc) are the "accounts" and the numbers are the "amounts" and the transactions are shown in "acct/amt acct/amt ..." format. In practice, "accounts" are typically represented by numbers (e.g., cash might be account 110, money market, 115, receivables, 130, payables, 420, etc.). There's nothing magic about that -- it's just generally easier to remember that 110 is cash than it is to remember whether we've chosen to represent cash as "cash", or "csh", or "ch". (A good practice is to use 3-digit numbers for assets, liabilities and equity, and 4-digit numbers for revenue and expenses). Note: The balances in your 3-digit accounts get carried over from year to year. The balances in your 4digit accounts get "closed out" at the end of each year (into Retained Earnings) and start the new year afresh at zero. The "key" that relates account numbers to account names is called the Chart of Accounts. The Chart of Accounts for a small product-line manufacturer might look like that shown below. This is just an example. Yours might contain fewer, different, or more accounts -- depending on what you find important to track (i.e., measure). The accounts are shown as account-number account-name, e.g., 101 Petty Cash, etc. The uppercase names, e.g., ASSETS (0-399), etc., are account summaries that you may wish to print out on your Balance Sheet and Earnings Statement (e.g., ASSETS (0-399) says that the amount to be shown for ASSETS on your Balance Sheet is to equal the sum of the balances in all account-numbers from 0

through 399). We'll talk about most of these accounts in subsequent columns.

General Journal
We introduced the General Journal in an earlier column, Paper Accounting. We said that all financial transactions could be recorded in a General Journal -- and in fact in the early months of a company, probably should be. We said that the essential data to be recorded are the date, the transaction (acct/amt acct/amt ...), and comments (e.g., who you paid or who paid you). The date is the date (mo/dy/yr), right? Not necessarily. If you're closing your books monthly, mo/dy/yr is ok -- the mo-entry clearly identifies the month. But if you're closing them weekly, it can get a little awkward. How do you identify what transactions belong to "this" week? Or "last" week? Or "this week" last year? You now need a "key" that relates each week in the year -- Sunday through Saturday, or however you choose to define a "week" -- to a beginning and ending mo/dy/yr. If you're doing paper accounting, that "key" is a calendar -- perhaps with week-numbers, e.g., 1-53, written on it. If you're doing computer accounting, however, your software must recognize what constitutes a "week" -- which may affect what you want in the date-field. For example, I use a week-number for date -- and did years ago when I was still paper accounting. My week-number format is <last-digit-of-year><week-number>, e.g., this year, 1998, my week-numbers run from 801-853. This method clearly identifies which transactions belong to which week. The only reason for last-digit-of-year is to avoid confusion with prior year transactions (which may have carried over as the result of year-end reversals, open receivables or payables, etc.) and next year transactions (so that I don't have to set up a next-year folder or computer file until I'm ready to close the current year). But how do you distinguish 1988 transactions from 1998 transactions? By the label on the Manila folder, "General Journal - 1988" -- or in the case of the computer, the directory name is "General Journal" and the file under it containing 1988 data is named "1988". How do you know what day the transaction happened? For most businesses, that's a "don't care". It really doesn't make any difference whether incoming transactions (e.g., vendor invoices) were received on Tuesday... or Wednesday... or Thursday (after all the Post Office is not that dependable). It does make a difference what "week" they were received because payment is going to be due about 4 weeks later. And most businesses do their outgoing transactions (e.g., bill payment, payroll, etc.) only once a week. And if you really need to know the exact day something was received, you can always go back to the source document (assuming you do date-stamp incoming mail). For businesses that do care about day (e,g., retail, where you'd like to compare this Monday's sales with the equivalent "Monday" of prior years), a day-of-week encoding (e.g., 1-7) can to be added to the journal. For example, in my retail businesses, I used day-number as the first digit of my sales-receipt

numbers, which numbers ended up in the equivalent of the comments-field above. The General Journal requires two Manila folders (whether you're doing paper or computer accounting). One is for the hard-copy Journal. Even if you're keeping the Journal on computer, you need a hard-copy for auditors and others -- and to backup your backup. The other is for the source documents -- the piece(s) of paper you recorded the transactions from. One passing suggestion -- my comments-field always starts off with a sequence-number (within the week). Then I annotate the upper-right-hand corner of each source document with <weeknumber><sequence-number>, e.g., 826-1, 826-2, etc. This makes it easier to go back and find a particular source document, especially if there are a lot of them. The General Journal records all transactions not recorded elsewhere, i.e., in other journals. Since subsequent columns will be describing these other journals, we'll leave the details of the transactions to those columns.

Payables Accounting
Payables deal with paying vendors (including the government). If your payments are few or mostly in cash, it's probably best to just record them in the General Journal. The typical transaction is <date> <cash/amt- expense/amt+..> <comments>, where <comments> include who you paid. However, if you make many payments... generally to invoices received... with payments generally made by check... it pays to set up a Payables system. A Payables system involves a Purchase Journal -- in which all vendor invoices received are recorded -and a Purchase Disbursements Journal -- in which all payments to those vendors are recorded. Purchase Journal The typical record in the Purchase Journal is <date> <payable/amt- expense/amt+... > <comments>, where <comments> include vendor (name or number) and any other data you may wish to record, like date-scheduled-to-pay, vendor-invoice-number, etc. Note: Keep in mind that if you use vendor numbers you will need a "key" -- paper listing or computer file -- associating the vendor numbers with vendor names, and perhaps other vendor data, e.g., address/phone/fax of where you order from, where you pay to, any special payment terms you have with that vendor, etc.). Purchase Disbursements Journal The typical record in the Purchase Disbursements Journal is <date> <check-nbr> <cash/amtpayable/amt+> <comments>, where <comments> include vendor (name or number) and any other data you may wish to record. Note that the transactions in these two Journals, netted together, reduce to the

cash/expense transaction we showed in the first paragraph. If you're doing paper accounting, it's recommended you set up a separate checking account used only for Payables. The reason for this is that your Purchase Disbursements Journal then becomes a sequential listing of your check numbers -- making it immediately obvious if any have been lost or stolen. If you're doing computer accounting, that's not as important because the computer can detect missing check numbers. (But make sure you have, get, or write software that can.) Payables Ledger With paper accounting, the transactions in these Journals are periodically (weekly or monthly) summarized into a Payables Ledger, by vendor (see earlier article, Paper Accounting). This lets you easily see how much you owe to who, compile Payables Aging Statements for your bank, etc. Note: A Payables Aging Statement is a list of active vendors with the amount due them in columns labeled, e.g, Current, Over 30 days, Over 60 days, Over 90 days, etc. Computer With computer accounting, it's not necessary to keep Purchase and Purchase Disbursements transactions in separate files since much of the data is redundant. Rather they can be recorded directly in what, in a paper system, would be considered a Payables Ledger. Essential data is <vendor> <date-paid> <check-nbr> <date-rcvd> <payable-amt > <expense/amt+... > <comments>. Using an undefined <check-nbr>, e.g., 0000, allows <date-paid> to serve as datescheduled-for-payment until such time as payment is actually made (whereupon <date-paid> becomes the real payment date and <check-nbr> becomes the real check number). From this data, the computer can look at <date-rcvd> to compile a hard-copy Purchase Journal and at <date-paid> (and <check-nbr>) to compile a hard-copy Purchase Disbursements Journal... or to print a Payables Aging Statement... or to print the actual checks themselves. Other useful data can be included in <comments> -- for example, the last 4 or 5 digits of vendors' invoice numbers. This makes it easier to check the payment status of an invoice when vendors call... Or coding that allows you to distinguish different classes of invoices from the same vendor, e.g., utility bills for different facilities paid to the same vendor... Or coding that allows you to distinguish the "real" vendor from the payee, e.g., when the invoices are to be paid to a factor... Or coding that allows you to distinguish which line-items of a Purchase Order are being billed by the invoice... Etc. Caution: The Ledger format shown above applies only if you pay "whole" invoices. If you may make "partial" payments on invoices, you'll need to add a "keying" system as we'll describe under under Receivables Accounting. Transactions

The "..." shown in the Payable Journal transaction field denotes that the <payable-amt> may be divided among multiple expense accounts. For example, with the Post Office now in retail, you might buy both stamps and mailing supplies from them. The transaction would be, payable/amt- postage/amt+ supplies/amt+ -- assuming you wished to account postage and supplies separately. When you buy something from a remote vendor, you could account it as, payable/amt- expense/amt+. Or as, payable/amt- expense/amt+ freight-in/amt+, if you wanted to watch your incoming shipping costs (a good policy)... Or as, payable/amt- expense/amt+ freight-in/amt+ sales-use-tax/amt+, if part of the bill was sales-use tax... Etc. And, under U.S. tax law, not everything you buy can be directly expensed, i.e., accounted to an expense-account. For example, inventory (products bought for resale, materials bought to manufacture products to be sold, etc.) can't be expensed until sold -- and in the meantime are accounted in an inventory assetaccount, e.g., payable/amt- inventory/amt+. Depreciable property (buildings, machinery and equipment, furniture and fixtures, etc.) may only be expensed over time (i.e., depreciated) -- and is accounted in a property asset-account, e.g., payable/amtproperty/amt+. New Accounts How do you know when you need to add a new account to your Chart of Accounts? Whenever it's required to be reported separately on a tax return. And -- if you're using your financial records to manage your finances -- whenever a definable expense becomes "significant". For example, if your Selling Expenses are running about 10% of sales, if your advertising expense... or literature expense... starts approaching 1% of sales, those expenses should certainly be called out as separate accounts. Non-Payables Disbursements And what payments might not be made out of Payables? Any payments made with other than Payables checks e.g., cash payments (minimize -- checks are a better record), transfers into Payables checking (i.e., checks written with Cash-in-Bank or Money-Market checks to replenish Payables checking), Payroll (if you have a Payroll checking account), replenishment of Payroll checking, etc. If you have a Payables account, try to make all payments with Payables checks -- even where that requires simultaneous Purchase and Purchase Disbursement transactions (e.g., paying a shipper -- at the door -- for a C.O.D. delivery).

Payables Processing
The major problem faced in payables processing is avoiding overpayments -- especially paying the same invoice multiple times.

After many years of dealing with other companies' payables processing, I can assure you that most companies are atrocious at this -- regardless of size. For example, when I was manufacturing, whenever a company would send in a Purchase Order, we'd return a Sales Order confirming their order and scheduled delivery. Then when we'd ship the order, we'd send them an Invoice. And later, if they hadn't paid within terms, we'd send them a Statement reminding them of their open invoices. It is unbelievable how many companies paid not only against the Invoice -- but against the Sales Order and against the Statement -- they'd triple pay on one order! And the invoiced amounts were not insignificant -- seldom less than $1,000. And all would occasionally do it -- even very large companies like the Big 3, Armco Steel, Hewlett Packard, Bell Labs, etc. We had a policy that, whenever we received an overpayment, we would notify the company and ask how they wanted to handle it. But once and only once -- it's hard enough dunning companies for underpayments -- it's unreasonable to expect to have to dun for overpayments. Even more unbelievable, less than 10% ever responded to these notices -- happily the small companies were much more likely than the large. As you'll see when we get into Receivables, the Bad Debt account is the account into which you expense uncollectible amounts. I never had a year in which my Bad Debt account did not show "revenue"! Note: In fairness to large companies, their poor performance is not simply a matter of ineptitude. Large companies purposefully try to balance the costs of overpaying against the administrative costs of trying to avoid doing so. They do periodic sample audits to see how much they're overpaying -- and so long as their overpayments remain only a few percent of their total payments, they consider that "good enough". (Of course, my experience leaves me questioning just how good their sample audits really are.) Anyway, you may think you're not overpaying -- but, if you're paying more than a very few bills, the odds are overwhelming that you are. I'm sure I have. There's no way to totally avoid the problem -- the best you can do is try to minimize it, with consistent procedures, similar to those outlined below. Payables Procedures Each day, take the vendor invoices received that day and prepare them as source documents. This may involve attaching other sheets -- like the packing slip (or other receiving record) evidencing actual receipt of the goods being invoiced. (Not only do you not want to double-pay, you don't want to pay for things you didn't receive!) Additional attachments could include a copy of the catalog page from which the goods were ordered... or a copy of your Purchase Order... whatever you'd like to see when you later refer to the invoice. The processing may also involve annotating the invoice with the transaction to be recorded, checking it against recent payments to the vendor to verify that it hasn't been paid, etc. If you -- the (sole) owner -- are doing this yourself, you may decide no other "approval to pay" is needed. However, if someone else is doing it, the source documents should come to you for approval --

and they should come to you with sufficient data that you can knowledgeably approve them. After approval-to-pay, the financial transactions they represent should be recorded in your Purchase Journal (paper) or Payables Ledger (computer), and filed in a week-to-be-paid folder (e.g., labeled Purchase Disbursements Journal, week-number). At the end of each week, you pull the current week-to-be-paid folder, write/print, sign and mail the checks. Again, if this is being done by someone other than the owner, the owner should sign the checks. The week-to-be-paid folder then -- automatically -- becomes the historical week-paid folder, containing the complete backup for all Payables checks written that week. Passing suggestion -- before writing the checks against this folder, consider re-arranging the folder to put the source documents in vendornumber order. This makes it easier to later find the source document by either check-number or vendornumber.

Receivables Accounting
Receivables deal with the payments received from your customers or clients. If these payments are few, it's probably best to just record them in the General Journal. The typical transaction is <date> <cash/amt+ revenue/amt- ...> <comments>, where <comments> include who paid you. However, if you receive many payments, generally against invoices you've issued, it pays to set up a Receivables system. (Note: If your business is retail, none of this applies. We'll talk about the handling and recording of incoming retail cash in a later column), A Receivables system involves a Sales Journal -- in which all invoices outgoing to customers are recorded -- and a Cash Receipts Journal -- in which all payments incoming from those customers are recorded. Sales Journal The typical transaction in the Sales Journal is <date> <invoice-nbr> <receivable/amt+ revenue/amt- ...> <comments>, where <comments include customer (name or number) and any other data you may wish to record, like your sales-order-number (if you use one). Note: Keep in mind that if you use customer numbers you will need a "key" -- paper listing or computer file -- associating the customer numbers with customer names, and perhaps other customer data, e.g., address/phone/fax of where you sell to, where orders come from, where payments come from, special terms you may have with them, etc. Cash Receipts Journal The typical transaction in the Cash Receipts Journal is <date> <invoice-nbr> <cash/amt+ receivable/amt-> <comments>, where <comments> again include customer (name or number) and any other data you may wish to record. Note that the transactions in these two Journals -- netted together --

reduce to the cash/revenue transaction we showed in the first paragraph. If you're doing paper accounting, the Sales Journal is important because it's your only sequential listing of customer invoice numbers -- making it immediately obvious if any are being used for purposes you had not intended. (The Cash Receipts Journal is equally important -- in an incoming cash control sense -- but we'll get into that later under Receivables Processing.) If you're doing computer accounting, invoice-number tracking is not as important because the computer can detect missing numbers. (But make sure you have, get, or write software that can.) With paper accounting, the transactions in these Journals are periodically (weekly or monthly) summarized into a Receivables Ledger, by customer (see earlier article, Paper Accounting). This lets you easily see how much each customer owes you, and whether (and how much) they're falling behind in payments. It also facilitates compiling a Receivables Schedule for your bank (as your receivables are likely one of the important assets they're loaning you money against). Computer With computer accounting, it's not necessary to keep Sales and Cash Receipts transactions in separate files since recording them directly in what, in a paper system, would be considered a Receivables Ledger is much more convenient. Essential data is <customer> <key> <date> <transaction> <invoice-nbr> <comments>. In the Ledger, Sales transactions, receivable/amt+ revenue/amt- ..., can be distinguished from Cash Receipt transactions, cash/amt+ receivable/amt- ..., by the lead account-number of the transaction. The computer can compile a hard-copy Sales Journal by looking for transactions that lead with the receivable account-number, and a hard-copy Cash Receipts Journal by looking for transactions that lead with the cash account-number. And by netting the receivable and cash amounts for each customer, compile the Receivables Schedule for your bank. Or by also looking at date, compile a Receivables Aging Statement for both you and the bank. Note the addition of <key> to the data. Since we have no control over customers making partial payments on our invoices, we have to provide for that eventuality. We do so by adding a "keying" system. Although there are many methods for "keying off" transactions, I'll describe one I've used. One field in the Ledger file is reserved for a "key". When an invoice (sales transaction) is first recorded, the key is left blank. When payment of that invoice is received, a letter or number (sequential by customer) is entered into the key in both the sales and cash receipts transactions. However, if only a partial payment was received, the key is left blank (on both transactions). The key is not filled in until the invoice has been paid in full -- and then the sales and all the cash receipts transactions that went into paying it off are "keyed off". Shipping & Sales Tax We showed the Sales transaction above as, receivable/amt+ revenue/amt-. However if you're shipping goods, you're probably billing the customer the shipping cost. (Actually, you're billing them to

reimburse you for the shipping cost your shipper billed you. You have, or will have, in your Purchase Journal, a bill from the shipper, payable/amt- freight-out/amt+.) The shipping cost you're billing the customer wants to offset your freight-out expense. So the more typical Sales transaction -- if you're shipping goods -- will be receivable/amt+ revenue/amt- freight-out/amt-. Similarly, if you're collecting sales/use tax on the sale, that tax has to be reported and paid to the state and, to simplify reporting and audit, should be accounted separately, e.g., into a Sales/Use Tax payables-account. So the more typical Sales transaction -- if you're also collecting sales/use tax -- will be receivable/amt+ revenue/amt- freight-out/amt- sales-use-tax-payable/amt-. Note: The states have been complaining for years that it's unfair that companies only have to collect sales-use tax on sales in states in which they are "doing business", i.e., in which they have physical presence. But here you can see the companies' problem -- are we really going to require every small business to set up 50 Sales/Use Tax payable-accounts (one for each state) -- never mind the subsequent hassle of understanding each state's rules, of paper-reporting to each state -- and making time for each state's audits. The answer to that question is -- yes, we probably will -- the powers-that-be believe that, with computers, it's not that big a hassle (sure it isn't!). See why "tax simplification" might be high on the small business agenda? Sales Allowance What if the customer pays the invoice -- except for a small amount (e.g., a few cents) that isn't worth going after? Set up a Sales Allowance expense-account and record the transaction as, cash/amt+ receivable/amt- sales-allowance/amt+. The receivable-amount matches what was owed (allowing the invoice to be keyed off) and the difference (between what was invoiced and what was paid) is expensed to sales-allowance. Reinvoiceable What if the amount is worth going after (e.g., a few dollars)? Just leave the transactions un-keyed-off until you collect. But what if the customer is a regular, keeps underpaying by a few dollars, and you start building up a bunch of un-keyed-off invoices that start becoming a hassle to you in trying to understand (and communicate) what they owe? That's where a Reinvoiceable receivables-account can come in handy. Simply transfer all those amounts from your normal Receivables account to a Reinvoiceable account with transactions of the form, receivable/amt- reinvoiceable-receivable/amt+. That allows you to key-off all those invoices -- without losing sight that they're still owed. (You just moved them into a different receivables account.) And if you want to re-invoice the customer for these unpaid amounts, go ahead. If they're that much out of control or into playing those kind of games, they deserve the opportunity to double-pay. (Just remember, when/if they pay to credit the payment to the right receivables account.)

Bad Debt What if the customer doesn't pay? All your dunning efforts have been unsuccessful -- and so has putting them into collection. Then you write-off the invoice (or unpaid balance) into a Bad Debt expenseaccount with the transaction, receivable/amt- bad-debt/amt+, keying off the invoice. Note: And as we mentioned in the Payables Processing column, this is not a bad place to record overpayments, cash/amt+ receivable/amt- bad-debt/amt-, where receivable is the amount owed, cash the amount paid and bad-debt the overpayment. Of course, if you subsequently have to return the overpayment, you'll have a Payables transaction, payable/amt- bad-debt/amt+. Credits What if the customer returns the goods and you want to credit out their invoice? Do a negative invoice (a.k.a., Credit Memo), with a transaction, receivable/amt- revenue/amt+, that keys-off the invoice. What if you want to charge them a restocking charge? If you infrequently bill restocking charges, simply credit out only part of the invoice (i.e., less the charge), and leave the invoice open (i.e., don't key it off). until the restocking charge is received. However, if you regularly bill restocking charges, you may wish to set up a Restocking receivablesaccount, receivable/amt- restocking-receivable/amt+, to track them separately -- or a Restocking revenue-account, in which you credit out the entire invoice, receivable/amt- revenue/amt+, and reinvoice the restocking charge, receivable/amt+ restocking-revenue/amt-. If you choose the latter, be sure you have a system in place that guarantees that the restocking invoice gets written. Be very, very careful with Sales transactions that give credit (i.e., any transactions that lead with receivable/amt-) -- whether they're giving credit or making corrections. Every one of them is an opportunity for your money to walk out the door.

Receivables Processing
There are two parts to receivables processing -- Sales processing and Cash Receipts processing. Sales Processing A "sale" starts when you receive a Purchase Order from a customer. That PO may kick off a Shipping Order (an in-house record to ship against) or a Job Order (an in-house record to build and ship against). If you need to send the customer written confirmation of scheduled delivery -- or your product's somewhat custom and you want to confirm with the customer (in your terms) what they've ordered -you might consider a Sales Order (a restatement of their PO). These papers are "operations" records -- not "financial" records (although they can be, which we'll get into in later columns when we talk about Inventory accounting). For now, they (or a copy of them) can

be simply held in an Customer Open Orders folder until the order is invoiced. A Customer Invoice is kicked off by some record (which may be one of the above "Orders" from the shipping area) recording when and what was shipped. A customer invoice is prepared and mailed, a Sales Journal source document is prepared, and the sale (i.e., the customer invoice) is recorded in the Sales Journal. The source document consists of a copy of the customer invoice and whatever "source data" you want to attach to it, e.g., the customer's Purchase Order, your Sales Order, whatever shipment record you've used, etc. If you've shipped only part of the order, you might annotate the line items of the PO/SO in the Customer Open Orders folder with date shipped, attach a copy of them to the invoice (maybe yellowhighlighting the parts shipped), and leave the original PO/SO in the Customer Open Orders folder until it ships completely. The Sales Journal source document is filed in a Sales Journal Source Document folder, by Invoicenumber, for ready reference when payments against that invoice are received. Cash Receipts Processing The major problem faced in cash receipts processing is making sure that all the monies coming in from customers really ends up in your bank account If you (the sole owner) receives and opens the mail, records the cash receipts, prepares and makes the bank deposits, no special procedures are likely required. However, if any employee (or another owner) is involved in any of these steps, procedures similar to those outlined below are recommended. Receiving and opening the mail (at least that addressed to the company) should be vested in one person (and not the one doing the subsequent receivables processing). Have that person keep a daily log of cash receipts -- a simple listing of payer, amount and total -- stamp each check with the company's bank deposit stamp, and forward to the person who will be doing the processing. That person prepares a source document for each cash receipt, in this case just a copy of the check annotated with week received, your invoice-number and anything else you might find useful. They then determine how the transaction should be recorded, record it, file the source documents in a Cash Receipts Source Document folder and put the checks in a safe place (e.g., in a bank bag stuck in the rear of an unrelated file cabinet drawer). The reason for annotating the Cash Receipts source document with invoice-number is to provide ready reference back to the Sales source document where most of the "source data" for the sale is filed. Note that we could have set up the files so that all source data for the sale ended up in the Cash Receipt Source Document folder -- as we set it up in Payables so that all source data for the purchase ended up in the Purchase Disbursements Source Document folder. In Payables, we chose to do it that way because we have control over how and when we make our payments (assuming we have adequate cash to pay our bills). But in Receivables, we have no control over how our customers choose to pay. Each time our customers

paid only part of our invoice, we'd have to attach and annotate a copy of the source data to the Cash Receipts source document and leave the original source data in an Open folder until the invoice was totally paid. That could amount to a lot of superfluous copying. However, if our customers always pay our invoices fully, attaching the source data to the Cash Receipts source document (and avoiding Sales Source Document folders altogether) could make sense. The point is there is no right or wrong to these decisions -- so long as you understand what you're doing and it meets your needs and the needs of others (internal and external) who may reference the data. It can be argued that the checks should be deposited every day. However, that's a hassle and the risks are minimal. Each check is stamped with a "For deposit only" to your bank account number, so even if they're stolen, the thief is going to have trouble doing anything with them. And you have a good record of them (in both your Cash Receipts Journal and Source Document folder) so you can notify your customers to stop payment on them and issue new checks. Periodically, e.g., at the end of each week, the Cash Receipts Journal is printed and filed, the checks are pulled, a bank deposit slip prepared, the checks deposited, and the bank's deposit receipt rubbercemented to the top sheet in the Cash Receipts Source Document folder. If you're computer accounting, the computer can print out the bank deposit data (same program that prints out the Cash Receipts Journal -- just different format). As owner, you should check that the checks-in log, the Cash Receipts Journal and the bank's deposit receipt all match, i.e., all the monies that came in were in fact deposited. About the only place this system can be "gamed" is at the mail-opening point. The person opening the mail may not stamp some checks and try to cash them himself. That's why you don't want this person involved with the receivables processing (sending out statements, talking to customers about overdue accounts, etc.). It's only a matter of time before this second person catches on to what's happening. What if the two of them conspire? About all you can do is keep a close eye on your Receivables Aging Statement -- and don't be afraid to call on an overdue account yourself!

Payroll Accounting
Payroll deals with paying your employees (including seeing that the government gets the monies they require you to withhold from the employees and the payroll taxes they require you to pay). If you have occasional employees, or even one or two full- or part-time, you can get by recording the payroll transactions in the General Journal. The typical transaction is <date> <cash/amt- laborexpense/amt+... withholding/amt-... accrued-tax/amt-... tax-expense/amt+...> <comments>, where <comments> include who you paid and the hours they worked. Labor-expense, withholding, accruedtaxes, and tax-expense include multiple accounts as we'll get into below. If you have more than a couple of employees it definitely pays to set up a Payroll system.

A Payroll system involves a Payroll Journal -- in which payroll is accrued, i.e., held in an "owed" state (like an open vendor invoice) until paid, and a Payroll Disbursements Journal -- in which the actual payments to the employees are recorded. Payroll Journal The typical transaction in the Payroll Journal is <date> <accrued-wage/amt- labor-expense/amt+...> <comments>, where accrued-wage is the employee's gross pay and <comments> include employee (name or number) and any other data you may wish to record, like hours-worked. Note: Keep in mind that if you use employee numbers you will need a "key" -- paper listing or computer file -- associating the employee numbers with employee names, and perhaps other employee data, e.g., their pay rate, federal and state tax exemptions, address, phone, social-security number, birthdate and any other data you need or the government requires you to maintain. The labor-expense in the above transaction might be to a single Labor account, or to many Labor accounts as shown in our earlier Chart of Accounts column, e.g., Administrative labor, Selling labor, Engineering labor, Manufacturing labor (and that could be further sub-divided into Area1 labor, Area2 labor, etc., depending on how finely we wish to track our labor costs). Payroll Disbursements Journal The typical transaction in the Payroll Disbursements Journal is <date> <check-nbr> <cash/amtaccrued-wage/amt+ withholding/amt-... accrued-tax/amt-... tax-expense/amt+...> <comments>, where <comments> include employee (name or number) and any other data you may wish to record. Note that the transactions in these two Journals -- netted together -- reduce to the cash/laborexpense/withholding/accrued-tax/tax-expense transaction we showed in the second paragraph. If you're doing paper accounting, it's recommended you set up a separate checking account used only for Payroll. The reason for this is that your Payroll Disbursements Journal then becomes a sequential listing of your check numbers -- making it immediately obvious if any have been lost or stolen. If you're doing computer accounting, that's not as important because the computer can detect missing check numbers. (But make sure you have, get, or write software that can.) With paper accounting, the transactions in these Journals are periodically (weekly or monthly) summarized into a Payroll Ledger, by employee (see earlier article, Paper Accounting). This lets you and others (e.g., a Labor Department or EEOC auditor) easily review the pay record and status of each employee. Payroll Withholdings & Taxes Now we have to get into withholdings and accrued taxes. Bear with me. This involves a lot of detail (don't blame me -- blame your user-friendly government) -- but there's really nothing horribly complicated about it.

The withholding portion of the Payroll Disbursements transaction are the monies required (by government dictum) to be withheld from each employee's gross pay. They include Withheld Federal Income Tax (WH-FIT), Withheld Social Security (WH-FICA), Withheld Medicare (WH-FICM), and Withheld State Income Tax (WH-SIT). The withholding portion of that transaction should really have been written as WH-FIT/amt- WHFICA/amt- WH-FICM/amt- WH-SIT/amt- .... The "..." indicates there may be more, e.g., if you have employees in other states, you'll need a separate WH-SIT account for each state... if you offer your employees "direct deposit" to their bank account, you'll have one or more WH-Bank accounts. The accrued-tax portion of the Payroll Disbursements transaction are monies you are required to pay for the "privilege" of having employees. They include AT-FICA (an amount related to WH-FICA, usually equal), AT-FICM (an amount related to WH-FICM, usually equal), AT-FUT (Federal Unemployment Tax), and AT-SUT (State Unemployment Tax), The accrued-tax portion of that transaction should really have been written as AT-FICA/amt- ATFICM/amt- AT-FUT/amt- AT-SUT/amt- .... And the tax-expense portion of the Payroll Disbursements transaction are the expense part of the accrued-tax transaction, i.e., FICA-expense = AT-FICA, FICM-expense = AT-FICM, FUT-expense = AT-FUT, and SUT-expense = AT-SUT. The tax-expense portion of that transaction should really have been written as FICA-expense/amt+ FICM-expense/amt+ FUT-expense/amt+ SUT-expense/amt+ .... Most of what you need to know to calculate these payroll withholdings and taxes are spelled out in Circular E (available from the Federal government and updated annually) and an equivalent booklet(s) available from the State government(s). The calculations are generally straight-forward -- simple linear equations, with tables included for those processing manually. Now, I've implied above that the accrued-tax and tax-expense amounts have to be calculated for each employee. They don't -- they can be calculated on total payroll. If you're processing payroll manually, you'd typically drop these from the Payroll Disbursements transaction and record separate transactions of the form, accrued-tax/amt- tax-expense/amt+, directly into your Purchase Journal. However, with computer processing it's easier to calculate them by employee because they all come with upper limits -- each applies only to the first $x of an employee's gross pay. (With manual processing, the person doing the processing sorta has to watch for these limits with side calculations.)

So how do all these payroll withholdings and taxes get paid to the government. The same Federal and state booklets we referred to earlier specify how and when they must be reported and paid and the Forms or deposit records to be used for reporting. A copy of these Forms or records becomes the source document for a Purchase Disbursement Journal entry recording the actual payment. WARNING: Make these payments -- and on time -- even if you don't have the cash to pay anyone else. The penalties for late payments are draconian -- and the government entities have Gestapo-like powers to collect far exceeding those of other debtors and penetrating into normal bankruptcy protections. Always -- pay your friendly government -- first! Computer With computer accounting, it's not necessary to keep Payroll and Payroll Disbursements transactions in separate files since recording them directly in what, in a paper system, would be considered a Payroll Ledger is more convenient. Essential data is <employee> <date-paid> <check-nbr> <date-accrued> <transaction>, where <transaction> consists of cash/amt- accrued-wage/amt+ and all the withholdings, accrued-taxes, taxexpenses and labor-expenses we talked about earlier. From this data, the computer can look at <date-accrued> to compile a hard-copy Payroll Journal and at <date-paid> to compile a hard-copy Payroll Disbursements Journal... or to print the payroll checks... or to printout the myriad payroll reporting forms... or to printout an Employee Pay Record for the year. If you intend to set this up yourself, i.e., put this data into a file to be processed by your own scripts, programs, tools, etc., a suggestion. In addition to the "essential data" we showed above, consider adding another type of record (an employee-record) that contains <employee> <date-changed> <pay-rate> <federal/state-tax-exemptions>, data that you would otherwise keep in an Employee Key. This buys you two things. First, a time-record of employee pay-rate and exemption changes. Second, it allows you to record labor-expenses in "hours" instead of "dollars" -- which you need to maintain for other purposes anyway. All payroll disbursements made on or after <date-changed> are processed using the new <pay-rate> and <exemptions>. And in fact doing it this way allows you to write a script, program, macro, etc., that calculates your payroll (and writes the data into the file) automatically -- you provide only employee and labor-hours (which you get from their Time Sheets or equivalent). I use a simple 50ish-line awk script that can calculate payroll (including all the withholdings and taxes) for several hundred employees in seconds -- and print out the checks and hard-copy Journals. And the only time I have to fiddle with the script is when the government's rules change (which is typically once a year). Source Documents The Payroll source documents are the employee Time Sheets (or equivalent) that record when the employee worked and generally what they did. These records are subject to audit by the Labor Department, EEOC and probably others that I haven't encountered. These should be bound into a

Payroll week-paid Source Document folder. However, there are other employee documents that need to be retained, e.g., their original employment application, employee reviews (if you do them), Federal and state W-4s (that record their federal/state tax exemption choices), employer's copy of their W-2 (reporting their annual wages and withholdings), etc. These can be filed in separate Employee files (by employee name or number) -- or simply integrated into the Payroll Source Document folders (in the week in which they occur). I very much favor the latter -- especially if you're doing computer accounting -- in keeping with my "always file chronological" bias.

Miscellaneous Accounts
We've talked about Payables, Receivables and Payroll. We still need to talk about Property and Inventory. But before getting into those, there are a few miscellaneous accounts we should touch on.

Overtime
If you ask your hourly employees to work more than 40 hours in a week, or ask them to work on holidays, the government requires you to pay them overtime -- time-and-a-half or double-time. You should account the overtime premium into a separate overtime-expense account -- for government audit, but also to watch what that practice (i.e., asking employees to work overtime) is costing you. In your Payroll Journal, account their actual hours worked to the labor-expense account -- but account the overtime premium (i.e., the extra half- or full-hour you're paying them) to an overtime-expense account, e.g., accrued-wage/amt- labor-expense/amt+ overtime-expense/amt+.

Employee Vacation
If you accrue vacation for your employees, you need to account it. That's money you owe -- and if it doesn't show up on your Balance Sheet, you're just digging yourself another hole of unforeseen expense. We need to add an accrued-vacation account and a vacation-expense account. When you accrue vacation for your employees, e.g., at end of month, you have a General Journal transaction, accrued-vacation/amt- vacation-expense/amt+. When they take vacation, it's a normal payroll transaction -- their vacation time is simply charged to the accrued-vacation account number. If you have many employees, you should consider setting up an Employee Vacation journal, to record the individual accruals, and an Employee Vacation subsidiary ledger (sheet per employee) to track their balances. The interesting aspect of employee vacation accounting is that the accounting is typically in hours -- not dollars. Your employees are concerned with how many "hours" of vacation they have coming -- not with how many "dollars". But your financial records need to be in dollars. If an $8/hour employee has

40 hours of vacation accrued, your liability to that employee is $320 -- and should show as such on your Balance Sheet. But what if between accruals, you raise that employee's pay to $9/hour. Your liability to that employee just went from $320 to $360. You need another General Journal (or Vacation Journal) transaction, accrued-vacation/amt- vacation-expense/amt+, to record this added liability. These accruals can be expensed to vacation-expense, as shown -- however, I prefer to expense them to a separate account, vacation-rate-change-expense, simply to track what they're costing separate from the normal accruals. If you offer your employees sick time -- in addition to vacation -- recognize you'll have a parallel set of books and transactions recording that time. Just replace "vacation" in everything above with "sick time".

Travel & Entertainment

Keep in mind that an employee can also be a vendor. For example, an employee travels to a trade show or entertains a customer for your company. He turns in an Expense Report and you reimburse him. This is a Payables transaction (cash/amt- T&E/amt+) -- NOT Payroll. It is important to account employee travel & entertainment expenses into a separate Travel & Entertainment (T&E) account because the government has its own peculiar ideas about what T&E expenses are "valid" -- hey, the employee had to eat anyway -- and this is one of the first areas an IRS auditor will dig into. Note: If you have T&E expenses, make special effort to stay current with the rules -- and adhere to them strictly! By the time an audit rolls around -- and you argue and appeal a bit -- you will find that penalties and interest can more than double the amounts disallowed. What if you advance the employee cash for a trip? That's a payables transaction, cash/amt- employeeadvance/amt+. When the employee turns in his Expense Report, another payables transaction, cash/amt- employee-advance/amt- T&E/amt+ -- if the advance didn't cover the trip... Or a general journal transaction, employee-advance/amt- T&E/amt+ -- if it did but he hasn't yet returned the overage... Or a cash receipts transaction, cash/amt+ employee-advance/amt- T&E/amt+ -- if he did return the overage. This latter is a good illustration of the importance of good accounting. It's so easy to advance someone, say $500, for a trip you want them to take for you. And they come back with an expense report for, say $450. You know they owe you $50 -- but that's very easy to forget. But if you account the transaction properly, there sits $50 in an Employee Advance account that stares back at you every time you look at your Balance Sheet. Now forgetting that $50 isn't likely to put you under -- but it doesn't take that many to do so.

Petty Cash
When you or your employees frequently make small (reimbursable) cash purchases from local businesses, it's convenient to set up a Petty Cash box. You initially load it with cash, say $100.

Whenever someone needs to be reimbursed for a small cash purchase, they simply turn in the receipt (or fill out a petty-cash slip) and the keeper of the box gives them cash. Eventually the box will contain more receipts and slips than cash -- whereupon we reimburse (replenish) the box by writing a Payables check to vendor "Petty Cash". The transaction to initially set up the box is cash/100- petty-cash/100+. Since petty-cash is an asset account, this has no effect on your expenses. When you go to replenish the box, you'll find that the receipts and slips will need to be accounted to many different expense accounts. The transaction is payable/amt- expense/amt+ .... Note that the petty-cash account balance doesn't change -- it continues to show on your Balance Sheet as a asset of $100. However, this transaction -- in terms of number of expense/amt+ entries -- can be one of the longest you'll encounter. Make sure you have, get or write software that can handle long transactions.

Commissions Payable
Let's say you do your selling through sales reps and they get, say a 5% commission on sales. You need some way of accruing these commissions so you can pay them out as agreed, e.g., monthly. You're going to need a commissions-payable account and a commissions-expense account. First question -- is the commission accrued on order or on invoice? If on order, you're going to have to build into your Customer Order Processing system a step that enters a Payable -- commissionspayable/amt- commissions-expense/amt+. If on invoice, however, you can simply add that transaction onto the end of your normal sales transaction -- see earlier Receivables Accounting column. Reps prefer the former. I very much prefer the latter -- less transactions and easier to audit. If you have many reps, you may wish to set up a separate Commissions Payable subsidiary ledger (sheet per rep) so you can more easily track how each is doing and how much each is owed. At end of month, another Payable transaction(s), cash/amt- commissions-payable/amt+, to pay each what you owe.

Bank Loan
The bank loans you some money. You now have cash -- but you also have a debt. Transaction is cash/amt+ bank-loan/amt-. The added cash shows as an asset on your Balance Sheet -- but the bank loan shows as an offsetting liability. The bank will expect you to make regular interest payments on that loan. If the payments are interest only, the payable transaction is cash/amt- interest-expense/amt+. If it's a self-amortizing loan (i.e., your payments include principal), the payable transaction is cash/amt- bank-loan/amt+ interestexpense/amt+.

Property Accounting
When you invest in property (building, machinery, furniture, vehicle, etc.), the government doesn't let

you "expense" it. Rather you have to put it into an asset account, cash/amt- property/amt+, and depreciate it over it's "economic life" (which the government -- not you -- defines, and which they lengthen whenever they need a little more tax revenue -- which is often). Depreciation is a curse on small business -- one that every small business suffers with. Government acts like your partner -- after all, they are taking 50% of your profits (in taxes -- city, state, federal). And for all the things they let you expense, they're picking up half the costs. But for things you have to depreciate, they shift the cost burden onto you. In the year you buy, say a building (30-year economic life), you pick up the full cost of that building -- and they pick up 1/30! And they'll argue that's "fair". They don't see themselves as your "partner". (Too bad, because if they did, we'd have a much more booming small business economy.) Instead, they look at your business simply as an economic entity. If they let you expense that building, it wouldn't show up on your Balance Sheet. The "book" value of your entity would drop by the price of the building, whereas the "real" value of the entity didn't drop at all -- all you did was shift the money from your cash account into a building account -- both asset accounts. The answer, of course, is for the government to let you keep your books according to "accepted accounting standards" -- but tax your property purchases on a cash basis. But, of course, that's too complicated -- but the myriad, ever-changing depreciation schedules aren't?! Anyway... One thing we've been able to count on (at least so far) is that they don't change depreciation schedules in mid-stream. Your depreciation schedule (i.e., the portion of your property purchases that you can expense each year) is established (and fixed) in the year of purchase. We know for our building, for example, that we can expense 1/30 of its purchase price each year for the next 30 years. So we set up accounts for categories of properties that will be depreciated alike (at least this year) -buildings, building equipment, machinery & equipment, furniture & fixtures, vehicles, etc. At end of year, we compute a depreciation schedule for each category and expense what we're allowed, buildingdepreciation/amt- depreciation-expense/amt+, building-equipment-depreciation/amt- depreciationexpense/amt+, etc. And we hold onto those schedules -- in a Depreciation folder -- so we know what to expense in subsequent years. A problem comes about when we sell one of those properties. Let's say 5 years downstream, we sell that building. And let's say we sold it at the price we paid for it. But we've been depreciating it for 5 years -its present value on our books is only 25/30 of its purchase price. So we have a gain-on-sale of 5/30 of it's purchase price. That's revenue, cash/amt+ building/amt- building-depreciation/amt+ otherrevenue/amt-. And we can't take any more depreciation on it so we have to back it out of our depreciation schedule. Now that's do-able if we set up our categorized depreciation schedules well. But there's still lots of room for error and confusion -- especially as you accumulate more property. Remember, "property" includes desks, chairs, benches, file cabinets, computer equipment, etc. I recommend just biting the bullet and setting up a separate depreciation schedule for each individual property. And also annotating the schedule sheet with a (sequential) property number -- and marking the

actual property with that number. Store these sheets in folders, one folder per category. Then when you dispose of a piece of property, you only have to annotate that one schedule (and move the sheet to an "inactive" section of the folder). To compute depreciation for the year, you just go through the "active" section of the folder and total up all the amounts listed for the current year. One possible format for these schedules is, <property-number> <physical-location> <purchase-date> <depreciation-method> <purchase-price> <description>, followed by the schedule, <year> <depreciation-expense>, <year> <depreciation-expense>, etc. <Depreciation-method> is just a shorthand description of the method used to compute the depreciation-expense numbers that follow, e.g., 30-year straight line (30sl), 5-year declining balance (5db), 7-year declining balance (7db), etc. When you sell or dispose of a property, annotate the depreciation-expense line in the year of sale with the selling price (zero if scrapped) and cross-out all following depreciation-expense lines. This gives you all the data you need to compile a source document for your depreciation transactions -- property schedule with prior and current year's depreciation, property added during the year, property disposed of during the year and gain-on-sale of disposed properties. If you keep these schedules in a computer file, scripts or programs can calculate the depreciationexpense numbers (filling in that portion of the file), compile and print out your depreciation source document, compile a property schedule by physical location (e.g., for personal property tax backup), etc. One final note -- do you really have to depreciate all property? Even an old desk you bought for, say $25? No. The government lets you just expense property whose cost isn't "significant" -- of course they don't define "significant" -- hey, they gotta have some things to catch on audit. I used to use $300 -property costing less than $300, I'd expense -- more than $300, I'd depreciate -- and never had IRS audit problems with it. (Of course, I may have just been lucky.) Ask your tax preparer what number they'd feel comfortable defending.

Inventory Accounting
As we said back in our Payables Accounting column -- "Inventory (products bought for resale, materials bought to manufacture products to be sold, etc., can't be expensed until sold --- and in the meantime are accounted in an inventory asset-account, e.g., payable/amt- inventory/amt+". So we got materials into the inventory account through payables. How do we get them out? That's the job of inventory accounting. If you're doing just custom jobs, where you're buying materials strictly for that job -- like a residential custom builder -- you could use a "percent completion" method. You buy the materials to a job-number and account your labor to the job-number -- accumulating them in an inventory account -- and then periodically expense them according to the percent the job is complete, inventory/amt- cost-ofsales/amt+. When the job is 100% complete, all of your costs for that job have been expensed, and no more sits in inventory. However, if you're manufacturing a product line, with subassemblies common to multiple products,

things aren't quite as simple. If you walk through the plant, you'll find stocks of purchased parts and materials, stocks of subassemblies, and batches of end products being assembled and tested for scheduled shipping. Each of these is different. Purchased materials have no labor content -- but subassemblies do have labor content. And the end products have both labor and subassembly content. How do you know what dollars you have invested in all these stocks and batches? And how do you know how many dollars to expense to cost-of-sales when you ship a product?

Inventory Processing
I'll lead you through a system I used back in the '70s. It's not the only system -- nor necessarily the best. It's just one that worked well for me. First, you'll need inventory accounts to reflect the inventories you have -- a purchased-materials account to account your purchased parts and materials... a subassembly-inventory account to account your subassemblies... and a product-inventory account to account your end products. Parts and materials get into your purchased-materials account through payables, payable/amtpurchased-materials/amt+. The purchased-materials account balance contains the cost of all those stocks of parts and materials on the plant floor. Now you purchased those materials to build things -- subassemblies and products. Let's say we want to build 50 of some subassembly. So we compose a Job Order to tell the assembly people what we want to build. And we give this Job Order a number, say S001 -- "S" for subassembly. The assembly people pull the materials, build the subassemblies and return the Job Order showing they've completed the subassemblies. We now have that many fewer parts in stock -- and that many more subassemblies. So we take the costs of those parts out of our purchased-materials account and add them into our subassembly-inventory account, purchased-materials/amt- subassembly-inventory/amt+. The subassembly-inventory account balance now shows the material cost of those 50 subassemblies. But those subassemblies should also contain the cost of the labor expended in building them. So we have the assemblers charge their time to the S-job number they're building. In our Payroll processing, we recognize that any S-job labor-expense should be accounted to our subassembly-inventory account, accrued-wages/amt- subassembly-inventory/amt+. Our subassembly-inventory account balance now includes the labor cost of those subassemblies. Now let's say we want to build 25 of a product, and that product contains 2 of the subassemblies we just built plus some purchased materials. So we compose a Job Order to tell the product assembly people what we want to build. And we give this Job Order a number, say P001 -- "P" for product. The assembly people pull the parts and subassemblies, build the products and return the Job Order showing they've completed the products.

We now have that many fewer parts and subassemblies in stock -- and that many more products. So we take the costs of those parts out of our purchased-materials account, and the costs of those subassemblies out of our subassembly-inventory account, and add them into our product-inventory account, purchased-materials/amt- subassembly-inventory/amt- product-inventory/amt+. The productinventory account balance now shows the materials cost of those 25 products. But those products should also contain the cost of the labor expended in building them. So we have the assemblers charge their time to the P-job number they're building. And in our Payroll processing, we recognize that any P-job labor-expense should be accounted to the product-inventory account, accruedwages/amt- product-inventory/amt+. Our product-inventory account balance now includes the labor cost of those products. We now know what each of those products cost us to build -- 1/25 of the product-inventory account balance. When we ship one, we can account its cost-of-sales in our Sales Journal transaction, receivable/amt+ revenue/amt- product-inventory/amt- cost-of-sales/amt+. Now let's take a look at what these Job Orders look like. They obviously have to contain a list of materials so the assemblers know what parts and materials to pull. And somewhere there have to be some instructions on what to do with those parts and materials. So why not combine them, e.g., like a recipe -- "pull these parts, do this with them, then pull these parts, do this with them, etc, etc." This "recipe", for building one (subassembly or product), can be your engineering documentation -- it carries a subassembly or product (part) number that you assign when you design it. If the assemblers need a drawing to refer to, the recipe can simply say, "refer to drawing so-and-so". (I prefer to use a model -- built by an assembler under engineering auspices.) Now the Job Order becomes simply a copy of that "recipe" with the quantity changed to the number you want to build.

Inventory Ledgers
In practice, you'll have many parts and materials flowing through this process -- into subassemblies and products into shipping -- in various stages of completion. How do you keep track of all this stuff? You'll need a subsidiary ledger for each of your inventory accounts -- a Purchased-Materials ledger (one sheet per part number), a Subassembly ledger (one sheet per subassembly part number), and a Product ledger (one sheet per product part number). When you purchase parts, you not only post the cost to the Payables ledger -- but you also post the quantity and cost to the Purchased-Materials ledger. When you get an S-job back from the floor, you post the quantity and cost of the parts used to the Purchased-Materials ledger (referencing the S-job number). The totaled cost of the parts posted is the material cost of the subassemblies -- which you then post to the Subassembly ledger. When payroll is run, you post the S-job labor not only to the Payroll ledger -- but also to the Subassembly ledger (to the sheets corresponding to the subassembly part numbers built).

When you get an P-job back from the floor, you post the quantity and cost of the parts used to the Purchased-Materials ledger (referencing the P-job number), and you post the quantity and cost of the subassemblies used to the Subassembly ledger (referencing the P-job number). The totaled cost of the parts and subassemblies posted is the cost of the products -- which you then post to the Product ledger. When payroll is run, you post the P-job labor not only to the Payroll ledger -- but also to the Product ledger (to the sheets corresponding to the product part numbers built). And when you get shipping papers back from the floor telling you products have shipped, you post the quantity and cost of the products shipped to the Product ledger (referencing the Sales (or Shipping) Order) -- which cost is the cost-of-sales amount posted to the Sales Journal when you prepare and account the Customer Invoice. As parts are purchased and used, subassemblies built and used, products built and shipped, the sheets in your ledgers tell you the current quantity and cost balance of each of your parts, subassemblies and products. The individual cost balances in your Purchased-Materials ledger should total to the balance in your purchased-materials account. Similarly, the individual cost balances in your Subassembly ledger should total to the balance in your subassembly-inventory account, and the individual cost balances in your Product ledger should total to the balance in your product-inventory account, Now this is a lot of work manually. But it's not a big deal on computer. If your "recipes" are on computer, you just print them out for a new Job Order -- and if your payables and payroll are already on computer -- all the data's there for your computer to construct and maintain these ledgers.

Standard Cost
One alternative to the above system should be mentioned -- a standard cost system. Rather than tracking "actual" costs through the manufacturing process, we track "estimated" (or standard) costs and periodically correct our inventory accounts to reality, e.g., through inventory counts. This avoids the inventory ledgers and multiple accounts. Rather we estimate the material and labor cost of each subassembly and product and assign it that (standard) cost. When we ship a product, we move its standard materials cost from our purchased-materials account -- and its standard labor cost from our manufacturing-labor-expense account -- into our cost-of-sales account, receivable/amt+ revenue/amtpurchased-materials/amt- manufacturing-labor/amt- cost-of-sales/amt+ This system buys you simplicity -- at the cost (loss) of considerable visibility and control. Of course, if you're not going to use that visibility to better control your manufacturing process anyway, then you might as well go the route of simplicity.

Retail Recordkeeping
The preceding columns have provided an overview of recordkeeping for the small manufacturer. Much applies to all businesses -- and some doesn't.

We'll wrap up this series with a look at financial recordkeeping for small retail. Our purpose is simply to illustrate how a financial recordkeeping system can be designed or adapted to fulfill the needs of your particular business situation. Remember that the purpose of financial recordkeeping is to give better visibility into where the monies in your business are going -- so that you can better control how much ends up in your pocket. Much of the recordkeeping for small retail is the same as that already described for small manufacturing. Payables and Payroll are handled the same, as are Overtime, Employee Vacations, Travel & Entertainment, Bank Loans, Petty Cash, Property Depreciation, etc. The major differences are in Receivables and Inventory processing. In manufacturing, your Receivables processing is concerned with issuing invoices to customers and tracking their payments on those invoices. In retail, you don't have "receivables" per se -- but cash receipts from your points of sale. And in manufacturing, your Inventory processing is concerned with tracking your purchased materials through increasingly higher levels of integration until they end up in the manufactured products you sell. In retail, your Inventory processing is concerned with making sure you have the correct (and sufficient) products on the display floor at the right time. I'm going to describe these systems in the context of a computer doing the processing -- primarily because I doubt they'd be practical otherwise, given normal retail profit margins.

Inventory Processing
The first difference we encounter in retail is in parts identification. In manufacturing, if an engineer designs in a 15-ohm carbon-comp resistor -- which we can and probably will buy from many sources -we need to assign it an internal part number to use in tracking it. That part number describes a "specification" -- not necessarily a specific physical part from a given source. In retail, however, we're not (generally) buying "specs" -- we're buying a physical product to resell. If we buy antiques... or one-of-a-kinds from a craftsperson... or Fall '98 womenswear..., we'll never be able to buy those products again anyway. Trying to assign them manufacturing-like "part numbers" would create unnecessary work and confusion. But we still need some way of identifying the products so that when they sell, we can figure out what we made on them. So we need a different kind of "part number" -- something related to a particular purchase, not to a particular specification. I'll call this an "item-number" to distinguish it from a manufacturing "part number". The format I chose for item-numbers was <purchase-order-number> <line-item>. And I further chose to format my purchase order numbers <week-number> <sequential-letter>. For example, PO-number 726a, identifies the first PO issued in week 726 (i.e., the 26th week of 1997 -- see earlier General Journal column). PO-number 726z identifies the last PO issued in week 726. Item-number 726aa identifies the product(s) bought on line-item "a" of PO 726a. Item-number 726az identifies the

product(s) (if any) bought on line-item "z" of PO 726a. Now this particular format limits us to 26 POs per week and 26 line-items per PO. But even with a dozen stores, that never proved a problem. If we needed to order more than 26 line items from a vendor, we'd simply continue with the next PO number. And if we needed to issue more than 26 POs in a week (e.g., Christmas buying), we'd simply continue with the next week. (Obviously, other part-number formats could be used, e.g., 726-nn-nn, allowing 100 POs a week and 100 line-items per PO if the letter usage proved restricting.) OK, so we have a shorthand way of identifying the items we're buying to resell. But we have to track them through to the sale. So when the items we order come in, we sticker them with our item-number and our retail price. (That's another reason to keep our item-numbers short -- to fit on a small sticker.) Let's assume for the moment that the sales clerk writes up sales slips manually. When a customer brings several items to the counter to purchase, the clerk pulls the stickers and writes up the sale as a list -quantity, description, price -- (where description includes the item-number), adds up the prices, calculates and adds the sales tax, and the customer pays. One copy of the sales slip goes to the customer as their receipt -- the other goes in the cash drawer as the store copy. (The stickers removed from the items are re-attached to the sales slip for error correction in case the clerk mis-writes an item-number.)

Inventory Ledger
So... now we have POs that identify items we've bought -- and sales slips that identify items we've sold. How can we organize this data into a usable ledger? One way is to put the data into a (computer) text file. Essential data for the purchase lines are <item-number> <week-received> <quantity-bought> <cost> <vendor> <retail-price> <description>. Essential data for the sales lines are <item-number> <week-sold> <quantity-sold> <price-received> <sales-slip-number>. From this data, a person looking at the file can easily determine how many of a given item remain in stock, what the cost of those items is, how much we've made (gross profit) on those we've sold, etc. More importantly, with relatively simple scripts or programs, so can the computer -- and faster and more accurately. This file needs to be purged periodically to remove the records of items we've sold out of -- otherwise it would grow without bounds. But we'd kinda like to keep this data for historical record. We'd like the computer to be able to compare, e.g., our sales this Monday with sales the equivalent Monday a year ago, with two years ago, etc. So we put the file in a directory called, say Inventory, name the file, say Open, and have the computer go through, say once a quarter, and move the data for all closed-out items into a history file named, e.g., 199713, or 199726, etc. We now have only open inventory in our Open file -- and our historical data is preserved in files related to the quarter they were closed out in. But how do we compare, e.g., this Monday's sales with other Mondays? One way is to encode day-of-

week into the sales-slip numbers. The format of my sales-slip numbers was <store-letter> <day-ofweek> <2-digits-sequential>. For example, sales-slip number A215 lists the items sold in the 15th sale of the 2nd day of the week from store "A". If we want to compare sales on week 726 day 2, with week 626 day 2, with 526 day 2, etc. --- the computer has the data needed to give it to us. Or for any periods we choose -- total sales ...or by store ...or by vendor. (We could have added time-of-day to the field to allow even time-of-day comparisons -- but that didn't appear useful at the scale I was operating.) What do such comparisons buy us? They allow us to "measure" how (and where) we're improving -- in sales and gross margin. Once again -- you can't manage what you can't measure! Since we have the open-inventory file, there's no sense typing up a PO and then entering the purchase data into the file. Rather we just enter it into the file to begin with -- and then have the computer print out the PO. The payables key (another computer file) contains the vendor name, address to order from, any special terms, etc., under the vendor-number (which is one of the fields in the purchase line). The computer just looks in the key to pull that information. (We'll show later a method for automatically generating these purchase lines for items that are repetitively ordered.) Similarly, the computer has all the data it needs (item-number and retail-price) to print out the stickers to attach to the physical items when received.

Point of Sale Processing

Now we don't really like hand-written sales slips. What we may gain in specialty retail "charm", we more than lose in inefficiency and inaccuracy. We need a better system. We could go out and buy a bunch of POS systems at several thousand dollars each... Or we could put a networked computer in each store for a couple of grand each... Instead, we picked up a bunch of old 8088 portable computers (very small and very pretty) from the used computer market for a couple of hundred dollars each, tied a receipt printer to them, loaded them with terminal emulation software, wired them back to our main computer (at that time, a 386), and that was the hardware for our point-ofsale system. Those terminals need a "home" directory for the clerks to log into -- so we create a series of directories, A, B, C, etc., one for each store. And instead of having the sales clerks hand-write the sales slips, we have them type them into the terminal (using the old vi text editor -- simple to learn yet very powerful). When they've entered the items for a sales slip -- quantity, item-number, description, unit-price -- a function key actuates a script in their directory that draws the item and receipt totals, adds sales tax, and prints the sales receipt. That's better than hand-writing -- but still too much typing. So we give them another function key that allows them to enter only the item-number and actuate a script that searches our open-inventory file and writes the rest of the data -- quantity, description, unit-price -- to their screen -- just as if they had typed

it in. If we make item-number the first field of each line in our open-inventory file -- and if the item-numbers are in order (which they are if we always enter new POs at the end of the file) -- then we can do a binary search (very fast search). But we'd like the search to be as fast as possible -- we'd like the receipt line to pop up on their screen instantly. There are a bunch of extra lines in the inventory file that aren't needed for this purpose -items that have been closed out but not yet moved to a history file, all those sales lines, etc. These slow the search a tad. So we add another script -- run before the stores open each morning -- that copies the open-inventory file to the stores' directories with all the extra lines stripped out -- and that's the file the stores search on. There's another aspect of the sales receipt we haven't touched on -- form of payment. The customer may pay in cash.. or by check.. or bankcard.. or American Express... etc. When the receipt is complete and totaled on the screen -- but before printing -- the clerk gets to indicate the form(s) of payment and that gets added to the receipt. During the day, the receipts accumulate in the file the clerk is writing into. The receipt numbers automatically increment as each receipt is entered (and date and time is automatically added to the receipt). At end of day, comes time to reconcile the cash drawer. Another function key, actuating another script, adds up all the stores' receipts and divides them by form of payment. Closing out the credit card machine returns a tape showing what credit card sales were reported to the credit card company during the day. The clerk verifies the total (i.e., all credit card sales for the day were reported -- and reported correctly). The clerk totals the checks in the cash drawer and verifies the total (i.e., the total of the physical checks matches the total check sales). And the clerk started the day with a certain amount of cash in the drawer, say $50. During the day, they've had numerous cash transactions -- accepting cash payments, giving change, etc. At end of day, the cash in the drawer should be over (or short) by the total of the day's cash sales. The clerk then takes any cash above their starting cash drawer amount, the checks and the credit machine tape, rubber-bands them to the store's copy of the day's receipts, and returns the bundle to the office for "back-office" processing. A couple of comments before we leave this subject.. The need for the clerk to enter the item-number is a potential source of error -- not great, because if they do enter it wrongly, the description coming back is unlikely to match the physical item in front of them -- but if it does, or they're busy and don't notice... It would be better if they had a barcode reader and could just scan in the item's barcode. We didn't take that step because so many of the items we carried were not barcoded -- coming from craftspeople, startup manufacturers, etc. (We could have added barcodes to our stickers -- instead of item-number, but that would have resulted in larger stickers that wouldn't have physically fit on many of

the items.) But if we had decided to, it wouldn't be particularly difficult. We would have to add barcode-numbers to the items in our open-inventory file. And when we create the store's search file each morning, our script would have to replace the item-numbers with the barcode-numbers (and sort the file into barcodenumber order). That's all. Now we'd search for scanned-in barcode-numbers instead of entered itemnumbers. Another area we could have improved was credit card processing. We had a credit card reader in each store that would dial out to the credit card company for their approval of the credit sale. It would have been better (simpler?) if the dialing-out and verification had been centralized in our main computer. That was on our "todo" list -- but we just never got around to it. One advantage of the POS system we've described above is that the clerk can service several customers simultaneously -- which many POS systems cannot. If the clerk enters a customer's sale -- and the customer remembers there are other items they wanted to get, the system isn't "hung". Since the clerk is just writing the receipts into a file -- and the receipts don't print until the clerk tells them to -- the clerk can go ahead and service other customers while the first customer is picking up the other items they want.

Back-office Processing
In the office, we now have bundles of receipts, with checks and cash, from each store -- and a computer file containing those same receipts in each store's directory. First thing we have to do is repeat (audit) the form-of-payment verifications that the clerks did at closing -- resolve or correct any discrepancies -- and bank-deposit (or accumulate for deposit) all those checks and cash. The bundled hardcopy receipts just get stuffed into a file folder, held for a few months (in case we need to refer to them), and then get pitched. All that remains is to update the open-inventory file with all the items that were sold. Another script -the computer copies the items out of the stores' receipts files, rearranges them into sales-line format, and adds them to the open-inventory file. Now we can run the script that compiles the stores' new search files -- and the stores are ready for the new day's sales. What about journals? Don't we need a Sales journal that details what we sold and segregates all the numbers into the appropriate revenue and cost-of-sale accounts for posting to the General Ledger? Yes -- and all that data is in the open-inventory file. So... another script, run at end of week, that copies all that data out of the open-inventory file and compiles and prints out a Sales journal. There are numerous nuances to the processing that we haven't discussed above -- handling of returns, consignment goods, cash control, bank and credit card statement reconciliations, etc. Our purpose was simply to illustrate how a financial recordkeeping system can be designed or adapted to new and different business situations.

Semi-Automated Buying
One subject that might be worth looking at before we leave retail recordkeeping are ways that we might simplify or improve our buying. For items we buy repetitively, e.g., we want to maintain some minimum stocking level, it's a hassle to re-enter those same old purchase lines into our open-inventory file every couple of weeks. (Even copying and editing their last purchase line is a hassle.) Plus, how do we know at what rate the items have been selling and how many we should buy based on the vendors' delivery time. All that data is in our files -- but it's spread out through the files making it difficult to use for this purpose. So let's make some vendor files containing the items we want to keep in stock -- description (including the vendor's part number), their current price and delivery, any minimum-buy quantities (or dollars) they may have, and what stocking levels we want to maintain. Another script... that looks at these files, copies the buy/sell history of these items out of our inventory files (including our history files as far back as we may wish to go), and compiles a compact buy/sell history of the items -- together with recommendations of what we should buy today. With a timeline of the items' performance in front of us (including their gross margins) -- we can decide to take the computer's recommendations or not -- or to modify them. If we decide to go ahead, the script can post the purchase lines to our open-inventory file and print out the POs. And as a result of looking at these items, we may decide to add more of a vendor's items to their repetitive-buy file -- or delete items from it. The computer can run this script, automatically, once a day -- alerting us only if there's something it thinks we ought to buy.

Computer Accounting
In the earlier Source Documents column, we said, "With the computer, it really doesn't matter whether you record your transactions in ordinary text files and use programs or "scripts" you write to use the data -- or with the spreadsheet or database tools you may already be familiar with -- or with full-fledged "accounting packages". From the preceding retail-recordkeeping discussion, it's obvious I prefer the text file and script approach. While I still have your attention, I'd like to explain why. My approach, from my first computer, has been to set up my business systems on computer exactly as I would set them up manually -- except that any records I would compile on paper in a manual system, I would compile instead in a computer file (and one looking much like the paper record). This got the "essential" data into the computer -- whereupon I could write "scripts" to use the data in the ways I wished. In the early days, when computers weren't particularly reliable and I wasn't particularly secure in my approach, this had the advantage that I could run the manual system and the computer system in parallel

while I gained confidence -- and I could always switch back to the manual system if things went badly wrong. But the approach proved versatile and powerful, so I've stayed with it -- despite the flood of software tools and packaged software that others have offered to "solve" these problems. To use this approach, I had to learn a "scripting" language. Scripting is simplified programming. (There are probably some programmers who would argue with that.) Scripts are "interpreted", i.e., run directly -- you write into a file what you want the computer to do. You run the file. It either does or doesn't do what you want. If it doesn't, you go back into the file, change something and try again. And you keep changing and trying until it does what you want. Programs, on the other hand, are "compiled" -- there's a (quite lengthy and complicated) compilation step between your changes and your trys. In addition, programs need more "details". You need to declare on the front end what variables you're going to be using, how you want each variable represented ("integer", "floating point", "double-precision floating point", "string", ...), etc. Scripting languages take care of all that mickey-mouse for you. (In fairness to programs, they're more powerful, more versatile and run faster than scripts. However, if scripts do the job you're looking to do, their simplicity and user-friendliness -- especially to a cut-and-try programmer -- make them the way to go). Note: Any good programmer would find "cut and try" programming abhorrent. But, hey, I'm not a "programmer" -- I'm just trying to get a job done. 80-90% of the time that goes into the writing of a "professional" program is in making it "robust" -- i.e., if the user mis-uses it, it will still yield sensible results. But I don't give a damn about that. I have enough redundancy built into my systems that if I screw something up, or forget something, I'll catch it -- and when I catch it, I'll fix it. Professional programming and "cut-and-try" scripting are two very different animals -- and the latter, anyone can do. There are many good freeware scripting languages available -- awk, perl, python, etc. Even the most primitive -- awk, which is what I use -- enables you to do anything with textual (i.e., alphanumeric) data. If you keep your data as readable text, awk can do anything you want with that data. And even awk is overkill for our purposes. I dare say I've never used more than 10-20% of awk's capabilities. (I sorta know those capabilities are there and every once in a while, I'll run into something that seems particularly awkward to do with what I know, so I'll play around with some of those unexplored capabilities until I find a better way of doing what I need -- and, voila, I'm using one more capability of the language.) Now, after watching the time people spend learning the popular spreadsheet or database tools -- and/or accounting packages -- I'm convinced they'd be far better off just sitting down and learning a simple scripting language. It would take a fraction of the time -- the way to learn a scripting language is to just start using it to try to do things you want to do -- and, once learned, gives you far more versatility and capability than those other tools and packages -- that take far more time to learn.

Next Previous Contents