Why your recruitment report shows almost zero on a busy stage
Echipa HR 365 · reviewed 2026-09-02 · 5 min read
Because the report counts who is in a stage now, not how many passed through it. Those are two different questions, and a table that mixes them answers both wrongly — usually with no sign that anything is wrong.
What the problem looks like, concretely
You add a new stage to the recruitment process, say “work sample”. At month end you open the report and see 2 candidates there, although you know for certain that about fifteen went through. It is not a bug: the other thirteen have already moved on, so they are no longer in that column. The report shows you where people are right now; you wanted to know how much work was done last month.
The same pattern appears wherever there are states: how many leave requests are pending (stock) versus how many were processed this month (flow); how many employees are on probation now versus how many completed it this quarter; how many onboarding tasks are open versus how many were closed.
| Stock — “how many are here now” | Flow — “how many passed through” | |
|---|---|---|
| Read from | the status column of the row | the history of transitions |
| The sum across categories | equals the total | can exceed the total |
| The date filter applies to | nothing — it is a snapshot of today | the date of each transition |
| It answers | where the process is stuck right now | how much was done in the period |
| It changes when | somebody advances or exits | never retroactively |
| Good for | the Monday operational meeting | the monthly report and comparisons |
The second trap: the date filter applied to the wrong date
Subtler and more frequent than the first. You select September, and the system filters candidates created in September, then groups them by their current stage. The result: somebody who applied in August and interviewed in September disappears from the report entirely, although September is when the work happened. And somebody who applied in September and has not moved appears in the “applied” column, as if that were an achievement of the month.
The rule: in an activity report, the date filter applies to the date of the event, not the date the row was created. If the report does not tell you which date it filters on, assume it filters on the wrong one and check.
How you check a report in two minutes
Three questions to ask any report, before you pass it on
- You — add up the columns: if the sum is exactly the total, it is a stock report; if it is larger, it is flow
- You — change the period back one month: if the figures do not change at all, the filter is not applied to the event
- You — look for a case you know — somebody whose activity last month you remember — and check whether they appear where you expect
The third step catches the most problems, because it checks the report against something you know from outside the system. A report that cannot reproduce a case you know personally cannot be trusted on the cases you do not.
What you report, depending on the question
- To leadership, monthly: flow. How many entered, how many advanced, how many exited. It is the only form in which work is visible.
- In the weekly operational meeting: stock. Where the process is stuck now, who has been waiting too long.
- For comparisons between months: flow, always. Stock compared between two months only says how the process looked at two moments, not what happened in between.
- For alerts: stock with ageing. Not “how many requests are pending”, but “how many have been pending over five days” — an ageing stock is the only stock that means anything.
Both perspectives are legitimate and they do not substitute for each other. The mistake is not using stock, it is labelling it as activity. A table titled “Recruitment — September” that actually contains a snapshot from 30 September is a false claim, even if every figure in it is correct.
How you ask for the right report
When you request a report from a vendor, from IT or from a system, the phrasing decides what you get. “I want a recruitment report for September” produces, in nine cases out of ten, a stock report labelled with a month.
| What you want to know | How you ask | What you check on delivery |
|---|---|---|
| Where the process is stuck now | The position as at date X, by stage | The sum across stages equals the total |
| How much was done in September | How many transitions occurred between 1 and 30 September, by type | The sum can exceed the number of people |
| How long each stage takes | The mean and median duration between transitions, per stage | The median is there, not only the mean |
| How it changed against last year | The same transitions, the same month, the previous year | The periods are equivalent, not consecutive |
The second column is all you have to say. The word that makes the difference is “transitions”: it signals that you want dated events, not a current state — and it is the only way to get a flow report out of a system that can produce both.
How do I build a flow report if my system does not keep history?
You cannot, retroactively. Flow can only be calculated if every state change was recorded with its date. If the system does not do that, the first step is to start — from today onwards, not backwards.
Why can I not simply compare the stock at the end of two months?
Because the difference between them is a net result, which hides the volume. A stock staying at 12 can mean nothing happened, or that 30 came in and 30 went out — two completely different situations with the same figure.
Reports explicitly separate the snapshot from the period’s activity
You see in one place where the process is stuck now and in another how many passed through each stage this month, without rebuilding the history from memory.
You can create an account in a few minutes and use every module for 7 days, no card required.