A payroll summary report sits in a different risk category from almost everything else in the Report Designer's usual output, because the data it prints is the one thing in the whole ERP that HR and finance actively don't want visible to the wrong person. Building this report is as much an access-control exercise as a layout exercise, and I treat it that way from the first conversation.
Design security before you design the layout
The report needs to answer, before a single field goes on the canvas: who can run this, and does it show one employee, one department, or the whole company? A payroll summary run by an HR generalist for their own department and a payroll summary run by the CFO for the whole company are two different access levels, and the report should either be two reports with different access rights, or one report whose schema filters by the running user's scope automatically rather than trusting a manually-entered department parameter that any user with report access could type around.
Join: EPEmployee ON PREmployeePayHistory.EmployeeID = EPEmployee.EmployeeID
Join: EPCompanyTreeMember ON current user's workgroup membership
Filter: EPEmployee.DepartmentID IN (departments under current user's workgroup)
-- not a free-text @Department parameter a user could overrideIf a company-wide version genuinely needs to exist, gate it behind a distinct screen ID with its own access rights entry, so granting "can run payroll reports" to a department manager doesn't accidentally also grant the company-wide variant through the same report.
Summary means gross, deductions, and net per period — not a pay-stub-per-employee dump
A payroll summary report is a periodwise rollup: total gross pay, total deductions by category (tax, benefits, garnishments), employer contributions, and net pay, grouped by department or cost center for a given pay period or date range. It's distinct from a payroll register or individual pay stub reprint, which shows line-level detail per employee. Confirm which one is actually being requested — "payroll summary" gets used loosely, and building the wrong grain (detailed register when a rollup was wanted, or vice versa) means redoing the report, not adjusting it.
Deduction and earning codes tend to accumulate over the life of an instance — a new benefit plan adds a code, a discontinued one doesn't get cleaned up. If the report's "total deductions" bucket is built from a hardcoded list of deduction codes rather than a category flag maintained on the deduction code setup itself, a new deduction code silently falls outside every bucket and the summary's totals stop reconciling to the payroll register without anyone noticing until a quarter-end audit.
Export and print controls matter more here than on any other report in this list
A payroll summary that's fine on screen for an authorized manager becomes a liability the moment Export to Excel is enabled without thought — an exported spreadsheet has no access control once it leaves the report viewer and lands in someone's Downloads folder or an email thread. For this specific report category, I disable open-ended export where the platform allows it, or at minimum ensure the schema itself never includes individual-level detail beyond what the summary needs, so even an export can't leak more than the aggregate view shows.
Wrapping up
Treat payroll summary reporting as an access-control problem first and a layout problem second — scope data to the running user's actual authority in the schema, not a parameter they could type around, and split company-wide and department-scoped versions into separately secured reports rather than one report trusted to behave. Confirm summary versus detail grain before building, keep deduction bucketing driven by a maintained category flag, and think hard about what export leaves the building once it's enabled.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.