How do you handle last-minute order changes without creating duplicates?

Who this is for: Small and mid-sized US wholesale distributors on QuickBooks Online whose customers change orders after sending them.

Common pain points

• The change arrives separately from the order — a second email, a phone call — and becomes a second order
• There's no single 'current state,' so two people can apply the same edit twice or each miss it
• A change that lands after export means editing a record you already sent to QuickBooks Online
• Vague edits like 'add a couple more cases' get missed, half-applied, or applied twice

The workflow

1. Keep one live order per request. Each order is a single live draft. New messages about it — a reply, a correction, a follow-up — attach to that draft instead of starting a new record.
2. Let the change attach to the existing order. A follow-up email routes to the active draft; a phoned change is recorded against the same order by hand. There's always one current state.
3. Review the proposed delta. The change appears as a before-and-after on the affected lines, with the source message shown — you don't re-read the whole thread.
4. Approve, correct, or ignore. Confirm the change, fix it, or dismiss it. Anything ambiguous is flagged for review rather than applied automatically.
5. Re-check pricing and totals. Changed lines re-price with that customer's rules, so the order total stays correct after the edit.
6. Export the updated order once. The single, corrected order exports to QuickBooks Online as an Estimate by default (configurable), or to Google Sheets or CSV — one clean record, not two.
7. Handle post-export changes as amendments. If a change arrives after export, it becomes an explicit amendment against the original with a clear diff — never a silent edit of a record you already sent.

Where duplicates come from

Duplicates happen when a change becomes a new order instead of an edit to the existing one. A customer emails an order, then sends "actually, make it 20, not 10" in a new thread — and whoever catches the second message starts a second order. The clean way to handle last-minute changes is to keep one live order per request that absorbs edits, show what changed and where it came from, and — once the order has been exported — record further changes as explicit amendments instead of silently editing the record.

That sounds simple, but it breaks down fast in real operations, because changes arrive at the worst times, often as shorthand, and often separately from the original order. The cost isn't just confusion — it's double-shipped lines, stale exports, and totals nobody trusts. For small and mid-sized US wholesale distributors on QuickBooks Online, this page covers how to keep one order one order.

Why do changes turn into duplicates?

It's rarely carelessness. The structure of how orders arrive almost forces it:

• The change arrives separately from the order. The original comes by email; the correction lands in a fresh thread, or the customer calls. Two messages, two places someone might act — and a second order is born.
• There's no single "current state." When the live order exists in someone's head, an email thread, or a spreadsheet row, two people can each apply the same change — or each assume the other did.
• The order's already gone downstream. After export to QuickBooks or a sheet, a late change means touching a record you already sent — which quietly creates stale data, or a duplicate when someone re-exports the "new" version.
• Changes are vague. "Add a couple more cases," "skip the blue ones," "make it 20." Buried in a thread, these get missed, half-applied, or applied twice.
• Nobody can see what changed. With no before-and-after, a changed order has to be re-read end to end — and when that's too slow, people rebuild it from scratch. Rebuilding is duplicating.

Every one of these points to the same fix: one order that holds its current state, absorbs changes with a visible trail, and treats post-export edits as amendments.

What are the ways to handle changes?

Email threads and spreadsheets. The default: the change lands in the thread, someone updates the row or the draft invoice — or, when it's busy, starts a fresh order to be safe. Works at very low volume with one person owning every order end to end. Breaks as soon as volume rises or a second person touches orders: edits get missed or doubled, and "just make a new one" becomes a habit.

A portal where buyers edit their own orders. For the buyers who'll log in and self-edit, a portal keeps one record clean. The buyers who won't — and many won't — keep emailing and calling their changes, so you're back to threads for exactly the orders most likely to change. And many rigid systems can't gracefully edit a confirmed order: the workaround is cancel-and-rebuild, which is a duplicate by another name.

A live draft that absorbs changes. The model built for the problem, and the one PeasyOrders uses. Each order is one live draft; every new message about it is an event that updates it, not a new record. The system proposes the change as a before-and-after on the affected lines, with the source message attached, and flags anything unclear. You approve, correct, or ignore; changed lines re-price with that customer's rules. There's one active draft until you export — and after export, a later change opens an explicit amendment against the original snapshot, so your downstream numbers stay honest.

One thing PeasyOrders won't do is auto-apply changes. It proposes and flags; you confirm. A last-minute change you can see and approve is safe. One applied silently isn't.

How does the live draft actually work?

A few mechanics make it trustworthy:

• One draft per conversation. The order and everything about it — the original message, the follow-up, the correction — accumulate on a single live draft with a single current state.
• Changes arrive as proposals. A follow-up email is read the same way the order was; the difference it implies shows up as a proposed delta — before and after, per affected line — never as a silent rewrite. A phoned change is recorded against the same order by hand.
• Everything has a source. Every value on the order shows where it came from: the original email, the follow-up, a pricing rule, a teammate's edit. The order also shows the last message received versus the last change applied, so a pending edit is visible at a glance.
• Pricing re-checks itself. Changed lines re-price with the customer's current rules, so "make it 20" doesn't leave a total computed for 10.
• Post-export changes become amendments. The exported Estimate in QuickBooks Online stays as the snapshot of what you sent. A change after that point is an explicit amendment with a clear diff — reviewed and confirmed like everything else.

Which approach fits you?

• A handful of orders, one owner, rare changes: email threads may genuinely be enough.
• Buyers who'll log in and self-edit: a portal covers them — but only them.
• Changes arrive as messages and calls, or two or more people touch the same orders: you want the live draft with proposed deltas.
• You export to QuickBooks or Sheets and fear stale edits: you want amendments — an explicit record of what changed after the fact, not a quietly edited row.

If your changes mostly arrive as messages — and your buyers won't change that — threads and portals leave the duplicates exactly where they start: in the inbox.

The bottom line

Last-minute changes aren't the problem — losing track of them is. When a change becomes a second order, you ship twice, export stale numbers, and chase totals that don't add up. Keep one live order that absorbs each change with a visible before-and-after, review the delta before it applies, and treat post-export edits as explicit amendments. That's how PeasyOrders is built: one order, every change tracked to its source, nothing duplicated — and nothing changed behind your back.