From biometric punch to payroll line: getting the integration right in SuccessFactors Time Tracking.

Why 80% of payroll disputes start here

Look at the root cause distribution of any mature SAP payroll programme and a pattern shows up. Engineering errors in the payroll engine itself are rare — payroll vendors spend decades refining the calculation logic. Configuration errors in pay element setup are more common but get caught in parallel runs. The dominant cause of post-go-live disputes — across the customers we've seen — is upstream: the time data that arrives at the engine is wrong.

That is not a payroll problem. It is an integration problem. A biometric reader produced a punch. Something happened between the punch and the payroll calculation. By the time an employee disputes a payslip line, the trail back to the original event is cold.

Three reasons this is structurally hard.

• Devices are noisy. Fingerprint reads fail, badge readers double-scan, employees forget to clock out. The raw stream of events is not the truth.
• Mapping is multi-step. A punch becomes a shift, a shift becomes an attendance record, an attendance record becomes a time account input, a time account input becomes a payroll line. Each step is a chance to drift.
• Reconciliation happens late. Most integrations reconcile at month-end. By the time HR sees an anomaly, the employee has already left for the day.

The mapping problem — punches to schedules to time accounts

A clean biometric integration into SuccessFactors Time Tracking has to make four decisions on every event.

One: whose punch is this? Device-side identity must map to a SuccessFactors person. Fingerprint templates, badge IDs, face-recognition vectors — none of these are SF identifiers. The mapping has to be authoritative and current — a transferred employee whose badge ID hasn't moved is a recurring incident.

Two: against which schedule? The punch occurred at a time. The employee's schedule on that day tells us whether they were on shift, on overtime, on a rest day, or working a make-up. A punch is meaningless without a schedule. Schedules in SF Time Tracking live as work schedule assignments — they are the lookup.

Three: which time type? A regular shift in-punch creates one kind of time account input. Overtime in another. Sick time, on-call, allowance-eligible hours — each has its own time type. The mapping has to be evaluated at ingest, not patched at month-end.

Four: which approval state? Some events need manager approval. Some don't. The integration has to know which is which, route accordingly, and pause the downstream flow if approval is missing.

Resolving missing punches without manual intervention

Missing punches are the single largest source of dispute volume. An employee forgets to clock out. The device doesn't read their fingerprint cleanly. The badge is forgotten at home. The integration sees the in-punch but never sees the matching out-punch.

Three patterns we've seen fail.

• Default to the scheduled time. Assume the missing punch happened at the scheduled start or end. Works on day one. Fails the first time someone works overtime, leaves early, or shows up late. Creates payroll lines that look correct but aren't.
• Hold the record indefinitely. Wait for a human to resolve. Works for a small team. At 2,000 employees it creates a queue HR cannot clear.
• Drop the record. Ignore unmatched events. The employee loses pay, then disputes the payslip.

What works: surface the missing punch the same day, route it to the employee's manager for resolution, and pause downstream processing for that record until resolution happens. The integration has to know how to wait. It has to know when waiting becomes a blocker. And it has to close the loop before the time evaluation window closes.

The Time Connector approach

Time Connector is the SAP-certified solution we ship for this problem. The architecture is intentionally narrow. Three responsibilities — and nothing more.

• Normalise events at ingest. Every device-side event is translated to a canonical event shape — person, timestamp, location, type, raw payload. The downstream pipeline operates on the canonical form, not on per-device dialects.
• Apply per-site rules. Each site's schedule patterns, grace windows, overtime treatment, and break policy are codified once. New rules are configuration changes, not code.
• Post to SuccessFactors Time Tracking through standard OData. No middleware, no point-to-point custom layer. The records arrive in SF as normally-shaped time account inputs.

That last point is load-bearing. The payroll engine sees inputs that look the way SAP's standard expects them to look. Time evaluation runs unchanged. The downstream is clean.

Three customer outcomes

Customers anonymised; figures verified pre-publication.

• A KSA retailer, 4,200 employees, 180 stores. Pre-Time Connector: 6.4% of payslips received a query in the first month after go-live. Post: 1.1% in steady state. The HR team redeployed two FTEs from reconciliation work to onboarding.
• A construction group, 2,800 site workers across 14 projects. Pre: project cost allocation lagged payroll by two weeks because attendance came in late. Post: cost allocation runs within 24 hours of payroll close.
• An F&B chain, 1,600 employees across 90 outlets. Pre: month-end reconciliation took five working days involving four people. Post: month-end reconciliation runs in half a day, by one person.

Where to go next

If your time-to-payroll path involves a spreadsheet — or a screen-scraping bot, or a middleware layer that nobody wants to touch — the conversation starts with two artefacts. Your current device inventory and a month of payroll query volume. We can map them against a Time Connector deployment in 30 minutes.

See the Time Connector product page for the device catalog and architecture detail, or talk to our team directly.