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-of-week> <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-of-sale 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 barcode-number order). That's all. Now we'd search for scanned-in barcode-numbers instead of entered item-numbers.

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.