Using Labor Rates with a non integrated Payroll System

[mhaugen (Michaela Haugen)]

We do not use Epicor’s payroll module or have it integrated with the one we use. I’ve been told by finance that because of that we cannot put any value into production labor or burden rates. This is causing issues with costing as you can imagine since the only cost we capture is material. I am having trouble believing this is true.

Are there any other customers out there that use labor rates in Epicor without it interfering with their payroll system? Can you give me a rundown of how that works or reach out to me directly and we can talk it through. I want to present our options to our financial team so they can see there is a way to do it.

[aball]

We don’t have any payroll integration with Epicor.

We use the same labour rate for all employees (Employee → Production Info → Labor Rate). Our finance department determined the rate to use, based on a fully-loaded employee cost (wages, benefits, etc). I don’t know how costs could be tracked otherwise. The payroll system is completely separate, so there’s no issue doing this AFAIK.

If the finance team compares payroll to the labour costs in the COGS that Epicor reports, there will be a variance. We’re okay with that.

[mufaddal]

Labor Rates and Burden rates are independent of payroll module, even if you don’t have payroll module you can still define labor rates in employee and burden rates on Resource group.

[mhaugen (Michaela Haugen)]

I believe they issue they are saying is that is captures the labor cost twice. Once in the payroll system and then once in the Epicor books for labor cost.

[Nancy_Hoyt]

Hi Michaela,

Just a little beware - Job tracker and production detail reports can be used by employees with access to these to backtrack another employee’s pay rate if you use actual labor rates. There are ways to hide it, just want to ensure your awareness.

Nancy

[mufaddal]

It all depends on how you allocate the payroll cost in Epicor. Generally if Payroll is not integrated in Epicor then the Labor cost generated by Job is booked under applied labor and your payroll is adjusted through that account and system will calculate COS only though job and not though payroll.

[tsmith (Tyler Smith)]

When employees clock time against jobs or indirect activity in Epicor, the system will generate a debit (increase) against WIP to put that employee’s labor cost onto the job they worked on. There will be an offsetting credit (decrease) to an applied labor account which is how the system stops from double dipping on labor cost with payroll. Later, when you ship the parts that were made on that job, you will capture COGS for the parts.

Typically that offset is not 100% since your employees will have breaks, downtime to get to/from their station, etc.

Our company has this applied labor account and the payroll expense account in the same category/grouping on the P&L so that they will (partially) offset each other. That allows us to capture payroll expense during payroll cycles while still properly adding labor cost to WIP and eventually COGS when parts are shipped. We’re also able to use this ratio between payroll expense and applied labor to see how much “idle time” we have - aka how much time people are spending not on a job.

[jgiese.wci (Joshua Giese)]

@aball

We use the same labour rate for all employees (Employee → Production Info → Labor Rate). Our finance department determined the rate to use, based on a fully-loaded employee cost (wages, benefits, etc). I don’t know how costs could be tracked otherwise.

We do the same thing same way.

[Doug.C (Doug Crabtree)]

We do the same by department. That way individual rates cannot be calculated, and since we cost by department it’s more accurate than doing an across the board approach. Of course, it’s more work on Finance, but I’m ok with that

[MikeGross]

@aball

We don’t have any payroll integration with Epicor.

We use the same labour rate for all employees (Employee → Production Info → Labor Rate). Our finance department determined the rate to use, based on a fully-loaded employee cost (wages, benefits, etc). I don’t know how costs could be tracked otherwise. The payroll system is completely separate, so there’s no issue doing this AFAIK.

If the finance team compares payroll to the labour costs in the COGS that Epicor reports, there will be a variance. We’re okay with that.

We do this also - same way. We built a script to push labor data OUT to UKG Payroll, and a GL entry FROM UKG to go into the GL Labor accounts. Works flawlessly. Point of note - we do NOT use employee calendars/exceptions inside Epicor. ONLY Production related labor activities are clocked via MES. All absence/PTO payroll activities are in UKG. This is also another reason for a huge variance in comparing labor to payroll as @aball alluded to.

[mhaugen (Michaela Haugen)]

Thank you. That helps. I have a limited background in finance so I was struggling to understand where the issue was coming from so that I could then work on a solution. It sounds like this is solid information I can work with. Thanks!

[mhaugen (Michaela Haugen)]

That is a good note. Thank you. We would be doing the same with only logging production activities in Epicor and all other payroll activities in our payroll software.

[Randy (Randy Stulce)]

@aball

We use the same labour rate for all employees (Employee → Production Info → Labor Rate). Our finance department determined the rate to use, based on a fully-loaded employee cost (wages, benefits, etc). I don’t know how costs could be tracked otherwise. The payroll system is completely separate, so there’s no issue doing this AFAIK.

This is also what we do and we DMT a new cost yearly when the new rate is calculated by finance.

[hkeric.wci (Haso Keric)]

It depends how you export the data. When I did Dayforce / Kronos we exported LaborHed for Hourly employees.

SELECT
    Erp.LaborHed.LaborHedSeq,
    Erp.LaborHed.EmployeeNum,
    Erp.EmpBasic.Name,
    Erp.LaborHed.ClockInDate, 
    Erp.LaborHed.ClockInTime,
    DATEADD(second, Erp.LaborHed.ClockInTime * 3600, CAST(Erp.LaborHed.ClockInDate as DateTime)) AS ClockInDateTime,
    Erp.LaborHed.LunchOutTime,
                            
	DATEADD(SECOND, 
		1, -- Add 1 second to avoid ClockOut and Lunch Collisions
		DATEADD(second, Erp.LaborHed.LunchOutTime * 3600, CAST(Erp.LaborHed.ClockInDate as DateTime)) 
		) AS LunchOutDateTime,

    IIF(Erp.LaborHed.LunchOutTime > Erp.LaborHed.LunchInTime, Erp.LaborHed.LunchInTime + 24, Erp.LaborHed.LunchInTime) AS LunchInTime,

	DATEADD(SECOND,
		2, -- Add 2 seconds to avoid ClockOut and Lunch Collisions
		DATEADD(second, IIF(Erp.LaborHed.LunchOutTime > Erp.LaborHed.LunchInTime, Erp.LaborHed.LunchInTime + 24, Erp.LaborHed.LunchInTime) * 3600, CAST(Erp.LaborHed.ClockInDate as DateTime))
	) AS LunchInDateTime,

    IIF(Erp.LaborHed.ClockInTime > Erp.LaborHed.ClockOutTime, Erp.LaborHed.ClockOutTime + 24, Erp.LaborHed.ClockOutTime) AS ClockOutTime,
                            
	DATEADD(SECOND, 
		IIF((Erp.LaborHed.LunchInTime <> 0 and Erp.LaborHed.LunchOutTime <> 0) AND (Erp.LaborHed.LunchInTime <> Erp.LaborHed.LunchOutTime), 3, 1), -- Add 3 or 1 seconds to avoid ClockIn and Lunch Collisions
		DATEADD(second, IIF(Erp.LaborHed.ClockInTime > Erp.LaborHed.ClockOutTime, Erp.LaborHed.ClockOutTime + 24, Erp.LaborHed.ClockOutTime) * 3600, CAST(Erp.LaborHed.ClockInDate as DateTime))
	) AS ClockOutDateTime,

    CASE WHEN (Erp.LaborHed.LunchInTime <> 0 and Erp.LaborHed.LunchOutTime <> 0) AND (Erp.LaborHed.LunchInTime <> Erp.LaborHed.LunchOutTime) THEN 1 ELSE 0 END AS Lunch,
    Erp.LaborHed.PayHours,
    Erp.LaborHed_UD.ForeignSysRowID

    FROM Erp.LaborHed
        INNER JOIN Erp.LaborHed_UD ON Erp.LaborHed_UD.ForeignSysRowID = Erp.LaborHed.SysRowID AND Erp.LaborHed_UD.smExportDTM_c IS NOT NULL
        INNER JOIN Erp.EmpBasic ON Erp.EmpBasic.EmpID = Erp.LaborHed.EmployeeNum AND Erp.EmpBasic.Payroll = 1 AND Erp.EmpBasic.Company = Erp.LaborHed.Company

    WHERE
        Erp.LaborHed.ClockInDate < GETDATE()
        AND Erp.LaborHed.ClockInTime <> 0.00
        AND Erp.LaborHed.ClockOutTime <> 0.00
		AND Erp.LaborHed.ClockInTime <> Erp.LaborHed.ClockOutTime

    ORDER BY
	    ClockInDateTime, Erp.LaborHed.EmployeeNum

[kve (Kevin Veldman)]

I set up a system previously using Labor Rates on resource groups and and ProdStandards on operations. It worked like this:

Employees were paid their hourly rate for hours clocked in ADP at minimum.

Employees would use Report Quantity on Job Operations (Quantity Only).

If an employee’s earned hours in Epicor exceeded their hourly wage, they would be paid that amount.

Example 1: An employee clocks exactly 40 hours at $15 per hour in ADP in a week. In that week, they completed 90 job operations with ProdStandard 30 minutes / piece (Resource Group Labor Rate $15), for a total of 45 earned hours. The employee would be paid $675 (45 hrs * $15 Labor Rate) for that week.

Example 2: A different employee clocks the same 40 hours, but at $17 per hour in ADP. The employee completes the same 90 job operations w/ ProdStandard 30 minutes / piece, Resource Group Rate $15 / hour. Employee is paid $680 (40 hrs * $17 per hour) as that exceeds the “Piece Rate” in earned hours.

This worked well, as some employees were able to absolutely kill it at the piece rate. There were a couple of difficulties.

First, Overtime made the calculations difficult. If the employee works 45 hours (5 hours at time-and-a-half), we had to find the percentage of hours overtime and multiply their piece rate by the same amount to be compliant with Overtime laws.

Second, since the Resource Group labor rates were constant, giving a raise to someone who consistently earned Piece Rate became difficult, as that didn’t really increase their income. Management found a few ways around that, via bonuses, increased PTO. I think there was another way but I need to ask someone bc I don’t remember.

EDIT: Forgot to add - We had spreadsheet from ADP upload to an Epicor Function that would compare the clocked hours, make the overtime calculations, then push all the data to grid. HR could review in the grid, export, and upload to ADP for final payroll.

[Doug.C (Doug Crabtree)]

Sounds familiar….

[kananga (John K)]

@tsmith

the system will generate a debit (increase) against WIP to put that employee’s labor cost onto the job they worked on. There will be an offsetting credit (decrease) to an applied labor account…

Another way of phrasing it, if this is a case of finance and accounting being separate disciplines… Payroll is an expense. Applied production labor and burden is an asset. It’s posted twice, because labor expense was converted to inventory value.

@tsmith

Typically that offset is not 100% since your employees will have breaks, downtime to get to/from their station, etc.

The variance becomes an indirect expense. Which means if labor and burden are zero, the entirety of production payroll expense will be indirect and not reflected in the asset value of inventory or COGS. Maybe that’s intended; unexpected, but not impossible.

Both points are also relevant when arriving at what those rates should be. For labor, some shops simply apply a pay rate, some include expenses which scale directly with hourly labor. Burden rates may be estimated based on expected production payroll hours, or adjusted to fit applied production hours minus the untracked indirect variances.

[spulsifer (Sharon Pulsifer)]

We also don’t use Epicor payroll. We also clock labor to jobs in another system. We use the job adjustment to get cost to the job. To do this we extract data aggregated by Job, Operation, Sum of hours and Sum of Cost (Hours * Actual Rates). Then we manipulate the data to calculate the burden factor from the Epicor operation.

To get cost to the job, we use this file in a job adjustment interface.

Instead of job adjustments, I assume you could have two interfaces. One would be to integrate employees with rates. Then you could either have employees clock into Epicor or integrate timecards if you clock in to another system. The only thing I don’t know is whether you can calculate overtime and doubletime without payroll.