Employee data cleaned before it reaches the platform

The problem

The client implements Zoho for other companies. Every new People implementation starts the same way: with the client's employee master data, held in spreadsheets in whatever shape that client happens to keep them.

Cleaning and validating that data by hand is slow. Worse, the platform gives no useful error report when an import fails, so bad rows surface one upload attempt at a time.

The friction

Arbitrary column headers had to be mapped to the platform's field set by hand, for every client. Dates, phone numbers, identifiers and addresses were checked by eye. Cross-field problems — a date that contradicts another date — were found late or not at all. And the whole exercise was repeated from scratch on the next implementation.

The system

An ETL tool. Upload the client's sheet, and a single model call reads the headers and maps them to the target field set. That is the one place the system uses AI, and it is there for a specific reason: mapping an unfamiliar column name to a known field is a judgement over ambiguity, which is what models are good at.

Everything after that is deterministic. The validation engine is rule-based code, never a model call per cell — correctness has to be repeatable, and a large file cannot afford it. It checks every field in the People module, including checks that only make sense across a whole sheet, such as duplicate phone numbers, and checks that only make sense across fields, such as dates that contradict each other.

What comes out is a clean import file and an error report a person can actually read.

The workflow

The tool was built with the client's own team rather than delivered to them. Their developer wrote code under our architecture and review. Their functional expert supplied the real platform rules and tested against real client files.

Those real files did what sample data never does: they exposed genuine defects — address columns shifted by one, phone numbers sitting in the wrong column — that the validation engine now catches for everyone.

A data-handling procedure was agreed before any of that started. No employee data in email or in model chats. Real data only for time-boxed work on a local machine.

What we learned

Use deterministic rules where correctness matters, and a model only where the problem is genuine ambiguity. The instinct to put AI in the middle of a validation loop is expensive in both senses, and it makes the result unrepeatable.

Build capability inside the client's team rather than handing over a black box. The client now has people who understand the tool because they wrote parts of it.

Forty-four fields are validated, covered by more than three hundred automated tests, with a real customer file kept as the regression check. The People module is complete and in team testing; Recruit and Payroll are planned as thinner layers on the same configuration-driven core.