Skip to content
Syndik8

Correct a finalised booking

Correct a finalised booking

Section titled “Correct a finalised booking”

Finalisation is deliberately one-way: once a charge is on the ledger, the original transactions stay there. Correcting a mistake on a finalised booking is a two-step admin action: fix the historical record, then post an adjustment for the financial difference. This page shows you both halves.

The most common reasons to reach for this recipe:

  • A flight was auto-finalised eagerly because its log was internally consistent at the time, and a later flight reveals the originally-recorded end-tacho was off by a small amount. (Eager finalisation accepts this trade-off in exchange for same-day pay-as-you-go billing — see auto-finalisation.)
  • A Trailing flight was bulk-finalised on admin trust, and the next pilot’s start-tacho when it eventually flew turned out to disagree with the recorded end-tacho.
  • A continuity-conflict notification fired some time ago, the booking was finalised manually with the values that looked right at the time, and subsequent flights have since clarified what the truth actually was.

In all three cases, the member needs to be charged the difference, and the historical log needs to reflect the truth.

Before you start

Section titled “Before you start”
  • You must be an owner or admin (treasurer counts as admin).
  • You’ll need to know what the corrected value should be — usually after talking to the member, or by reading the next flight’s start-tacho.
  • Have the booking’s detail screen open. The member will be visible at the top.

Step 1 — Fix the historical usage log

Section titled “Step 1 — Fix the historical usage log”

The usage log records what was logged at the time. Editing it changes the historical record, not the financial state. Members can’t edit a usage log on a finalised booking, but admins can.

  1. From the booking’s detail screen, find the usage log entry. Tap it to open the log editor.
  2. Update the field that was wrong (typically tacho_end or hobbs_end).
  3. Save. The log now reflects the corrected reading.

Note. Editing the log alone does NOT update the ledger. The original charge for that booking stays exactly as it was posted. Step 2 is what corrects the money.

Step 2 — Issue an adjustment for the difference

Section titled “Step 2 — Issue an adjustment for the difference”

The original transactions are immutable on the ledger (correct double-entry bookkeeping). To bill or refund the difference, you post a new adjustment transaction.

  1. From the booking’s detail screen, scroll to the financial section.
  2. Tap Add adjustment.
  3. Enter the amount — positive to charge the member more, negative to refund. Calculate it as (corrected_hours − originally-billed_hours) × hourly_rate.
  4. Enter a description so future you (or another admin) can read the audit trail. A good template:

    “Tacho correction on flight YYYY-MM-DD: end-tacho corrected from X.XX to Y.YY, charging Z hours at £R/hr.”

  5. Confirm.

The adjustment posts as a new transaction linked to the same booking. The member’s balance updates accordingly. Both the original charge and the adjustment are visible on the booking’s financial section, leaving a complete audit trail.

What you should NOT do

Section titled “What you should NOT do”
  • Do not delete the original transactions. Posted ledger entries are sacrosanct. Even if you have admin DB access, deleting a transaction destroys the audit trail and breaks balance reconciliation.
  • Do not re-finalise the booking. It’s already finalised. Trying to finalise again will fail (the booking is already in the completed state).
  • Do not edit the log without posting the adjustment. That leaves the historical record correct but the ledger wrong — a worse state than before the correction. Always do both, in this order, in the same sitting.

Why two steps?

Section titled “Why two steps?”

The historical log and the ledger answer different questions:

  • The log answers “what did the meter read?” — a fact.
  • The ledger answers “what was charged?” — a financial event.

When the meter reading turns out to have been recorded wrong, the fact changes (we update the log) and a new financial event fires to correct the original charge. The original financial event is left intact because it represents what actually happened on the ledger at the time. This separation is standard double-entry bookkeeping practice and what every accounting system Syndik8 might integrate with assumes.

See also

Section titled “See also”