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 agency’s 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 agency’s 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.

In the first set of calculations, the system-wide expenses are allocated to each of the agency’s cost centers. Such expenses include all fringe benefits, most utilities, office supplies, leased office space, etc. they are initially coded to a pseudo department, numbered 9999.

In the second set of calculations, expenses of the indirect departments are reassigned to each of the other cost centers, and ultimately wind up in the direct cost centers and departments. An indirect department is one such as Clerical Services, Personnel, or Finance, which provides support services to the rest of the agency. A direct department, by contrast, carries out a particular basic function of the agency, such as administering federal contracts.

In the third set of calculations, the indirect costs which have accumulated in the direct departments as a result of the first two allocations are assigned to the various projects upon which their people have spent time during the month. At the end of the allocation process, all expenditures should have been assigned to a particular cost center within a direct department and to a particular project.

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 department’s indirect costs to projects, the dollars of labor charged to the different projects by the department’s 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”. The”501” 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 government’s 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 computer’s 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 agency’s 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 Personnel’s 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 Personnel’s code for safety’s 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 Personnel’s 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 Personnel’s 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 Personnel’s 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:

I was lucky to have found this so quickly. What had happened? I recalled that I had decided not to line-gen these particular accounts because Department 5100, Personnel, was an indirect department. Its costs would not be allocated to the projects. True enough. However, in a roundabout way Personnel’s expenses do go to the projects because, in the second round of allocations, the indirect departments allocate costs to the direct departments. The $129.64 was not passed through to them from Personnel so that the direct departments, in turn, did not distribute these dollars to the projects.

There is a pseudo-report number on the cost-allocation task for distributing Personnel’s 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 computer’s 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 department’s 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 Personnel’s 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 Personnel’s 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 Personnel’s 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 Roger’s 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. “It’s 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. “You’re in the clear.” As part of Roger’s closing procedure, a JS-13B had been run, which has a JS-16 tacked on front. Roger’s 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 Roger’s 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 period’s 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.

    to: main page             to: personal storyteller

Click for a translation into:

French - Spanish - German - Portuguese - Italian