> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# How to edit an existing order
> Change a live order without breaking what sits behind it — moving dates, adding and removing items, answering the price prompt, and reconciling the stock and the money the edit leaves behind.
orders
Orders change after they are taken. A customer wants the bike for another day, drops one of the two helmets, or the booking was entered with the wrong dates and only noticed at pickup.
An order is edited in place. There is no amend-and-reissue step, and no version of the order to reconcile against. What makes editing worth a guide is not the form — it is that a single change ripples: the price for the new dates may not be the price on the line, the stock behind the item may have to move, and the money already collected does not follow the total on its own.
This guide is the edit plus the three things it leaves behind. For the line item editor control by control, see the [Line Items tab](/docs/orders/order-tabs/line-items).
## Prerequisites
**Required permissions:** `orders:order` in manage to change the order, and `orders:order_line_items` in create, manage and delete to add, edit and remove its lines. All four system roles — Owner, Admin, Manager and Member — hold every one of these. See [Users & Roles](/docs/settings/users-roles).
**Have ready before you start:**
* **An order that is still editable.** Closed and archived orders are read-only, and both say so in a banner at the top. See the first step.
* **What is actually changing** — dates, quantity, which items, or the price. Each has a different downstream cost.
* **Whether money has already been collected.** An edit moves the total; it does not move the payments. Check the [Payments](/docs/orders/order-tabs/payment) tab before you change anything priced.
## The Walkthrough
Open the order and look at the top of the page.
* **A closed banner** — the order is read-only. Set the status chip back to **Open** or **In progress** to reopen it, then edit.
* **An archived banner** — unarchive from the banner itself first. The status chip will not respond until you do.
* **No banner** — it is editable.
How much you can change also depends on where the order has got to. An **Open**, unfulfilled order takes any change. An **In progress** order takes extensions and additions, but items already handed over cannot simply be removed. See [Edit rules at each stage](/docs/concepts/orders/order-lifecycle#edit-rules-at-each-stage).
Go to the **Line Items** tab and click the row you are changing. The line item editor opens with its current values.
This is the same editor used when adding an item, in edit mode. Two things behave differently here than they did on the storefront, and both are deliberate:
* **Past dates are selectable.** The calendar goes up to 24 months back, so an order that began before anyone entered it can be recorded with its real dates. Auto-preselection still defaults to today, so backdating takes a deliberate click.
* **The location's fulfilment hours do not cap the times.** Staff decide when they can hand over and take back. Stock availability still applies.
Change **Start** and **End** — or **Sales date** on a sale — and let the availability check settle before you save.
**The line item does not block its own edit.** When you re-date an item, its existing reservation is taken out of the availability check, along with those of its add-ons and the buffer windows around them. Extending a two-hour booking by an hour therefore does not report a clash with the buffer that booking itself created.
What is *not* excluded is everything else. Other line items on the same order hold their reservations normally, and an edit that collides with one is reported unavailable like any other clash. Full rules in [Editing an existing line item](/docs/concepts/catalog/availability#editing-an-existing-line-item).
If the dates come back refused, the editor says which end is the problem — **Selected start date is not available**, **Selected end date is not available**, or **The selected dates and booking option are not available. Please select different dates or a different booking option.**
**Changing the dates does not change the price.** The unit price on the line is kept deliberately, which means it can now disagree with what the catalog charges for the new dates.
You find out on save. Where they differ, **Unit price differs from list price** opens and shows both — **Manual unit price** and **List price for selected dates** — with three ways out:
| Choice | Result |
| ---------------------- | ------------------------------------------------------------------ |
| **Apply manual price** | Keep the price the line already had. The order total does not move |
| **Apply list price** | Reprice to the catalog's price for the new dates |
| **Cancel** | Back to the editor, nothing saved |
Neither answer is the safe default — that is why you are asked. Honouring a quote you already gave means **Apply manual price**; charging for the extra days means **Apply list price**.
The prompt is for catalog line items in edit mode only. Custom items, add-ons and subscriptions never raise it: an add-on's price derives from its parent, and a subscription prices off frozen plan terms. And when the two prices already agree, the line saves with no prompt at all — so no prompt does not mean no price change is due.
**To add:** **+ Add**, then **Listing**, **Add-on product**, **Stock Item** or **Custom item**, exactly as when the order was taken. An add-on can attach to one line item or to the whole order.
**To remove:** select the rows on **Line Items** and use **Remove line items** in the action bar. The confirmation counts what you are removing.
Removing a line releases the stock it held. Removing a line that has been paid for does not refund it — see the money step below.
An edit that moves dates or quantity can leave the assigned units wrong: a unit that was free for the old dates may not be free for the new ones.
Check the [Stock Items](/docs/orders/order-tabs/stock-items) tab. Every line should carry the units it needs, in a sensible fulfilment state. A conflict banner at the top of the order means a unit is double-committed — see [Stock item conflicts](/docs/concepts/orders/stock-item-conflicts).
Watch the fulfilment states too. An item already marked **Fulfilled** is out with the customer; re-dating around it does not bring it back.
**The total is recalculated; the payments are not.** The order's unpaid balance is the current total less what has been captured, so an edit moves the balance the moment it saves:
* **The total went up** — the order returns to **Unpaid** for the difference. Collect it with **Payment**, the same three ways as on a new order.
* **The total went down below what was captured** — the order is overpaid. Nothing refunds automatically; issue the refund from the [Payments](/docs/orders/order-tabs/payment) tab.
* **A deposit is involved** — deposits are tracked on their own balance and are not adjusted by a change to the order total.
Do this in the same sitting. An edited order with a stale balance looks settled in the table and is not.
## How do I know it worked?
* **The line item shows the new dates and the price you chose** on the Line Items tab — not the list price you did not pick.
* **The order total matches** what you intend to charge, and the **Payment** chip reads **Paid**, or **Unpaid** for a balance you know about and mean to collect.
* **Every line carries stock**, with no conflict banner at the top of the order.
* **The old dates are free again** — the released period shows as available for the units that were holding it.
* **The [Activity Log](/docs/orders/order-tabs/activity-log) carries the change**, with who made it and when. On a disputed booking this is the record.
## Troubleshooting / Common Pitfalls
**Cause:** it is closed or archived. Both make the order read-only, and both show a banner.
**Solution:** reopen a closed order by setting the status chip back to **Open** or **In progress**. An archived order must be unarchived from its own banner first — the status chip will not respond until then.
**The item is not blocking itself** — its own reservation and buffers are excluded from the check. Something else is holding the time.
**What to check, in order:**
1. **Another line item on the same order.** These are not excluded, and are the most easily missed because they are on the screen in front of you.
2. **Another order** over the new period.
3. **The buffer of a *different* booking** that starts after yours ends.
4. **A maintenance reservation or a unit at another location.**
[Work out what is available, and why something is not](/docs/guides/inventory/check-availability) walks the whole list.
**Working as designed.** The unit price is kept when dates move, deliberately — it protects a quote you already gave the customer.
**What to do:** to reprice, either answer **Apply list price** when the prompt appears on save, or set the **Unit price** yourself in the editor. The **Apply list price** button under the field snaps it to the catalog price for the currently selected dates.
**Three reasons it stays silent**, all of them normal:
* **The prices already agree** for the new dates, so there is nothing to decide.
* **The line is an add-on or a subscription.** An add-on is priced from its parent and a subscription from frozen plan terms, so the catalog's standalone price is not the right comparison to offer.
* **The line is a custom item.** It has no catalog price to differ from.
The prompt only ever fires for a catalog line item being edited. Treat its absence as "nothing to choose", not "nothing changed".
**Cause:** you answered **Apply list price** and the new dates price higher. The total moved, the captured amount did not, and the difference is now outstanding.
**What to do:** collect it, or reopen the line and apply the manual price instead if the customer was quoted the old figure. Both are legitimate — the point is that the edit has already made the choice, so decide it deliberately.
**Removing a line does not refund it.** The stock is released and the total drops, which leaves the order overpaid rather than settled.
**What to do:** issue the refund from the [Payments](/docs/orders/order-tabs/payment) tab. Nothing reconciles this on its own, and the order will not flag it.
**Cause:** the change committed a unit that something else also holds over the new period.
**What to do:** the banner points at the affected items. Resolving it means swapping one side onto a different unit or moving the dates. See [Stock item conflicts](/docs/concepts/orders/stock-item-conflicts).
## Next Steps
The whole arc, from creating the order to closing it on return.
The line item editor, control by control.
What the check counts, and what it excludes when you edit.
What each stage lets you change.