Ecommerce platforms measurement: matching order, payment and settlement records across platforms and providers

An England merchant should report events it can reconstruct, not whichever total happens to occupy a platform card. An order, payment authorisation, capture, settlement, return and refund answer different questions. They need separate definitions and reconciliation before anyone interprets performance.

This guide to ecommerce platforms measurement uses a reference case: an English legal seller offering its own non-regulated physical products to adult consumers in the UK. Marketplaces, credit and third-party sellers require extra analysis. It uses no live store data and claims no result.

What to take away

Report each order and payment transition separately rather than relying on a platform total.
A rate is meaningless without a stated eligible population and denominator.
Keep catalogue price, captured value, settled cash and accounting revenue in separate fields.
Attribution assigns credit by model and is not proof of cause.
A dashboard should start with data health before showing sales totals.

Start with the decision

A report exists to support a named decision. The owner might need to pause a broken checkout, investigate settlement differences, change stock allocation or assess whether a controlled change deserves expansion. Write that decision before selecting a chart.

For every measure, maintain a definition record containing:

event or state and its evidence;
eligible population;
numerator and denominator, or a stated currency or duration unit;
period, timezone and treatment of boundary events;
source system, export or query and definition version;
test, duplicate, cancelled and other exclusions;
missing and late-data treatment;
accounting and VAT basis for money;
owner, reviewer and next review trigger.

The Office for National Statistics describes statistical quality through relevance, accuracy, timeliness, accessibility and comparability in its quality definition. That framework is for official statistics, but the questions are useful discipline for a merchant report. It does not validate a private dashboard.

Measure the order and payment chain

The operational ledger should preserve each transition rather than overwrite an order with its latest label. A practical reporting sequence is:

order submitted;
order accepted or rejected under the merchant's contract rule;
payment attempted, authorised or declined;
payment captured;
goods allocated, dispatched and delivered or excepted;
cancellation, return or other remedy requested;
refund initiated and completed;
dispute opened and resolved;
provider settlement received and reconciled.

Do not use submitted orders as a substitute for accepted orders. Do not call an authorisation cash. A capture is not the same as bank settlement, and settlement is not automatically revenue. Each count should use distinct identifiers, event timestamps and permitted state transitions.

Shopify's current sales-report definitions illustrate why labels need a local translation. Its gross sales can include pending, cancelled and unpaid orders, while its net sales subtract discounts and sales reversals. The same documentation says sales reports do not track payments moving between customer and merchant. Those are Shopify definitions, not general accounting rules.

The Shopify Payments activity report is similarly explicit that balance activity and payouts are not an accounting revenue statement. It can include fees, refunds, disputes, holds and other movements. A merchant using another provider needs that provider's current record instead.

Platform and provider records differ

Shopify is used above because its public documentation states these definitions plainly. Each platform and payment provider names its order-to-settlement records differently, and a merchant moving between them must map the fields rather than assume equivalence. Menu paths and report names change between versions, so confirm each one in current documentation.

Stripe:the Balance page shows available and pending funds; the Payouts report lists each bank transfer with a payout ID; PaymentIntent objects carry statuses (requires_payment_method, processing, succeeded, canceled) that map to the order chain above.
PayPal:the Activity log records each transaction with a Transaction ID; Reports > Payouts shows settlement transfers; the API returns capture and refund objects with their own identifiers.
Adyen:the Settlement Detail report lists authorisation, capture, refund and chargeback per transaction, matched by Merchant Reference and PSP Reference.
Worldpay:Settlement Statements and Transaction Reports provide per-transaction capture, refund and fee lines matched to an Order Code.

On the platform side, WooCommerce records orders under Orders > Reports > Sales by date and keeps payment-gateway transaction logs under WooCommerce > Status > Logs. BigCommerce exposes Reports > Store Overview and per-provider transaction records. Adobe Commerce (Magento) uses Marketing > Reports > Orders and Sales > Transactions. Squarespace and Wix each publish their own order and payment status fields in their admin panels, which must be read from the current documentation rather than assumed from another platform.

A merchant comparing ecommerce platforms, or moving a store between them, should carry the definition record across rather than the dashboard. One platform's net sales figure is not another's net revenue. Reconciliation requires matching keys: the platform order ID must link to the payment provider's transaction or payment-intent ID, which in turn links to the payout or settlement line item, which must match the bank reference on the merchant's statement. When a key is absent or changes format between systems, the exception must be logged and investigated before the total is reported. Shopify Payments' payout schedule, hold periods and any reserve terms are stated in the provider's current merchant agreement and documentation at the time of setup; a merchant must record which version applied to each settlement batch.

The same task on each platform

Use these four tasks as the common field map when you compare platforms. Names change, so confirm each in the current documentation.

Find the order and its payment reference.Shopify keeps the order and its payment transactions together on the order record. WooCommerce stores the gateway transaction ID against the order. BigCommerce attaches the payment provider's transaction ID to the order. Adobe Commerce lists payments under Sales > Transactions.
Separate authorisation from capture.Stripe shows the PaymentIntent status. PayPal returns a capture object. Adyen reports capture per PSP Reference. Worldpay reports capture lines on its transaction reports.
Link the payment to the payout.Stripe links each balance transaction to a payout ID. Shopify Payments lists the transactions inside each payout. PayPal's payout report and Adyen's settlement detail report serve the same purpose.
Link the refund to the original payment.Every provider above records a refund against the original transaction identifier, so keep that key in your reconciliation table.

The comparison shows where a merchant must supply its own key. Shopify and Stripe name the payout link directly, while self-hosted WooCommerce depends on the chosen gateway to supply it.

Give ratios honest denominators

A rate without an eligible population is not reproducible. Define checkout completion, for example, as eligible sessions with the approved completed-purchase event divided by all eligible sessions that reached the agreed checkout-start event. State how consent choices, bot filtering, blocked scripts, multiple devices and repeat purchases affect coverage.

Even within one product, similar labels may count different things. Shopify's analytics fields reference contains rates based on sessions, product views or checkout-reaching sessions. Copying a percentage without its denominator changes the measure.

Using the same discipline, a starting set of formulas is: conversion rate = eligible completed-purchase sessions ÷ eligible checkout-start sessions; average order value = recognised revenue ÷ accepted orders; refund rate = completed refunds ÷ captured orders; chargeback rate = disputes opened ÷ captured orders. State the period, currency and tax basis beside each, and record the definition version.

Browser measurement is conditional on privacy design. The ICO's storage and access technologies guidance is now final after consultation.

It covers cookies, tracking pixels, link decoration and related technologies, including their use in advertising measurement. A privacy and PECR lawyer must review the configured purpose, information, consent or exception and withdrawal route. Missing tracking does not permit inferring the absent people.

Keep commercial values apart

Create separate fields for catalogue price, gross sales under the selected supplier definition, discounts, cancellations or reversals, tax, shipping, refunds, disputed sums, provider fees, captured value, settled cash and accounting revenue. Then define net contribution with merchant-owned cost inputs; the whole-life budget separates cash, accounting and economic cost, and the return on investment framework shows how to use the result.

A blank working formula can be:

net contribution = eligible recognised revenue - refunds and reversals - cost of goods - fulfilment - payment costs - incremental service and marketing costs

The accountant decides revenue recognition and ledger mapping. The tax adviser determines VAT treatment and period. GOV.UK's VAT record-keeping guidance sets requirements for VAT-registered businesses, but it does not turn a platform total into the correct return value.

Returns and refunds must not collapse into one event. A physical item can return without an immediate refund; a refund can occur without a physical return. Shopify documents this distinction in its sales discrepancy guide. The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 set the statutory fourteen-day cancellation duty, with refunds due within a further fourteen days of the goods coming back or proof of return, for distance sales to consumers in the UK. The merchant's consumer lawyer should separately review actual cancellation and remedy treatment against GOV.UK's online and distance selling guidance.

Build a dashboard from reconciled layers

The first dashboard layer reports data health: expected feeds received, latest complete event time, unmatched identifiers, duplicate events, late adjustments and definition changes. A colourful sales total is unsafe when its source stopped loading yesterday.

The second layer shows the operational path. Include eligible products, stock exceptions, accepted orders, capture exceptions, fulfilment delays, cancellation and return cases, refund completion, disputes and unresolved support. Each tile links to an inspectable case population.

The third layer covers cash and accounting reconciliation. Display capture, provider balance movement, settlement, bank receipt and ledger status independently. Use original currency and approved conversion evidence. Put VAT-inclusive, VAT-exclusive or outside-scope treatment beside each monetary measure, not in a footnote.

The fourth layer contains interpretation. Annotate catalogue changes, outages, campaigns, consent changes, supplier releases and reporting breaks. Separate observed value from supplier-reported value, modelled estimate, attributed value, forecast and causal estimate. Blank is better than a category chosen by guesswork.

Protect the evidence behind the report. NCSC's logging and monitoring guidance recommends a proportionate approach, protection from tampering and testing that expected logs still arrive. Record the query version and access history without collecting unnecessary customer content.

Attribution is a rule, not proof of cause

Marketing attribution assigns credit according to a model. Shopify's current marketing-report documentation describes first-click, last-click, last non-direct click, any-click and linear allocation. Its any-click method can allocate more credit than the number of orders received. That is a particularly clear reason to label attributed orders and sales rather than adding them as observed totals.

Platform-reported attribution depends on identity matching, interaction windows, channel coverage and model rules. Compare methods only on the same eligible orders, period, timezone, currency, exclusions and interaction evidence. Retain unattributed cases. Do not choose the model that produces the largest number.

Causal incrementality asks what happened because of an intervention. HM Treasury's current quality in policy impact evaluation guidance distinguishes observing an outcome from attributing it to an intervention and explains the role of a credible counterfactual. It is public-policy guidance, not an ecommerce benchmark. The principle still exposes a common error: before-and-after movement alone rarely isolates cause.

If the merchant lacks a proportionate comparison design, report the outcome and the platform attribution separately. Call any commercial explanation an editorial interpretation and list competing causes. A statistician and measurement lead should approve any causal claim.

Refuse incompatible benchmarks

There is no single defensible England ecommerce-platform conversion or revenue benchmark in the official sources reviewed for this guide. ONS publishes current internet retail sales data for Great Britain by store type, month and year. That population, geography and measure do not describe England merchants on a particular platform.

A benchmark candidate needs an evidence passport: publisher, field date, geography, merchant population, goods mix, channel, numerator, denominator, currency, tax basis, collection method, exclusions, sample coverage, uncertainty and definition version. Reject a candidate when one of those fields blocks like-for-like use. Do not average incompatible numbers to disguise the gap.

An internal reference is often more useful. Freeze the merchant definition, compare equivalent periods where operational conditions are understood, mark breaks and show uncertainty. It is still an internal comparison, not an industry norm.

Set blank decision thresholds

The dashboard owner proposes thresholds after observing data quality and normal process behaviour. Consumer, safety, privacy, accessibility, payment, accounting and tax gates can stop activity regardless of a commercial result. Leave numeric fields blank until the authorised owner records the evidence and response.

Useful decision rules state the trigger, minimum evidence, owner and action. For example, a missing settlement match can open an investigation; a failed product-safety gate can suspend sale; and a material definition change can block period comparison. None requires an invented percentage.

At each reporting cycle, sign off source completeness, reconcile event populations, review exclusions, explain revisions and list unresolved unknowns. Hold any decision when the denominator cannot be reconstructed, money does not reconcile, tracking permission is unproved, a benchmark population is incompatible or a causal label lacks an acceptable design.

Before you act

Write the named decision before choosing a chart.
Define the eligible population for every rate.
Separate returns from refunds as distinct events.
Reconcile capture, settlement and bank receipt independently.
Label attributed values rather than adding them as observed totals.
Record the query version and access history.

Common questions

Why should submitted orders not be used as accepted orders?

Acceptance depends on the merchant's contract rule, so a submitted order is not yet an accepted one. Each transition in the order and payment chain answers a different question, so counts should use distinct identifiers, event timestamps and permitted state transitions rather than one latest label.

What is the difference between a capture and settlement?

A capture is not the same as bank settlement, and settlement is not automatically revenue. Each count should use distinct identifiers and permitted state transitions, and the cash layer should display capture, provider balance movement, settlement, bank receipt and ledger status independently.

Why can attributed orders exceed the number of orders received?

Shopify's any-click method, for example, can allocate more credit than the number of orders received. Attribution assigns credit according to a model, so attributed orders and sales should be labelled rather than added as observed totals, and methods compared only on the same eligible orders and period.