Auto-finalisation

What it is

Auto-finalisation is the per-syndicate setting that lets Syndik8 finalise a member’s booking without an admin step. It is the fallback, not the main route. Where the syndicate lets members close their own bookings (the default), the main route is the pilot: after logging their last flight on a booking they close the booking, see the charge, and post it themselves. Auto-finalisation picks up the bookings nobody closed. In a syndicate that doesn’t let members close their own bookings, it is the only route that needs no admin.

A scheduled sweep runs every 30 minutes. It finalises a member’s booking only when all of these hold:

24 hours have passed since the booking ended. That gives the pilot a day to log any remaining legs and close the booking themselves.
At least one flight is logged against the booking.
The meter continuity check passes: every flight on the booking starts on the reading the flight before it ended on. The first is compared with the last flight before the booking on the same aircraft (or, on the very first flight on an aircraft, its opening reading), each later flight with the leg before it.
Every flight left from where the aircraft last landed. The first flight is compared with the last landing before the booking, each later flight with the arrival of the leg before it, and ground runs are passed over. A departure that differs means one of the two routes is wrong; see Departure conflict.
No flight is logged on it twice. Two logs covering some of the same time, or with the same start and end readings, are one flight logged twice, and finalising would charge both.
There is no minimum-usage shortfall. A shortfall is never posted automatically.

Anything that fails one of those stays in the unfinalised bookings queue for an admin. Syndicates that prefer end-of-month reconciliation turn the setting off and use finalise multiple bookings at once, which runs the same continuity check, batched and admin-triggered.

Who can use it

Admin: turn the syndicate setting on and off.
Treasurer (admin): same; usually the person who owns this decision.
Member: never sets it. Where the syndicate lets members close their own bookings, a member closes their own booking; the sweep only reaches the bookings a member leaves open.

Where to find it

Setting: Open the syndicate and go to the Admin tab, then tap Member billing (under Money) → Finalising bookings → Finalise automatically (saves immediately on change). It sits with Pilots finalise their own bookings because it decides whether a member’s flying can become a charge without anyone pressing a button.
What it leaves behind: Unfinalised bookings at /syndicates/:syndicateId/unfinalised-bookings. Bookings the sweep would not finalise wait here, with a badge saying why. Once they are more than 24 hours past their end they sit in the queue’s Needs you group and count towards the Finalisation section of the Admin Pending page.
Notifications: the Flight logs don’t follow on alert for a continuity or departure conflict, sent when the flight is logged whether or not this setting is on, and Booking Needs Attention when a shortfall or a flight logged twice holds a booking back. The half-hourly sweep also runs in every syndicate, with this setting on or off, to send any Flight logs don’t follow on alert that was missed and bring every standing one up to date or withdraw it. It only finalises bookings where the setting is on.

Fields / options

Field	What it sets
Finalise automatically	Whether the sweep finalises members’ bookings that are still open 24 hours after they end. The screen explains: “24 hours after a booking ends, if nobody has. Any minimum-usage shortfall waits for an admin.” Default: on for a new syndicate (an admin can turn it off to reconcile monthly instead).

The switch sits next to Pilots finalise their own bookings, which decides whether members can close their bookings at all. The two settings are independent. Between them, they decide how a member’s booking becomes a charge:

Pilots finalise their own bookings	Finalise automatically	A member’s booking is finalised by
On (default)	On (default)	The pilot closing it, or the sweep 24 hours after it ends
On	Off	The pilot closing it, or an admin
Off	On	The sweep 24 hours after it ends, or an admin
Off	Off	An admin

In every case, a shortfall is posted only by the pilot closing the booking or by an admin.

Behaviour rules

What the sweep does with a member’s booking

Every 30 minutes the sweep looks at each confirmed member booking in a syndicate with the setting on, and chooses one of these outcomes:

Situation	What the sweep does
The booking ended less than 24 hours ago	Nothing yet. The pilot can still log more flights and close it themselves.
No flight is logged	Never finalises it. The booking stays in the unfinalised queue for an admin to decide whether it was flown.
One flight is logged twice on the booking (two logs cover some of the same time, or have the same start and end readings)	Never finalises it, whatever the continuity check says. The booking stays in the unfinalised queue, and every admin of the syndicate gets one Booking Needs Attention notification: “Flights logged on a booking on aircraft overlap, as though one flight was logged twice, so it was not finalised automatically. Open it to remove the spare log, then finalise it.” The notification is withdrawn once the booking is finalised. Legs flown back to back, where one starts at the moment or on the reading the other ended, do not count. Nor do readings that only partly overlap: those are two flights, and the later one is a continuity conflict.
The booking has a minimum-usage shortfall	Never finalises it. The booking stays in the unfinalised queue, and every admin of the syndicate gets a Booking Needs Attention notification: “A booking on aircraft has a minimum-usage shortfall of £X, so it was not finalised automatically. Open it to review the shortfall and finalise it.”
No earlier eligible booking on the aircraft (this is the first)	Finalises, provided its start matches the aircraft’s opening reading when one was set. A start that does not is a continuity conflict, below.
The start matches the last flown reading (within 0.01 h), including when the booking just before was a no-show or grounding that never moved the meter	Finalises.
A flight’s start does NOT match where the flight before it ended (continuity conflict): the previous booking’s last flown reading for the first leg, the leg before it for a later leg, or the opening reading for the very first flight on the aircraft	Skips. The booking stays in the unfinalised queue. The pilot and every admin receive the Flight logs don’t follow on alert. A new mismatch between bookings waits for ten quiet minutes after the last relevant log insertion, edit or deletion reaches the server, then the sweep can send it. Internal-leg conflicts and opening-reading conflicts with no earlier booking remain immediate; standing alerts refresh or withdraw immediately. A later leg that disagrees with an earlier one is a conflict even while the first leg is still waiting on the flight before the booking.
The meter lines up, but a flight left from somewhere other than where the aircraft last landed (a departure conflict)	Never finalises it. The booking stays in the unfinalised queue, held by the same Flight logs don’t follow on alert. Nothing is checked when either flight has no route recorded.
The previous booking has no log and the start differs from the latest genuine reading or opening reading, or neither is available	Waits silently for missing usage. This also applies before any flight has been logged: an earlier empty booking may still have flights to upload. Time passing does not turn the wait into a conflict. An admin can review and finalise individually if no log is expected.

For the booking’s first leg, the continuity check compares against the last actually-flown reading on the aircraft, looking past any booking that recorded no usage (a no-show that wasn’t cancelled, or an empty maintenance grounding). Legs are taken in flying order: by start reading, then off-blocks or take-off time, then when each was written. Later-written repeats are passed over using the same rule as device pre-fills: overlapping flight times, or both readings matching within 0.01 h. A partly overlapping meter range at different times remains a separate flight. The tolerance (0.01 h) matches the precision the engine-meter form accepts. The check applies only to aircraft that capture the engine meter; others have no meter to compare.

Saving a flight never finalises anything

Logging a flight records it; it does not finalise the booking, online or offline, and nothing is queued to finalise when the device next syncs. The booking becomes a charge in one of three ways: the pilot closes it (where the syndicate lets members close their own bookings), the sweep finalises it once the conditions above hold, or an admin finalises it.

Members logging a flight in a syndicate with the setting on see a short grey note at the top of the log form. Where members may close their own bookings:

Close the booking after your last flight to make the charge payable. It will auto-close 24 hours after the booking ends.

Where only admins close bookings:

This booking auto-closes 24 hours after it ends, and the charge becomes payable then.

Why a shortfall always waits for a person

A shortfall charges a member for time they didn’t fly, so either the pilot accepts it by closing the booking or an admin posts or waives it; the sweep never decides on anyone’s behalf. For the reasoning, see why finalisation is a separate step.

Out-of-order log arrivals

Members do not always log in flight order. If pilot B logs straight away and pilot A (whose flight came first on the same aircraft) logs later, B’s start reading reflects A’s flight but the meter has moved since the last logged reading, so the sweep waits on B’s booking. Once pilot A logs, the next sweep reconciles B without an admin stepping in, unless the readings still disagree. A new between-booking mismatch alert then waits for uploads to settle under the shared timing rule. (A booking just before B that was a genuine no-show never moved the meter, so B lines up with the last real reading and is not held up.)

Manual finalisation always works

An admin can finalise any booking from the unfinalised queue or the booking’s Finalise Booking section, including one the sweep held back, with the Waive shortfall and custom-charge options. The single-booking path bypasses the continuity check: the admin has already decided. See finalise a booking.

What auto-finalisation writes

When the sweep finalises a booking, the ledger entries are identical to a manual finalisation: same transaction types, same amounts, same links to booking and usage log. See finalisation rules and transaction types. The pilot is sent a Booking finalised notification.

Flights logged after the booking is finalised

A flight can still arrive on a booking that has already been finalised: from the End Flight card, from the Apple Watch, or from a device that was offline. It is kept, not refused, and every admin of the syndicate gets one Booking Needs Attention notification for that booking so they can add it to the charge with Apply the new charge. The booking is also listed under Needs attention on the Admin Pending page until the new charge is applied. See finalisation rules.

What this commits the system to

Finalising a booking promptly means a flight will sometimes land on the ledger before a later flight reveals that the earlier reading was off by a small amount (say the previous pilot misread the Hobbs by 0.1 h). When that happens, the finalisation stays committed: there is no automatic unfinalising. The recovery path is admin-driven and forward-only: the flight is corrected, then the difference is applied as an adjustment transaction; see correct a finalised booking.

Maintenance bookings

Maintenance bookings close by themselves, whether or not this syndicate has the setting on, and they close on the first sweep after their end time, not 24 hours later.

That is the one place Syndik8 steps over the setting, and the reason is that the setting is about money. Turning auto-finalisation off says “a member’s flying should not become a charge on their balance until someone has looked at it”. Flying the aircraft to the engineer is not billed to anybody — it is a cost of owning the aircraft, already met through the monthlies — so a maintenance booking has no charge for anyone to look at. Leaving it queued would give the admin a row whose only available action is to close it, on every trip to the workshop, for ever.

So the sweep closes a maintenance booking once its end time has passed:

With a usage log (a ferry flight, a ground run): the same continuity check runs first. A ferry flight is a real link in the meter chain, so if its start reading disagrees with the flight before it the booking is held back and the Flight logs don’t follow on alert stands, exactly as for a member’s flight. Its route is not checked.
With no usage log at all (an annual with the aircraft on a trailer, work done on site): it closes on the next sweep. There is no meter movement to check and nothing to bill, and these are precisely the bookings that would otherwise sit in the queue for ever because nobody has any reason to open them.

Closing a maintenance booking writes no ledger entry of any kind, so nobody’s balance moves.

Turning the setting off

Turning auto-finalisation off stops the sweep finalising members’ bookings; it does not reverse any finalisation already made. Existing finalised bookings stay finalised. Members can still close their own bookings if the syndicate lets them, and anything they leave open waits in the unfinalised queue for an admin. With both settings off, an admin finalises every member booking.

When to leave it on

Leave it on where members log promptly and accurately and the admin would rather not open every booking to press Finalise: most bookings are closed by their pilots, and the sweep tidies up the clean ones the pilots forgot. Turn it off if the syndicate would rather an admin looked at every booking the pilot didn’t close, and use bulk finalisation at a monthly cadence instead.

When something goes wrong after the fact

Occasionally a finalised booking turns out to have been wrong. The recipe for that case is correct a finalised booking: correct the flight, then apply the difference. The original transactions stay on the ledger; the correction is a new event that nets the balance back to truth.