One Setting, Two Requirements

A reader on a door and a reader on a clock are doing different jobs with the same hardware. One decides whether to admit a person to a space; the other decides whether to write a line in a record.

The setting discussed in “One Setting, Two Requirements” should be tested against real people and real exceptions rather than accepted as a vendor default. For teams researching hourly timesheet template, this workforce platform can supply time and project context, while biometric thresholds remain a separate decision with written ownership, accessibility checks and human review.

Configured as one estate, they get one setting, and the setting comes from the stricter requirement. That is defensible for the door and quietly expensive everywhere else.

For an independent benchmark relevant to “One Setting, Two Requirements”, consult the FASB accounting standards. Use it to test notice, accessibility, security, recordkeeping, retention and exception handling against the real operating process rather than treating a device report as self-explanatory evidence.

Why the stricter requirement wins

Because the consequences of its failure are easier to describe. A stranger in the building is a scenario anybody can picture; a payroll entry that had to be made by a supervisor is not.

So when the installer asks what sensitivity is wanted, the answer comes from whoever is thinking about doors, and nobody in the room is thinking about the two hundred refusals a year that the answer implies.

What a time clock actually needs

Enough assurance that the record is attributable to the person named on it. Not certainty — no record anywhere in an organisation is held to that standard — but enough that the entry can be relied on and that casual substitution is prevented.

That is a looser requirement than keeping an unauthorised person out of a room, and it is supported by things a door is not: corroborating records, a supervisor who knows who is there, and the fact that an error is recoverable because it is only money and it is auditable.

Per-device settings

Most modern systems support a threshold per device or per device group. It is rarely used, and using it is a configuration change rather than a purchase.

The arrangement that follows is straightforward: doors at the security setting, clocking terminals at the recording setting, both written down with the reason. Where the same physical reader does both — the turnstile that admits and records — the choice is to accept the tighter setting or to add a separate clocking terminal inside, which is the cleaner answer and costs a unit.

The turnstile case, which is the awkward one

A turnstile that both admits and records is doing the two jobs in one transaction, and the record it produces is a by-product of the admission decision.

That is why so many sites have a clocking record that is actually an access record. The person who was refused at the turnstile and admitted by the guard has no time entry at all, because the entry only exists when the turnstile opens. The fix is not a setting; it is a terminal that records separately from the thing that admits.

Who has to be in the conversation

Whoever owns security, whoever owns payroll, and whoever will be standing at the terminal at shift change. Three people, one meeting.

The output is two numbers and a sentence of reasoning, which is more governance than this decision has received on any site where it has been left to an installer. It also means that when the refusal rate is raised six months later, there is a decision to revisit rather than a default to discover.

The thing to check first

Whether the estate is actually configured as one. Export the device list with the threshold against each. On a site with a dozen readers it is common to find several different values, set at different times by different engineers, with no record of why.

That variation is itself the finding. It means the setting is not an expression of anybody's risk appetite; it is an accident of installation order, and the refusal rate at any given door is a consequence of which week it was commissioned.

The reader that records a door

There is a quieter version of this problem. Where the clocking record is generated by an access event, every access event becomes a clocking event, including the ones that are not arrivals: a cigarette break, a trip to a vehicle, a delivery taken at the gate.

The system then applies rules to a stream of events that mean several different things, and the resulting hours depend on logic nobody has read. Separating the clocking terminal from the door is the clean answer; where that is impossible, the rule set deserves an hour of somebody's attention, because it is currently deciding pay.