How KYBN determines active population for a selected snapshot date
KYBN works from a fuller employee extract, then uses mapped source fields such as hire date, termination date, and status to determine who should be counted on the selected snapshot date.
Why this matters in real reporting work
Most teams are used to solving this question before the workflow even starts: export an active list, save it, and hope the filter logic was right. KYBN keeps that decision inside the workflow so the active population can be reviewed instead of assumed.
That matters when someone asks why a person was counted, why a person dropped out, or why a number changed from one snapshot date to the next.
Which fields KYBN uses
The exact logic depends on what is available in the uploaded file and how the relevant fields are mapped during Check & Prepare.
What KYBN is actually doing
- Upload a fuller employee extract rather than a pre-filtered active list.
- Map the source fields used for workforce status logic.
- Choose the snapshot date inside KYBN.
- Review how the workflow resolves missing, conflicting, or ambiguous values before generating outputs.
Why teams usually prefer this once they see it
A pre-filtered active list gives you a final answer but hides how that answer was produced. KYBN keeps the intermediate logic visible so teams can review what is being counted, which records are borderline, and what source quality issues could affect the final output.
What this avoids
- Hard-coding counting logic into a spreadsheet filter before review.
- Re-exporting a different active list for every reporting date.
- Losing traceability when source rows are excluded before the workflow begins.
Keep reading
For the broader workflow, read One dataset, multiple reporting views. For the day-to-day reporting context, read Why HR reporting stays manual after the HRIS export. For shorter answers, see the FAQ.