Why finalisation is a separate step

The question this page answers

A member lands, taps out their Hobbs reading, and saves the usage log. It would be natural for the system to write the charges to the ledger right then: instant accounting, no backlog. Syndik8 deliberately doesn’t do that. Charges are computed at save time, but they don’t become real money movements until the booking is finalised: by the pilot closing it after their last flight, by an admin, or by the auto-finalisation sweep. These routes sit side by side, and an admin can always finalise. This page explains the reasons.

Finalising is also a different thing from a charge falling due. Finalising turns the flying into a charge, which a member can pay by card straight away. The charge becomes due, and so collectable by Direct Debit, on the syndicate’s monthly bill day or as soon as it is finalised, whichever the syndicate chose. Keeping the two apart is what lets a syndicate review and correct bookings through the month and still send one bill.

Usage logs are editable. Ledger entries are not.

The first reason is the most practical. A member who just finished a flight types what they see on the instruments. They may be tired, rushing, or mis-reading the last digit on a Hobbs drum. Corrections happen (often within minutes of the original save) and they are normal. The usage log is designed to absorb this: edit the hours, fix the tacho, change the landing count.

If charges were posted to the ledger on save, every edit would be a reversal plus a re-post. The member’s balance would go up, down, up again. The statement would fill with corrective pairs that exist only because the system was too eager the first time. Keeping the usage log mutable and the ledger immutable means the common case (save, look again, fix) produces no ledger churn at all. The ledger only learns about the flight once the member (and the admin, implicitly) are ready to say “this is final”.

Rate snapshotting needs a commit point

When a usage log is saved, Syndik8 writes the resolved rates onto the log: the effective hourly, the event fee rates, the currency. Later changes to the scheme modifier or the asset base rate don’t back-date what’s already been logged. This is how rate changes stay safe: a scheme tweak on Monday doesn’t reach into Sunday’s flight. The settings that belong to the booking as a whole, such as the shortfall rate and the daily minimums, are kept with the booking when it is finalised, so a change to them never reaches a booking already finalised either.

But snapshotting on save only gets you halfway. The rates are captured, but nothing has moved. Finalisation is the moment the snapshot becomes financially real: the captured rates are multiplied through the logged usage and written as ledger entries the treasurer can reconcile. Separating the two gives admins a window in which the charge is defined but not yet binding. If a member disputes the rate, or asks for a correction, or points out that the booking should have been priced on the instructor rate rather than the equity rate, the conversation happens before finalisation rather than after; it happens before the ledger is involved.

Minimum-usage shortfalls need a person’s judgement

Many syndicates have a minimum-usage policy (say, two hours per weekend booking). If the member flies less, the shortfall between actual and minimum is charged at the shortfall rate. This sounds like an obvious candidate for automation, but the reality is messier. Aeroplanes get weather-cancelled after the first leg. Engines throw oil pressure warnings and get taxied back. A member may land after forty minutes because the cloud base dropped, not because they bailed out on the booking.

An automatic shortfall charge would prosecute members who weren’t at fault, so Syndik8 never posts one automatically. A shortfall reaches the ledger only when a person has seen it. In a syndicate that lets members close their own bookings (the default), the first person is usually the pilot: when they close their own booking after their last flight, the sheet shows the flying, the shortfall and the total, and closing accepts all three. A pilot who thinks the shortfall is unfair can leave the booking open and talk to an admin. The second person is the admin: the shortfall preview shows the computed number as read-only, and the admin either accepts it or checks the Waive shortfall box to credit it back on the record. Auto-finalisation handles only the clean cases (a booking still open 24 hours after it ends, with no shortfall and no flags); a booking with a shortfall waits for an admin, who is notified.

Closing early raises a second question: once the booking is shorter, what should the minimum be worked out on? A minimum charges for holding the aircraft, and a booking holds it from the moment it is made, not only for the hours it ends up covering. In a small group, others plan their week around a booking, so an afternoon given back at midday rarely gets flown, and charging the minimum on the booking as made reflects what the group lost. In a busy club, time released early is often rebooked within the hour, so charging only for the time kept is fairer.

So each syndicate chooses (on the Asset rates screen, next to the minimums), and the choice is fixed on each booking when it is closed: a later change of mind never reprices a booking the pilot has already agreed to. The rule and a worked example are in finalisation rules.

Finalisation is atomic; mid-booking writes would fragment the ledger

Finalisation writes, in one database transaction, every consequence of the booking:

One usage charge transaction per usage log.
One event charge transaction per active counter (landings, touch-and-gos, etc.).
Optionally, one shortfall transaction.
Optionally, one custom charge (a hangar fee, a fuel stop top-up).
The status change moving the booking from confirmed to completed.

Either all of them land, or none do. There is no halfway state where charges are partly posted and the booking is still confirmed. If the finalisation fails for any reason, the ledger is exactly as it was before.

Writing charges on usage-log save would break this. A booking typically has one usage log, but it can have more (pre-flight taxi, a positioning leg, the flight itself, a post-maintenance test). Writing them individually would fragment the booking’s financial footprint across several independent ledger events. The treasurer would reconcile the booking by reassembling those fragments; the statement would group them by timestamp rather than by booking. Deferring everything to finalisation means one booking = one discrete finalisation event in the audit trail.

Batch efficiency is a feature, not a cost

Treasurers do not want to finalise bookings one at a time. Most syndicates run a weekly or monthly rhythm: someone sits down, opens the Unfinalised Bookings queue, and works through everything that accumulated since the last pass. The queue is deliberately visible: it is how the treasurer plans their session.

Splitting finalisation from usage logging is what makes that queue possible. If charges were posted on save, there would be nothing to queue; the “work” would already be distributed across every member’s save actions, and there would be no natural moment for the treasurer to review a coherent set of bookings. The Finalise No-Shortfall action on zero-shortfall bookings exists specifically because the queue exists: clean bookings are dispatched in bulk, tricky ones get individual attention.

The offline dimension

Financial tables in Syndik8 are deliberately online-only. The ledger does not sync offline; the risk of two devices writing conflicting money is not one Syndik8 is willing to accept. Usage logs, bookings, and rate resolution all work offline; finalisation does not. This is only possible because finalisation is separate from the capture of usage. Members can log flights on a hangar apron with no signal; the charge becomes real once someone with a connection finalises the booking, whether that is the pilot closing it back online, an admin, or the sweep. Nothing finalises by itself when the log syncs. See offline-first architecture for why the sync boundary falls where it does.

What admins get

What does the admin get from the separation?

A window to correct mistakes before money moves: usage logs are editable; ledger entries are not.
A rate that is captured but not yet charged: the snapshot commits, finalisation spends.
Judgement on shortfalls: weather and mechanicals don’t penalise members unfairly.
Atomic, booking-level ledger events: the audit trail groups by booking, not by log.
A review queue: the treasurer’s natural rhythm fits the data.
A clean boundary for the offline story: capture is offline-capable; the ledger is not.

None of these individually would justify the extra step. Together, they are why finalisation exists as a first-class action rather than a side effect of saving a log.