Reconciliation
Part of Checkout measurement
Tracking order value consistently through checkout
Keep basket, checkout, payment and final-order amounts distinct, with consistent components and currency.
Use four labels throughout checkout: Basket estimate, Pre-payment total, Submitted amount and Final order amount. The basket estimate records the basket when checkout begins; the pre-payment total is the latest payable total shown before payment; the submitted amount is for a payment attempt; the final order amount is the completed storefront order. Keep each value’s currency, timestamp and order or checkout reference.
Match each question to an amount
| Question | Label and amount to use |
|---|---|
| What was in the basket when checkout began? | Basket estimate: the checkout-start item value under a stated calculation rule. |
| What did the buyer see before paying? | Pre-payment total: the latest payable total presented before the payment action. |
| What amount was sent to the provider? | Submitted amount: the amount and currency for that payment attempt. |
| What was the completed order worth? | Final order amount: the completed storefront order under documented completion and adjustment rules. |
Keep a timestamp and order or checkout reference for each snapshot. If delivery or quantity changes recalculate the total, retain the earlier values so the change can be explained. A failed attempt has a Submitted amount, but does not create completed-order value.
Checkout Amount Labels and Their Definitions
- Basket estimateThe basket value when checkout began, under a stated calculation rule.
- Pre-payment totalThe latest payable total shown before the payment action.
- Submitted amountThe amount and currency sent to the payment provider during a payment attempt.
- Final order amountThe completed storefront order value under documented completion and adjustment rules.
Record the parts of the payable total
Use the store’s actual calculation to identify items after discounts, delivery, applicable tax and other charges. Note whether tax is included in line prices or added separately. Label Australian-dollar amounts as AUD, and retain a different charge currency when one applies.
Document the formula and rounding point for each label, including how later order edits, cancellations and refunds are handled. Avoid using a generic value label for merchandise at one stage and the total payable at another. Preserve checkout snapshots and record later changes separately.
Map GA4 fields to the store’s amounts
For begin_checkout, map GA4 value to the Basket estimate at checkout start, and send currency and item-level data. For purchase, map value to the Final order amount, and send currency, transaction_id and item-level data.
Keep the Pre-payment total and each Submitted amount as separate store or payment-attempt snapshots; do not label them as the completed order’s GA4 purchase value. Document the calculation behind each GA4 value so analytics reporting stays distinct from the store’s payable total.
Check how an order-wide discount is represented in the store’s item and order records so it is not subtracted twice. Where item prices already include tax, document how the store derives analytics item value and tax consistently from those prices. Keep analytics reporting measures distinct from the store’s accounting revenue and final amount collected.
Keep the order join reliable
Set GA4 transaction_id on purchase to the stable storefront order reference, and use it to join the GA4 event to that order record. Keep the provider payment reference separately beside the order reference, especially if an amount change leads to another payment attempt.
Define how order references are created and check for empty or reused IDs, which can make event-to-order matching unreliable. This analytics safeguard does not replace checking the store’s own order history.
Key Requirements for Reliable Checkout Data
- GA4 transaction_id
- Must use stable storefront order reference
- Payment provider reference
- Keep separate from order reference, especially after amount changes
- Order reference rules
- Define creation logic; avoid empty or reused IDs
- Analytics vs accounting
- Keep reporting measures distinct from store revenue and collected amounts
Check a changing basket
Run a test order in the permitted test setup: apply a discount, change delivery, make a failed payment attempt, then complete the order. Inspect the events in GTM Preview and GA4 DebugView, checking that begin_checkout appears at checkout start and purchase fires once, only on the order-confirmation page.
Check that each snapshot has the expected amount and currency, and that purchase carries transaction_id, value, currency and item-level data. Pass when the submitted amount matches its payment attempt and GA4 purchase counts and revenue match the store record within a small margin.
Steps to Ensure Consistent Order Value Tracking
- Apply discount and change deliverySimulate real-world basket changes during checkout.
- Make a failed payment attemptVerify Submitted amount is captured without creating a final order.
- Complete the orderConfirm `purchase` fires once on the confirmation page.
- Validate event dataCheck `transaction_id`, `value`, `currency`, and item-level data match store records.
