Correcting a Sale

Correcting or deleting a sale

Automatic sale detection is careful, but the real world is messy: an email can arrive garbled, a hand-recorded sale can carry a typo, or a duplicate can sneak in. Every sale row has an Actions column so you can fix any of it in seconds.

The Actions column

On Sales > All sales, the last column holds up to three small buttons:

  • Pencil - edit the sale's numbers and date.
  • Refund arrow - record or edit a refund (see the Refunds and returns article).
  • Trash - delete the record entirely.

(screenshot: the Actions column on a few rows)

Editing a sale

Tap the pencil to change Sold for, Fees, You keep, or the sale date. A couple of things happen for you:

  • If you correct Sold for on a cash sale where tax is included (like a Facebook Marketplace sale), the tax and your take-home are recalculated automatically.
  • Numbers you set here are yours. Automatic detection never overwrites a sale that is already recorded.

Deleting a record

Tap the trash and confirm. Deleting removes the record from RelistKit only: nothing changes on the platform, and the item keeps its current status. If the wrong sale had marked an item Sold, open the item and set its status back; the confirmation reminds you.

If the same order's email ever arrives again, the sale is simply recorded fresh, so deleting a botched record and letting a re-forwarded email recreate it is a perfectly good repair.

Behind the scenes (internal, cut before publishing)

  • Decision #55 amendment (2026-08-31 review). PATCH /sales/{id} whitelist: label_cost_cents, shipping_charged_cents, gross_cents, fee_cents, net_cents (null clears, negatives 400), sold_at (Y-m-d, stored as noon UTC). Gross changes re-derive the tax stamp ONLY when the stored treatment matches what current settings produce (forward-only preserved); included-mode net follows unless net was set explicitly in the same call.
  • DELETE /sales/{id}: hard delete of RelistKit's row, account-scoped, item status untouched by design (the confirm dialog says so). Ingest dedupe is by (platform, external_order_id), so a re-forwarded email recreates the sale -- intended.
  • The edit modal sends ONLY changed fields, so an untouched You-keep field lets the server re-derive included-mode net when gross is corrected.
  • Manual sales (e.g. Facebook cash) are RECORDED from item detail: status to Sold + sold price + "where did it sell" creates the sale via record_manual. This article covers correcting after the fact.