The order was edited after the money was taken

What it is

An order is a contract and a payment is its settlement, and the two are equal only at the moment of checkout. As soon as someone edits the order, adding a product the customer asked for by e-mail, removing an item that turned out to be out of stock, changing a quantity, adding a custom shipping charge or a manual discount, the order total moves and the captured amount does not. The difference is an outstanding balance the customer owes, or a refund the store owes, and the edit tool leaves collecting or returning it as a separate manual step.

Shopify's order editor states this plainly: after an edit you either send the customer an updated invoice or issue a refund. Nothing forces either. The order can sit with an outstanding balance for months, or ship with the extra item unpaid, or carry a refund due that nobody issued. The mismatch is invisible in a sales report, which counts the edited total, and invisible in the processor, which shows one clean capture.

How it happens

Upsell by e-mail or phone. Support adds a second item to an existing order because that is easier than a new checkout. The invoice for the difference is sent, the customer never opens it, and the warehouse ships both items because the order shows them.

Out-of-stock substitution. A line is removed or swapped after payment. If the replacement is cheaper the store owes a refund; if it is dearer the customer owes the difference; in both cases the person doing the swap is thinking about the shipment, not about the money.

Shipping or duties added after the fact. A remote-area surcharge or a duties line is added as a custom charge. Shipping methods and rates are not recalculated by the edit, so the amount is typed by hand and easy to get wrong, and the invoice for it goes out after the parcel does.

Discounts applied after payment. A manual line-item discount added to placate a customer lowers the total without moving money. The order now shows a refund due, and unless someone issues it the customer was promised a discount and paid the original price.

Edits on an authorized but uncaptured order. Here the capture is still ahead. If the edit raises the total above the authorized amount the capture fails for the difference; if it lowers it, a full capture takes more than the order is worth. Either way the edited total and the captured amount part ways at the moment of capture.

Why it matters

For each edited order there is one number and it has a sign. gap = order.current_total − sum(captures on the order) + sum(refunds on the order). A positive gap is money the customer still owes; if the goods shipped, that is exposure, and once the customer stops answering it is loss: potential_exposure = gap for shipped orders with an unpaid invoice. A negative gap is money you owe the customer; left alone it becomes a dispute, which costs the amount plus a dispute fee, or a refund issued late from the wrong system.

The gap also corrupts the two reports people trust. The sales report counts the edited total as revenue although only the original capture arrived, so revenue is overstated by the sum of positive gaps. The payout reconciliation, which starts from captures, is not affected, which is exactly why the shortfall is never found there.

Volume decides the priority. One edited order a week is a support habit; fifty is a checkout that does not let customers add items, and the fix is upstream of any reconciliation.

How to diagnose

1. List the orders that have been edited. On Shopify, the order timeline records every edit, and the order shows an outstanding balance or a refund due; in the API the current total fields reflect edits and returns while the original total fields do not. Export order id, original total, current total, financial status and the edit date.

2. Join the processor captures on the order reference and sum them per order. Add the refunds on the same order, storefront and processor, and sum those too. Compute the gap with the formula above, keeping the sign.

3. Split by sign and by fulfillment. Positive gap and shipped: send or resend the invoice today, and stop shipping edited orders until the invoice is paid. Positive gap and not shipped: hold fulfillment; the order is not paid. Negative gap: issue the refund from the processor, once, and let the storefront record it, rather than the other way round.

4. Check for the edit that was paid twice. A customer who received an invoice, paid it, and was then also refunded by a colleague shows a gap of exactly the invoice amount with the opposite sign. The order timeline and the two processor objects settle it.

5. Age the list. An unpaid invoice older than the return window is unlikely to be paid; decide whether to write it off or recover the goods, and record the decision so the row stops reappearing next month. Then count edits per week per staff member and per reason, because the cure is usually a checkout or policy change, not a chase.

What AXIOTRA does with it today

The order_payment_mismatch detector is the one that sees this. It matches payments to orders on the order reference and compares each payment's amount with the order total; any difference raises a finding with potential_exposure = abs(payment.amount − order.total), the evidence being the order total and the capture, and the reason offered as partial capture, an edited order, or an add-on applied on one side only. An edited order with one capture therefore appears as exactly the gap, with an unsigned amount, so the finding does not say which way the money is owed; the order's financial status on the finding's order evidence, such as partially_paid or partially_refunded from a Shopify connection, tells you.

Two things to know about the comparison. It reads one order total, not a current and an original one: a Shopify connection stores the order's totalPriceSet, and a CSV stores the total column as given, so the result depends on which total your export carries. And it compares each payment on its own instead of summing them, so an edited order that was paid correctly in two captures still raises a finding whose difference equals the other capture; both findings share one id, so only one is kept in the stored list read by the API. Mark it a false positive after checking that the two captures sum to the total.

Refunds are not part of the comparison. An edit that lowered the total and was settled with a processor refund shows a payment larger than the order total and a refund on the same order; the finding still fires, and the Refunds screen is where you confirm the refund exists. The detector does not read the order's edit history, does not see invoices, and does not know whether a pending invoice was paid; those stay in the storefront until an order-edit kind exists in the ledger.