TL;DR: Merchants combine two orders from the same customer expecting one shipment and one invoice. What the threads describe instead is a third order created alongside the originals, inventory committed twice, and a merged order that reporting counts as new revenue. The merge is a supported workflow; reconciling everything downstream of it is manual, and 42 high-scoring threads are people doing that cleanup by hand.
The evidence
PainHunt holds 42 posts scoring 10 or higher out of 15 on order merging and draft-order reconciliation, averaging 12.0/15 with a pain intensity of 7.6/10 and the highest willingness-to-pay signal in this batch at 7.6. The concentration is extreme: 38 of the 42 come from merchant Discourse communities, with the remainder from GitHub. This is operators talking to other operators about a workflow, not consumers complaining about a store.
Four consequences recur.
The merge creates rather than replaces. Combining two orders through a draft order produces a third fulfillable order while the originals still exist. Nothing about the source orders changes until someone changes them.
Inventory gets committed twice. The merged order reserves stock the original orders had already reserved. For a store running close to zero on a SKU, that difference is the gap between accepting an order and overselling it.
Manual cleanup is required and easy to get wrong. Merchants describe cancelling the original orders and restocking their items before fulfilling the merged one — a sequence with an ordering requirement, no confirmation that it worked, and no way to reverse it if it didn't.
The financial side is where it gets expensive. The merged order can be counted as a new sale, inflating revenue, sales, and tax reports. Merchants in these threads are visibly unsure whether marking a merged draft as paid by an external method is the correct way to avoid double-invoicing — which is the sound of people guessing at accounting treatment.
Merchants also state the gap directly: existing merge apps do not automatically reconcile inventory, fulfillment status, and financial reporting after a merge.
Why now
Split orders got more common. Faster checkout, saved payment methods, and one-tap purchase mean a customer who forgot an item places a second order in the next two minutes rather than abandoning the first. The behaviour that creates this problem is a direct result of checkout getting better.
Shipping cost pressure made merging mandatory. When per-order shipping was cheap, sending two parcels was acceptable. With carrier surcharges and free-shipping thresholds, combining is often the difference between a profitable order and a loss — so merchants do it whether or not the tooling reconciles cleanly.
Reporting accuracy stopped being optional. Stores now feed order data into ad platform conversion tracking, inventory planning, and tax filings. An inflated revenue figure used to be a cosmetic problem in a dashboard; now it corrupts bid optimisation and tax reporting downstream.
The wedge
The general build is an order management system. Merchants already have one — it is the platform — and they are not replacing it. The narrow version is a merge operation that owns everything the merge touches.
- Make the merge a transaction, not an action. One operation that creates the combined order, releases the original inventory commitments, cancels or voids the source orders in the correct sequence, and confirms the end state. Partial completion is the failure mode merchants describe, so atomicity is the product.
- Reconcile the financial record explicitly. Emit the accounting treatment the merchant needs — one recognised sale, the source orders neutralised in a way reporting understands, and a note explaining what happened. Guessing at this is exactly what the threads show merchants doing today.
- Ship a reversible audit trail. What was merged, from which orders, by whom, and how to undo it. Merchants will not run an automated operation against paid orders without a rollback path, and asking them to is how a tool with correct logic still fails to get adopted.
- Handle multi-supplier and partial merges. The related threads describe orders spanning several suppliers where attribution matters. Merging only the lines that ship from one place, and keeping the rest intact, is the case generic tools skip and the one that makes the product hard to replace.
- Sell through the operations community. 38 of 42 threads are on merchant forums. That is where the buyer already asks this question, and answering it credibly there is cheaper than any ad.
Risks and honest caveats
- The platform may absorb this. Native merge with proper reconciliation is an obvious roadmap item, and if it ships, the generic version of this product is finished. Build toward the parts that stay messy — multi-supplier attribution, partial merges, reversibility — not toward the button.
- The addressable market is narrow. 42 threads is a real signal about a real workflow, not evidence of a large market. This concentrates in stores with frequent repeat orders from the same customer. Sizing it honestly before building is worth more than the build.
- Writing to financial records is a high-consequence surface. A tool that mishandles cancellation or restocking damages a merchant's books and their stock accuracy at the same time. The support burden of that failure is heavier than the revenue from several customers.
- App-store distribution sets your economics. Platform commission, review cycles, and API deprecations are all outside your control, and a breaking API change lands as an outage for every customer simultaneously.
- Merchants may accept the manual work. Some already have a checklist that works. A product competing with a functioning spreadsheet has to be much better, not slightly better, and the threads do not tell you how many merchants are in that camp.
How to validate this further
The question that decides scope is whether the pain is the manual cleanup or the wrong revenue number, because operations teams and finance teams buy differently and at different price points. Use the PainHunt dashboard to read the merchant threads that mention reporting or tax specifically — those separate the two buyers. Then test whether reversibility alone is enough to get an automated merge adopted, using idea validation.
Related reading: preventing overselling when inventory sync breaks, Shopify proof approval for custom orders.