How I Resolved a $129.64 Discrepancy
The story, How I Resolved a $129.64 Discrepancy, written around 1982, gives an insight into the mentality of an accountant working for a large bureaucracy. In this case, it was the Metropolitan Transit Commission, the public transit agency of Minneapolis-St. Paul. For sixteen years, I was the cost accountant for this agency, responsible for the monthly cost allocation. The knowledge to do this job was quite specialized as you will see. I spent years of my life thinking about such things.
In my position as cost accountant for a public transportation agency, I have frequent occasion to use the computer. Even so, I must confess some difficulty in communicating with this machine. A user’s manual is available, but its chapters are written and organized in a way which only Data Processing initiates would find meaningful. And I am an accountant.
My chief responsibility is to administer the agencys cost-allocation system. This is the method by which we assign overhead costs to the different cost centers and to projects. All expenditures must be assigned to an organizational or functional unit in these two separate systems of reporting. Allocated costs are those which are assigned by a calculated distribution instead of being specifically identified with the cost center or project. Partly that is done for the sake of administrative convenience, and partly because no other way has been found.
Cost centers represent a breakdown of the organization into smaller, specialized units. These follow the organizational chart, which reveals which persons supervise which employees. Cost centers are subdivisions of the agencys departments. For example, the Program Management and Evaluation department (PM&E) has three cost centers: administration, capital projects, and contract management. The departmental number is 2200, while the three cost centers are numbered respectively 2210, 2220, and 2230.
A project, sometimes called work project, describes the function which the agency and its various departments and cost centers are performing. For example, the purpose of Project 3761 is to install a Management Information System (MIS), which is a computer-based system to control all information-gathering and reporting operations. Another project, numbered 5451, identifies Project Mobility, which provides specialized transportation services for the handicapped. In all, the agency is conducting more than fifty separate projects during this year.
Some types of expenditures are obviously identified with particular cost centers or projects. For instance, the salary of the director of the PM&E department is assigned to Cost Center 2210, which is entitled Program Management & Evaluation - Administration. When this man works on a task related to MIS, he records on his weekly time sheet the number of hours charged to Project 3761 so that the Payroll department can code the labor expense to that project. On the other hand, certain expenditures have a more general value to the agency and cannot be readily assigned to cost centers and projects, at least not without excessive effort. For example, the agency rents space for its administrative headquarters on the eighth floor of an office building. A single dollar amount appears on the monthly billing from the landlord. The Accounts Payable clerks do not have time to determine how much of this expense belongs to one or another cost center or project. Instead, the expense is allocated to such units through the computer-based cost-allocation system which I administer.
Our particular cost-allocation system is executed in three stages.
The distinction between direct and indirect costs is basic to governmental accounting. Generally speaking, the direct costs can be associated directly with projects, while the indirect costs have a less definite relationship. Even so, their expenditure does benefit the project to a certain extent. The cost-allocation system attempts to assign fairly a portion of the indirect costs to projects.
One reason why we go through this exercise is that many of the projects were developed under contract with the federal government. Those contracts allow the agency to be reimbursed for 80% of the project expenditures up to the total number of dollars in the grant, which includes reimbursement both for direct and indirect costs. However, the indirect costs, to be reimbursable, must have been determined by a method of calculation which is provided in an approved cost-allocation plan. The calculations must be fully documented, so that federal auditors two or three years later can verify that the charges for indirect cost were properly assigned to the project. In the absence of an approved cost-allocation plan, fully documented and executed in conformance with federal guidelines, some or all of the indirect costs claimed under the project grants might be disallowed.
The actual method of allocating costs follows a standard procedure, although the particular factors or elements involved in the calculations may vary. The basic technique is to split a single dollar items of cost into several smaller amounts, each assigned to a cost center or project. The particular split depends upon the allocation base which is chosen to weight these units in an equitable manner. In the case of leased office space, for instance, a fair way to allocate the cost of the monthly rent might be on the basis of the number of square feet of floor space which each cost center occupies in the building. If the Finance department occupied 30% of the space, it should be charged 30% of the rent. In the case of allocating a departments indirect costs to projects, the dollars of labor charged to the different projects by the departments employees might be an appropriate means of assignment.
Each type of allocated expense requires its own calculation. Each month, more than one hundred separate sets of calculations must be made in a period of several days to execute the three-step allocation procedure previously described. That is my job responsibility. However, I perform mainly a supervisory function; the computer does most of the work. What I actually do each month is to submit processing requests to the computer operator, accompanied by my own green security card and, perhaps, a deck of punched cards, which specifies that a certain Job stream should be run.
A Job Stream number tells the computer what kind of processing is to be done. We use abbreviations, such as JS-03 for Job stream #3. The job streams are run in a particular sequence each month to perform the cost allocations, make entries to accounts, and print the related reports. I monitor these runs, checking for error messages and reconciling numbers which have come from different sources. In the period-end cycle of runs, I work closely with Roger Krebs, the senior accountant in charge of the general ledger, who notifies me when allocations may begin and who later closes out the period. Each of us has an idea of what the other is doing, but the entire operation is bigger than one person.
In a nutshell, my part in this process may be defined by the following series of job streams: JS-14, JS-16, JS-09F, JS-5P1, JS-09G, JS-5P1, JS-11, JS-31A, JS-09H, JS-5P1, and (after several more journal entries submitted by others), JS-10, JS-09, and JS-14. Dennis Wachholz, my predecessor, set this up, and, with minor modifications, it continues to function according to his conception. These job-stream numbers may have little significance to an outsider. To us, however, whose livelihood depends upon calling for the right run at the right time, each JS-number means running a particular report or creating particular transactions which affect the accounts. The JS-11, for instance, compiles and prints the Cost Center reports. The JS-09 calls forth the Project reports. The JS-09F, JS-09G, and JS-09H do the cost allocations.
As one final point of explanation, let me say that the heart of our computerized accounting system is the 21-digit account number used in transactions. These numbers are punched into the appropriate columns in the 80-column cards so that the computer can recognize which account goes with which cost. The 21-digit account number consists of several smaller clusters of digits, which each designate a characteristic of the account.
For instance, a typical account number might be: 01-501-03-181-2400-4-3701. The 01 in the first cluster of digits indicates that the expenditure has been made from the 01 fund, otherwise known as the general fund. The501 in the second cluster designates wages and salaries. The subsequent digits, 03, are a sub account or minor of the major category, 501. Taken together, we call these two fields, 501-03, a major/minor, which means wages and salaries - administrative. The cluster of digits numbered 181 is a functional designation which follows the federal governments standardized list of transportation functions. The 2400 in the next cluster indicates the cost center - in this case, Transit Development. The single digit, 4, is again a federal code indicating mode of transportation. Finally, the 3701 at the end of the account number represents the project. One might notice that the above account number contains only 19 digits, not 21. Two more spaces are reserved following the project cluster in case a sub-project coding is required.
The beauty of this system, at least in my eyes, is that the computer can directly identify characteristics which are relevant to a calculation or report, and can thereby combine and accumulate related types of expenditures, regardless of the characteristics in other fields. For example, it can calculate in a flash the total expenditures to date for Project 3701 by scanning all the accounts and adding up the balances of all accounts whose numbers include 3701 in the appropriate position. without that capability of focusing upon particular clusters within the account number, our cost-allocation system would not be possible.
In the process of allocation, the computer pulls together information from several sources which are needed to make the calculation. The structure of this calculation is called a cost-allocation task. The task stipulates which numbers are to be divided into other numbers during the allocations by means of numbered positions on its report. Some of the numbers are programmed into the task and remain constant. Others are pulled from the balances in particular sets of accounts in a process which we call line-genning. Here the computers ability to identify all accounts having the same digits in a relevant cluster makes it possible to code the tasks on the report specification file in a reasonable period of time.
For each allocation, we need, of course, the dollars of the expense to be allocated. we need the base factors to determine the percentages that will be used to spread this expense between the different cost centers or projects. We need to indicate the account numbers to which these allocated expenses will be charged, so that the cost will be included in the proper fund, cost center, project, etc. All these parts must be coded into the computer before the monthly allocations can be run. Most of the coding of tasks was done at the beginning of the year. The method was expected to stay the same from month to month throughout the year.
One type of expense, which is allocated in the first set of calculations, pertains to the use of the agencys staff cars. Authorized employees may use these cars from the motor pool in the course of conducting official business. When an employee receives the keys, he or she also receives a credit card for purchasing gasoline and other purposes as might be required. Such expenditures, when the agency receives the bill, are considered system-wide expenses. Otherwise, the paperwork which would be required in order to assign the cost to projects or cost centers might defeat the convenience of maintaining such a fleet. We have decided to allocate the staff-car expenses on the basis of the number of cars assigned to each cost center. The five different kinds of related expenditures - gas and oil, tires, car wash, maintenance, and towing - require five separate cost allocations to be run each month.
At the end of last year, I obtained a listing from research of the tentative assignment of cars in the coming year, and on that basis set up the cost-allocation tasks. subsequently, though, several of the cars were traded in, and new cars were added, with the result that the result that the distribution of staff cars to the cost centers was changed. Not long ago, Brian Lamb from the research department gave me a revised listing of the staff-car assignments. He reported that the Assistant General Manager had inquired whether the allocations might be changed to reflect the new assignments. (Note: Brian Lamb, then a staff person in the Research Department, is now General Manager of Metro Transit after a stint as head of the Minnesota Motor Vehicle Department and the state's Department of Administration.) Normally we try not to change cost allocations in the middle of the year; but in this case I promised to do something about it.
During a spare moment in the mid-month lull, I recoded all the lines on the five tasks which pertained to staff-car expense, and submitted these changes to the computer. that part went smoothly enough. However, when it came time to run the first allocation in the period-end cycle, I spotted five error messages at the end of the report. these messages said NA, which I think means no account on file. The messages also indicated the number of the task in which the error had occurred. After locating each of the five tasks, I recognized from the account number next to the NA on each page that the error pertained to the allocation of staff-car expenses to the Personnel department, or Human Resources department as it is now called. All five account numbers contained 5100 in the cost-center position, which is Personnels department number.
I pulled from the file my work sheet which summarized the changes in staff-car assignments. The car in question had been assigned to Training, which is part of Personnel. The problem was that in the previous assignment Personnel was not assigned any cars, but it now had one. On the other hand, the Safety department, which had one car in the old listing, now had none. Therefore, I had substituted Personnels code for safetys on one of the lines in the five tasks.
Unfortunately, while doing this, I had neglected to add the new account numbers to the General Ledger master file, which incorporated Personnels coding. Our computer system requires all new accounts to be put on file with an 01 card before expenses can be charged to their number. Otherwise, the computer will not recognize the account, and will generate the NA error message. In this instance, only the five accounts involving Personnel caused a problem. For the other cost centers, the new listing merely changed the number of cars assigned. Their accounts for receiving the allocated expense were already on file. In order to correct the errors, I needed now to create 01 cards for the five new accounts, keypunch them, and submit the cards to the computer on the JS-03.
Another thought briefly crossed my mind. Usually when we create new accounts, we must also set up for them report locations, which will accumulate their balances in the computer for the project reports. We call this line-genning an account. Line-gen is short for line-code generation. It refers to the process of assigning a code for the account number, which becomes a storage location for costs whose total appears in a particular spot on the project reports. Typically, this code would be a report-and-line number. Code 13715, for instance, would refer to line 15 on report 137. Line 15 might designate, let us say, materials and supplies - other. Report 137 might be the report number for Project 2715. Line-genning is necessary to move the dollars from the pertinent accounts into the desired positions on the reports.
In this instance, however, I reasoned that it was unnecessary to line-gen the account which accumulated Personnels staff-car expense because Personnel was an indirect department. Only the expenses from direct departments are allocated to projects, and only the project reports or project-summary reports require line-genning. With that logic, I added the five new accounts to the master file, but let the other part go.
Adding the new accounts to the file did, indeed, clear up the errors which had appeared in the first allocation run. Likewise, the second and third allocations, as well as the cost-center and project reports, were run without a hitch. Near the end of the cycle, though, I also prepare a work sheet which lists the total year-to-date balances in the accounts for expenditures from each fund. This information comes from the General Ledger trial balance and would include all accounts on file. On this worksheet, the total of the trial-balance accounts is compared with other totals which come from the JS-10 report. The JS-10 is a detailed listing of the accounts whose totaled balances appear on the project reports.
If an account is not line-genned, its dollars may appear in the trial balance, but not in the project reports. The purpose of preparing the worksheet is to spot such differences, locate the source of the error, and make timely corrections, before the project reports themselves are run. Otherwise, if the differences are not reconciled, it would be necessary to show them as reconciling items on the statements which go to the Commissioners.
In preparing the work sheet this month, I noticed a difference of $129.64 between the total expenditures included in the trial balance and the total for Matrix Report #5, which is a summary of all expenditures by fund. In previous months other differences had appeared, but never between these two totals. Also, I noticed that for the first time this year the bottom line on Report 31 showed a balance other than zero. This balance was $129, rounded to the dollar. Something had obviously been done during the past month to create the discrepancy. Where did the error lie?
One technique for locating errors or differences which have appeared for the first time is to examine the coding sheets filled out most recently to access the computer. I keep a file of these sheets in a cabinet near my desk. Most of the sheets pertained to the year-end coding of cost-allocation tasks and reports; not many entries had been made since March. Therefore, it did not take long to find the sheets which had been used to add the five new accounts to the file, representing Personnels staff-car expense. In hot pursuit, I went immediately to the General Ledger update, a run which lists all the accounts on file in account-number order, along with opening and closing balances and the current monthly change. I jotted down the total dollars in each account and took a sum of the five account balances.
Here is the result:
There is a pseudo-report number on the cost-allocation task for distributing Personnels expenses to other cost centers, which accumulates all the costs for allocation. I should have, at least, line-genned the new accounts with respect to that location. This pseudo-report number was 42005, and it was to be found on level 16. To confirm my suspicions, I checked the accounts in the JS-10 run which comprised 42005. Sure enough, none of the five accounts were there.
Ordinarily, accounts which are added to the file will automatically be line-genned when we run a JS-14 report. we do this at least twice a period. It happened, though, that we had run a JS-14 since the JS-10 listing was produced. I was curious to know whether the five new accounts had been line-genned. They had not. Two possible explanations came to mind. On one hand, the accounts might not have been line-genned if the JS-14 was run in a period after the accounts had been entered. I checked with Roger to see if we had closed the period yet. No, the period was still open. Therefore, the JS-10 and JS-14 had both been run in the same period; so that could not have been the reason. The other possibility was that the computer card used to line-gen accounts to 42005 had been punched in such a way as to prevent these particular accounts from being included. I pulled this card out of the file cabinet. Yes, the problem was here.
A diagram of the card which I pulled out of the file cabinet is shown above. What this does is to associate a particular storage location with particular accounts whose features are specified by the digits punched in pertinent columns.
The IL16 in columns 1 to 4 show that pseudo-report number 42005, punched in columns 60 to 64, appears on level 16, which is merely a subdivision of the computers memory. The 5 in column 7 specifies that only accounts whose major begins with 5 will be selected. the 9 in column 20 similarly determines that only the accounts whose project field begins with 9 will be selected. finally, the 5110 in columns 15 to 18 requires that the cost-center field contain those particular digits. Columns which are left blank in a particular field may be filled by any digit; but, if a digit appears in a column, that position in the account number must be filled by that digit. The card, read as a whole, says that all account numbers on file whose major begins with 5, whose project begins with 9, and whose cost center is 5110 will accumulate balances in storage location 42005 on level 16.
The reason that the five new account numbers were not line-genned is that 5110 had to fill the cost-center position. Instead, these accounts had 5100 in that position. It was the 1 in column 17 which did the mischief. I had put the departmental number for Personnel in the accounts for its staff-car expense rather than the cost-center number. It was an understandable, but nonetheless harmful, mistake. In some cases, where a department has only one cost center, the same number is used to designate both the department and the cost center; but not here, unfortunately.
In order to pick up accounts with either 5100 or 5110 in the cost-center position, I could create a new line-gen card, which would have 51 punched into columns 15 and 16 but which would leave columns 17 and 18 blank. Alternatively, I could punch a new card with 5100 in the cost-center field and input this to the computer while leaving the line-genning from the present card also intact. The new card with blanks in columns 17 and 18 seemed a neater solution, so that is what I did. I coded and keypunched a new line-gen card for pseudo-report number 42005 and fed it into the computer on a JS-14C.
Then I started to wonder: If the costs which had been distributed to the five accounts containing 5100 in the cost-center position had been included in the trial balance but had not been allocated to the direct departments, then those dollars should still be sitting in the Personnel departments accounts. More money had gone into those accounts during the month than had come out. The ending balance should reflect the increase. I knew exactly where to check that theory: the cost-center report for Personnel. If the allocations had been handled properly, the total expenditures for this department should have been transferred out to other departments, leaving a zero on the bottom line. But, as they were not handled properly, I confidently expected that the ending balance would be at least $129.
However, that was not the case. The balance which remained in Personnels cost center after allocations was only 41. It took me a minute or two to figure out what had happened. During the year-end coding, I had specified which accounts should be included in Personnels cost-center report by means of control cards. These cards associated particular report numbers with cost-center numbers. I checked my coding sheets in the drawer and discovered that 5110 had been specified as the cost-center digits for accounts included in this report; but my five account number had 5100.
The conclusion was inescapable: Either I had to change the control card for the JS-11 report to include only accounts with 5100 in the cost-center position - which would probably be only those five accounts - or else I had to change the account numbers, substituting 5110 for 5100 in that position, if indeed I wanted to include those staff-car expenses in Personnels cost-center report. I did want to include them, not only for the sake of completeness, but also because to do otherwise would consistently leave a credit balance on the bottom line. That was because I had already changed the line-gen card for 42005 so that the expense in accounts containing 5100 would be allocated out to the other departments; however, the previous changes to those accounts would not be admitted to the cost-center report.
Bowing to that fate, I redid the coding for the five cost-allocation tasks and also created five new account numbers on the 01 cards. I brought job-stream requests to Jan in the computer room for the JS-08 and the JS-03 respectively.
Something troubled me still. I did not know what the problem was, now that everything seemed resolved, and that uncertainty compounded my worries. finally I decided it would be wise to try to retrieve my two job-stream requests before Jan fed them into the computer. I raced to the window of the computer room and saw my request forms on the counter. It was too late. The forms had already been stamped by the time clock, indicating that job cards had already gone through the reader.
Suddenly I realized the problem. It was all right to submit the JS-08 but not the JS-03 which added new accounts. I did not want to add new accounts at this time because Roger had not yet closed the period. The significance of this was that the new accounts would not be line-genned unless I submitted another JS-14 between now and closing. For, the JS-14 is flagged to process only new accounts - i.e., those which h have been added during the current period and require line-genning. When the closing entries are run, all unprocessed accounts are changed from new to old, which makes them ineligible to be line-genned by the JS-14 in periods after that. It did not seem practical to run a JS-14 now. Roger was ready to close the period at any moment, and the JS-14 is an 800-page report, taking half an hour to run and costing at least $50.00. It was just too expensive for what I had in mind.
The new accounts had already been added. The alternatives at this point were to wait until after closing and then either to line-gen these five account by hand or else to delete them and then re-add them so that they would become new accounts, eligible for line-genning by the JS-14 when we ran it again in several weeks. I felt uncomfortable with the first alternative: Each new account line-genned manually would require me to determine five or six different line codes. Although there was a logic to each number, I did not understand it completely and had made mistakes in the past. The JS-14 would do the line-genning automatically and without mistakes.
Therefore, I opted for Alternative B. What was required here, so I supposed, was to create five new cards. On each card, one column character would be changed from an A (for add) to a D (for delete). I would save both sets of cards. Then I would run the deletion cards through first on a JS-03, and then the addition cards on another JS-03, so that the same accounts which had been deleted would be immediately put back on file. The only difference would be that these accounts would now be new.
I thought that I should touch base with Roger regarding my plans. He informed me that the computer would not accept successive deletion and addition of account numbers. Although the accounts might be changed to delete status, they would nevertheless remain on file. And, so long as the accounts were on file, the computer would not allow the same accounts to be added. To get around this problem, I would h have to run a JS-17 between the two JS-03 runs. The JS-17 would pull the accounts marked delete off the file. The second JS-03 would add them to the file again.
I followed Rogers suggestion. The print-out from the first JS-03 confirmed that the accounts had been changed to delete status. the JS-17 did not generate any report, but I assumed it had run successfully. Finally, I ran the second JS-03 with the add cards. When the print-out came back, I read, to my surprise, INV ADD, which meant that the attempted additions were invalid.
Roger did not know what to make of this, and neither did I. Our only recourse was to call Ray Deeb, the senior programmer-analyst. Ray spends a considerable amount of time putting out fires in our department. when ray arrived, I explained to him how I had tried to delete and add accounts by running the JS-17 in between. Yes, but you should have run a JS-16 before you ran the 17, Ray responded. He said he was irritated that the computer room had put the JS-17 through. there was a note from him with the control cards asking to be notified whenever the JS-17 was requested.
Ray explained that the JS-17 caused the General Ledger master file to go back to the point when the last JS-16 (which creates a back-up take for safety purposes) was run. Its possible you did some damage, Ray commented. I remembered last having run a JS-16 three or four days earlier, at the beginning of the period-end closing procedure. If that was the last JS-16 run, it would be necessary for me to repeat all of the cost-allocation runs, updates, and reports. Ray suggested that I request a current trial balance on the JS-07 to compare with our earlier period-end trial balance. Hopefully, the two would be the same.
Ten minutes later Ray returned, all smiles. Youre in the clear. As part of Rogers closing procedure, a JS-13B had been run, which has a JS-16 tacked on front. Rogers JS-16 had thus been run before I added the five accounts, but before I had begun the series of JS-03 deletions, JS-17, and JS-03 additions. The JS-17 brought things back to the point where the five new accounts were on file. This explained the error message: Invalid Addition.
The period was now closed, and I was back to the stage of having five unwanted accounts on the master file. As matters stood, these accounts would not be line-genned by the next JS-14 because they were old - due to Rogers closing. Again, I weighed the alternatives: either allowing the accounts to remain on file and line-genning them by hand, or else making them eligible to be line-genned automatically later in the period by deleting the accounts with a JS-03, running a JS-16 and JS-17, and then adding them back on another JS-03.
I thought that I might try manual line-genning this time, but then another, unrelated problem arose which required my immediate attention. I scribbled a note to myself about the five unreconstructed accounts. A day later, this project was almost forgotten. But then my note reminded me that there remained a loose end to tie before the weekend. Taking a deep breath, I submitted the JS-03, and then the JS-16, JS-17, and second JS-03. When the last run was ready, I peered anxiously at an inside page of the print-out and, to my immense relief, read beneath each of the five account numbers, RECORD ADDED.
I must admit that the $129.64 discrepancy was never corrected in that periods report. But at least its cause has been treated. In future periods, I feel quite confident that the Personnel department will be charged its full share of the staff-car expenses, and that this cost will appear on both the cost-center and project reports. Meanwhile, I have gained another learning experience. while the computer may be a nitpicker, it is not vindictive or unreasonable. Eventually, misunderstandings can be resolved.