Setting up time tracking in Bitrix24: where it breaks
Time tracking in Bitrix24 is most often enabled formally: the tool is there, but data gets into it manually.
Employees continue to log hours in spreadsheets, the manager transfers them into the system closer to calculation, and timesheets are not calculated automatically — instead of a single source of truth, you get another file with discrepancies.
Setting up time tracking in Bitrix24 begins not with checkboxes in the settings, but with answering the question of where each number in the timesheet comes from.
First break: schedule vs actual. The schedule is set up once during implementation, while vacation orders, transfers, and shift mode live separately, so the norm is calculated using an outdated template and a production calendar that no one has updated.
Hours match in the report only after manual reconciliation, and manual time entry nullifies the point of automation: an error in one line triggers a recalculation of the entire month and an export to 1C.
Second break: overtime. It surfaces on calculation day, when there is no longer anything to confirm it with: the start and end of the day are not closed, time in tasks is not recorded, the manager's approval left no trace. Disputed hours have to be confirmed retroactively, and some of them are simply lost.
The price in both cases is the same: calculation is delayed by days, trust in the timesheet falls, and tracking again drifts back into spreadsheets. Below we break down how this is closed with the system's standard tools.
What changes after implementation: effect in measurable numbers
Before implementation, the timesheet is assembled manually: managers send edits in chat, HR consolidates them into a common spreadsheet, accounting reconciles them with schedules. Closing the period takes several days, and any edit after submission triggers a new approval cycle.
After setting up automatic time tracking, data is born in the system: the employee clocks in, absence and overtime requests are approved in the same loop, and the timesheet is assembled from actual events.
The share of manual operations drops severalfold. The HR specialist stops transferring marks from journals and reconciling them with the schedule line by line — they work with exceptions: a missed mark, work on a day off, a rejected request.
Reducing manual timesheet entry also removes the main source of typos: someone else's shift schedule, a duplicated shift, an incorrect date.
Control of overtime and lateness stops being a one-off review at the end of the month. Rules set the threshold and approval procedure in advance; accumulated hours are visible to the manager during the period, not after the fact. Disputed situations are resolved before calculation, not after payment.
Payroll calculation accuracy rests on explicit rules: the time type, coefficient, and allowance are described once and applied equally to everyone. Every number in the accrual retains its source — a mark, request, or approved deviation — so resolving discrepancies takes minutes.
Period close is reduced from days to hours, and the class of errors "data did not match the schedule" disappears entirely, because the discrepancy simply cannot occur.
Shift, flexible, and summarized schedules: comparison
The tracking mode in Bitrix24 is set for the link "employee — calendar — rule," so security guards' shifts and a project team's flexible day can coexist in one company.
The problem starts when all modes are described with one schedule: overtime is not counted, and undertime surfaces upon dismissal.
Below is a comparison by what each mode actually covers and where its limit is:
| Mode | When it fits | Limitations and what to agree additionally |
|---|---|---|
| Shift schedule | Continuous processes: manufacturing, security, support with night windows | Two shifts in a row are not allowed, the schedule is issued in advance, shift swaps only via request |
| Flexible schedule | Project and office teams with a fixed core of the day | A start and end window is needed, plus a rule for carrying undertime to the next period |
| Summarized working time accounting | Seasonal peaks, rotations, crews where the weekly norm cannot be maintained | The norm is calculated for the accounting period; the procedure for calculating overtime and compensating it is fixed in the policy |
| Irregular working day | Managers and specialists who are occasionally engaged outside the schedule | This is not a tracking mode but a basis for additional vacation; hours are still recorded |
The main fork is summarized accounting: it does not cancel the schedule but moves the point at which the norm is calculated. Overtime becomes visible at period close, not at the end of the week, so the policy describes in advance how it is compensated — time off or pay.
An irregular working day is introduced in the hope of removing hour control — in vain: it only gives the right to additional vacation, while arrival and departure are still recorded in the timesheet.
We transfer the existing labor regulations into schedule settings, not the other way around — then during an audit the setup and the document match.
Work order: from process scheme to pilot operation
Time tracking is not enabled with a single switch: it rests on an agreed scheme of schedules, roles, and rules. Below is the route our engineers follow for a project so the portal works according to the company's policy, not against it.
- Audit of time tracking processes. We analyze how hours are recorded today — timesheets, spreadsheets, correspondence — and who approves overtime and time off. The output is a role map and a list of discrepancies between the policy and actual practice.
- Scheme of schedules and rules. We approve schedule types, shift boundaries, deviation thresholds, and the approval procedure. Until the document is approved, setup turns into endless edits.
- Portal preparation. We configure departments, roles, and access rights, and reconcile the employee directory with 1C: duplicates and different spellings of surnames break reports.
- Bitrix24 setup stages. We implement the selected schedules, check-in methods, reminders about unclosed shifts, rules for remote and mobile employees, checking that new conditions do not conflict with existing ones.
- Testing on real scenarios. We run through lateness, work on a day off, time off, sick leave, and transfers between departments. We close edge cases before pilot operation, not after.
- Pilot operation. We launch tracking in one department, reconcile the numbers with the previous method, collect managers' comments, and refine the rules — usually over one or two payroll periods.
- Training and handover. We show managers and HR how to close the period and read reports, and provide instructions describing the logic of the settings.
Each stage ends with a document or a verifiable result, so entering pilot operation leaves no open questions.
Handover kit: configuration, schemes, policies, accesses
After launch, you are left not with an enabled portal section but with a working kit: configured scenarios, fixed rules, and documentation by which HR and managers close periods themselves.
We test the kit on a pilot group — if the policy diverges from real routes, we correct it before handover.
- Tracking scenario map — which time types are recorded (arrival and departure, breaks, remote work, overtime) and by what means they are entered.
- Working time tracking policy — day boundaries, lateness tolerances, deadlines for submitting absence requests, and those responsible for each operation.
- Approval routes — chains for vacations, sick leave, time off, and overtime, including escalation if the manager does not respond on time.
- Access rights matrix — roles of employee, manager, HR specialist, and payroll specialist: who approves, who sees the department summary, who only reads.
- Employee instructions — clocking in and out, absence request, correcting an erroneous mark, with references to portal screens.
- Instructions for managers and HR — approval of requests, export of data for a period, manual adjustments and their justification.
- Period close policy — the date for locking results, actions with unclosed marks, the procedure for edits after close, and who confirms them.
We provide the data transfer scheme to the accounting system as a separate document: export composition, control points, and the procedure for discrepancies.
Case: schedule and vacation changes without manual edits
At a service company with about 120 employees, schedules changed almost daily: substitutions at sites, unscheduled vacations, shift transfers.
Requests arrived in messengers and email, the HR specialist manually edited schedules in Bitrix24, and collected timesheets in separate spreadsheets by the end of the month.
What it was like
By period close, discrepancies accumulated: some substitutions did not make it into tracking, overtime surfaced after calculation. Reconciliation took three days, disputed timesheets were recalculated again, and employees did not see their actual hours until the very payment.
What was changed
The schedule change request was moved into a form with a business process: the employee creates a request, the manager approves it, and the approved data automatically rewrites the schedule in the card. Vacations followed the same route — with checks for shift overlaps and remaining days.
The timesheet is assembled automatically from shift start and end marks; deviations from the schedule — lateness, incomplete shift, overtime — are flagged immediately and sent to the manager for confirmation.
Export to 1C for accounting is generated based on the closed period, without manual assembly and transfers between spreadsheets.
Two months later, month close took four hours instead of three days, and the share of timesheets with manual edits fell from the majority to isolated cases.
Substitutions are tracked on the day of the event, not retroactively, and the HR specialist stopped being a bottleneck on every schedule change.
What to do if Bitrix24 is already implemented but timesheets are still manual?
The platform is implemented, but timesheets are still assembled in spreadsheets — the reason is usually not Bitrix24 but the fact that time tracking is not configured by department.
There are no work schedules or production calendar, norms are not set, managers do not have rights to confirm the period — the fact settles in tasks and chats but does not get into calculation.
There is no need to switch the whole company at once. We start with one department: configure schedules and norms, give the manager rights to confirm the period, and collect worked time from tasks and deals. Manual entry remains as an exception — with justification visible in the report.
Until the results match, both methods work in parallel: the system exports worked time into the familiar spreadsheet format, accounting reconciles it with manual data and calculates payments according to the previous rules.
The discrepancy at this stage is useful — it shows unconfigured areas earlier than payroll starts being calculated from them.
Then departments are connected one by one, each from its own payroll period: manual entry is closed for that department, not for the whole company, so calculation does not stop in any week.
Separately, we check access separation — the employee sees their own hours, the manager sees their department, HR and accounting see the summary.
This order removes the main risk of transition: a dispute about numbers on period close day. We are ready to analyze your department structure and propose a connection sequence.
Data migration, access rights, and schedules: frequently asked questions
Before the start, the same technical questions almost always come up: what to do with history from spreadsheets, how to separate rights, whether the link with payroll calculation will break, and how the portal will behave after a platform update. Below is how this is solved in practice.
How to migrate history from spreadsheets?
We export employee directories, departments, schedules, and past marks, match them by employee IDs, and send disputed rows for reconciliation in a separate report. Loading proceeds in batches with a log: an interrupted import restarts without duplicates.
How to separate the rights of department managers?
The role is tied to the company structure: the manager sees their department and nested ones, approves absences, and notices deviations for their employees. HR and payroll specialists get full access, while regular employees get only their own marks.
How to link tracking with 1C:Zarplata?
Approved timesheets and deviations are exported to payroll according to the policy, and employee directories are synchronized in both directions. Discrepancies in employee IDs and departments are caught before export, not after accrual.
What happens during a platform update?
We install updates first on a copy, run checks on schedules, rights, and exports — and only then on the production portal. Customized scenarios are kept separate from the core, and a backup allows returning to the previous state.
Let's discuss the task and come back with an estimate and plan
The estimate of setup timelines rests on facts, not assumptions. If we do not have a snapshot of current tracking, the implementation plan is built on guesses and breaks at the first discrepancy with calculation — most often on overtime or summarized accounting.
To make the estimate substantive, it is enough to send:
- Current work schedules: shift, flexible, summarized accounting, holiday transfers. They are used to configure overtime thresholds and accrual rules.
- Department composition and role matrix: who clocks in and out, who approves vacations and sick leave, who has the right to edit time retroactively.
- Samples of timesheets for two or three closed periods — they show the actual summary format, not its description in the policy.
- Integration points with the calculation system: which hours, allowances, and deductions go outside and in what form.
- Deviation policy: lateness, undertime, work on weekends, business trips — what requires separate approval.
- Source of the employee and org structure directory, as well as the frequency of its changes.
- Requirements for access and personal data, including the retention period for marks.
This set is enough to assemble a staged implementation plan, show bottlenecks before the start, and come back with an estimate of setup timelines.
It is faster to discuss the time tracking task using your files than general questions: a short review of the data structure removes most of the uncertainty before work begins.