Auto-finalisation

What it is

Auto-finalisation is the per-syndicate option that says “this is a pay-as-you-go syndicate”. When it is on, a member’s booking finalises once it has ended and they’ve submitted a clean usage log: no admin step, no unfinalised queue. Finalisation fires at the booking’s end, not per leg, so a multi-leg trip isn’t billed and locked after only its first leg is logged. When a log fails a continuity check against the previous flight on the same asset, the booking stays in the queue and a notification fires so the discrepancy is investigated before any money moves.

The toggle’s full meaning is: “this syndicate finalises eagerly via a look-back continuity check”. Syndicates that prefer end-of-month reconciliation leave it off and use the admin bulk path described in finalise multiple bookings at once, which runs the same look-back check, batched and admin-triggered.

The two paths share one continuity check; they differ only in cadence: eager and member-triggered for pay-as-you-go syndicates (every flight billed the day it happens), batched and admin-triggered for reconciliation syndicates (admin reviews everything monthly). Both ask the same question — does this flight’s start line up with the flight before it?

Who can use it

Admin: turn the syndicate toggle on and off.
Treasurer (admin): same; usually the person who owns this decision.
Member: never sets the toggle, but submitting a usage log in an auto-finalise syndicate is what triggers the finalisation.

Where to find it

Toggle: Open the syndicate and go to the Admin tab, then tap Payments → Billing → Auto-finalise bookings (saves immediately on change). It sits with the billing due mode and the bill run because it decides whether a member’s flying becomes a charge at all.
Conflicts queue: Unfinalised bookings at /syndicates/:syndicateId/unfinalised-bookings. Bookings skipped by the look-back continuity check land here with a discrepancy badge.
Notifications: the tacho-discrepancy notification fires to the submitter and all admins when a look-back conflict is detected.

Fields / options

Field	What it sets
Auto-finalise bookings	Whether this syndicate uses the eager look-back model. Default: on for a new syndicate (an admin can turn it off to reconcile monthly instead).

Behaviour rules

The look-back continuity check

When a member submits a usage log on an auto-finalise syndicate, Syndik8 first asks whether the booking has ended. If it has not, nothing is charged yet and the log waits — a booking with time left may gain another leg, and billing the first would bill part of the booking and close it to the rest. Where the booking has ended, Syndik8 compares the flight’s start meter against the last actually-flown reading on the asset, looking straight past any booking that recorded no usage (a no-show that wasn’t cancelled, or an empty maintenance grounding). It then chooses one of these outcomes:

Situation	What auto-finalisation does	What the member sees
The booking has not ended yet	Wait. Nothing is charged; the finalisation sweep closes it shortly after the booking’s end time, with every leg present.	“Flight logged. You’ll be charged when this booking ends.”
No earlier flight on the asset (this is the first flight)	Finalise.	“Usage logged successfully.”
Start matches the last flown reading (within 0.01 h tolerance), including when the booking just before was a no-show or grounding that never moved the tacho	Finalise.	“Usage logged successfully.”
*The immediately preceding flight* is logged and its end does NOT match the start** (continuity conflict)	Skip and notify. The log is saved, the booking stays in the unfinalised queue, and the tacho-discrepancy notification fires to the submitter and all admins.	“Logged. Auto-finalise skipped: this flight’s start reading does not match the previous flight’s end reading. An admin will review.”
The immediately preceding booking has no log and the meter has jumped since the last flown reading (real flying went unlogged, or an out-of-order log is still to come)	Wait silently. The log is saved and stays queued; the retry path picks it up once the missing log lands.	“Logged. Auto-finalise is waiting for the previous flight on this asset to be logged.”
Start meter does not match the asset’s current recorded reading (discrepancy on log)	Skip without notifying admins. The log is saved and the booking stays queued; the member is prompted to re-check the meter reading.	“Logged. Auto-finalise skipped: meter reading doesn’t match the last recorded value. Please double-check the reading.”

The tolerance (0.01 h) matches the precision the engine-meter form accepts; typos beyond hundredths-of-an-hour fail the check.

The check fires only on assets that capture the engine meter. Assets that don’t capture it have no meter to compare.

Logging offline

Finalisation is a ledger write, and the ledger is online-only, so a log submitted offline cannot finalise on the spot. The log saves locally and the member sees “Logged. It’ll finalise automatically once you’re back online.” When the log syncs, the server runs the look-back check and finalises the booking (or queues it, exactly as an online submission would). There is no admin step and no misleading “an admin will review” prompt for the offline case; that prompt is reserved for a genuine online continuity conflict.

What this commits the system to

Eager finalisation 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 eager finalisation stays committed: there is no retroactive auto-unfinalisation. The recovery path is admin-driven and forward-only via an adjustment transaction; see correct a finalised booking.

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 before B’s on the same asset) logs after, B’s start reading reflects A’s flight but the meter has moved since the last logged reading, so B’s auto-finalisation waits with the waiting for the previous flight outcome above. Once pilot A logs, A’s own auto-finalisation may run; B’s booking stays queued until the retry path reconciles it. (A booking just before B that was a genuine no-show, on the other hand, never moved the meter, so B lines up with the last real reading and finalises straight away.)

A scheduled retry runner re-runs the look-back check across every queued auto-finalise booking. Once pilot A’s late log lands, the next cron tick reconciles B automatically; the admin doesn’t need to intervene unless the conflict is a real continuity mismatch (which surfaces as a notification rather than a silent skip).

Manual finalisation always works

Manual finalisation from the booking detail screen bypasses the look-back check. The admin has already decided to proceed. See finalise a booking.

What auto-finalisation writes

When auto-finalisation goes ahead, 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.

Maintenance bookings

Maintenance bookings close by themselves, and they do so whether or not this syndicate has the toggle on.

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 an admin 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 finalisation 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 tacho-discrepancy notification fires, exactly as for a member’s flight.
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.

Two things stay as they were. Closing a maintenance booking still writes no ledger entry of any kind, so nobody’s balance moves. And it happens on the first sweep after the booking’s end time, not the instant somebody saves the hours — submitting a usage log against a maintenance booking never finalises it on the spot, because that route exists to bill the person who just logged and there is nobody to bill.

Turning the toggle off

Turning auto-finalisation off does not reverse any finalisations it already ran. Existing finalised bookings stay finalised; the toggle controls future submissions only.

When to turn it on

Auto-finalisation suits syndicates where members log promptly and accurately, and where the admin would rather not open every booking to press Finalise. If your members regularly miss logs or typo their meter readings, the look-back check will constantly punt work to the queue and you may as well leave the toggle off and use bulk finalisation at a monthly cadence instead.

When something goes wrong after the fact

Eager finalisation is honest about the trade-off: it accepts that occasionally a finalised booking turns out to have been wrong. The recipe for that case is correct a finalised booking: edit the historical log and post an adjustment for the difference. The original transactions stay on the ledger; the correction is a new event that nets the balance back to truth.