Skip to content
Syndik8

Enable auto-finalisation

Enable auto-finalisation

Section titled “Enable auto-finalisation”

Turn on auto-finalisation to make a syndicate run pay-as-you-go: a booking finalises the moment a member submits a clean usage log, with no admin step. “Clean” means the start meter on the new log lines up with the end meter on the previous flight on that asset. When it does not, the booking stays in the unfinalised queue and a notification fires for the submitter and admins.

If your syndicate prefers monthly admin reconciliation, leave this toggle off and use finalise multiple bookings at once instead — that path uses a look-ahead continuity check that suits batched workflows.

Before you start

Section titled “Before you start”
  • You must be an owner or admin (treasurer counts as admin).
  • Auto-finalisation is off by default. Turn it on once your usage logs are reliable — if members regularly forget to log flights or typo their meter readings, the look-back check will keep skipping bookings into the queue and you will not save the admin work the toggle promises.
  • Auto-finalisation does not bypass continuity checks. A submitted log whose start reading disagrees with the previous flight’s end reading is still saved, but finalisation is skipped and the booking stays confirmed. The submitter and all admins receive a tacho_continuity_detected notification — that delivery is critical-tier and cannot be silenced in notification preferences.
  • Eager finalisation accepts a known trade-off: occasionally a flight will finalise before a later flight reveals that the earlier reading was off. The recovery is admin-driven and forward-only — see correct a finalised booking.

Steps

Section titled “Steps”
  1. Open the syndicate you want to configure.
  2. On the dashboard, tap Syndicate settings.
  3. Tap Billing & Rates.
  4. Scroll to the Auto-finalise bookings switch, below the meter-label settings.
  5. Tap the switch to turn it on. The change saves immediately — you see a Settings saved confirmation.

From now on, eligible bookings are finalised the moment a member submits their usage log, if the look-back continuity check passes. Finalised transactions appear on member balances without you opening each booking.

Members submitting usage logs in an auto-finalise syndicate see a reminder banner on the log form: “Auto-finalise is on — submitting this log will charge immediately if the start reading matches the previous flight’s end reading. Double-check your readings.”

Typical multi-leg flow

Section titled “Typical multi-leg flow”

The cleanest case for auto-finalisation is the everyday one: a member flies a leg, lands, logs it, then later flies another leg and logs that. Here’s what happens end-to-end, with concrete numbers, on a Hobbs-metered aircraft.

Starting state. The previous booking on the aircraft (flown by another member yesterday) ended at Hobbs 2202.0. Auto-finalisation is on. Alex has two confirmed bookings on the same aircraft today: a morning leg and an afternoon leg.

Leg 1 — morning flight

Section titled “Leg 1 — morning flight”
  1. Alex opens the morning booking and taps Log Usage.
  2. Hobbs Start is pre-filled with 2202.0, read straight from the previous booking’s last log — see previous-tacho pre-fill.
  3. Alex taps the camera button on Hobbs End, photographs the meter, OCR fills in 2203.5, Alex confirms it matches the drum, types the landing count, and taps Log Usage.
  4. The log saves. Server-side, the look-back continuity check compares Alex’s start (2202.0) with the previous booking’s last log end (2202.0) — match.
  5. Auto-finalise runs. The booking flips to completed and a charge transaction lands in the ledger — see finalisation rules.
  6. Alex sees a “Logged successfully” snackbar and lands back on the booking. The booking now reads “This booking has been finalised.”

Admin POV. Nothing arrives in the unfinalised queue. The booking shows up in the syndicate ledger as a finalised charge — typically 1.5h × £180+VAT/hr = £270+VAT against Alex’s balance, plus any event fees configured for the syndicate.

Member POV. Alex opens My Balance and sees a fresh charge for the leg, dated today, linked back to the morning booking.

Leg 2 — afternoon flight

Section titled “Leg 2 — afternoon flight”
  1. Two hours later, Alex opens the afternoon booking and taps Log Usage.
  2. Hobbs Start is pre-filled with 2203.5 — the end reading from the morning log.
  3. Alex flies, lands, photographs the meter, OCR reads 2205.0, Alex saves.
  4. The look-back check compares submitted start (2203.5) against the morning booking’s last log end (2203.5). Match.
  5. Auto-finalise runs. The afternoon booking flips to completed, a second charge transaction lands in the ledger.

Admin POV. Two legs back-to-back, two finalised charges, no admin queue work.

Member POV. Alex’s balance now shows two charges from today; the earlier “finalised” indicator on each booking matches what the admin sees.

What goes wrong, and what the system does about it

Section titled “What goes wrong, and what the system does about it”

If Alex had typed 2203.0 instead of 2203.5 on Leg 2 — a typo, or a missed ground run — the look-back check would compare 2203.0 against the morning booking’s last log end (2203.5) and detect a mismatch. The log itself is still saved. Auto-finalise skips the booking, and Alex sees:

“Logged. Auto-finalise skipped: this flight’s start reading does not match the previous flight’s end reading. An admin will review.”

The server-side trigger fires the tacho_continuity_detected notification to Alex and to every active admin — the body reads “The previous flight ended at 2203.5 h, but this flight started at 2203 h. An admin will review.” — and the booking turns up in the unfinalised-bookings queue with a Junction conflict badge.

The admin opens the queue, identifies which side has the wrong reading, edits the historical log to truth using the normal usage-log editor, and either lets the look-back retry pick the booking up next time it runs, or finalises manually using finalise a booking.

Out-of-order arrivals

Section titled “Out-of-order arrivals”

Members do not always log in flight order. If pilot B logs straight away but pilot A (whose flight came first on the same asset) logs later, B’s auto-finalise finds no log on A’s booking and skips silently. B sees:

“Logged. Auto-finalise is waiting for the previous flight on this asset to be logged.”

The log is safe in the queue. Once pilot A logs, A’s own auto-finalise may run; B’s booking stays queued until the look-back retry — or an admin’s manual finalisation — reconciles it.

This is the boundary auto-finalisation is designed to enforce: clean data finalises instantly, dirty data lands in front of an admin, and out-of-order data waits without surprising anyone.

To turn auto-finalisation off

Section titled “To turn auto-finalisation off”

Repeat the steps above and toggle Auto-finalise bookings off. Existing finalised bookings stay finalised — auto-finalisation does not reverse its past work.

If it goes wrong

Section titled “If it goes wrong”
  • A booking stayed confirmed instead of auto-finalising — “Auto-finalise skipped” snackbar. The look-back continuity check detected a meter mismatch with the previous flight on the asset. The submitter and all admins got a tacho_continuity_detected push. Open the booking, identify which log is wrong (yours or the previous one), edit the historical log to truth, and finalise manually using finalise a booking or wait for the look-back retry.
  • A booking stayed confirmed — “Auto-finalise is waiting for the previous flight” snackbar. No conflict — the immediately preceding booking on the asset hasn’t been logged yet. The booking will reconcile once the predecessor lands. No action needed.
  • The member saw “Logged, but finalisation failed.” The log is saved, but the finalisation RPC errored — typically a transient network problem. The member (or any admin) can retry from the booking detail screen.
  • The switch is greyed out or missing. You are not an owner/admin on this syndicate. Auto-finalisation is an admin-only toggle.
  • Maintenance bookings are not being auto-finalised. This is deliberate. Maintenance finalisation fans out costs across members by equity share, so it always stays in the admin-only finalise_maintenance_booking flow. The member-side auto-finalise gate only applies to personal bookings.
  • A finalised booking later turned out to have been wrong. Eager finalisation accepts this trade-off. The recovery path is correct a finalised booking — edit the historical log + post an adjustment for the difference. Do not try to “unfinalise” the booking.

See also

Section titled “See also”