Why the timesheet diverges from actuals
The chain breaks at the junction of three sources: the arrival check-in, the shift schedule, and the accounting rule.
An employee badged in at 9:07, his schedule has a shift from 8:00, and summarized accounting counts the deviation only at the end of the period — in Bitrix24 these are three independent facts that no one reconciles with each other.
Add night shifts, flexible schedules, transfers between departments within a month, and the production calendar — and the divergence between timesheet and actuals becomes the norm, not the exception.
Then manual timesheet maintenance comes into play. The responsible person exports the check-ins to a spreadsheet, compares them with shifts by eye, manually enters absences, and corrects the total.
Errors in hour accounting accumulate unnoticed: a request not closed on time, a forgotten sick leave, a shift assigned to the wrong department, overtime left in the access log and never making it to the payroll total.
The cost shows up during hour reconciliation by department. The manager sees one set of numbers, the payroll department sees another, and unaccounted overtime surfaces after the period is closed, when it is too late to change anything.
Up to two or three dozen employees this is tolerable; beyond that, reconciliation stretches over days, and the share of discrepancies grows faster than headcount — manual transfer simply does not scale.
The problem is not employee discipline, but the absence of a single rule by which check-ins turn into hours. Below we break down how this is resolved.
Effect of automating hour and overtime tracking
Automatic hour calculation is built on events, not manual entry. An employee clocks the start and end of a shift, breaks are deducted according to a defined policy, and night and holiday hours get their own coefficient.
The timesheet is filled based on actual work, not the manager's memory. Manual transfer of hours between spreadsheets leaves the process.
Separately, we configure reconciliation with access control systems: turnstile and badge system events are pulled into Bitrix24 and matched with employee check-ins.
A discrepancy, missing shift closure, or lateness goes into schedule deviations and is sent to the manager immediately, rather than surfacing at the end of the month.
The main effect is at period close. Previously, the timesheet was consolidated over several days in spreadsheets and reconciled manually; now hours are already calculated, disputed entries are flagged and await the responsible person's decision.
The overtime report is generated from the same data: you can see who has accumulated hours, how many, and over what interval.
The share of manual edits shrinks: duplicate entry, lost shifts, and incorrect hour category simply do not occur — the system takes them from a single source.
The class of errors that used to be found during payroll calculation is eliminated at the input stage, so recalculations after period close drop to almost zero. Deviations arrive together with the reason, not just the fact.
Methods of tracking: manual, out-of-the-box, customization
The choice of tracking method determines not the type of report, but how much manual work remains for HR and what will have to be maintained with each update.
The out-of-the-box time tracking module in Bitrix24 handles a regular five-day week, but hits limitations where shifts, night hours, and summarized accounting appear. Below are the options that are actually chosen on projects, and their maintenance cost.
| Option | When it fits | Limitations and what you maintain yourself |
|---|---|---|
| Manual entry | Up to 10 people, the same schedule, tracking needed for order rather than calculations | No hour norms or overtime, actuals diverge from the production calendar, summary is assembled manually |
| Out-of-the-box time tracking | Five-day week, a single schedule, simple reports on time worked are enough | Shift work and summarized accounting are configured partially; everything non-standard lives in spreadsheets alongside |
| Customization for shift schedules | Several shift schedules, night hours, overtime, hour norms by period | Your own branch of changes: carry-over during updates, regression checks at the junction with payroll calculation |
| External tracking system | Norms and attendance already live in the HR or accounting system, at the access point | Two data systems, exchange, and discrepancy resolution during synchronization failures |
Mixing methods is worse than choosing one: if some shifts are counted manually and some in the system, hour norms diverge, and disputed overtime surfaces during period close.
Therefore, before configuration we fix where the norm is calculated, where actuals are, and by what rule they are reconciled.
A separate axis is compatibility with what is already implemented. Customization for shift schedules does not cancel out-of-the-box reports and access rights, and an external tracking system can pull ready-made timesheets rather than replace them.
Describe how your shifts are organized and who currently calculates the norm — we will come back with an estimate and a plan for the chosen option.
How implementation in Bitrix24 proceeds: stages of work
The timesheet breaks not on the form, but on the rules: some employees have shifts, some have flexible schedules, and for some overtime is carried over into days off.
That is why we start implementation with an audit, not with interface configuration — otherwise the scheme will reproduce manual errors inside the system.
- Audit of schedules and rules. We collect current schedules, employee categories, rules for night shifts, holidays, overtime, and time off. Separately, we record areas where tracking is still done manually.
- Design of the tracking scheme. We determine which schedule types are needed, how deviations and hour norms are calculated, who can edit the timesheet and on what basis. We agree on the scheme before configuration begins.
- Configuration of shift profiles. We create shift profiles and schedules in Bitrix24, link them to departments, and configure rights for editing and manager approval of the timesheet.
- Pilot group of employees. We launch the scheme in one division with all occurring schedule types — from a five-day week to 24-hour shifts. Edge cases surface on a dozen people, not across the whole company.
- Reconciliation with actual data. We compare the calculation with already closed periods and analyze every discrepancy. While discrepancies exist, we do not move to production operation.
- Handover to operation. We train the responsible staff, hand over the edit regulations and rules for changes after launch: who approves a new schedule and how it enters the system.
Shift profiles, reports, and regulations: what remains in the system
Configuration is considered complete not at the moment the timesheet opens, but when the support service can maintain it without us.
That is why the handover includes not a single report, but a connected set: profiles, calculation rules, rights, closing regulations, and documentation.
- Shift profiles — day, night, 24-hour, and rotating schedules with individual norms; a new profile is assembled by copying and editing two parameters.
- Hour accrual rules — coefficients for night and holidays, overtime thresholds, automatic recalculation when a check-in is adjusted; we test them on closed periods.
- Access rights — roles of employee, department manager, and timesheet administrator: who makes edits, who approves, who sees only their own data.
- Period closing regulations — the sequence from reconciling check-ins and manual adjustments to locking the month and transferring data to payroll.
- Report exports — templates by employee, division, and period, a summary of deviations, and saved views that do not need to be assembled again.
- Integration with 1C — exchange of accruals with the payroll system, matching of reference data, and the procedure for resolving discrepancies.
- Administrator guide — examples of typical operations: add a profile, correct a check-in, unlock a period.
This set is the result of the work: the service closes the period according to the regulations, and comes back to us only for further development — new profiles or changes to calculation rules.
Case study: shift tracking in manufacturing — what changed
In a continuous-cycle area, four crews worked on a rotating schedule: day and night shifts, substitutions during sick leave, and overtime in peak weeks.
The timesheet was kept in spreadsheets — the foreman transferred check-ins from a paper log, HR separately reconciled them with the access control system, and discrepancies were discovered already at the payroll calculation stage.
Period close took three days: two specialists consolidated shifts, looked for overlaps, and reconstructed who substituted for whom. For every hundred people, several dozen disputed lines accumulated, and each required a written explanation from the foreman. The cost of an error was recalculation and re-approval after payments had already been made.
What was changed
Shift schedules were entered into Bitrix24 and linked to the production calendar: the norm is derived automatically, night and holiday hours get their own coefficient, and a substitution is processed as a shift transfer with history preserved.
Clock-in and clock-out records are pulled from terminals at the access point, and validation rules flag deviations — undertime, a double clock-in, or a missing clock-out.
The foreman sees only lines with discrepancies and confirms them in the interface; rights are configured so that he can edit his own crew but not the neighboring one. HR and accounting work with the same data set and do not reconcile two versions of the timesheet.
What the result was
Period close was reduced from three days to several hours, the share of manual operations fell by about two-thirds, and the number of disputed lines dropped several-fold — now you have to discuss not the entire timesheet, but individual cases.
The main effect is not speed: every shift now has an auditable trail, and the dispute “I worked the night shift” is resolved by records, not memory.
How the out-of-the-box timesheet differs from customization for shift schedules
The out-of-the-box timesheet in Bitrix24 handles a fixed schedule and a flexible schedule with a floating shift start, but not a shift cycle.
As soon as 2/2, 3/3, duty shifts, and night shifts crossing midnight appear, the standard mechanism stops matching the staffing arrangement, and hours start being added manually.
The limitations of standard tracking are structural: one shift per day per employee, the norm is calculated from the calendar rather than from output for the period.
Summarized monthly accounting is assembled by hand, a shift crossing midnight splits into two incomplete days, and a substitution is not linked to the colleague's absence.
| Option | When it fits | Limitations |
|---|---|---|
| Out-of-the-box timesheet without changes | Fixed schedule, stable staff | One shift per day, substitutions entered manually |
| Configuration and extension of the out-of-the-box module | One or two shift types, rarely changing rules | Edits accumulate, updates require calculation checks |
| Separate period tracking scheme | Several shift types, night shifts, substitutions, summarized accounting | Requires migrating part of the reference data and interfacing with payroll calculation |
The choice is determined by the number of rules and how often they change: while there are one or two shift types and they are stable, extending the out-of-the-box module is faster.
When there are several shifts, night hours, and summarized accounting, customization becomes overgrown with exceptions — it is more reliable to rebuild the scheme and count the period as a whole.
We check compatibility with current settings before the start: vacations, sick leave, orders, and exports to accounting must continue to work, and the totals must match.
Technical questions: integrations, rights, period closing
Practical doubts when configuring a timesheet are almost always the same: rights, terminated employees, migration of accumulated data, night shifts, and connection with the access point. Below are short answers without generic wording.
How to delimit rights to the timesheet?
We delimit by structure: a manager approves only their own staff, HR sees all divisions, and an employee sees personal check-ins. The right to edit and the right to approve are separated, and changes after approval are visible in the history.
What to do with terminated employees?
First we close the period and upload check-ins to the archive, then deactivate the account. History remains for reconciliation, and hours cannot be added retroactively to a closed month.
How to migrate accumulated data?
We match people by employee ID, transfer schedules, vacations, and sick leave, then reconcile the control period total with the previous tracking. We look for discrepancies before launch.
How to count night shifts?
A shift crossing midnight is not split: the norm is taken from the schedule, and night hours go as a separate type and a separate line in the additional pay.
How to configure exchange with access control systems?
Events from the access point are loaded into the timesheet and reconciled with the schedule; mismatches go into a report for review. If the system is unavailable, the check-in is entered manually.
Let's discuss your tracking scheme and come back with a plan
To come back with an estimate and work plan rather than generalities, we need a set of inputs — usually your HR or finance specialist gathers them in one short conversation.
The more accurately the current tracking procedure is described, the fewer edits will have to be made during implementation.
- current schedules: shifts, summarized accounting, flexible start of day, night and holiday intervals;
- deviation rules — lateness, overtime, time off, business trips, sick leave: how they currently get into the timesheet and who confirms them;
- company structure: divisions, managers, period approval procedure;
- roles and access: who needs entry, who only viewing, who closes the month;
- interface with related systems: whether export to 1C and another accounting system is needed, in what form, and how often;
- what exists now: timesheet file, internal rules, instructions — even if everything is maintained manually.
As a result, you receive a technical specification with agreed fields, formulas, and rights, a stage-by-stage work plan, and a preliminary estimate.
Then implementation follows: configuration of entities, checks on your real period examples, and an export reconciled with the accounting system — there should be no hour discrepancies.
After launch, ongoing support remains: if schedules or division composition change, we adjust rules, reports, and rights without rebuilding the solution.
Describe the task in a convenient format — a meeting, an email, or a short list of requirements — and we will come back with an estimate and work plan.