Finalisation rules

What it is

Finalisation is the act of finalising a booking’s financial consequences: the booking’s usage logs are priced, the resulting transactions are written to the ledger, any shortfall is applied, and the booking’s status moves from confirmed to completed. It happens in one of three ways: the pilot closes their own booking, an admin finalises it, or the auto-finalisation sweep does.

Before a booking is finalised, its usage is informational: the member has logged flight data but no money has moved on the ledger. After finalisation, the charges are real: they are on the member’s balance and appear on the statement.

Booking finalisation vs payments settlement: this page is about booking finalisation: turning a flight or maintenance booking into ledger entries. The payments domain has transaction settlement, the record that a charge has been paid (by card, Direct Debit, waiver, offset, etc.). The two flows are independent: booking finalisation creates debits; payments settlement clears them.

Who can use it

• Admin: finalise any booking manually from the booking detail screen or in bulk from the Unfinalised bookings queue.
• Treasurer (admin): same; this is typically the treasurer’s workflow.
• Member: can finalise only their own booking, by closing it once a flight is logged, including before the scheduled start (see Close a booking), and only while the syndicate has Pilots finalise their own bookings on (the default, set on the Member billing screen). Closing has no waive or custom-charge options; the member posts the charge shown. Cannot finalise anyone else’s booking.

Where to find it

• Booking detail: /syndicates/:syndicateId/bookings/:bookingId. The Finalise Booking section appears on confirmed, not-yet-finalised bookings.
• Unfinalised bookings queue: /syndicates/:syndicateId/unfinalised-bookings. A list of every booking awaiting finalisation, with Finalise No-Shortfall for the zero-shortfall ones and Finalise All for every eligible one.
• Close booking (the pilot’s own booking): the sheet after saving a flight, the Close booking button on the booking detail screen, and the Finished with registration? card on the Home screen.

Fields / options

From the booking detail screen

Field	What it sets
Shortfall preview	The shortfall amount that will be posted (read-only). Computed server-side from the booking’s usage logs.
Waive shortfall	Checkbox. When ticked, the shortfall is charged and immediately credited back, leaving the waiver on record. Offered only when there is a positive shortfall to waive.
Custom charge	Optional extra line (for example a hangar fee). Requires a description.

From the unfinalised bookings queue

Field

What it does

Finalise All (count)

Finalises every booking whose checks all pass, shown with no badge, plus those whose only finding is Shortfall, applying that charge (see How each path handles a junction below). Every other finding holds a booking back: No member (nobody to charge; assign the booking to a member), Possible duplicate (two logs on the booking cover the same time, or have the same start and end readings, as though one flight was logged twice; open it and remove the spare log), Meter mismatch, Departure mismatch (a flight left from somewhere other than where the aircraft last landed; see Departure conflict), Missing previous log (an earlier booking that has not been logged may explain a different reading or departure), Earlier logs unclear, No baseline reading, Check failed and No flight logged. The server refuses an unassigned booking outright and a bulk run is one transaction, so leaving it in would take every other booking down with it. The count reflects the includable subset; when nothing is includable the button is greyed out at “Finalise All (0)”.

Behaviour rules

What finalisation does

Finalisation atomically writes the following ledger entries:

• One usage charge transaction per usage log, equal to logged usage × resolved rate. The rate is read from the rate snapshot stored on the log at the time the log was saved.
• One event charge per active event counter on each log (landings, touch-and-gos, etc.). The rate for each event is read from the same snapshot.
• One minimum shortfall transaction if the booking came in below the configured minimum and the shortfall was not overridden to zero.
• One custom charge transaction if the admin entered one.

For maintenance bookings, finalisation writes no charge at all. Flying the aircraft to the engineer is a cost of owning it, in the same family as hangarage and insurance, and those are already met through the monthlies — so there is nothing left to bill per flight, and no shortfall either. Finalising a maintenance booking only closes it: its status moves to completed. The flight itself is unaffected by that: its hours had already moved the asset’s meter and joined the technical log the moment the usage log was saved, independently of finalisation. A syndicate that genuinely needs extra money for a big maintenance bill raises a cash call instead — a deliberate, separately-issued charge, not something finalisation does on its own.

That holds however the booking is finalised — opened on its own, picked up in a bulk run from the unfinalised queue, or closed by the auto-finalisation sweep. A maintenance booking closes automatically on the first sweep after its end time (the sweep runs every 30 minutes), and does so even in a syndicate that has auto-finalisation switched off: that setting decides whether a member’s flying becomes a charge without an admin’s say-so, and closing a maintenance booking never charges anybody, so there is nothing for it to protect. That applies whether or not anyone logged usage against the booking — an annual with the aircraft on a trailer records no hours, costs nobody anything, and closes on the same schedule.

Once the transactions are written, the booking’s status changes to completed. The booking cannot be finalised a second time.

When the pilot closes their own booking, the same entries are written, the shortfall included: the close sheet showed it and closing accepts it. Closing early ends the booking immediately, never before the latest logged landing or on-blocks time and never after its original end. If the first logged flight departed before the reserved start, the completed booking starts at that departure. The released time can be booked immediately, including by bringing a later booking forward to exactly the released end. Which times the minimum is then worked out on is a syndicate setting; see When a member closes early.

Flights logged after a booking is closed

The app hides Log Usage on a finalised booking, but a flight can still reach one: from the End Flight card, from the Apple Watch, or from a device that was offline when the booking was closed. The same can happen on a booking that nothing will bill, because it completed without a charge (a £0 finalise, or a past booking brought in by an import), was cancelled, or was not approved.

Such a flight is kept, not refused, and it is not billed. Every admin of the syndicate gets one Booking Needs Attention notification per booking, linking to it. For a finalised booking it reads “A flight was logged on aircraft after the booking was finalised and has not been billed. Open it to correct the charge.” For the other cases it says the flight was logged against a booking that was closed without a charge, was cancelled, or was not approved, so it has not been billed, and asks the admin to open it to review it. On a finalised booking the admin uses Apply the new charge, which reprices every log and posts one adjustment (with the Waive the shortfall tick beside it, the new shortfall is left out and waived in the same step); see correct a finalised booking. A pilot who logs onto a finalised booking sees “Flight logged. This booking was already finalised, so an admin has been asked to add this flight to its charge.”

Until an admin applies the new charge, a finalised booking with a late flight is listed under Needs attention on the Admin Pending page. Applying it takes it off that list, clears the notification for every admin, and, when it changes what the member owes, sends the member a Booking charge corrected notification with the amount added to or credited to their balance. A late flight on a cancelled or rejected booking raises the notification only: there is no charge to correct, so it is not listed.

Rate snapshot

When a usage log is saved, the rates in effect at that moment (the asset’s resolved usage rate for the logging member, the event fee rates, and the currency) are snapshotted onto the log. Finalisation uses the snapshot, not the live rates. This means:

• Changing an asset base rate or a scheme modifier after a log is saved does not retroactively change what that log charges.
• Very old logs that pre-date snapshotting fall back to the asset’s base rate, and then to the syndicate’s default rate if the asset has none. No scheme modifier or asset-scheme override is applied on the way past: scheme resolution happens only when a snapshot is stamped.

The settings that belong to the booking as a whole are not on any log: the shortfall rate, the weekday and weekend minimums, the home airfield that event fees depend on, and the measure and fees a flight falls back to when its snapshot does not name them. Until the booking is finalised they are read as they stand, so the shortfall preview and the finalisation itself use the current settings. When it is finalised they are kept with the booking, and every later pricing of it (a corrected flight, a flight logged late, Apply the new charge, a shortfall waiver) uses those. Changing them afterwards never re-prices a finalised booking, and never marks it as changed since finalising.

Shortfall

The shortfall is computed before finalisation and shown in the shortfall preview on the booking detail screen.

A minimum is a day minimum, and only some days count towards it. The booking is broken into the calendar days it touches and each day is judged on its own. A day contributes its minimum only when the booking covers at least eight hours between 08:00 and 20:00 on that day. That twelve-hour stretch is the day’s core window, and hours outside it count towards nothing. A qualifying Saturday or Sunday contributes the weekend minimum; any other qualifying day contributes the weekday minimum. A day that does not qualify contributes nothing.

The booking’s expected usage is the sum of the days that qualified, and the shortfall is the amount the member flew below it:

expected_hours   = sum of the minimum for each qualifying day
shortfall_hours  = max(0, expected_hours − total_logged_hours)
shortfall_charge = shortfall_hours × shortfall_rate

What the minimum is for. It charges for monopolising the asset, not for flying little. A member who books an aircraft for a half day leaves the rest of that day free for somebody else, so nothing is owed however briefly they flew. The case the minimum exists to catch is the member who books Monday to Friday and flies twenty minutes on the Wednesday, keeping everyone else on the ground all week.

That is why the threshold is eight of the day’s twelve core hours rather than any flying-time test, and reading the rule against that intent is what makes its edges make sense. Monday to Friday with twenty minutes flown qualifies all five days, so the minimum bites five times. A half-day booking qualifies no day and is exempt, which is the right answer. An overnight Friday-into-Saturday qualifies neither day, which is also right: nobody else wanted the aircraft at three in the morning.

What this means in practice. A short weekday flight raises no shortfall, however high the weekday minimum is set: a booking from 09:00 to 13:00 covers four hours of the core window, so that day expects nothing and there is nothing to fall short of. Nor does a long booking at the wrong end of the day — 05:00 to 13:00 is eight hours, but only five of them (08:00 to 13:00) fall inside the window. For a day to count, the booking must hold eight of that day’s twelve core hours, so it cannot start after 12:00 or end before 16:00 on a day it is to count. Hours flown always count in full towards the total, whether or not the day they were flown on qualified.

A multi-day booking adds up the days that qualified. A booking running from Saturday morning to Sunday evening that holds eight core hours on both days expects the weekend minimum twice.

When a member closes early

Closing early moves the booking’s end, which can change which days qualify. The syndicate decides which times count, with If a pilot finishes early, charge the minimum on on the Asset rates screen (Billing and rates):

• The booking as made (the default): the days are judged on the booking’s original times, so closing early never lowers the minimum.
• Only the time they kept: the days are judged on the shortened booking, so a day it no longer covers for eight core hours stops counting.

For example, G-QSYN costs £180 an hour, with a weekend minimum of 3 hours and a shortfall rate of £100 an hour. A member books Saturday 08:00 to 20:00, flies for one hour, and closes at 11:50, so the booking now ends at 11:50. On the booking as made, Saturday still qualifies: the minimum is 3 hours, the shortfall 2 hours (£200), and the total £380. On only the time they kept, the booking covers 08:00 to 11:50, under four core hours, so Saturday doesn’t qualify: there is no shortfall and the total is £180. Either way, 11:50 to 20:00 is free for others to book.

The original reserved start is kept separately when an early flight moves the completed booking start earlier. The booking as made retains both original reservation boundaries. Only the time they kept uses the original reserved start and the released end; if the booking closes before that start, it retained no reservation time and has no daily minimum. The basis is fixed on the booking when it is closed. The close sheet shows the charge on that basis before the pilot agrees, and the booking detail then shows “Minimum usage worked out on the booking as made, until date and time” whenever the booking was closed early on that basis, even when the flying met the minimum. On The booking as made, when the completed start moved earlier, the details show the original reservation used for minimum charges. Changing the setting later does not reprice bookings already closed. The same basis holds if a member shortens their booking by editing its end after it has begun. A booking’s start can’t be changed once it has begun, so moving the start later can’t take a day out of the minimum. The setting affects no other route.

Days are counted in the operating timezone — currently the booking owner’s profile timezone, falling back to Europe/London — and the window is worked out in local wall-clock time, so it stays 08:00 to 20:00 on the two days a year the clocks change.

The admin can waive the shortfall at finalisation using the Waive shortfall checkbox. Waiving charges the shortfall and credits it straight back, leaving the waiver on record. The shortfall amount itself is computed server-side and shown read-only; it cannot be reduced or increased.

Atomicity

Finalisation is one database transaction. Either every charge, every event, any shortfall, any custom charge, and the status change all land together, or none of them do. There is no partial finalisation.

How each path handles a junction

The pilot’s close, automatic finalisation and admin bulk actions check meter and departure continuity on the server. They also hold a changed earlier booking that conflicts with the next genuine logged booking. The individual admin finalisation remains an intentional review decision and can accept those findings.

A start within 0.01 of the previous genuine end passes across empty bookings. A lower reading is a mismatch. A higher reading waits for a missing log only when an unlogged booking intervenes; without one it is a mismatch. A booking’s first departure that differs from the last landing waits in the same way across an unlogged booking that is not a maintenance booking; otherwise it is a departure mismatch. Internal leg gaps and overlaps remain mismatches. The empty earlier booking keeps its own review and is never automatically closed to clear the later one.

The queue shows one primary issue plus a count of additional findings. Detail shows all findings in the same priority order. Passed checks have no positive badge. Missing membership, possible duplicates, meter and route disagreements, missing earlier usage, failed checks, no flight logged and shortfall each have their own explanation. Bulk excludes held bookings and rechecks the batch on the server; Finalise All may include an established shortfall. Any refusal rolls back the entire batch.

Late backfills and corrections are diagnosed on the changed earlier booking, with a link to its later logged neighbour, including a finalised neighbour. They do not reopen or rebill the later booking. Manual finalisation accepts the facts reviewed; Mark reviewed does the same for an already-completed booking without changing money. Changed facts can raise a new review. See Meter continuity and Departure conflict for timing and details.

Reversing a finalisation

A completed booking cannot be “unfinalised”. If the finalisation was wrong, the admin corrects the flight with Correct flight, then settles the money on the booking with Apply the new charge, Waive shortfall or Add charge or credit. See Correct a finalised booking. The booking’s completed status stays; the money is corrected through the ledger, not by undoing the finalisation.

Reversals carry a cause (admin correction, full refund, partial refund) and a transaction-handling mode (rebill puts the original charges back on the member; forgive writes them off).

Reversals on a payments settlement are a separate flow and do not undo the booking-level finalisation either. Be aware that raising one against a payment collected through the payment provider moves real money: it asks the provider to return it to the member. What happens to the charges then depends on what the refund was recorded as — re-opened, forgiven, or left settled at a corrected figure. See Refund or correct a payment.

See also

• Transaction types: every ledger entry finalisation can write
• Member balance: where the charges land
• Close a booking: the pilot finalising their own booking
• Auto-finalisation: the fallback sweep for bookings nobody closed, with look-back continuity
• Tacho-continuity conflict: the meter-junction check both paths use
• Departure conflict: the matching check on routes
• Finalise a booking: the manual single-booking recipe
• Finalise multiple bookings at once: the admin bulk recipe with look-back classifications

For the reasoning behind finalisation being a separate, explicit step rather than happening on log save, see the explanation on why finalisation is a separate step.