Order Editing: Fixing Mistakes After a Customer Submits an Order

Reviewed and updated June 2026 — native order-editing limits and the payment/stock/invoice reconciliation rules verified on PrestaShop 1.7, 8 and 9.

A customer places an order. Five minutes later the email lands: "I typed the wrong house number," or "Can I switch that from M to L?", or "I meant to add the matching case." In a perfect world you would just edit the order and move on. PrestaShop will let you do a surprising amount of that — but it draws hard lines in specific places, and the moment you cross one (a generated invoice, a captured payment, a stock movement already booked) a five-second fix turns into a tangle of credit slips and mismatched accounting. This guide is about exactly that surface: what you can safely change on a submitted order from the PrestaShop back office, where the platform stops you and why, and how to keep the customer, the invoice and the stock in sync while you do it.

This is the editing-a-placed-order problem specifically. If your question is more about the day-to-day flow of moving orders through statuses and batching the repetitive work, that's a different job — start with order management workflows that save you hours instead, and come back here when a particular order needs surgery.

Where order editing actually lives

Everything below happens on one screen: Orders → Orders, then open the individual order. Under the hood that's the AdminOrders controller rendering a single order from the Order object, its OrderDetail lines (one row per product/combination), the linked Address, and any OrderInvoice already attached. Knowing those four objects exist explains every rule that follows — when PrestaShop "won't let you" edit something cleanly, it's almost always because changing it would desynchronise one of them from the others.

How much freedom you get before you even open an order depends on the order's current state rather than a single dedicated toggle. PrestaShop has no generic "editable status" flag — what you can change is governed by the order's context: whether an invoice has been generated, whether the order has reached a delivery/shipping state, and whether a refund or cancellation is in play. On PrestaShop 1.7/8/9 the line-item editor (the small pencil and the "Add a product" button inside the order's products panel) tends to be available while the order is still in early statuses and becomes more constrained once invoicing, delivery or shipping has happened — the exact behaviour varies by version. So the first thing to check when "PrestaShop won't let me edit" is simply where the order sits in its lifecycle: its current status, and whether an invoice or delivery document already exists.

What you can change directly — and the catch on each

PrestaShop's native order page handles more than most merchants realise. Here's the honest version of each edit, including the part that bites.

So what does this mean in practice? The address change is genuinely a five-second fix and the single most common request — do it without hesitation on anything not yet shipped. Everything else on that list silently touches one of three other systems: payment, stock, or the invoice. The skill of editing orders cleanly is really the skill of keeping those three reconciled, which is what the rest of this guide is about.

The variant swap: why "M to L" isn't a field edit

This trips up almost everyone. Swapping a size Medium for a Large feels like changing one character, but PrestaShop stores each combination as a distinct product attribute / combination with its own reference, its own stock counter, and its own line in OrderDetail. There is no "change the size" field because, to the data model, Medium and Large are two different things.

The native workflow is therefore: remove the M line (re-stocking the M), add the L as a new line (decrementing L stock), and reconcile any price difference. That's three movements where the customer asked for one, and it's exactly the kind of repetitive, error-prone editing that an in-place swap tool exists to collapse. Our Order Editor module lets you change the combination on the existing line — size, colour, any attribute — and recalculates stock, tax and totals in one action instead of three, so the M goes back on the shelf and the L comes off it without you bookkeeping it by hand. The benefit isn't "fewer clicks" for its own sake; it's that a tired afternoon of order corrections stops producing stock counts that don't match the warehouse.

The three systems an edit can desync — and how to keep them honest

1. Payment

When you add products, raise a quantity or change a price upward, the order total grows but no money moves. PrestaShop reflects this on the order as an outstanding amount; it does not reach back into the customer's card. You have to collect it deliberately — a payment link via your gateway, an offline payment recorded on the order, or rolling it into a follow-up order. The reverse (removing products, discounts) creates a refund obligation that your gateway, not PrestaShop, ultimately settles. The rule of thumb: PrestaShop edits the order's books; it never edits the customer's bank. Treat every total change as a separate "now reconcile the money" step.

2. Stock

When stock management is enabled for the product or combination, adding a line decrements stock the instant you confirm it; removing a line only returns stock if you tick the re-stock option. It is genuinely easy to edit a dozen orders in a session and quietly drift your inventory out of true — the kind of slow desync that makes you distrust your own numbers. If you're already wrestling with stock accuracy, the editing discipline here is one input to the bigger picture covered in inventory management for small online stores, and the re-stocked units feed straight back into your reorder calculations.

3. The invoice

This is the line PrestaShop is strictest about, and for good reason — an invoice is an accounting document, not a draft. Once an OrderInvoice has been generated, editing the order does not rewrite that invoice retroactively. The correct, audit-clean path is to issue a credit slip for what changed and let the corrected amounts flow onto a new invoice document, so the paper trail shows the history rather than pretending the first version never happened. Fighting this — trying to force the original invoice to match — is how you end up with VAT figures that don't reconcile at quarter-end. If your store does enough corrections that this is a recurring chore, our Financial Revolution module gives you more control over invoice and credit-note generation so the documents stay consistent after edits. When the time comes to hand figures to an accountant, getting them out cleanly is its own task — see CSV exports for orders and invoices.

What our Order Editor adds over the native screen

The native order page is capable but conservative: it favours credit slips and add/remove cycles because those keep the accounting unambiguous. That's the right default for the platform, but it makes routine corrections slower than they need to be for a merchant who just wants to fix a human mistake. Our Order Editor closes that gap from the back office — no theme edits, no core overrides, so it survives upgrades:

• Edit quantities in place — raise or lower a line without the remove-and-re-add dance, with stock adjusted to match
• Swap combinations on the line — change size, colour or any attribute without creating two separate movements
• Adjust individual line prices — for price matches and goodwill corrections, with totals and tax recalculated
• Change carrier and shipping cost — re-rate the delivery side of the order in one place
• Automatic recalculation — taxes, discounts and totals re-derive after every edit, so the order stays internally consistent
• Audit trail — every change is logged with who made it and when, which is the difference between "we think someone edited this" and a clean record when a customer disputes an amount

The "So what?" is peace of mind during the messy moments: the busy hour when three customers all want changes at once is exactly when manual remove/re-add/re-stock juggling produces the mistakes you'll be untangling next week.

Edit, or cancel and reorder? A decision framework

Not every change is worth editing the original order — sometimes a clean restart is genuinely simpler. Use the order's progress and the size of the change to decide:

The deciding question is simple: will editing create more reconciliation work than starting fresh? If the answer's yes, set the order to a cancelled status and let a new, correct order carry the real money and stock. If your store is still figuring out which statuses to use for these moments — a "Correction pending" or "Awaiting extra payment" state, for instance — that's worth designing deliberately rather than improvising; see order status workflow customization and automation.

Tell the customer — every time

When you change an order, the person who placed it should hear it from you before they spot it themselves. After any edit:

• Confirm in plain language exactly what changed
• Show the updated order total
• Spell out any payment consequence — an extra charge to collect, or a refund coming back
• Re-send the order confirmation so they have the corrected version in writing

That last point is easy to forget and genuinely appreciated — resending the confirmation after an edit closes the loop without the customer having to ask. It's a small touch with outsized goodwill; we made the case for it on its own in resending order confirmations. The principle underneath all of it: a surprise change, even a favourable one, reads as "they're doing things to my order without telling me," and that erodes trust faster than the original mistake did.

Frequently asked questions

Can you edit an order after it's been placed in PrestaShop?

Yes, a surprising amount — from Orders → Orders, opening the individual order. You can change the address, add or remove product lines, edit a line price (native on 1.7.6+), add a discount, and often adjust shipping. How much is available depends on where the order sits in its lifecycle: the line-item editor is open in early statuses and tightens once an invoice has been generated or the order has reached a delivery/shipping state. There's no single "editable" toggle — the order's context governs it.

How do I change a product size or colour on an existing order?

Natively, you can't edit the variant in place — PrestaShop stores each combination (Medium, Large) as a distinct item with its own stock counter and order line. The native workflow is to remove the M line (re-stocking the M), add the L as a new line (decrementing L stock), and reconcile any price difference: three movements for one request. Our Order Editor module changes the combination on the existing line and recalculates stock, tax and totals in one action.

If I add a product to an order, does the customer get charged automatically?

No. PrestaShop edits the order's books; it never reaches into the customer's bank. Adding a product raises the order total and shows an outstanding amount, but you must collect the difference deliberately — a payment link via your gateway, an offline payment recorded on the order, or a follow-up order. The reverse (removing products or adding a discount) creates a refund obligation your gateway settles, not PrestaShop.

Why won't PrestaShop let me edit the order after an invoice exists?

Because an invoice is an accounting document, not a draft. Editing the order doesn't rewrite the invoice retroactively. The audit-clean path is to issue a credit slip for what changed and let corrected amounts flow onto a new invoice document, so the paper trail shows the history. Fighting this — forcing the original invoice to match — is how VAT figures stop reconciling at quarter-end. For stores doing this often, Financial Revolution gives more control over invoice and credit-note generation.

Should I edit the order or cancel and let the customer reorder?

Edit for small, clean changes: a wrong address on something unshipped, a quantity or single-variant change with no payment shift, a minor price correction. Cancel and reorder when the change is large: completely different products, a major payment swing either way, or an order that's already partly shipped. The deciding question is whether editing creates more reconciliation work than starting fresh — if yes, cancel and let a new, correct order carry the real money and stock.

The best edit is the one you never make

Order editing is a necessary operational capability — but a store that needs it constantly usually has a fixable leak upstream. A few investments quietly drain the queue of correction requests:

• Better product information. Clear descriptions, size guides and combination charts cut "I ordered the wrong one" requests at the source — the most common variant-swap trigger is a customer who genuinely wasn't sure which option they were picking.
• Address validation at checkout. Catching a malformed postcode before submission prevents the single most frequent edit there is.
• An honest final review step. A checkout that shows the customer everything they're about to buy — with a visible running total — turns "I didn't realise" into "I confirmed it."
• A short self-service window. Letting customers cancel and re-place within the first hour, before fulfilment starts, moves the easy corrections off your desk entirely.

Editing a submitted order well comes down to one habit: respect the three systems an order touches. Change the words and the address freely; change the money, the stock or the invoice only with your eyes open and the reconciliation step queued up right behind it. Do that, and the panicked "I made a mistake" email becomes a thirty-second fix instead of a quarter-end headache.