One Source of Truth for Employee Data

What they had

The company had just implemented its first HRIS. Before that, employee information lived in an internal database backed by a web application. The database was limited to whatever data the onboarding team had entered at the time of hire. There was no process for employees to review or update their own records afterward, so addresses, dependents, tax forms, and banking details drifted out of date quickly.

Payroll ran from a separate accounting system. That meant the company had two disconnected sources for employee information: the internal web app for personal and employment details, and the accounting system for pay. Reconciling them was a manual exercise.

What broke

Double entry. Onboarding spent extra time entering data into both the internal web app and the accounting system.
Payroll errors. Discrepancies between the two systems caused pay mistakes and corrections.
Stale employee data. Employees could not update their own records, so mistakes stayed until someone else noticed them.
Downstream workflows could not trust either source. Access, benefits, documents, and time tracking had to reconcile incomplete data by hand.

The deeper issue was that employment data had no single owner. The internal web app was supposed to hold employee records, but payroll relied on the accounting system. Until those systems agreed on one record, every downstream process had to reconcile the difference by hand.

What we chose

We chose a full HRIS implementation to replace both the internal employee database and the accounting-system payroll. The new HRIS became the single system for employee data and payroll. Then I proposed an API integration so the HRIS could feed clean, current employee data back to the internal web app and other downstream systems.

The design had four principles:

One entry point. The onboarding team enters employment data only in the HRIS.
No re-entry. Payroll runs from the same HRIS record, and the internal web app receives updates through an automated feed.
Employee self-service. Employees update their own personal details in the HRIS, reducing stale information.
Triggers downstream work. Changes in employment status start access, benefits, document, and time-tracking workflows.

The integration also made it possible to compare data across systems. For example, clock-in data from the HRIS could be matched against time-tracking records from other tools. Discrepancies could be flagged automatically instead of being caught during manual payroll review.

My role

I gathered employee feedback, mapped the current data flow between the internal web app and the accounting system, and built the business case for moving both employee data and payroll into the HRIS. I worked with the HRIS, payroll, and operations teams to design the API touchpoints, define the data fields, and agree on error handling. I also helped the onboarding team transition to a single-entry process, set up self-service access for employees, and trained them on validation rules so the source data stayed clean.

Why this matters

This project was about more than switching systems. It was about stopping people from acting as messengers between systems. When employment data has to be carried by hand from one platform to another, errors and delays are inevitable. The integration made the HRIS the messenger, which is the core idea behind Issue 002 on this site: stop people from being messengers.

All employment changes should start in the HRIS and trigger the rest. That is what makes the workflow scalable, auditable, and ready for automation.

Outcome