Most HRIS selection processes are run off a feature list. You sit through six demos, tick boxes for payroll, leave, onboarding, and performance, pick the vendor with the cleanest interface, and start migrating.
Eighteen months later, the system does everything the feature list promised and still cannot answer the questions your leadership team asks every quarter. What did this person cost us last year? Which of our engineers are certified for the Dubai project? Why does finance think headcount is 112 when HR says 108?
Those are data model questions rather than feature questions. The features usually work exactly as demonstrated. The field structure sitting underneath them is what was never designed, and that is what limits the system two years in.
This guide walks through what an HRIS data model is, the six layers of fields a system of record needs to hold, and the design decisions (effective dating, field ownership, retention) that determine whether your employee data is usable three years from now. It is written for HR, operations, and finance leaders at project-driven firms, where the employee record has to serve payroll and delivery at the same time.
What Is an HRIS Data Model?
An HRIS data model is the structure that defines what information your Human Resource Information System stores about each employee, how those fields relate to each other, and how changes to them are recorded over time. It covers the field list, the relationships between records (person to job, job to manager, manager to cost center), and the rules governing who can create or change each value.
A feature answers the question “can the system do leave approvals?” A data model answers the question “when this person moves from Bengaluru to Dubai on 1 October, what happens to their leave entitlement, their statutory deductions, their cost center, their billing rate, and last year’s reports?”
That distinction matters because features are replaceable and data is not. You can swap a performance module. You cannot recover three years of salary history that was overwritten instead of versioned.
If you want the broader picture of what a system of record does before going field by field, our guide to HRIS in human resources covers the functional side.
Why the Data Model Decides What Your HRIS Is Worth
Three things break when the underlying field design is weak, and all three show up long after go-live.
Reporting stops being trustworthy: If department names were free text at migration, you have “Engineering,” “engineering,” “Engg” and “Eng Team” living as four separate values. Every headcount report is wrong by an amount nobody can quantify. This is the single most common finding in an HR data audit and it is entirely a field design problem.
Payroll inherits every error: Master data is stable by nature (name, employee ID, date of joining, bank details, statutory identifiers) while transactional data changes constantly. An error in transactional data affects one cycle. An error in master data repeats every single month until someone catches it, and by then it has usually been filed with a tax authority.
Integrations expose the gaps: The moment your HRIS has to talk to payroll, an accounting system or a project tool, the receiving system needs fields your HRIS may never have been asked to hold. A missing cost center or a missing employment type is a manual reconciliation every month, forever.
The Six Layers of an HRIS Data Model
A workable employee record has six layers. The first four appear in almost every HRIS on the market. The fifth is where regional systems separate from global ones. The sixth is where most HR systems stop and project-driven firms start losing money.
| Layer | What It Holds | Primary Consumer | Change Frequency |
| 1. Identity and personal | Name, contact, IDs, emergency contacts | HR, payroll | Rarely |
| 2. Employment and job | Dates, contract type, role, manager, location, cost center | HR, finance, reporting | On lifecycle events |
| 3. Compensation and payroll | Pay structure, bank details, tax setup, benefits | Payroll, finance | Annually or on change |
| 4. Time, attendance and leave | Balances, timesheets, shift patterns, holiday calendar | Payroll, delivery | Continuously |
| 5. Statutory and compliance | Country-specific IDs, permits, filings, registers | Compliance, payroll | On regulation change |
| 6. Commercial and capability | Billing rate, cost rate, skills, certifications, allocation | Delivery, finance | On project events |
Layer 1: Identity and Personal Data
This layer answers who the person is. It is the smallest layer and the one most likely to be over-collected.
Core fields:
- Employee ID (system-generated, immutable, never reused)
- Legal name, preferred name, name as it appears on statutory documents
- Date of birth, gender, nationality
- Personal email and phone, distinct from work email and phone
- Current address and permanent address, held separately
- Emergency contacts with relationship, minimum two
- Government identifiers, encrypted and access-restricted
Two design points are worth spending time on.
Legal name and payroll name are different fields: A person’s name on their tax record, their bank account, and their passport may differ in ways that break automated filings if you store one value. Firms operating in India and the GCC hit this constantly, where a bank account name mismatch will reject a salary transfer outright.
Collect identity data against a purpose: India’s data protection framework rests on seven principles, among them purpose limitation, data minimization, accuracy and storage limitation, as set out in the Ministry of Electronics and Information Technology briefing on the DPDP Rules. Every field in this layer should map to a stated purpose. Marital status collected “in case HR needs it” is a liability with no offsetting benefit.
Layer 2: Employment and Job Architecture
This layer answers what the person does and where they sit. It is the layer that drives reporting, and it is the one most often left as free text.
Core fields:
- Date of joining, confirmation date, exit date, notice period
- Employment type (permanent, fixed-term, contractor, intern, consultant)
- Employment status (active, on leave, notice period, exited)
- Job title, job code, job family, grade or band
- Department and cost center, held as separate fields
- Reporting manager and dotted-line manager
- Work location, legal entity, and country of employment
- FTE value for part-time and shared resources
Three rules make this layer usable.
Every one of these should be a controlled list, not free text: Job title can stay free text for business cards. Job code cannot. Reporting depends on a finite, governed set of values.
Department and cost center are not the same thing: Department is an organizational concept. Cost center is a finance concept. A person can sit in Delivery and be charged to three different cost centers over a year. Merging them means finance rebuilds the mapping in a spreadsheet every month.
Legal entity is a first-class field: If you operate an Indian private limited company and a UAE free zone entity, employment law, statutory deductions, and reporting all key off the entity, not the office address. Firms that store only “location” discover this during their first cross-border transfer.
Layer 3: Compensation and Payroll Data
The most sensitive layer, and the one where versioning matters most.
Core fields:
- Salary structure broken into components, not a single CTC figure
- Currency and pay frequency
- Effective date for every compensation value
- Variable pay, bonus eligibility and commission structure
- Bank account details, IFSC or IBAN, account holder name
- Tax residency, withholding setup, declared exemptions
- Benefits enrolment and dependant records
- Full and final settlement status on exit
The field that causes the most downstream pain is the salary component breakdown. Storing a single annual figure works until you need to run a payroll calculation, model a revision, or explain a payslip. Basic, allowances, employer contributions, and reimbursements each behave differently for tax and for statutory deduction purposes. A guide to how this connects end to end sits in our HRMS payroll walkthrough.
Compensation history is not an archive. It is an operational field set. Pay equity analysis, promotion modeling, and exit settlement calculations all read historical values, which brings us to a design decision covered further down.
Layer 4: Time, Attendance and Leave
This layer changes daily and feeds both payroll and delivery.
Core fields:
- Leave types with their own accrual rules and caps
- Opening balance, accrued, availed, encashed and closing leave balance per type
- Carry-forward rules and expiry dates
- Holiday calendar mapped to location and entity
- Shift pattern and roster assignment
- Attendance records with source (biometric, geotagged, self-marked)
- Timesheet entries with project, task, date and billable flag
The billable flag on the timesheet line is the field that connects HR to revenue. Most HRIS platforms treat a timesheet as an attendance artifact and record hours worked. A services firm needs hours worked, hours billable, and the project each hour belongs to, held on the same line. Without that, someone is reconciling attendance against project records by hand before every invoice run.
Holiday calendars deserve a mention because they are usually modelled as one list. A firm with staff in Bengaluru, Dubai and Pleasanton needs three calendars, mapped to entity and location, with the person’s calendar resolved from their job record. One global list produces incorrect leave deductions in at least two of those three places.
Layer 5: Statutory and Compliance Fields
This is where regional reality enters, and where global HRIS platforms configured for a single market tend to fall short.
India: Provident fund number and UAN, ESIC number where applicable, PAN, professional tax state, gratuity eligibility date, and the fields required to produce the registers your establishment must maintain. Statutory deduction setup should be a structured field set rather than a payroll-side override, because a change to statutory deductions needs to be auditable back to the employee record.
Data protection has moved from advisory to operational here. India’s Digital Personal Data Protection Rules were notified on 14 November 2025, giving full effect to the Digital Personal Data Protection Act, 2023. The Rules set an eighteen-month window for phased compliance and require data fiduciaries to address requests relating to access, correction, updating or erasure within ninety days. Penalties are material, reaching ₹250 crore for failure to maintain reasonable security safeguards. In field terms, that means your HRIS needs to support targeted correction and erasure of an individual’s data, with a record of what changed and when.
UAE and the wider GCC: Emirates ID, labour card and work permit numbers, passport and visa expiry dates, MOHRE establishment reference, IBAN in the format the Wage Protection System expects, and gratuity accrual data. Visa and permit expiry dates should be date fields with alerting, not scanned documents in a folder.
Wage compliance tightened sharply this year. Ministerial Resolution No. 340 of 2026 came into force on 1 June 2026 and repealed Ministerial Resolution No. 598 of 2022. It introduces a unified due date, under which wages for the preceding Gregorian month must be paid on the first day of each Gregorian month, and any later payment counts as delayed. An establishment is now deemed compliant where it transfers at least 85% of total wages due by the due date, raised from the previous 80% threshold, and the exemption that covered new employees for their first 30 days has been removed. Practically, a new joiner’s bank details and wage record now need to be complete and correct from day one, which is a data readiness requirement before it is a payroll one.
United States: Work authorization status and expiry, I-9 verification record, state of work for tax nexus, exempt or non-exempt classification, and benefits eligibility dates.
The pattern across all three is the same. Compliance fields are date-driven and jurisdiction-driven. A data model that assumes one country will need a parallel spreadsheet for every other one.
Layer 6: Commercial and Capability Data
Here is where an HRIS built for a generic employer and an HRIS built for a project-driven firm diverge.
If your firm sells time, the employee record is a commercial object. It carries a cost, it carries a price, and the gap between them is your margin. A system that holds salary but not billing rate can tell you what a person costs and nothing about what they earn.
Core fields:
- Billing rate and cost rate, each effective-dated
- Rate variations by client, project or role
- Standard capacity in hours, and target utilization
- Skills and proficiency levels held as a structured skill matrix
- Certifications and licenses with issuing body and expiry date
- Current and planned project allocations with percentage and date range
- Bench status and available-from date
This layer is where the industry data gets uncomfortable. SPI Research’s 2026 Professional Services Maturity Benchmark, drawn from 509 professional services organizations employing over 245,000 consultants and generating nearly $63 billion in professional services revenue, recorded billable utilization falling to 66.4% in 2025, the lowest level in the study’s nineteen-year history. Utilization at that level is a capacity problem and a visibility problem at once. You cannot manage a number your system of record does not hold.
Certifications carry a second, harder consequence. In engineering, MEP and EPC work, the license or certification determines whether a person can be assigned to a job at all. If that data lives in a folder of scanned PDFs, your resourcing decisions are being made on memory, and an expired certification surfaces during a client audit rather than during planning.
Most HR teams object that this data belongs in a project tool. It can live there, provided both systems agree on who the person is. Splitting the record across two systems means maintaining a mapping table, and mapping tables drift. Holding capability and commercial fields on the same employee record removes the reconciliation entirely.
Effective Dating: The Field Design Decision Most Teams Miss
A field with one value tells you what is true today. A field with an effective date tells you what was true on any date you ask about. The difference between those two designs decides whether your HRIS can answer historical questions at all.
When a salary revision is applied by overwriting the salary field, the previous value is gone. Reports run against last quarter now use this quarter’s number. Cost analysis for a completed project uses a rate that did not apply while the project ran. No errors. The numbers are simply wrong, quietly.
Effective dating stores each value as a row with a start date and an end date. A change inserts a new row rather than replacing the old one. Ask the system what someone’s grade was on 12 March, and it returns the row that was in effect that day.
At minimum, effective-date these fields:
- Salary and every compensation component
- Billing rate and cost rate
- Job title, grade and job code
- Department, cost center and reporting manager
- Work location and legal entity
- Employment type and status
- FTE value
The billing rate case is the one that costs real money in services firms. A rate that changed in April, applied retroactively across a project that started in January, either overstates or understates margin on every invoice raised in between. When the rate is effective-dated, the system applies the rate that was in force on the day the work was logged.
Ask this directly in vendor demos: “Show me this employee’s job and pay record as it stood on a date twelve months ago.” A system that cannot do it is storing a snapshot rather than a history, and you will find that out during your first audit.
Field Ownership and Data Governance
A data model is field definitions plus rules about who maintains them. Without the second half, the first half decays.
Assign every field an owner. In practice, the mapping is simple:
| Field group | Owner | Update route |
| Personal contact, address, emergency contacts | Employee | Self-service, no approval |
| Bank details | Employee | Self-service with verification step |
| Job, grade, manager, cost center | HR | Approved change request |
| Salary and compensation | HR and finance | Approved change request |
| Billing rate and cost rate | Finance or delivery lead | Approved change request |
| Skills and certifications | Employee, HR verifies | Submitted, then verified |
| Statutory identifiers | HR | Verified against document |
Two governance mechanisms do most of the work.
- Employee self-service for the fields employees know best. The person who moved house last week is the most reliable source for their new address. Routing that change through an HR inbox adds delay and a transcription error. Employee self-service moves those fields to the people closest to them and takes low-value work off HR.
- An audit trail on every governed field. For salary, statutory identifiers, and bank details, you need to know what changed, who changed it, and when. An audit trail is a compliance requirement in most jurisdictions and a practical necessity in all of them, particularly for correcting an error that has already reached a payroll filing.
Add validation at the point of entry rather than cleaning up afterwards. Format checks on identifiers, mandatory fields at each lifecycle stage, and controlled lists on anything that gets reported prevent the four-spellings-of-Engineering problem before it starts.
Access Control, Retention and Privacy by Design
Your HRIS holds the most sensitive data set in the business. Three controls belong in the data model rather than bolted on later.
Field-level access, not module-level: A project manager needs to see capacity, skills and allocation for their team. They do not need salary, bank details, or statutory identifiers. Role-based access that operates at the module level forces a choice between blocking managers from useful data and exposing them to sensitive data. Field-level permissions remove that trade-off.
Retention rules per field group, not per record: Different fields have different lawful retention periods. Payroll records typically need to be held for a defined statutory period after exit. Recruitment notes and background verification reports usually should not be. Storage limitation is one of the stated principles of India’s data protection framework, and a data model that treats the whole employee record as a single retention unit cannot honor it.
Erasure and correction that operate at field level: Given the ninety-day response requirement for access, correction, updating, and erasure requests, your system needs to locate and act on individual fields for an individual person. A model where personal data is duplicated across five modules turns each request into a manual hunt.
Ask vendors where their data is hosted, what certifications they hold, and whether they will sign a data processing agreement. Juntrax publishes its posture at trust.juntrax.com, including ISO 27001 certification and GDPR and CCPA alignment, and has a standard DPA available.
How to Audit the Data Model You Already Have
You do not need a migration to fix a data model. Run this in an afternoon.
- Export every field: Pull a full field list from your current system, including custom fields. Most teams are surprised by how many exist.
- Mark each field’s purpose: For every field, write the business question it answers. Anything with no answer is either dead weight or a privacy liability.
- Flag free text where you need controlled lists: Department, job code, location, cost center, and employment type are the usual offenders.
- Check which fields carry history: Change a test employee’s grade and see whether the previous value survives. Repeat for salary and for rate.
- Assign an owner to each field: Any field without a named owner will drift.
- Test one reporting question end-to-end: Pick something real, such as fully loaded cost per billable hour by department for the last completed quarter. Whichever field blocks you is your priority fix.
- Map your statutory field set against your entities: One row per country you employ in, one column per required identifier or date. Gaps are visible immediately.
Step six is the one that generates the shortest and most useful list. A question you cannot answer points to a specific missing or unversioned field, which is a fixable problem with a defined scope.
Common HRIS Data Model Mistakes
Storing CTC as a single number: It cannot be used for payroll calculation, tax modeling or revision planning without being broken apart every time.
Treating cost center as a synonym for department: Finance will maintain a shadow mapping, and the two will diverge within a quarter.
Using free text for anything you report on: Reporting fields need governed values. This is not negotiable and it is trivially cheap to fix at setup.
Overwriting instead of versioning: History is not recoverable once it is gone. Effective dating costs nothing at configuration time and cannot be retrofitted onto data that was already destroyed.
Collecting fields with no stated purpose: Under current Indian and European frameworks, holding data you cannot justify is an exposure that returns nothing.
Leaving rate data outside the employee record: For firms that sell time, this is the difference between knowing project margin in real time and calculating it in a spreadsheet a month after the project closes.
Scanning documents instead of capturing dates: A visa expiry inside a PDF cannot trigger an alert. The same value in a date field can.
Where Juntrax Fits
Juntrax was built as a project-to-cash operations layer for professional services firms, which shapes the data model directly. The HRMS holds the identity, employment, compensation and statutory layers you would expect from any system of record. PSA adds the commercial and capability layer on the same employee record, so billing rate, cost rate, skills, certifications and allocation sit alongside job and pay rather than in a separate tool. Cash-Flow picks up from there, so billable hours reach an invoice without anyone re-keying a rate.
Rates are effective-dated, so the system uses the rate that applied on the day work was logged rather than today’s rate. Documents keep their own copy of what they were built from, which means a catalog price change next month does not rewrite an invoice you already issued.
Juntrax works alongside your accounting system rather than replacing it. Tally, QuickBooks, Xero, and SAP continue to own the ledger. Juntrax owns the operational layer that feeds them, which is generally where services firms lose margin.
If your firm sits in the 25 to 150 person range and runs project work across India, the GCC or the US, our comparison of HR software for consulting firms covers how to evaluate this category, and the consulting firms page shows what the setup looks like in practice.
Start With the Questions, Then Design the Fields
A useful HRIS data model is built backwards. Write down the ten questions your leadership team asks every quarter. Work out which fields answer them, at what grain, with what history. Then configure the system to hold exactly those fields, with an owner and a retention rule attached to each one.
The firms that get this right are rarely the ones with the largest field list. They are the ones where every field has a purpose, a controlled set of values, an effective date where it matters, and a person accountable for keeping it accurate.
Frequently Asked Questions
What Is an HRIS Data Model?
An HRIS data model is the structure defining what fields your Human Resource Information System holds for each employee, how those records relate to each other, and how changes are recorded over time. It covers the field list, the relationships between person, job, manager, and cost center, and the governance rules for who can change each value.
What Data Does an HRIS Store?
An HRIS stores six layers of data: identity and personal details, employment and job architecture, compensation and payroll setup, time and leave records, statutory and compliance identifiers, and, in systems built for project work, commercial data such as billing rate, cost rate, skills and allocation.
What Is the Difference Between Master Data and Transactional Data in an HRIS?
Master data is relatively stable and describes the employee: name, employee ID, date of joining, designation, bank details, and statutory identifiers. Transactional data changes constantly: attendance, leave taken, timesheet entries, variable pay, and reimbursements. An error in master data repeats every payroll cycle until corrected, which makes it the more damaging of the two.
What Is Effective Dating in an HRIS?
Effective dating stores each value with a start and end date rather than overwriting it. A salary revision inserts a new row instead of replacing the old one, so the system can return what someone’s salary, grade, or billing rate was on any date you ask about. Without it, historical reports silently use current values.
Which HRIS Fields Should Be Effective-Dated?
At minimum: salary and every compensation component, billing rate and cost rate, job title, grade and job code, department, cost center and reporting manager, work location, legal entity, employment type and status, and FTE value.
What Statutory Fields Does an HRIS Need for India?
Provident fund number and UAN, ESIC number where applicable, PAN, professional tax state, gratuity eligibility date, and structured statutory deduction setup. Under the Digital Personal Data Protection Rules notified in November 2025, the system also needs to support correction and erasure of individual fields within a ninety-day response window.
What Statutory Fields Does an HRIS Need for the UAE?
Emirates ID, labour card and work permit numbers, passport and visa expiry as date fields with alerting, MOHRE establishment reference, IBAN in Wage Protection System format, and gratuity accrual data. Since Ministerial Resolution No. 340 of 2026 took effect on 1 June 2026, new joiners fall within the Wage Protection System scope immediately, so wage and bank data must be complete from day one.
Should Billing Rate Live in the HRIS or the Project System?
It can live in either, provided both systems agree on employee identity. Splitting the record requires a mapping table between systems, and mapping tables drift as people join, move, and exit. Holding billing rate and cost rate on the same employee record as job and pay data removes the reconciliation and lets margin be calculated without an export.
How Many Fields Should an HRIS Hold?
There is no correct number. The useful test is whether every field answers a business question someone asks, has a controlled set of values where it feeds reporting, carries an effective date where history matters, and has a named owner. Field count without those four conditions adds maintenance cost rather than capability.