Working without a network

The honest overview

The app is in preparation, but not yet submitted to the stores. Until then, the browser and the terminal carry everyday work without a network — with the limits set out below.

How offline recording works in principle

All three methods — app, browser, terminal — follow the same rules. That explains why nothing arrives twice:

1. When you clock in or out without a network, the clock event is saved locally on the device.
2. The device visibly shows that clock events have not yet been transmitted (“2 clock events waiting for network”).
3. As soon as there is a connection again, they are sent automatically — in the order of the clock time.
4. Each clock event carries its own identifier. If the same clock event is transmitted twice — for example because the connection drops in the middle of the process — the server recognises this and creates it only once.

Browser: the queue

The clock-in page in the browser buffers clock-in and clock-out when there is no connection. What you need to know:

• The page must already be open. Zeitflex does not store pages with business data on the device — a cached timesheet from yesterday would look like the truth. Anyone who reloads the app or signs in again without a network therefore sees the “No connection” page. Anyone who already has the clock-in page open keeps clocking.
• The button shows the state including the waiting clock events. After an offline clock-in it says “Clock out”, even if the server does not know anything yet.
• Transmission happens by itself. On Android even when the browser tab was closed long ago. On the iPhone it happens as soon as the page is next loaded or comes back online — so briefly open the app there once you have reception again.
• You can see what is still missing. The status line shows the number of waiting clock events; empty means: everything has been transmitted.

Breaks cannot be booked in the browser without a network — the queue only knows clock-in and clock-out. With a network, you book a break by clocking out and clocking in again with Break; a break not recorded without a network is added later by management.

Terminal without a network: 72 hours

The wall terminal is built for the warehouse, the basement and the building site — in other words exactly for places without a network. It also starts without a connection after a power cut and shows the person tiles from its last known data.

• The data lasts 72 hours. A weekend plus a public holiday does not bring the terminal to a halt. After three days without a network it no longer shows tiles, but the instruction to note clock-in and clock-out times by hand and have them added at the office. Anyone without a network for that long has an infrastructure problem that a tablet silently carrying on would only hide.
• From 12 hours on, the age is shown. After a night shift the data is from the previous day — normal, but the terminal says so. Anyone hired after the terminal last had a network is missing from the tablet and notes their times on paper.
• Clock-in and clock-out only. Breaks go through the app or the browser.
• Badge only with a network. Without a connection the Clock in with badge button is locked; clock in with the PIN instead. Anyone with only a badge notes the time and reports it to the office. More under Clocking in and out by phone, tablet or browser.
• The PIN is carried along sealed. Without a network the terminal cannot check whether the PIN is correct. It encrypts the input so that only the server can read it — there is never a PIN in plain text on the tablet, not even as a hash. It is checked on upload.
• Time yes, attribution with reservation. If it turns out on upload that the PIN was wrong or could not be checked, the clock event is still created — work actually done must not disappear because of a mistyped digit — but marked as unverified, and the tablet tells the person to report to the office. The time is recorded and included in payroll, but stays under reservation until management approves it or confirms it explicitly at month-end closing. A human decides this, not software — see the section “When the tablet reports ‘PIN not confirmed’” further down.

When the server rejects

Most waiting clock events are simply accepted on upload. In some cases the server rejects them — and then the rule is: the server wins. A rejected clock event is not retried and not silently deleted. It stays in a red box until the person has acknowledged it, with the notice that it was not counted.

The table lists every reason for which an uploaded clock event is rejected, together with the sentence the device shows. The first eight reasons apply to every method — browser, app and terminal. The last three name the method they apply to.

Two cases in which no rejection arrives at all

The sentence “visibly rejected once” above applies to the browser and the app. On the wall tablet there are two cases in which the server turns down the whole batch instead of individual clock events — the tablet then receives no result per clock event, and no red box appears either:

• Two events with the same identifier. One batch carries up to 50 clock events from several people; a single duplicated identifier turns down the entire batch (“Two events in this batch carry the same identifier. The batch was not applied — please contact the office.” — the tablet does not show that sentence, though). Nothing is lost: the tablet has received no acknowledgement, keeps everything and carries on clocking as usual — it is only that nothing arrives until someone at the office looks into it. The only visible sign is that the status line says “Online” while the number of waiting clock events stays where it is. The tablet also cannot resolve this batch by itself; that is why the server's message says “please contact the office” rather than “try again”. Contact the office, have the times added, and report the device via support.
• An error while saving. Nothing is acknowledged then either. The device keeps the clock event and tries again next time — that is deliberate: losing working time would be the worse outcome, and the server recognises by its identifier what has already arrived.

In all cases the way forward is the same: management enters the time in the timesheet via Add late entry, with a reason. How this works is described under Correcting a forgotten clock entry.

The terminal response “PIN not confirmed” is not a rejection: the time has been created, just unverified. What that means is explained in the next section.

When the tablet reports “PIN not confirmed”

The tablet accepted the clock event without a network and carried the PIN along sealed. When the event arrived, the server could not establish that it really was the person on the tile who clocked in. The reasons that occur:

• The PIN entered was wrong — usually a mistyped digit.
• No PIN was set for the person.
• There were too many failed attempts for this person on this device.
• The tablet could not seal the PIN at all (no secure context in the browser).
• The sealed package could no longer be opened when it arrived — because it is damaged, because the server key was changed in the meantime, or because someone moved it onto a different person.

In each of these cases the time is recorded. Its note carries a marker that is always stored in German and begins with “[Offline am Terminal erfasst” (“recorded offline at the terminal – PIN not confirmed”), and it is marked as unverified.

For employees: what it means and what you do

• Your time is there. You do not need to clock in again or hand in anything on paper.
• Report to the office and say whether the clock-in and clock-out are right. Management then approves the entry or corrects it.
• It wasn't you? If you did not clock in at that time at all, say so explicitly — then someone else clocked in on your tile, and management needs to know that before it closes the month.
• If it happens often, ask management for a new PIN (see I can't get into my account).
• Was your time “not recognised”? Then management has decided that this clock entry did not come from you. You receive a message about it in Zeitflex — the same bell that carries leave and correction decisions — including the reason. If you have push switched on, the notice reaches your device straight away as well. Only clock entries whose clock-in was booked without a confirmed PIN can be affected — never a break, and never a row from before September 2026.
• Do not rely on the bell — rely on the row. A message is **deleted 90 days after it was created, read or not, and the bell only shows the 20 most recent** ones. So in a busy business your message can slide down the list, and after a quarter of a year it is gone. The lasting evidence is something else: the original record is not deleted, only superseded. In your timesheet the row stays, clearly marked and struck through, with the date, the name and the reason, and with no hours in the total. The same goes for the monthly sheet and the audit folder. So you still have something in your hand long after the message has gone.
• And if you did work after all? Object inside the application, at the entry itself: open that day in your timesheet and choose “I did work this time” at the struck-through entry. A reason is required; that creates a request which the management that closes the month sees and decides — the owner or your shift lead; Zeitflex itself does not decide this. If management agrees with you, they withdraw the rejection: the same entry then counts again, no second version is created, and the hour counts as working time again. Two limits of that button, so you do not look for it in vain. First, it is only shown while the month of that time is still open; once the month is closed (locked) it is gone, and an objection then only works outside the application — through management, see Corrections after locking. Second, accounts with a management role do not see it: where a manager's own time has been rejected, **another manager withdraws the rejection at the entry itself** — nobody is a witness in their own case. Entering the time again comes afterwards, not before. Only when withdrawal is no longer possible does management enter the time again with a reason (see Correcting a forgotten clock entry). That order is not a formality: once an added entry covers the same span, withdrawal is blocked permanently — the section “For management” further down says the same thing to your management. If you get no further there, your works council is the place to go, where one exists (Works council and co-determination) — and you can always pull your own record yourself with the data access report (see What Zeitflex stores about me).

And if your objection was granted but there was nothing left to withdraw? There is an answer for that too, instead of the request sitting on “approved” while nothing ever happens. Zeitflex then closes it with a named outcome, records the step in the log and sends you a message about it. Three situations, three different answers:

• “Time added in the meantime”. The hour is already back, just by a different route: management recorded it as a new entry instead of withdrawing the rejection on the old one. Your objection is therefore fulfilled — the time is in your timesheet on that day as a new entry. How it stands there today is shown on that entry. The old, struck-through entry stays next to it; it is your evidence that the rejection happened, and it still counts in no total. Look at the new entry: if its clock-in and clock-out do not match what you asked for, submit a correction on it.
• “Time partly added in the meantime”. Another entry now covers part of the same span in your timesheet — but it does not cover your objection in full. The message therefore names both spans: the one that was rejected, and the one that stands there today. The rejection still cannot be withdrawn, because the same hour would otherwise appear twice in the record. Your objection is therefore not closed, and the request stays visibly open — Zeitflex does not claim a close that never happened. **There is no button in the application that deals with the remainder.** Your management looks at the day and decides; whether a late entry is possible depends on whether the month is still open — if it is not, the same route applies as in the next point.
• “Month locked in the meantime”. Here the hour does not come back through this request: the payroll month was closed before the withdrawal had been carried out, and from then on Zeitflex refuses it. The outcome says so and claims no settlement. Once a month lock has been set, Zeitflex does not take it back — the owner cannot either, and whether payroll has already been run makes no difference. What helps is a late entry in the current month: management records the hour there afresh, makes the connection to the old day in the reason and informs the payroll office. This single route is set out step by step in Corrections after locking — tell your management or the payroll office which day it is about. Your evidence remains the struck-through entry in the timesheet.

For management: find, approve, confirm

• The time is included in payroll, but under reservation. It is deliberately not held back: after month-end closing it could never reach payroll again, and hours actually worked would be lost. So unverified time counts in your hours like any other. What remains is a marking — and a month can only be closed once you have done one of two things: approve that time, or confirm it explicitly at month-end closing. Releasing a row removes its marking; confirming at closing leaves it in place, as proof of origin in timesheet, monthly sheet and audit folder.
• Approve it. In the person's timesheet, like any other time. That settles the marking for other people's times. Approving applies to the person's open entries in the selected month — so look at the unverified entry first. Times of people with a management role are approved by the owner. Your own times are approved along with the rest but keep their marking: the timesheet says so explicitly in the prompt before approving, and those times come up again at month-end closing.
• Or one row at a time. In a person's timesheet, an unverified row carries a “No PIN” mark. While that month is open, a “Lift reservation” button sits beside it and settles just that row, without touching their other open entries. That is safer. In a locked month no button appears.
• On your own row nobody lifts it — not even the owner. Is a marked time your own, no button appears but a note: “Your own time — confirmed at month-end closing”. That holds for every role, explicitly including the owner account: a PIN answers who clocked in, and nobody can witness that about themselves. Your route is month-end closing, where such a time appears as “your own time” and your confirmation is logged with name and timestamp. Nothing is lost: those hours are booked and paid like any other working time.
• What this means in a business with only one management account. Then no second person exists for your own times, and confirming at month-end closing is your own act. Zeitflex does not promise a check by somebody else — that would be a promise its software cannot keep. What it does deliver: a marking that stays, an explicit line in your closing, your confirmation in its log, and an origin that remains visible in timesheet, monthly sheet and audit folder. An auditor therefore sees both: no PIN was confirmed, and you confirmed it yourself.
• Confirm it at month-end closing. Whatever still carries the mark when you lock the month is listed by month-end closing under “wall-tablet records without a confirmed PIN” — per person, with days affected and total hours, not as individual entries. The month is only locked once you explicitly confirm that list. If the list changes after you confirmed it, your confirmation does not carry over to the new list, and you confirm again. To see a single row, open that person's timesheet first.
• Correcting does not lift the reservation. If the time is wrong, correct it with a reason. The marking stays afterwards, even if the correction brings a new note: a correction says when someone worked — the PIN says who clocked in, and that question is still open.
• Is only the time of day wrong? Then correcting it with a reason is your route: bring that row to the time actually worked. Your reason stays as evidence, and so does its earlier version. Before locking you must still approve that row or confirm it at **month-end closing**, otherwise the month will not close; confirming means “I have looked at it”, not “these hours were worked”.
• What if a person did not work at all? If you know for certain that this time was never worked — somebody clocked in at the tablet for another person — then please do not shorten the row to one minute. In the record that would claim one minute had been worked, and a forged record is worse than a clean “not recognised”. For that case the marked row in the timesheet offers the route “Do not recognise this time”. It is deliberately narrow, and every limit has its reason:
• Only where the CLOCK-IN itself was booked without a confirmed PIN. It appears solely on rows whose start came about without a confirmed PIN — and not on every row that carries the “No PIN” mark. The difference is not a detail: that mark is also set by a clock-out without a confirmed PIN, on a row that was already running. Where it is settled who clocked in, the route is absent.
• Rows from before the changeover stay out of it. Until September 2026, Zeitflex did not record separately which of the two halves was booked without a confirmed PIN. For older rows that cannot be said reliably in hindsight, and we do not guess here: those rows can only be corrected, the “do not recognise” route does not appear on them. Better no route than one that can be misused.
• Only on working time, never on a break. A break is unpaid time; taking it out of the row would lengthen paid working time instead of shortening it — the effect would be upside down. If a break is wrong, the route is a correction with a reason.
• Never on your own row. Four eyes, explicitly including the owner account — the same rule as for lifting the reservation: nobody can witness about themselves.
• Only with a reason, and fully logged. Who, when, why and which row goes into the audit log. Without a reason you cannot proceed.
• Only in an open month. In a locked month the closing has already run, and the route does not appear.
• Only on a finished time. For a still-running clock entry it is too early — while it is open it enters no payroll anyway. Wait for the clock-out, or have the person concerned discard their own running time.
• The record stays readable. Nothing is deleted. The original version is only superseded; what it recorded stays readable in the audit log and in the evidence — the duty to record working time (section 16 (2) of the German Working Hours Act) does not end because someone disputes a time.
• Visible in the evidence. In the monthly sheet and the audit folder the row remains, as “not recognised”, with your reason. A missing hour with no trace is worse in an audit than a named one.
• The person concerned is told twice — and the two last for different lengths of time. They receive a message in Zeitflex, the same bell that carries leave and correction decisions, including your reason; on top of that a push notification goes to their device, provided push is switched on and no personal quiet period is running. Both are the fast notice, not the evidence: a message is deleted 90 days after it was created — read or not — and the bell only shows the 20 most recent ones. The evidence is the row: it stays in that person's timesheet, struck through and marked “not recognised on … by … — …”, with no hours in the total and with the way to object next to it.
• And what these limits do NOT achieve. They keep the route narrow — they do not prevent misuse, and we are not claiming here that they do. The mark the route hangs on does not say “it is unclear who worked”, it says “the PIN for the clock-in was not confirmed”, and there are five reasons for that, only one of which is a wrong PIN; the other four are: a lock-out after the sixth failed attempt, a tablet without a secure context or server key, a PIN record that cannot be opened, and a person who has no PIN on file at all. So anybody with access to the wall tablet can produce that mark — six wrong entries are enough, and after that an honestly clocked shift with the right PIN carries the reservation. And anybody who wants working time to disappear does not need this route at all: **any manager can shorten any time in an open month to one minute by correcting it** — with no PIN mark and no second pair of eyes. What exposes misuse is therefore not how narrow the door is, but visibility: the row stays, the person concerned is notified, and the act is in the records and the audit log with name, time and reason.

Time that has not been recognised then drops out of the payroll figures and out of the set you have to approve or confirm at month-end closing — so it no longer holds up your closing. It does not drop out of the timesheet: it stays there, struck through and with your reason, for the person concerned as much as for you. The decision is not final: if it turns out the work did happen after all, the rejection is withdrawn at the entry itself — the same entry then counts again, and no second version is created. There are two routes for that, and which one applies depends on whose entry it is, not on who made the decision. If you rejected somebody else's entry and spot the mistake yourself, you withdraw your own decision at that same entry — with no request and no second pair of eyes, but with a mandatory reason; the act is in the audit log with your name, the time and that reason, and the person concerned gets a message. You use the same button when you agree with an objection. Where a manager's own time has been rejected, another manager withdraws the rejection at the entry itself: on your own row the button never appears — nobody is a witness in their own case, the same rule as for rejecting. So the second pair of eyes hangs on the entry here, not on the decision. Do not add the time back first. Once an added entry covers the same span, withdrawal is blocked permanently — otherwise the same hour would stand twice in the records and be paid twice. And what this means in a business with only one management account: the times of your staff stay withdrawable — the same account that rejected also withdraws the rejection at the entry. There is no second pair of eyes in that case, and Zeitflex does not promise one there either; what remains is visibility: the mandatory reason, the message to the person concerned, and the name and time in the audit log. That account's own time cannot be rejected there in the first place (on your own row the route never appears); if it still is, from a time with two management accounts, the withdrawal stays blocked and all that remains is entering the time again with a reason (see Correcting a forgotten clock entry); the rejected entry stays beside it, and both acts are readable in the records. Otherwise too, the time is only entered again when withdrawal is no longer possible, for example because the entry meanwhile has a newer version — in a locked month via Corrections after locking. So decide before you lock, and only when you really know.

What else you can do today

For building sites and routes without reception:

1. Have people clock in at the depot, where there is a network. Whether the journey from the business to the building site counts as working time is governed by the employment contract or collective agreement — Zeitflex does not decide that.
2. Or: open the clock-in page in the phone browser before setting off and leave it open. Then everyone clocks in the dead zone, and the transmission happens on the way back.
3. Or: note the times on a slip of paper and have management add them later. The way is described under Correcting a forgotten clock entry.

For businesses with unreliable Wi-Fi:

Connect the tablet terminal permanently to the network with a LAN adapter or give it its own SIM card. The 72 hours are a safety net for an outage, not for continuous operation: without a network the list of people becomes outdated, and the PIN check is postponed until later.

When Zeitflex itself is disrupted

Check the status page. It states in plain language which areas are affected and since when. If clocking is disrupted: anyone who has the clock-in page open keeps clocking into the queue; everyone else records on paper (name, date, start, end, break) and adds the times as soon as everything works again.

Frequently asked questions

I clocked in in a dead zone, then clocked out on the computer. What counts?

Both count, as a rule. If the server objects when you clock out (“no running entry”), the page first uploads everything waiting — your offline clock-in goes along and is accepted, after which the second press on Clock out takes effect. Only if the contradiction still remains afterwards is exactly the one contradicting clock event marked as undeliverable and shown to you; management then adds the time.

My clock-in was acknowledged and is shown as rejected later on. Why?

Because the clock-out of the same batch was rejected. A clock-in without a clock-out would otherwise remain a running entry — and a running entry holds up the month-end close for the whole business. The server therefore withdraws the clock-in it created in that same batch and pulls its answer from “applied” to rejected. The device then shows “The matching clock-out was not applied – this clock-in has therefore been withdrawn as well.” The working time is then recorded nowhere: have both the clock-in and the clock-out recorded together at the office as a late entry with a reason.

This works within one batch. If the clock-in arrived earlier and only a clock-out from a later batch is rejected, the clock-in remains a running entry and is resolved at the office.

The terminal shows “Data too old”. What should I do?

The terminal has had no network for more than 72 hours, and the list of names is therefore no longer reliable — someone might have left. Note clock-in and clock-out times by hand, have them added at the office and reconnect the tablet to the network — it then fetches the current list and uploads all waiting clock events.

Do I have to open my phone specially after getting back?

On Android, no — the browser uploads the queue in the background. On the iPhone, yes: open the clock-in page once as soon as you have reception again. The status line shows whether anything is still waiting.

I entered the wrong PIN at the terminal without a network. Is the time lost?

No. The clock event is created on upload and marked as unverified. Report to the office — management approves the entry, corrects it with a reason or confirms it at month-end closing. More under “When the tablet reports ‘PIN not confirmed’” further up.

Still stuck?

Get in touch via support and describe exactly where the network is missing. For some cases (depot without reception, basement, underground car park) there are solutions that have nothing to do with software. The ways to clock in and out are described under Clocking in and out — the options; adding times later under Correcting a forgotten clock entry.