Time reporting from the field.

The hours arrive as texts on Sunday night. Somebody types them up on Monday. Nobody remembers whether it was three hours or three and a half, and nobody can show where the person was when the shift began.

The loss is not dishonesty. It is three ordinary things:

Recall rounds down. A day reconstructed on Sunday is a day of round numbers. The twenty minutes waiting for the customer to find the key, the second trip to the wholesaler, the forty minutes on a job that was quoted at thirty — none of it survives four days of memory, and all of it was real.

Paper does not reach the invoice. The materials are on a note in the van. The job is finished, the note is in a jacket, and the invoice waits for somebody to decipher the handwriting. What cannot be read is not billed at all.

There is nothing to point at. When a customer disputes six hours, a text message saying "6h tors" is not evidence. It is a claim, made after the fact, by the person being paid for it.

None of these are solved by asking people to be more careful. They are solved by making the report happen at the moment the work does, and by keeping what the phone observed apart from what the person claimed.

Time reporting the team will actually use is about the adoption half of this, which is the half that decides whether any of it works.

A shift starts when somebody presses a button. At that instant the phone is asked once for a position, and the reading travels with the entry.

Four decisions make that reading worth having.

The reading is taken at the tap, not when the report is sent. Taking it when a queued report finally reaches the server would record where the van was when it found a signal, which is a different place and a worse lie than no position at all.

Accuracy is rounded up, never down. The phone says a reading is good to within some number of metres. Claiming it is better than that would put somebody outside a fence they were standing inside.

The server decides, not the phone. The coordinates are compared against the job's service address on the server. A phone that could decide its own verdict is a phone that can be told to decide differently.

A missing reading is unknown, not outside. If the job has no service address, or the address has no coordinates or no radius, or the phone gave nothing, the entry records that there was no verdict. Recording "outside the fence" would put an accusation on the row on the strength of a field the office never filled in. "No position" and "probably somewhere else" are not the same statement. (The coordinates and the radius are set on the service address in the panel, where the coordinates can be fetched from the street address via OpenStreetMap.)

And the clock never waits on any of it. A denied permission, a phone indoors, a dead chip, location services switched off entirely: every one of them resolves to no position after eight seconds, and the shift starts anyway. An app that refuses to start somebody's day because of a permission prompt is an app they stop opening.

This needs saying plainly, because it is sold as a feature elsewhere.

A web app installed on an iOS home screen cannot read the phone's position while it is not in the foreground. There is no background geolocation for web apps on iOS. That is a platform limitation, it applies to every vendor equally, and no amount of engineering works around it. So an app of this kind cannot clock somebody in automatically when they arrive at an address. Not slowly, not approximately, not at all.

Anybody claiming otherwise is describing one of three things: a native app from the App Store, a feature that only works on Android, or a feature that only works while the phone is unlocked with the app open on screen — which is not automatic, it is just a tap you have not been told about.

What is delivered instead covers most of the value: the position is verified at the instant the button is pressed, and the server compares it against the job's address. What you lose is the arrival you did not mark. What you keep is a verdict you can stand behind, and a limitation stated in the sales process rather than discovered in month three.

The field app is a web app installed on the home screen. It opens without a signal, and clocking in and out queues offline; the rest of a visit — the checklist, photos, materials and the customer's signature — is sent when the job is completed, and that needs a connection. It is not a native app, and that is worth knowing before you buy rather than after.

What GPS clock-in can and cannot do goes through the platform detail.

Field work happens where the network is not. A van in a cellar, a house with metre-thick walls, a stretch of motorway. An app that answers "could not connect" to somebody trying to clock in teaches them to write the day on paper instead.

So a clock-in or a clock-out is never sent directly. It is written to a queue on the phone first, sent when there is a connection, and removed only once the server has acknowledged it.

Written before sent, always — even with a perfect signal. Sending first and queueing on failure leaves a window: the request is in flight, the app is killed, the work is gone. That window opens exactly when the network is bad, which is exactly when field work happens. Writing first costs a few milliseconds and closes it.

The queue drains serially, oldest first. These entries are not independent. A clock-out closes the clock-in before it. Sending them in parallel would be faster and would arrive out of order often enough to matter.

It stops at the first failure worth retrying, rather than skipping past it. Whatever failed is almost certainly the connection, and delivering later work while the thing it depends on is still queued is how a clock-out arrives before its clock-in.

Three answers mean the entry is finished with. A 409 from a clock-in means the server already has it — the request landed and the reply was lost, which is precisely what a flaky connection does. A 422 is a payload the server refuses once and will refuse every time. A 404 names a job that is gone. None of the three get better by being sent again, and retrying forever would pin the queue behind an entry that can never succeed. Everything else — a timeout, a server error, no network at all — is worth another go.

The time is the tap, not the sync. A queued clock-in or clock-out counts from the moment it was tapped, by the phone's clock, within sanity limits: not more than five minutes in the future, not more than a week back. The time it actually reached the server is kept beside it, and the timesheet flags any stretch that synced more than 15 minutes late, so a late sync is visible rather than silently trusted.

The queue lives in IndexedDB rather than in simple browser storage, because that is the storage that survives an iOS home-screen app being evicted mid-shift. What goes through it is clocking and nothing else: the checklist, photos, materials and the customer's signature are sent when the job is completed, and that needs a connection. Scheduling in an offline web app covers the same machinery from the planning side.

A reported hour becomes two documents read by people who were not there: an invoice and a basis for pay. So the row keeps three different things and does not blur them.

What the worker reported — the start, the end, the break.

What the phone said — coordinates, the accuracy the phone itself claimed, and whether the reading came from the satellite at all or was typed in. An entry typed in afterwards by the office is recorded as such, because a timesheet that cannot tell a clock-in from a correction cannot be audited.

What we concluded — whether it was inside the fence, or that there was no verdict to reach.

Storing only the conclusion would leave a dispute with nothing to re-examine. That is the whole reason for the split: three months later, "was Anna on site" is a question somebody answers by looking, not by trusting a boolean.

Two smaller decisions hold up the same way. The entry's minutes are computed when it is closed and written down, never recomputed on read — an approved timesheet that changes because a rounding rule was edited afterwards is one nobody can defend. And when an entry is approved, the hourly rate is copied onto it there and then, rather than read from the employee later. A pay rise in June must not rewrite what March cost.

Something else the queue gives you for free: each entry is stamped with an id and a time on the device at the moment the act happens, and that stamp is what orders the queue. A day reported from three basements arrives in the order it was lived, not in the order the signal came back.

An hour that reaches an invoice was agreed by somebody other than the person who reported it. That is the whole point of the approval step, and it is why approving is its own permission that a field worker does not hold.

The shape of it:

An entry closes as submitted, not approved. The worker is done; somebody else says whether the hours stand.

A week is signed off in one go. Approval takes a list of entries, not one at a time, because the real act is a manager going through Friday afternoon with deviations at the top.

Rejection is what makes a correction possible. An entry is sent back with a written reason, the reason stays on the row, and it becomes editable again by the person who reported it. Nothing is silently amended.

An approved entry cannot be edited or deleted. It is part of a run somebody else has signed. Correcting it means rejecting it first, which leaves a trace of why the number changed.

The bottleneck people actually complain about is not the approving. It is the chasing: hours that never arrive, so the invoice waits. Two things help more than a faster approval screen. Hours reported at the moment of work do not need chasing at all. And where hours are still outstanding, they are stated on the invoice basis rather than silently left out, so the office knows what it is waiting for before it sends anything.

Approving time without creating a bottleneck is about running this weekly without it becoming somebody's Friday.

Be careful here, because this is the area where scheduling software is most often oversold.

What exists. Reported time carries a kind: ordinary work, travel, or overtime. The person reporting chooses it, or the office sets it afterwards. It follows the hour all the way through: on the invoice basis and in the export, an overtime hour is labelled as overtime and a travel hour as travel, and travel never carries a ROT or RUT deduction. Employment type is recorded per person — salaried, hourly, contractor — because whoever runs payroll has to know.

What does not exist. Nothing computes an OB supplement. Nothing reads your kollektivavtal. Nothing decides that an hour was overtime because of when it fell, or applies a percentage because it was a Sunday, or checks dygnsvila. There is no rule engine for any of that, at any tier.

That is a deliberate boundary rather than an unfinished feature. An OB supplement depends on which agreement covers the person, which clause the local agreement changed, and how the week is counted — and getting it 95 percent right is worse than not doing it, because the 5 percent is invisible until somebody's union representative finds it.

So: the hours, their kind, who approved them and when are recorded and exportable. Payroll is calculated in a payroll system. What leaves here is the invoice basis as CSV; there is no payroll file and no payroll export of any kind.

A finished job becomes a basis: what it is worth, stated so that somebody else can invoice it. It has to be arguable on its own, because it is read by an office that was not there and by a customer who is disputing it.

Three rules hold it up.

Only approved time is billable. The approval step is the only thing standing between "I worked nine hours" and an invoice. Hours nobody signed off never appear among the ones that do.

Labour and materials are separate lines, always. A ROT or RUT deduction applies to one and never to the other, so they cannot share a line.

Nothing is rounded twice. Each line is rounded once and the totals are sums of rounded lines, which is what the invoice written from them will do. A basis that disagrees with its own rows by an öre is one nobody trusts twice.

Hours group the way an invoice reads them: one line per person, per kind of time, per rate. "Anna Svensson, 14 hours" is something a customer can check; fourteen clock-ins is not. Two people on one job are two prices, and so is one person whose rate changed between two approvals, so the rate is part of what makes a line one line. The rate is the person's billing rate, kept apart from what their hour costs you; people who were set up before the two were split start with the billing rate equal to the cost.

What is not billed is still shown. Time marked unbillable, or hours on a fixed-price job where the agreed price is what is charged, are carried as lines at zero with the reason stated rather than dropped — so the hours on the invoice basis still add up to the hours on the timesheet.

And the basis says what it does not know, by name: time still awaiting approval, a job that is not finished so the basis will still change, a job already invoiced, hours carrying no rate and therefore billed at nothing, hours billed at cost. Naming them is the difference between an invoice that is short by a day and a conversation you had before you sent it.

The whole month exports as CSV written for Swedish Excel — a byte-order mark, semicolons, decimal commas — which is the difference between a file a bookkeeper uses and one they email back. If you also run the invoicing module, the basis becomes invoice lines with nobody retyping anything.