Skip to content

Finalise a booking

Finalise a booking’s charge. Finalisation writes the usage charge, any shortfall, any event fees, and any custom charge to the ledger, then marks the booking completed.

  • You must be an owner or admin (treasurer counts as admin).
  • Finalisation is irreversible in the UI — to change a finalised booking, correct it via an adjustment rather than trying to “unfinalise” it.
  • Once finalised, the booking disappears from the unfinalised-bookings queue.
  • You must be online. Finalisation writes to the financial ledger and cannot be queued — see Offline behaviour below.
  • The single-booking flow on this page bypasses the look-ahead continuity check the bulk path uses. The admin has already decided to finalise. Use this when bulk left a row in the queue (a Junction conflict or Awaiting next log badge), or when you want to override a shortfall.
  1. Open the booking detail screen.
  2. Scroll to the Finalise Booking section.
  3. Review the shortfall preview. Syndik8 computes the shortfall from the minimum-usage rule and the logged usage, and shows the breakdown: Shortfall: X hrs × £rate = £total.
  4. If the shortfall is correct, leave the Shortfall charge field as shown.
  5. To waive, reduce, or increase the shortfall, edit the field — this overrides the calculated shortfall.
  6. To add an ad-hoc charge unrelated to shortfall, enter a Custom charge amount and a Custom charge description (the description is required when an amount is entered).
  7. Add an optional Note — a short explanation that is attached to the finalisation transactions.
  8. Tap Finalise Booking.
  9. Confirm in the dialog. The dialog restates the amounts: Finalise this booking with a shortfall charge of £X? (or with a custom charge if one was entered).

You see Booking finalised successfully. The ledger now carries the usage charge, shortfall, any event charges, and any custom charge. The booking shows This booking has been finalised.

The most recent flight on an asset has nothing in front of it to confirm its end-tacho against. The bulk path’s look-ahead check classifies these as includedTrailing and pulls them into “Finalise All” anyway, on admin trust, with a Trailing flight badge calling them out — see finalise multiple bookings at once. If you would rather check the meter values yourself before committing, finalise the trailing flight individually here instead. The single-booking flow does not stop you doing either.

If a trailing reading later turns out to have been wrong (the next pilot’s start tacho disagrees with what was recorded as the end), use correct a finalised booking to edit the historical log and post an adjustment for the difference. Do not try to “unfinalise” — finalisations are forward-only.

The Finalise Booking button watches connectivity. When the device is offline, the button disables and shows Settlements need a connection — try again when you’re online in a snackbar if you tap it. The button re-enables automatically when the connection returns; you do not need to refresh the screen.

This is deliberate. Finalisation writes to the ledger via a server-side RPC that atomically posts the per-log charges, the shortfall transaction, any event fees, and any custom charge before flipping the booking to completed. Queueing that offline would risk double-posts or partial writes — money conflicts that an “eventually consistent” model cannot resolve safely. So the action waits for a connection rather than accepting a tap that might never reach the server.

  • “Please provide a description for the custom charge” — the Custom charge description is required when a custom amount is entered.
  • “Failed to finalise” — connectivity dropped mid-call (or the RPC errored). No partial finalisation is written; retry when you have signal again.
  • The Finalise Booking button is disabled. Either the booking is not eligible (not yet completed, or already finalised), or the device is offline. See Offline behaviour above.