When staff correct an order before final payment, loyalty points should follow the final eligible spend under the restaurant’s stated rules. The original item and its replacement should not both earn points if only the replacement is ultimately sold. Any provisional points shown during the order should be updated or removed before the final award.
That sounds straightforward until a cashier makes several corrections, a discount is applied, or a guest account is attached late. The buying decision is whether the system can make those changes understandable to staff and produce the final result your restaurant expects. This is a pre-payment question; refunds and cancellations after payment need their own rules and tests.
Map the original item to the final eligible spend
Start with the receipt, not the points balance. Identify what the guest ordered, what staff changed, and which items remain when payment is finalized. Then decide which parts of that final amount are eligible for points.
For example, your policy might award points on eligible food and drink after discounts, excluding tips and taxes. Another restaurant may choose a different rule. What matters for the purchase decision is that the vendor can explain how its calculation matches the policy you intend to publish and operate.
The following example is hypothetical. Assume one point per dollar of eligible item spend, with no discount, tax or tip included in the eligible amount. A staff member first enters an $18 item, replaces it with a $14 item, and then corrects that to a $16 item before payment. The final eligible spend is $16, so the expected final award is 16 points.
The table traces the order and the expected loyalty treatment. The provisional column describes what a system might display; it is not an instruction to add each displayed amount to the guest’s balance.
| Order stage | Eligible item value | Provisional points if shown | Expected final award |
|---|---|---|---|
| Initial entry | $18 | 18 | Not final |
| First correction | $14 | 14 | Not final |
| Second correction | $16 | 16 | Not final |
| Payment finalized | $16 | Cleared or marked final | 16 points total |
Those 16 points are a points award, not a $16 reward. Their value depends on the redemption rules, including what a guest can actually redeem and any minimum balance. The example calculates eligible spend and points only; it does not calculate the cost of the reward, fixed software costs, variable processing costs or exception-handling costs. For that separate decision, use the loyalty reward cost guide.
Separate provisional points from the final award
A provisional figure can help a guest or cashier understand what an open order may earn. It should not be confused with points already available to spend. Ask the vendor whether its system displays provisional points at all, where they appear, and whether the guest can use them before payment. If it does not display them, the final award still needs to be accurate.
In the example, 18, 14 and 16 are alternative calculations at different moments. They are not three awards. A ledger might preserve an audit trail of changes, or it might show only the final award. Either approach needs to let an authorized manager establish that the guest received 16 points in total for that order.
Ask for a clear explanation of the event that makes an award final. Is it payment completion, a closed check, or another status? What happens if the staff member changes the order while payment is being started but before it is completed? Your team needs a consistent boundary between an editable order and a finalized transaction.
Also ask how the system handles partial-dollar amounts and discounts. For instance, does it round each eligible item, round the order total, or retain fractional points? Does a discount reduce eligible spend before points are calculated? These choices can produce different results even when the receipt is correct. Write your preferred rule down and compare it with the vendor’s actual configuration.
Compare staff actions with the loyalty ledger
Walk through the correction as a cashier would. The person taking payment should be able to identify the original item, remove or replace it using the normal order workflow, check the final amount, and associate the correct guest account. Avoid making the points outcome depend on a hidden manual adjustment that busy staff must remember for every correction.
Then compare three records: the order history, the final payment record, and the loyalty ledger. The order history should make the item changes understandable. The payment record establishes what was finalized. The ledger should show the resulting award or provide enough detail for an authorized manager to reconcile it. Ask what access each role needs and whether a manager can find these records by order or guest account.
Request these items from each vendor before accepting the workflow:
- A demonstration of the normal staff steps for replacing an item before payment, including any required permissions.
- An explanation of the eligible-spend rules, rounding, discounts and the point at which the award becomes final.
- A sample order history and loyalty ledger showing how the original entry, corrections and final award can be reconciled.
- The guest-facing view, including whether provisional points appear and whether they can be redeemed before finalization.
- The procedure for correcting an unexpected award, including who can make the adjustment and what record remains.
Consider account timing as well. Ask what happens if the guest is identified after the first item is entered, or if staff select the wrong account and correct it before payment. The acceptance criterion should name the account that receives the final award and require no duplicate award to the earlier account.
If your team uses separate ordering and payment screens, ask the vendor to show where the correction must be made and when each screen updates. Your restaurant POS system workflow and your loyalty records need to agree on the final order; do not assume that an item change on one screen automatically updates every other view.
Set acceptance criteria and run a safe simulation
Turn the example into a short, repeatable buying test. Run it in a vendor-provided demonstration or test environment with simulated payment. Do not use a real card, send a guest message or dispatch a courier for practice. Confirm that any test account and points are isolated from real guest balances.
- Create the test order with the $18 item and attach a test guest account. Record any provisional points displayed.
- Replace the item with the $14 item, then replace that with the $16 item. Record the order history and provisional display after each change.
- Simulate final payment. Inspect the final order and loyalty ledger for the test account.
- Check that the final eligible spend is $16 and the total final award for the order is 16 points, not 18, 14, 32 or the sum of the displayed figures.
- Repeat with the account attached after the first correction, and ask the vendor to show how the result is tied to the correct account.
Record a pass only if the final order, payment status and ledger can be reconciled without an unexplained duplicate award. If provisional points are displayed, they should reflect the current eligible order under the agreed rule and should not be treated as separate final awards. If they are not displayed, note that choice rather than failing the vendor solely for omitting them.
Add your own policy cases before signing: a discount added after a correction, an ineligible item substituted for an eligible one, and an amount that requires rounding. For each case, write the expected final spend and award first. Ask the vendor to demonstrate the result and explain any difference. If the workflow needs a manual adjustment, decide whether its permissions, audit record and staff workload are acceptable.
A simulation checks the mechanics without affecting a guest. A later live service pilot is a separate operational decision: use normal, authorized transactions and review the actual order and ledger records with your team. Do not treat a successful demonstration as proof that every channel, configuration or staff situation will behave the same way.
Before comparing quotes, separate the loyalty workflow from its cost. Ask what the quote includes for setup, recurring software, payment processing and handling exceptions, and request written amounts for anything excluded. Check Fleksa plans for current pricing; the plans page was checked in November 2026. Fees are operating costs, while points and eligible sales are different measures.
Next step: Use the worksheet and your written acceptance criteria to compare your requirements with Fleksa. Review its restaurant marketing automation tools, then ask Fleksa to confirm the corrected-order workflow and show the relevant order and loyalty records before you buy.
Frequently asked questions
Should the original item earn points after it is replaced?
Not under the policy used in this example. The award is based on the final eligible item spend, so an item removed before payment should not also produce a final award.
Can a guest redeem provisional points?
That depends on the system and your policy. Ask whether provisional points are visible or redeemable before payment, and set an acceptance criterion that prevents an unintended redemption.
What if the ledger shows more than one entry?
Multiple entries can represent an audit trail rather than multiple awards. Ask the vendor to reconcile the entries and show the net final points credited for the order.
