Acumatica Time Entry — Customisation Patterns

Time entry looks like the simplest self-service screen in Acumatica — a grid of hours against days — until you factor in overtime rules, project billability, and payroll or Projects module integration all reading from the same records. Most time-entry customizations are really about getting those downstream calculations right.

Core DACs and screens

Time entries are typically recorded through EPTimeCard/EPActivity style DACs, submitted through a self-service time entry screen (often numbered around EP305000) and approved through the standard Approval Maps engine. Time entries that reference a project and task feed into PMTran for project cost and billing purposes; time entries without a project reference typically feed payroll or general labor tracking instead.

Extension points

Overtime rules (daily over 8 hours, weekly over 40, state-specific variants) are the most common time-entry customization, and they're best implemented as a calculation run at approval or at a nightly batch process rather than recalculated live on every keystroke in the entry grid — overtime depends on a full week's entries, which aren't necessarily complete while the employee is still entering Tuesday's hours.

A realistic scenario: daily and weekly overtime

A frequent request: apply daily overtime (anything over 8 hours in a single day pays at 1.5x) and weekly overtime (anything over 40 total pays at 1.5x, with daily OT hours not double-counted toward the weekly threshold) — a specific interaction that's easy to get subtly wrong.

public class TimeCardOvertimeCalculator
{
    public virtual (decimal regular, decimal overtime) CalculateWeek(IEnumerable<EPActivity> weekEntries)
    {
        decimal totalRegular = 0, totalOT = 0;
        var byDay = weekEntries.GroupBy(a => a.Date.Value.Date);

        foreach (var day in byDay)
        {
            decimal dayHours = day.Sum(a => a.TimeSpent ?? 0);
            decimal dayOT = Math.Max(0, dayHours - 8m);
            decimal dayRegular = dayHours - dayOT;

            totalOT += dayOT;
            totalRegular += dayRegular;
        }

        // Weekly OT applies on top of regular hours already counted,
        // not on hours already classified as daily OT.
        decimal weeklyOTThreshold = Math.Max(0, totalRegular - 40m);
        totalOT += weeklyOTThreshold;
        totalRegular -= weeklyOTThreshold;

        return (totalRegular, totalOT);
    }
}

This is a simplified illustration of the daily-then-weekly cascading logic — actual payroll rules vary significantly by jurisdiction (some states require daily OT past a different threshold, some have double-time rules past 12 hours), so this needs to be parameterized per the client's actual policy rather than treated as a universal formula.

Project billability interactions

When a time entry is tagged to a billable project task, the hours flow into PMTran and eventually the project billing engine — overtime premium handling needs an explicit decision here: does the client bill the client at a blended rate, a straight rate with OT absorbed internally, or pass through the OT premium? This is a business decision that needs to be nailed down before writing the calculation, not inferred from the code.

Testing considerations

Test a full pay period with entries submitted out of chronological order, at least one day crossing the daily OT threshold, and a week crossing the weekly threshold — and test the interaction of both in the same week, since that's where the subtlest bugs live, exactly as illustrated in the calculation above.

Wrapping up

Time entry customization is a payroll problem wearing an ERP UI — get the overtime cascade logic (daily before weekly, no double counting) and the project-billing interaction explicitly agreed before writing code, and compute overtime as a period rollup rather than a live per-entry calculation.