Finalise a booking
Finalise a booking
Section titled “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.
Before you start
Section titled “Before you start”- 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.
- Open the booking detail screen.
- Scroll to the Finalise Booking section.
- 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.
- If the shortfall is correct, leave the Shortfall charge field as shown.
- To waive, reduce, or increase the shortfall, edit the field — this overrides the calculated shortfall.
- 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).
- Add an optional Note — a short explanation that is attached to the finalisation transactions.
- Tap Finalise Booking.
- 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.
Trailing flights
Section titled “Trailing flights”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.
Offline behaviour
Section titled “Offline behaviour”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.
If it goes wrong
Section titled “If it goes wrong”- “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.
See also
Section titled “See also”- Finalisation rules — what finalisation does, the snapshot rule, and how each path handles a junction
- Transaction types — the ledger entries finalisation writes
- Unfinalised bookings queue — the admin view of bookings awaiting finalisation
- Finalise multiple bookings at once — bulk version with look-ahead classifications
- Enable auto-finalisation — eager pay-as-you-go alternative for syndicates with reliable logs
- Correct a finalised booking — recovery when a finalised booking later turns out to have been wrong