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 an admin (or the auto-finalisation job) finalises the booking. This page explains the reasons.

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 shortfall rate, 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.

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 — when 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 — before the ledger is involved.

Minimum-usage shortfalls need admin 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. Giving admins an explicit finalisation step means shortfalls can be waived, reduced, or posted at the full rate depending on what happened. The shortfall preview shows the computed number; the admin either accepts it, edits it, or zeroes it out with a note. Auto-finalisation handles the clean cases — zero-shortfall bookings with no flags — and defers anything with a shortfall to the admin for review.

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 All 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 the next time an admin with a connection finalises it. See offline-first architecture for why the sync boundary falls where it does.

What admins get

Stepping back, 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.