Skip to main content
Your customer says they entered the promotion. You read the employee and the old title comes back. Nothing has failed, and waiting for the next sync will not help. The change is there. It has not started yet.

​
Two different dates

HR systems separate when a change was recorded from when it takes effect, and both are real. A raise entered on 1 March and effective 1 April is recorded in March and current from April. For the whole of March the two disagree. The effective state is the one describing what the employee is paid today. This is not an edge case. Compensation changes, promotions, transfers, benefit enrollments and terminations are routinely entered in advance - entering them on the day is the exception.

​
Future-dated records are in your data

Bindbee syncs what the source system holds, which includes records whose effective date has not arrived. They are ordinary records with dates in the future.
Reading the most recently created compensation or employment record does not give you the current one. It frequently gives you a future one. Anything surfacing pay or title to a user must select by date, not by recency.

​
The selection rule differs by model

There is no single “effective period contains today” test, because most models do not carry an end date. Only benefits and dependent benefits have a true period. For employment and compensation the rule is latest one that has already begun: discard anything dated ahead of today, then take the most recent of what remains. Taking the newest record outright is the most common way to show someone a salary they are not yet earning.
Note the last column. Employment - the model this rule matters most for - has no date filter at all, so you page through everything and select in your own code. Compensation and benefits let you bound the query, which is worth doing on large tenants.
Terminations behave the same way. An employee with a future termination_date is currently employed, and treating any termination date as past tense will offboard people who are still working.

​
Sync timing is a separate problem

Two different delays produce the same symptom, and telling them apart is the first diagnostic step. Sync lag is Bindbee not having read the change yet. The record does not exist in your data at all. It resolves on the next sync, or immediately on a forced resync. Effective dating is Bindbee having the change and the change not applying yet. The record exists, with a future date. No amount of resyncing changes it. If the customer swears they made the change and you cannot see it anywhere, that is sync lag. If you can see a record dated ahead, that is effective dating - and everything is working correctly.

​
Where the future is legitimate

Some models are forward-looking by design and should be read that way. Payroll run calendars describe periods that have not happened, benefit plan years often open before they begin, approved time off is usually ahead of today, and scheduled interviews sit in the future by definition. For these, filtering out future records discards the data’s purpose.

​
Why it works this way

Bindbee could resolve effective dating for you - return only what is currently in force and hide the rest. It does not, because “currently” is not a stable enough idea to bake into an API. Applications need different answers at different moments. Payroll reconciliation asks what was in force during a past period. Benefits eligibility asks about a specific date. Onboarding automation asks what will be true when someone starts. An API that pre-resolved to today would serve the simplest case and make the others impossible, since the discarded records would be gone. Returning the full dated set means every question is answerable, at the cost of requiring you to state which date you mean. That cost is real, and it is why the selection is worth writing once as a shared helper rather than repeating at each call site.

​
What this means for you

  • Select by date, never by recency. The newest record is often the future one.
  • Use the right rule per model. Only benefits support period containment; employment and compensation have no end date.
  • A future termination date means currently employed.
  • Distinguish sync lag from effective dating before investigating. Only one of them has a fix.
  • Do not filter future records blindly. Calendars and plan years are supposed to be ahead.