The Mystery of Work-In-Process

Accounting never matches the service department’s WIP report. As a result, many of us were taught to make an entry to make them match. Just debit or credit the WIP inventory and offset the difference against cost-of-sales, other service payroll expense, or accrued payroll and then reverse that entry next month and repeat. This is important for month-end because the general ledger balance will often be a credit due to unposted payroll. Most manufacturers will not accept a financial statement with a credit in an asset account. What if there is a deeper issue driving the two balances further apart? This is often the case over years, and this difference can snowball into a five or six-figure write-off.

Technician time is a saleable inventory item, just like a part on the shelf. We purchase an hour through payroll and then sell that hour on a repair order. If one single RO has been closed on the 31st but that day’s payroll won’t be posted to accounting until the following week, at month-end, we would have a credit balance on the general ledger for the labor cost of that RO.

Step one is to run the flag sheets for all technicians for the last days of the month that won’t be paid and posted until the following month. This entry will debit Work-in-Process and credit Accrued Payroll. Giving this a control like “TECHPAY” or something similar is a good option. Then, we’ll reverse that journal entry on the 1st of the new month so we don’t double up on the WIP inventory when that payroll is processed.

The second step is that once the payroll accrual is posted, we want to compare the GL balance with the service department’s Work-in-Process report and run it at the end of the day on the last day of the month. Be sure to run it once they’re done for the day, so that anything service is working on late to get into the month will be closed and left off the report. You should be able to set this report to run overnight. It’s critical that the service cutoff is the same as accounting’s cutoff. The total labor cost on the report represents purchased time that hasn’t yet been sold. This amount should be the debit balance in your general ledger.

In a perfect world, your GL balance will tie precisely to the WIP report. It is okay to allow a small variance of a couple hundred dollars, as it is probably not worth your time to chase down the difference. But often, this variance can be closer to a thousand dollars or even higher if this process hasn’t been followed. Finding that difference is step three.

If you see handwritten notes on the weekly tech time report turned in for payroll, adding hours to one technician and deducting from another, that’s the likely reason. If we’ve costed out a repair with a C tech making $18 per hour for a six-hour repair, the RO will reduce your WIP GL balance by $108. If the service manager made a note on payroll to deduct six hours from the C tech and pay the A tech instead (who is paid $36 per hour), your purchased payroll for that job would be $216 – twice what was sold. If this happens on a weekly basis, that will grow to over $5,000 in one year. This is a common issue, and the best way to correct it in accounting would be to adjust the repair order to match the correct cost of sale. This can be time-consuming, and a lump sum adjustment at the end of the month may be more efficient.

A technician performs a repair, and for some reason, that job, or maybe even the entire repair order, is voided. If the service department doesn’t make these adjustments before payroll, the tech will be paid, but the time will never be sold. Look at your voided documents or exception report and compare the time paid to technicians for that repair order. This may happen occasionally, but usually, a voided RO occurs for ‘no show’ appointments, and no time was flagged. This is a worthwhile exercise since these voided transactions could be fraudulent. If a repair is completed and then voided, what happened to the parts and the tech time? Is it possible the customer paid cash, and the advisor removed some work after collecting payment? Is the technician being paid intentionally for ‘phantom’ work, and is some of the pay being kicked back to the advisor? Completed work that isn’t covered under warranty and won’t be paid by the customer should be changed to an internal repair, not simply voided as if it didn’t happen. This may not be theft of cash; an advisor may be hiding a mistake.

I once worked with a dealership that had never reconciled their work-in-process in over twenty years. For that same length of time, pay rate increases were never entered into the service side of the DMS. The service manager assumed that was a function of the accounting department, and accounting thought service would adjust technician rates on their own side. Needless to say, this is my example with the six-figure write-off. We found technicians who were paid over $40 per hour but were still costed out on repairs at their entry-level rate back in 2002 of $9.00! While this is an extreme situation, there could be timing differences between service and payroll’s adjustment reflecting rate increases that would affect your work-in-process reconciliation. Service changes won’t be retroactive, so significant differences will build up if the manager forgets about an increase and doesn’t correct it for a few days (or weeks!). Service must enter the increase on the morning of its effective date. Likewise, setting it up too soon will cause an imbalance as work is costed out at a higher rate than purchased.

Service managers usually incorporate some sort of spiff or bonus into the technicians’ weekly payroll. The most common is the ‘bump’ for flagging over 45 hours where a tech may be paid an additional dollar per hour for the week; higher tiers of time earn higher bumps. Some have games with payout bonuses – technicians earn a ‘pull’ for flagging so many hours, picking a card, and getting a bonus based on whatever random card value they select. No matter the criteria, any additional pay above the standard pay rate should not be posted to the WIP account. If you are posting all tech pay to the asset account, the general ledger balance will grow much higher than the true work-in-process, as these bonus pays are never ‘sold’ on a repair order. Bonuses should go to cost-of-sale, split between customer pay, warranty, and internal accounts based on the percentage each contributes to overall department sales. Use the statistics on the financial statement to determine how to split that.

Lower-skill level techs usually don’t flag as many hours as they spend at work, and it’s often a debate about how their pay should be applied. The correct application would be to post pay for flagged hours to work-in-process and unproductive time to your ‘service other’ payroll expense account. Some service departments will argue that these employees shouldn’t go to work-in-process at all, but that isn’t accurate. For example, the oil doesn’t change itself! If there is a labor sale, there more than likely is a cost associated with that work. In the unusual situation where an hourly tech earns overtime and does flag all of those hours, only straight time pay should be posted to the WIP account. For example, a tech earning $15 per hour worked and flagged 42 hours. Gross pay will be $645 ((40 * 15) + (2*22.50)). Post $630 (42 * 15) to the work-in-process account, and $15 to labor cost of sale since the repair orders don’t include overtime in the cost.

If you have technicians on a guarantee, their unproductive hours should not be posted to the work-in-process account. Just as in the above two scenarios, if it’s not being sold on an RO, it shouldn’t be purchased as WIP. Of course, training and paid time off should be expensed accordingly as well. Bonuses should go to cost-of-sale, split between customer pay, warranty, and internal accounts based on the percentage each contributes to overall department sales. Use the statistics on the financial statement to determine how to split that.

Here’s another unusual situation that I’ve encountered. Service reports for time flags were incorrectly set in the DMS to not only display the current pay cycle flag time; this report was giving the sum total of all flag time for any repair order that had new flags added in the cycle. A job that a technician flags one hour this week should only show one hour on the weekly payroll report. The parameters for this incorrect report gave the total accumulated time for any repair order worked on in the pay cycle; all technicians were being significantly overpaid. While this is not a common occurrence, it is possible for weekly flag reports to have incorrect dates, and it’s easy to make a typographical error that leads to extra time being paid and posted to the general ledger. In most DMS flag reports, the start and end dates are entered each time the report is generated. Always look at the time period at the top of the report to ensure the hours reported fall within your current pay cycle. Do service managers see what the technicians are paid on each check? Your payroll person may not question big hours being earned, but the service manager should know what looks ‘off.’

I’m calling this a reconciliation, but it’s not a formal spreadsheet like your bank or floorplan rec. It is more of a check and balance to ensure the general ledger ties in with the true work-in-process. If you notice a difference between the two, run through these suggestions and make sure you aren’t experiencing any of the problems I’ve described. If you still can’t find the reason for your discrepancy, scheduling work-in-process will provide the answer.

Few dealerships schedule work-in-process. It requires much more work in accounting, as the time flags now have to be posted individually so they will be paired directly with the RO. Accomplish this by posting each tech’s weekly flags as a journal entry, debiting your work-in-process account, and using the repair order number as the control. Each line on the report will be its own line on the journal entry; then the lump sum total will be posted as a credit, again to the work-in-process account, but now use the technician’s employee number as the control. These can be posted daily, weekly, or even monthly if that’s what works best for your team. Just make sure you are posting activity in the month it was performed. Be sure to set the control as the RO number but allow overrides to ensure that the credits on repair orders will pull for you. When payroll is processed, you’ll post the technician’s pay for total flagged labor hours as a debit to the work-in-process, using their employee number. The posting of the flag sheets will ‘wash out’ since you’re debiting and crediting the same account, and your general ledger balance will remain unaffected until payroll is posted – so you will still need to post the accrual at month end, even if the flags have been posted. Some DMS’s will allow the flag reports to be printed to excel worksheets, making it simple to then drop into a power posting template. However, you may need someone to key them in manually. Depending on the size of your shop and volume of business, this may be too big of a task to undertake. If you have a significant problem that you can’t find the solution for, remember you may only need to schedule the account for a couple of months to find the problem – you can return the account to be unscheduled once you’ve solved the mystery.

When you have that schedule, the differences will be obvious. We can now clearly see when we’ve paid $100 in labor on a particular RO, and it was costed out at only $60. There should be no debit balance on the schedule once the repair order is closed, and credits should clear one pay cycle after the RO is posted – no one is working on the car once it’s left the dealership, right? Look for patterns that lead to the problem – is it always the same technician or advisor on the repair? Are there duplicate entries of time being posted? How much per hour is coming from the time flags as opposed to the per hour sold on the RO? When you find a common difference, you’ll know how to correct it.

I’m sure there are plenty of other situations besides what I’ve shared here – your investigation might find something else causing the difference. Do you have a work-in-process story? I’d love to hear it!

Author: Jen Moylan | [email protected]