💡 This guide is for software vendors, integrators and technical teams preparing exports from an HR or payroll software that has no Reflect-compatible API. It presents the approach to follow, then the expected content of the files.

Approach: one export per software, not per client

Reflect builds one connector per software. That connector then serves every new client company using the same software, with no new development. For this to work, the export must be identical from one client to the next: only the data changes.

Start from the software’s standard exports

Use the exports the software already provides first: native reports, the vendor’s standard extractions. They exist for every client, follow the software’s updates and do not need to be rebuilt for each integration.

Otherwise, build maintainable custom exports

If the standard exports do not cover the expected data, add custom exports that remain:

Reusable: the same structure for every client company using the software. No column, filter or calculation specific to a single client.
True to the software: keep the native column labels, for example “Company” rather than “Legal Entity”. Do not rename them to match the Reflect model: Reflect maps them to its model during configuration.
Stable: same columns, file naming, encoding and separator from one export to the next. Any change is prepared with Reflect before it is applied.
Automated: generated and dropped every day without manual intervention.

⚠️ Send the generated files without editing or re-saving them manually: a manual edit can change dates, employee numbers or figures.

Examples

Talentia: together with the software’s teams, we adapted the exports to the Reflect model while keeping the original column names.
Cegedim: the software’s native exports were complemented by custom queries to cover the Reflect model.
In-house HR hub: some clients use an internal tool. Its data was integrated as a custom source, following the Reflect V3 template.

Expected data

Provide one CSV file per data type, or one Excel workbook with one sheet per type. The 7 types follow the Reflect data model, the same as for a compatible API:

Data type	Information to include
`Employee`	Employee ID, legal entity, last name, first name, professional email, gender, nationality, birth date.
`Contract`	Effective date, contract ID, contract type, job title, professional category, FTE, arrival dates, contract start and end dates, hire and departure reasons, trial period end dates, remote status, active or inactive status.
`Career`	Effective date, department and other organizational levels, work location, career stage or classification.
`Management`	Effective date, manager’s ID, email, last name and first name.
`Salary`	Effective date, planned fixed, variable and bonus salary, period of each amount (monthly or yearly), currency.
`Absence`	Start and end dates, number of days, absence reason.
`Payroll`	Payroll month, amount and label of each pay item, currency.

Each item is defined in the V3 template column details. Your column names may differ: only the meaning must match. You can also add further data useful to your analyses.

Content rules

Employee ID: each row carries a unique, stable identifier (payroll number or social security number), identical across all files. A name or email is not enough.
Code and label: when an item exists as both a code and a label (for example the department), export both columns.
Formats: dates as YYYY-MM-DD, currency codes such as EUR, numbers without currency symbols.
Departed and never-arrived employees: include employees who have left. For cancelled hires, add a status column (active or inactive) or exclude them upstream.
Multiple contracts: for successive contracts (fixed-term then permanent), export each contract with its actual start and end dates, and its ID if the software provides one.

History and frequency

Effective dates

In the Contract, Career, Management and Salary files, each row states the date on which the change takes effect. Also provide separately, if the software holds them:

the group entry date (seniority);
the company entry date (legal entity);
the start date of the current contract.

Full or differential export

A first export covers the history over the period agreed with Reflect. Daily exports then follow one of these two modes:

Mode	Content of each export
Full (recommended)	The whole database, every night. Reflect compares successive exports to keep the history of changes.
Differential	Rows created or modified since the previous export. Requires a reliable “Modification date” column. To be validated with Reflect.

Absences

Absences are often entered or corrected after the fact. The export must contain at least the absences created or modified over a rolling period, for example the last 3 months.

Setup

⚠️ Mandatory prerequisite: Reflect needs access to the HR software, read-only or on a test environment. This access lets Reflect review the screens, exports and available fields to configure the connector. Without it, the connector cannot be built.

Sample: you provide a first export in its final format, with real data, anonymized if needed.
Configuration: Reflect validates the structure and identifiers, then maps your columns to its model.
Automation: files are dropped every day on an SFTP server provided by the client, the vendor or a service provider. See Setting up an SFTP connection with Reflect.
Acceptance: the client and Reflect compare the first results with the source software before validating regular updates.

💡 The connector is then reused for every new client of the software. Notify Reflect before any change to the format: it affects every connected client.

Create the standard connector for a new HR software