Skip to main content

Sail POS & Focus POS: A tip edit failed after batch settlement - the tip isn't lost, it needs a rekey

Summary. Explains why editing a tip after the credit card batch has settled will fail, why that's expected behavior rather than a system problem, and what actually needs to happen next so the tip gets paid correctly.

Applies to. Sail POS and Focus POS - all current versions.

Before you start

  • Know whether the batch for the date in question has actually settled - check batch status in Backoffice/Functions, or the Batch Report by Date.
  • On Sail, know that a batch can close even if nobody at the restaurant triggered it: if the POS fails to close the batch at its scheduled time, the processor has a failsafe that closes it anyway. Focus does not have this processor-side failsafe - its batch only closes when the POS itself runs it.

What's happening

Both platforms typically batch and settle transactions automatically overnight. Once a batch settles, every transaction inside it is locked with the processor - no further changes, including tip edits, can be made to those original transactions from the POS. This is true whether the batch closed on its normal schedule or, on Sail, via the processor's failsafe.

Why this looks like an emergency (but isn't)

A server or manager tries to adjust a tip - often the next morning - and the edit fails, won't save, or the field is greyed out. It's easy to assume something is broken or that the tip has been lost, which is why this often comes in as a panicked call. In reality, this is expected behavior once a batch has settled, not a malfunction. Think of it like mail: once the carrier has picked up the envelope, you can't reach back in and add something to it. A settled batch works the same way - those transactions have already been picked up.

What to do

  1. Confirm the batch for that transaction's date has actually settled (Batch status in Functions, or Batch Report by Date in Backoffice).
  2. If it has settled, don't keep retrying the tip edit or restarting terminals - that won't fix it, because the transaction itself is locked, not the software.
  3. Submit a support ticket describing it as a tip rekey. This routes to the payments team, who runs a new, separate transaction for the correct tip amount - the original transaction can't be touched once its batch is settled, so a rekey is the only path. Link to rekey form https://form.jotform.com/ingage/rekey-authorization  
  4. Let the server or manager know the tip isn't lost - it's paid out through the rekey, just via a different mechanism than a normal same-transaction edit.

Verify it worked

  • The payments team confirms the rekey transaction has processed and the correct tip amount is reflected once that new transaction settles.

If it doesn't work

  • If the batch has not actually settled yet and the tip edit is still failing, that's a different problem - treat it as a normal POS issue and troubleshoot or escalate as you would any other failed edit.
  • This scenario doesn't call for on-call escalation as a "true emergency" - there's no keep-serving step because it doesn't interrupt operations. It's a back-office correction handled through a support ticket, not something to treat with the same urgency as a system outage.