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 the moment they submit a clean usage log: no admin step, no unfinalised queue. When the 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 uses a different (look-ahead) continuity model.

The design is asymmetric: eager look-back for members, prudent look-ahead for admins. This reflects the different cadences of pay-as-you-go syndicates (every flight billed the day it happens) and reconciliation syndicates (admin reviews everything monthly).

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 Asset rates → Auto-finalise bookings (saves immediately on change).
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: off.

Behaviour rules

The look-back continuity check

When a member submits a usage log on an auto-finalise syndicate, 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
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.

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 hourly 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 are never auto-finalised. The cost-splitting logic across equity members warrants admin review, and the maintenance finalisation path stays admin-only regardless of the toggle.

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.