To reconcile a partial refund on a lesson package, record two linked changes: the money returned through the payment provider and the lesson units removed from the student’s entitlement. Do not reduce a package balance merely because a dollar refund exists, and do not delete the original payment, completed lessons or booking history to make the totals look neat.
This workflow begins after an authorized person has approved the refund under the school’s current terms and applicable requirements. It does not decide whether the customer has a legal right to a refund, how taxes should be adjusted, or which accounting entries a bookkeeper should make.
Freeze the before-state first
Before staff press Refund or edit any credit, save one incident record. Capture:
- student, order and package item IDs;
- original payment ID, amount, currency and provider status;
- package definition: lesson type, duration and quantity purchased;
- completed units, units attached to active future bookings and units still available;
- refund amount approved, the policy or exception used, approver and reason; and
- the exact lesson units the refund is supposed to remove.
The package terms should already say what happens when a customer leaves partway through. If they do not, fix the cancellation and refund language before the next sale rather than inventing a new calculation for each caller. The package description should also define the lesson unit clearly enough that staff know whether they are removing one 60-minute lesson, one 90-minute lesson or something else.
Worked example: refund two unused lessons from a six-lesson package
The following figures are a hypothetical example, not a RouteOS customer record, legal rule, tax calculation or recommended refund policy.
A student bought six 60-minute lessons for $600. Two lessons are completed, one future lesson is confirmed, and three units remain available. Under this example school’s approved policy, the school refunds $200 for two unused units and leaves the existing future booking in place.
| Record | Before | Refund event | After |
|---|---|---|---|
| Original payment | $600 paid | Keep the original payment; link a $200 refund | $600 original payment, $200 refunded, $400 net retained operationally |
| Package units issued | 6 | Remove 2 specifically approved unused units | 4 adjusted package units |
| Completed lessons | 2 | No change | 2 |
| Future booked lessons | 1 | No change in this example | 1 |
| Available to schedule | 3 | Reduce by 2 | 1 |
The lesson arithmetic is:
- Remaining unused: 4 adjusted package units − 2 completed = 2
- Available to schedule: 2 remaining unused − 1 future booked = 1
This is an operational reconciliation. It does not say when revenue is recognized or which general-ledger accounts change. Give the payment and entitlement evidence to the school’s bookkeeper rather than turning this worksheet into accounting advice.
Process the refund as its own transaction
Find the original successful payment at the provider and confirm how much remains refundable. Stripe, for example, allows a full or partial refund after a payment succeeds, permits more than one refund against a charge, and prevents the combined refunded amount from exceeding the original charge. Its API accepts a partial amount in the currency’s smallest unit. See Stripe’s current refund documentation and refund API reference.
When staff submit the $200 example refund, retain:
- the original PaymentIntent or charge ID;
- the provider refund ID;
- amount and currency;
- created time and current status;
- the internal order/package item ID; and
- the internal approval and reason.
Do not mark the case closed merely because the button was clicked. Provider outcomes can be pending, require action, succeed, fail or be canceled depending on the payment method and circumstances. While the result is not final, place an administrative hold on the two identified units so they cannot be scheduled and refunded at the same time. On success, replace that hold with the permanent linked removal. On failure or cancellation, release the hold and restore the before-state.
Remove entitlement once, without rewriting history
The credit adjustment should be a new event connected to the refund—not a silent edit from “6” to “4.” Keep the two completed lessons completed. Keep the surviving future booking attached to its unit. Remove only the two approved unused units, then recalculate remaining and available balances.
The earlier RouteOS guide to unused lesson credits explains why remaining unused and available to schedule are different numbers. This refund uses that distinction: after the adjustment, two lessons remain unused, but one is already reserved by the future booking, so only one remains available.
If an automated request times out, do not create a second refund just because the first response was lost. Use one operation key and look up the first result before retrying. Stripe’s idempotency guidance describes this retry safeguard. Likewise, process a provider refund event only once; a repeated notification must not remove another pair of lessons. Stripe documents refund lifecycle events in its refund-event guidance.
Do not convert dollars into units by guessing
The example is easy because $200 was explicitly approved for two $100 units. Real cases can be messier:
| Situation | Safe office response |
|---|---|
| The refund amount does not divide evenly by a lesson price | Do not round the money into a unit count. Record the approved financial calculation and a separate explicit unit decision. |
| The package had a discount or completed lessons are repriced under the stated policy | Use the approved policy calculation; do not assume every unit has the original average price. |
| The package was paid through more than one transaction | Identify which provider payment receives the refund and keep the allocation connected to the same package item. |
| A future booking uses one of the units being removed | Stop and resolve the booking first. Do not leave a confirmed lesson backed by a unit that no longer exists. |
| The student books while the refund is pending | Block the identified units during review or send the case to staff; do not let two workflows spend the same value. |
Close one case with one reconciliation line
A completed record for the example can read:
Example: Order DS-1048, package item PK-61. Original payment $600. Refund RF-208 for $200 succeeded on September 15, 2026. Approval AP-74 removed two unused 60-minute units. Two completed lessons were preserved; one future booking remained; one unit remained available. Customer notice CN-19 sent. Bookkeeping treatment pending external review.
That one line should link to the underlying records rather than replace them. A supervisor can then reproduce both sides:
- $600 original payment − $200 refund = $400 net retained operationally; and
- 6 original units − 2 refunded units = 4 adjusted units, consisting of 2 completed, 1 scheduled and 1 available.
RouteOS sells driving-school software, so we have a commercial interest in cleaner office workflows. The current Task Operations page describes giving an administrative request an owner, deadline and visible outcome. That can help organize review work when configured, but it is not evidence that a refund, entitlement adjustment, tax result or accounting entry happens automatically. Those records still need to be reconciled against the live payment provider and the school’s actual package history.