HR’s Role in a Custom ERP Build: Requirements Only People Teams Know

People are the most essential resource in any business that helps it grow, and in many cases, among the most expensive. The impact of employees on business performance and the size of investment that companies make in them are significant. 

HR’s module provides core capabilities across common HR processes, advanced analytics and reporting capabilities, and integration with other financial and operational modules.

Why HR Belongs in the Room Before Scoping Ends

ERP projects infrequently fail because the code doesn’t assemble. They fail because the system that routes doesn’t match how the business actually works. Gartner predicts that by 2027, more than 70% of recently executed ERP enterprise projects will fail to fully meet their original business case goals, and at a 2025 Gartner Symposium session, analyst Dixie John pointed to reasons like unrealistic scope, inconsistent stakeholder interests, and limited change management. Every one of those has an HR extent.

There’s a structural reason HR gets left out: ERP projects are usually financed by the CFO or COO, and the first modules scrutinized are general ledger, purchasing, and inventory. People data gets treated as a search table that “we’ll import later.” That’s a mistake, because almost every other component depends on it. Purchase sanction route through managers. Labor costs post to cost centers. Project billing needs to know who worked where. If the employee record is wrong, the errors extend into every module that reads it.

So ask for a seat early, and ask for it in writing: a named HR owner on the requirements team, with ratification rights on anything that touches employee data, approvals, or pay.

The People Data Nobody Else Can Map

Most custom ERP builds start requirements assembly with process interviews and a module list, then assess effort per module. Teams that offer custom ERP software development typically ask each division to describe its data and process, and the quality of what comes back depends on who answers. For people data, that has to be HR.

Org Structure and Reporting Lines

A creator will model “employee has one manager.” You know that some employees have an unbroken line manager for performance reviews and a dashed line manager who approves their timesheets. You also know that a regional director covers two locations while an opening stays open. Write down those inconsistencies, because they decide how approvals route.

Job Codes, Positions, and Cost Centers

Interpret early whether the system should track people, positions, or both. Position management lets you set allowances for a role before anyone fills it, which matters if finance plans staff counts by cost center. Then map every job code to:

• Its FLSA status (exempt or non-exempt)
• Its default cost center and department
• Its pay grade or salary band
• Any certifications or licenses the role requires

If two job codes mean the same thing, decide now whether to combine them.

Who Owns the Employee Master Record

Every field in the employee record needs an owner. HR usually owns hire date, job, manager, and status. Payroll owns tax creation and direct deposit. The employee owns their emergency contact and home address across self-serve. If you don’t task ownership field by field, you’ll end up with three systems and three variants of someone’s address, and no rule for which one wins.

Approval Workflows and Who Can See Salary Data

Approvals look simple in a requirements doc and get intricate fast. Before a single screen is built, list every individual’s approval your company runs and answer the same questions for each one.

Map Each Workflow End to End

For leave, overtime, expense reports, and hiring demand, document:

1. Who starts the request
2. Who approves it, in what order, and whether approval depends on amount, department, or employee type
3. What happens when the authorizer is out (delegation rules and time limits)
4. What the system should do with requests nobody acts on
5. Who gets notified once it’s approved or rejected 

A hiring demand is a good test case. In many companies it needs the hiring manager, the department head, finance (to confirm budget), and HR. If the role is new rather than a refill, it may need a manager too. That conditional step is precisely the kind of rule that gets missed when nobody from HR is in the workshop.

Roles, Permissions, and Salary Visibility

Salary data is where permission design issue most. A department manager may need to see their team’s pay for allocating, but not pay in other departments. A recruiter may need salary bands but not individual salaries. An IT admin running the system needs access to the database, but probably not to legible remuneration fields.

Ask the build team for job-specific permissions at the field level, not only the screen level, and ask for an audit log of who viewed or changed stipend records. Then write the permission framework yourself. You’re the one who knows which conversations would follow if the wrong person saw a worksheet of salaries.

Employee Self-Service

Decide what employees can change on their own and what needs review. Updating a phone number shouldn’t need approval. Changing a bank account for direct deposit probably should activate a verification step, since that’s a common target for paysheet fraud. Self-service also needs to work on a phone, because shift workers often don’t sit at a desk.

Pay Rules Belong in Configuration, Not in Code

This is the single most useful thing HR can tell a development team: pay rules change, so they shouldn’t be fixed.

Start with overtime. Under the Department of Labor’s Fact Sheet #23, an employee’s workweek is a fixed, regularly repeated period of 168 hours, seven consecutive 24-hour periods, and it doesn’t have to match the calendar week. Taxable employees earn at least one and a half times their regular rate for hours over 40 in that working week, and the FLSA doesn’t allow averaging hours across two weeks. That means the system needs to know each employee’s workweek start, and it can’t treat a two-week pay phase as one 80-hour block.

Then add the rules on top of national law. Some states have daily overtime entrance. Your company might pay a shift differential for nights and weekends, a premium for on-call hours, or a different PTO increment rate after five years of service. Each of those is a rule with inputs, and HR should hand creator a table rather than a paragraph:

Rule	Applies to	Calculation	Effective date
Weekly overtime	Non-exempt job codes	1.5x regular rate over 40 hours per workweek	Current
Night shift differential	Shifts starting after 10 p.m.	Flat hourly premium	Per policy
PTO accrual, tier 2	Service of 5+ years	Higher hours accrued per pay period	Per policy

The “effective date” column matters more than it looks. When a protocol changes on January 1, payroll still has to recompute December correctly. Rules with start and end dates let the system handle both.

Retention Rules the System Has to Enforce

Developers will ask how long to retain records. Don’t let them guess, and don’t let “keep everything forever” become the oversight, since holding data longer than required adds its own risk.

Two national rules belong in almost every US company’s requirements. Under the FLSA, the Department of Labor needs employers to keep payroll records for at least three years and the records that wage calculations rest on, such as time cards and wage rate tables, for two years.

For employment fitness, USCIS says you must hold each Form I-9 for three years after the date of hire or one year after employment ends, whatever is later. That rule is a calculation, which makes it a perfect system necessity. When someone is concluded, the system can figure both dates, keep the later one, and flag the form for inspection once that date passes. Ask for the same logic for any state rules that apply to your locations, and have your employment advice confirm the final list.

Store I-9s individually from the general staff file, too. Limiting who can open them is easier when the system treats them as their own document type with their own permissions.

Onboarding, Offboarding, and Access Provisioning

A new hire touches more departments than nearly any other event in the system. HR creates the record, IT challenges a laptop and accounts, paysheet sets up taxes, the manager tasks training, and facilities might issue a badge. When those steps live in email threads, someone always starts without system entry.

Ask for orientation as a task workflow triggered by the hire record: each department gets its own checklist, with due dates relative to the start date. The same goes for shift. When an employee moves from warehouse to accounting, their entry should change the same day, not whenever someone remembers.

Induction is where the risk sits. When HR enters an end date, the ERP should:

• Activate access removal for every system it controls, timed to the last working hour
• Route unauthorized timesheets and expenses to the right approver
• Transfer pending approvals the departing employee owned
• Start the Holding clock on their records
• Generate the final pay calculation inputs, including any payout of Accumulated PTO your policy or state law requires

Running Requirement Workshops and Acceptance Testing

Informed requirements are half the job. The other half is acquiring them into the build in a form developers can test.

Workshops That Produce Usable Requirements

Bring real examples, not rules. Rather than saying “managers approve overtime,” walk through last month’s untidiest timesheet: the employee who worked a split shift, picked up a holiday, and relocated departments mid-week.

Keep each session to one process, invite one or two people who actually do the work (a payroll specialist, a scheduler), and end every session by reading back the decisions. If something is still open, give it an owner and a date.

Acceptance Testing You Design Yourself

Don’t let the build team write all the test cases for HR situations. Write your own, based on the edge cases you see every year: a mid-period reappoint, a backdated raise, an employee on leave during open registration, a manager who leaves with pending approvals. For each test, state the anticipated result before anyone runs it.

Change Management and Training

A system people don’t trust gets worked around with spreadsheets. Plan training by role, so managers learn ratification and employees learn self-serve, and schedule it close to go-live instead of months ahead. Hire a few managers as early as possible. If they find the leave request screen confusing, you want to hear it before 300 people do.

An HR Requirements Checklist

Use this as a starting list for your first workshop, and add your company’s specifics:

• Org data: reporting lines, dotted-line managers, positions vs. people, cost center mapping
• Job codes: FLSA status, pay grade, department, required licenses
• Master data: an owner for every employee field, plus the system of record for each
• Approvals: leave, overtime, expenses, requisitions, with delegation and escalation rules
• Permissions: field-level salary access, audit logs, separate I-9 permissions
• Pay rules: overtime by workweek, shift differentials, PTO accrual tiers, effective dates
• Retention: FLSA payroll and time records, I-9 calculation, applicable state rules
• Lifecycle: onboarding tasks, transfers, offboarding with access removal
• Self-service: what employees edit freely, what needs verification, mobile access
• Testing: HR-written edge-case scripts with expected results
• Training: role-based sessions timed near go-live

Conclusion

The staff in the HR department offer a unique perspective on the processes that take place in the company, allowing us to see the nuances that would otherwise be unnoticed. The ERP system will be truly beneficial and utilized, which cannot be achieved if the software is designed without considering the employees’ contribution.

FAQ