Sonata Stores of Breton, Inc. (SSB) is a small chain of retail department stores headquartered in Grand Rapids, Michigan, with stores in Grand Rapids and seven additional medium-sized cities in Michigan, Illinois, Indiana, and Wisconsin. SSB is privately held and earned approximately 140 million in revenues. The company is highly leveraged and its major loans are subject to covenants that require SSB to achieve certain financial performance parameters.

SSB utilizes a highly integrated accounting information system (AIS). Point-of-sale terminals (cash registers) are directly interfaced to the system. Inventory management, merchandising, human resources and all accounting functionality including general ledger, reside within the system.

Like most retailers, SSB performs a physical inventory once a year that is observed by the companys auditors. This has always been done at year end, in order to obtain inventory counts to use in the calculation of the book value of inventory that will be reported in SSBs audited annual financial statements. SSB also prepares quarterly financial statements that are provided to its lenders. Unlike the value reported on the annual financial statements, the book value of inventory at the end of the first three quarters is not based on a physical inventory count.

The company uses a perpetual inventory system. All receipts of inventory, vendor returns, and movements of inventory between stores and cost centers are recorded in real-time using hand-held RF terminals that communicate directly with SSBs AIS. These terminals have bar code readers and a keypad with which workers can scan merchandise and key in the inventory transfer location. Real-time data collected from point-of-sale terminals are likewise used to update inventory for all items sold.

However, the perpetual inventory is not assumed to be accurate. Theft, breakage and errors such as the over-or-short recording of sales or receipts eventually result in less inventory on hand than what is recorded in the companys books. This difference is commonly referred to as shrinkage or more typically, shrink, in the retailing industry.

A parameter representing the rate of shrink is estimated for each merchandise class, inventory location and season. The system automatically updates these shrink parameters (parm) using a time-series statistical methodology that estimates the parameters based on historical deviations between actual and book inventory.

At the middle of the second quarter, the controller requested a meeting with a representative of its outsourced information systems function to answer some questions about the shrink estimation within the system. Can the shrink parameters be changed? he asks. Yes, answered the representative. But as designed, no application exists within the system that can modify the parameters directly from manual input. The only existing application that can modify the parameters is the statistical estimation process. However, one of our technical guys could modify them using a software utility. The controller pondered what he was told for a few seconds and then asked Is there an audit trail when the shrink parameters are changed in this manner? No, said the representative. The estimated parameters are input once when the system is first installed. We let the statistical process use recent data and historical shrinkage experience to converge to the best estimate of the values of these parameters. It was never anticipated that we would change these values after system start-up except through the statistical process. The controller then asked Is it possible to change the parameters a month before the end-of quarter, and to change them back after the quarter? The representative, who was knowledgeable in accounting answered We can, but are you SURE you want to do that?

Required:

1. What action might the controller be considering?

2. Comment on any internal control weaknesses.

3. What audit procedure would detect what the controller is considering?

4. Could the risks within this scenario be readily anticipated?

5. What should the software firm do?

6. Thoughts, suggestions, any alternatives?