Full Answer

GA4's ecommerce model is append-only. A purchase event is a snapshot: it fires once at checkout with a transaction ID, a value, and an items array, and that snapshot is final. Google's own recommended-events reference (https://support.google.com/analytics/answer/9267735) lists purchase and refund as the complete revenue vocabulary — there is no adjust_purchase, no order_update. When an admin edits an order, WooCommerce rewrites its own totals and moves on. Nothing fires toward GA4.

Here's the thing: the stores hit hardest are the ones editing orders as normal practice — B2B quotes finalised by phone, stock substitutions, goodwill discounts applied after checkout. Day to day, GA4 looks healthy. Transaction counts match, IDs match, funnels render. Only the values are wrong, which means Smart Bidding and every ROAS decision downstream is optimising against fiction. Seresa's analysis of order-edit revenue loss (https://seresa.io/blog/data-quality-validation/woocommerce-order-edits-are-permanently-breaking-your-ga4-revenue) walks through how the divergence builds and why standard reconciliation reports miss it.

The correction has to happen server-side, because that is the only place the order lifecycle is visible. WooCommerce fires hooks whenever an order changes; a server-side pipeline listening to those hooks can compute the revenue delta and route a corrective event — a refund for reductions, a Measurement Protocol adjustment for increases. That can be scripted by a developer against the Measurement Protocol, or handled by tooling built for the job, such as Seresa's Transmute Engine, which listens to order lifecycle hooks for exactly this class of drift.