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, after the 2026-05-10 changes, 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 asymmetric design — eager look-back for members, prudent look-ahead for admins — 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

Owner and 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: Syndicate Settings → Billing & 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_continuity_detected 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 looks back at the immediately preceding booking on the same asset and chooses one of four outcomes:

Previous booking on the asset	What auto-finalisation does	What the member sees
None (this is the first booking on the asset)	Finalise.	”Logged successfully.”
Exists, no usage log yet (out-of-order arrival)	Skip silently. The log is saved and stays queued; the retry path will pick it up once the predecessor lands.	”Logged. Auto-finalise is waiting for the previous flight on this asset to be logged.”
Exists, log’s end matches my start (within 0.01 h tolerance)	Finalise.	”Logged successfully.”
Exists, log’s end does NOT match my start	Skip and notify. The log is saved, the booking stays in the unfinalised queue, and the `tacho_continuity_detected` 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 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 whose billing basis reads the engine meter. Assets billed on clock time alone 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 auto-finalisation finds no predecessor log and skips silently 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 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.