Reconciling shop orders: find gaps in revenue tracking

Why the shop and analytics show different numbers

A shop and a web analytics tool count orders in different places. The shop creates the order as soon as the buyer presses the order button. A tracker only sees it if the confirmation page loads completely in the buyer's browser and its script runs there. In between lie payment services, redirects, browser extensions and sometimes a telephone receiver.

This suggests a division of labour: how many orders came in is known to the shop. Which channel and campaign brought the buyers is known to the tracker, because only the tracker knows the visit. A reconciliation connects the two and shows how large the share of orders without a measured visit is.

How far apart the numbers are varies from shop to shop. An audience with many young buyers, a high share of payments through external services or a sales team that takes orders by phone all widen the gap. How ad blockers cut into analytics data and what role first-party measurement plays is covered in a separate article. This one is about the second step: the shop as a cross-check.

Where the measurement gap comes from

Blockers are the most familiar cause. According to Eurostat, 21 % of internet users in the EU used software in 2023 that limits the tracking of their activities (Eurostat 2023); among 16- to 24-year-olds the share was highest at 24 % (Eurostat 2023). Slightly above one third (36 %) had changed their browser settings to prevent or limit cookies (Eurostat 2023). For a cookieless tracker the software matters more than the cookie settings: cookie settings do not directly affect a measurement without cookies, whereas filter lists in extensions can stop a script from loading altogether. The Eurostat release gives no German figure for this software, so the EU value is only a reference point.

The second big cause lies in the payment step. According to the payment diaries of the Bundesbank study on payment behaviour in Germany, 50 % of payment transactions for purchases on the internet ran through internet payment services (Bundesbank). With many of these services the buyer confirms the payment with the provider and is then redirected to the shop's completion page. If the buyer closes the window first or the connection drops, the order exists in the shop and may already be paid, but the confirmation page does not load. On a smartphone this path can also lead through the payment service's app, and 73 % of the online shoppers surveyed in Germany use a smartphone for shopping (Bitkom 2025).

Third, measurement fails on the page itself. Of internet users in the EU aged 16 to 74, 78 % bought online in 2025 (Eurostat 2025), and 12 % of these online buyers reported problems because a website was difficult to use or worked unsatisfactorily (Eurostat 2025). A script error on the completion page, a theme update that removes the order total from the markup, or a consent tool that also holds back scripts without cookies has the same effect as a blocker: the shop has the order, the tracker does not.

The fourth cause lies outside the reach of any tracker: orders without a storefront page. The sales team enters a phone order in the Shopware Administration, a field representative records one in an app through the Store API. For web analytics these orders do not exist; for revenue and stock they are as real as any other.

The reverse case is the cancellation. The tracker measured the purchase on the confirmation page, and days later the shop cancels the order, for example because the prepayment does not arrive or the customer withdraws. Web analytics then counts revenue that does not exist in that form.

The order number as the shared key

To reconcile two sources, they need a shared attribute. For orders, that is the order number. Shopware assigns it on creation, the completion page shows it to the buyer, and the tracker reads it there together with the order total, as far as the page displays both. If you report the purchase yourself, you pass the number as the third value to xictraq.revenue(); the parameters are described in the JavaScript tracker documentation.

The order import matches by this number. The exact number fits even weeks after the order, for example when payment comes late. If the tracker's auto-detection reports a shortened number, a narrower window applies: from one day before to 30 days after the order, and only if exactly one order clearly fits. Once matched, the tracker's purchase counts, and the import adds the order state, line items and payment and shipping method. An order therefore counts once, regardless of which source learned about it first. If a second order carries the same number, for example with a separate number range per sales channel, XICTRAQ® stores it with a suffix from its shop ID, so that none drops out.

What the order import fetches from Shopware 6

The order import uses the same integration as the rest of the shop API connection for Shopware: an access the merchant creates in the Shopware Administration under Settings › System › Integrations without administrator rights. Once switched on, XICTRAQ® fetches the entire existing order history, from the newest to the oldest, in pages of 100 orders. After that the sync runs every ten minutes and fetches new and changed orders, with a 15-minute overlap with the previous run.

• Orders from the Administration, for example after an order by phone, are taken over with the next sync without waiting.
• Online orders without a captured purchase are only taken over two hours after the order, so the tracker has time to report the purchase itself; a later report replaces the import row.
• Online orders whose latest payment failed or was cancelled do not count, because the buyer neither paid nor saw the confirmation page. If the buyer pays later, the order comes back with the new payment attempt.
• Orders cancelled in the shop get no import row; an existing one is removed with the next sync.
• Fully refunded orders receive a refund of the order amount at the time of the refund. Partial refunds, returns and chargebacks appear in the shop overview but do not reduce revenue.

The website settings show the status under Shop API: imported orders, of which created in the shop admin, backfill status and last sync. Per shop and run the sync works for at most 90 seconds; whatever does not fit, the next run continues. The step-by-step guide is in the shop connection manual.

The capture rate: the gap as a number

From the imported orders XICTRAQ® computes a shop overview per website and period. The most important figure for the reconciliation is the tracker capture rate: the share of online orders the tracker captured on the confirmation page, per day. Admin orders and cancelled orders are left out. It is computed from the website's first tracker purchase; before that the rate stays empty instead of showing a zero.

The rate answers two questions. Its level shows how large the gap is in your own shop and how many online orders cannot be assigned to a channel. The EU figure of 21 % of users with software against tracking (Eurostat 2023) is only a rough reference point, because audience and payment methods shape your own gap more strongly. The trend of the rate shows whether that is changing. A stable level is no cause for concern, whereas a sudden dip usually has a technical cause with a specific date.

XICTRAQ® evaluates the trend itself: if the capture rate drops over three days below 80 % of its own 28-day value and there are enough orders for the comparison, an insight appears; relating it to its own value takes into account that every shop has a different baseline. Typical triggers for such a dip are a theme or plugin update on the completion page, a new payment method with its own redirect, or a changed setting in the consent tool.

Besides the rate, the shop overview shows the origin of orders and revenue (tracker, import, of those shop admin), plus states, cancellations, open payments and deliveries. The API delivers the same values. The following calls show the fields of the capture rate and the order numbers of online orders from the last seven days that the tracker did not capture.

With .data[].payment_method instead of the order number, the same query shows the payment methods of these orders. If certain methods pile up, the gap probably lies in their redirect; the analysis per payment method shows how completion rate and failed payments behave there. If the orders spread evenly across all methods, blockers are the more likely explanation.

Cancellations: count them or leave them out

By default the figures stay as the tracker measured them: a captured purchase counts even if the order is cancelled in the shop later. For assessing a campaign that is often the right view, for the revenue that actually remains it is too optimistic.

XICTRAQ® recognises a cancellation by the order state cancelled of the order the import matched to the purchase. Such purchases carry the flag “Cancelled in shop” in the order history and in a visitor's timeline, and the tile of the same name shows how many there are in the period. The switch “Cancellations: without” in the e-commerce tab leaves these purchases out of revenue, orders and the other figures, and a refund for the same order as well. Through the API the switch is exclude_cancelled=1.

What stays in conversion rate and funnel

Imported orders without a tracker purchase count in revenue, orders, average order value, finances, customers, products, payment and shipping methods and in the weekly and monthly reports. They do not count in conversion rate, funnel and ROAS, because no visit underlies them. Among the revenue sources they appear as a separate entry, “No visit (shop)”.

A conversion rate relates purchases to visits. If orders without a measured visit were counted, the rate would rise without a single additional visitor buying. One distinction helps when reading it: if a blocker swallows the whole visit, both visit and purchase are missing, and the rate stays roughly right, provided blocker users buy about as often as others. If the buyer does not return after paying, the visit is counted but the purchase is not, and the rate comes out too low. How cookieless analytics measures visits, funnel and purchases is described on the feature page.

Which data the import reads and which it does not

For the import the integration needs a role with exactly eight read permissions: order, order_line_item, order_transaction, order_delivery, state_machine_state, payment_method, shipping_method and currency, each with “Read” only. When the import is switched on, XICTRAQ® checks the permissions and lists missing entries.

Fetched are the order number, time, amounts with tax and shipping costs, currency, payment and shipping method, states and line items, as well as the name, company and customer number of the person ordering. XICTRAQ® does not request the email address, postal address, phone number, comment or VAT ID, even where the role technically makes some of them readable. XICTRAQ® only stores name, company and customer number with customer identification in the plan, and only for orders of the last 365 days. A share link, for example for an agency, shows the figures without customer data.

This selection follows the principle that personal data must be limited to what is necessary for the purpose (Art. 5(1)(c) GDPR). For the reconciliation itself the order number is enough; name and customer number serve the customer list and the analysis of repeat buyers. Because personal data of the people ordering is still processed, the connection belongs in your own data protection documentation. The provisions that a contract for processing on behalf must contain (Art. 28(3) GDPR) are included directly in the XICTRAQ® terms.

Before Black Week: set up the reconciliation now

The promotion days at the end of November are when a measurement gap costs the most. Around one in two (52 %) of the surveyed internet users aged 16 and over in Germany planned to use the reduced prices during Black Friday and Cyber Week 2025, most of them online (Bitkom 2025). For Black Friday and Cyber Monday 2025, the German Retail Federation expected revenue of 5.8 billion euros (HDE). Anyone shifting budgets between channels during those days decides on the basis of channel reports. If the capture rate has collapsed by then, those shifts rest on incomplete figures.

As an early warning, the rate needs a comparison value from normal weeks. If the tracker has been in place for a while, the backfill also computes it for past days. Setup errors such as missing role permissions, however, are better discovered in October than on Black Friday.

1. Create the integration: in the Shopware Administration, an integration without administrator rights, plus a role with the eight read permissions.
2. Switch on the import: in the website settings under Shop API, once the domain is verified, and follow the backfill until the history is complete.
3. Read the baseline: note the level of the capture rate in recent weeks and how much it fluctuates from day to day.
4. Test order per payment method: check that it appears in the tracker and the shop with the same order number, then cancel it in the shop; it then carries the flag “Cancelled in shop”.
5. Narrow down the gap: sort the online orders with an import row by payment method and cross-check conspicuous methods with a browser check of the checkout.
6. Settle the cancellation view: decide in advance which reports run with “Cancellations: without”, so that two revenue figures do not circulate after the promotion.
7. Add an outage alert: the rate shows a creeping gap over days, while an order heartbeat reports a complete checkout outage faster.

A browser check complements the reconciliation: it regularly clicks through the path to the order review without triggering a real order. How that looks for a discount code in the checkout is shown in an article from this week; the basics are on the browser checks page.

Limits of the reconciliation

• Shopware 6 only: Shopware 5 and other shop systems cannot be connected through the shop API; there you rely on the tracker and on the events the shop reports itself.
• Several sales channels: if a shop serves several websites, a website only counts a channel from which its tracker has already reported an order. Shops with several channels therefore need the tracker on every website for the import.
• No visit data after the fact: an imported order brings no channel, campaign or path. The gap becomes visible but is not assigned to a channel retroactively.
• Currency: the tracker reports the completion amount of a Shopware 6 shop as EUR, even if the sales channel bills in another currency. The import reads the currency of the order along with it.

For shops outside Shopware 6 a simple cross-check remains: export the online orders for a period from the shop and put them next to the purchases in the tracker. That shows the level of the gap without matching individual orders. How the tracker captures purchases on other systems is described in the article on e-commerce tracking without cookies.

Two sources instead of an estimate

Web analytics that count fewer orders than the shop are not a fault, as long as it is clear how many fewer and why. Reconciling by order number merges both sources into one order count, shows the gap per day and separates cancellations from the measured purchase. Channel reports do not become more complete as a result, but they become more honest, and a collapse in measurement stands out before it distorts a budget decision.

If you run Shopware 6 from version 6.4 on the Business plan, you set up the order import with one integration, one role and one switch. The demo shows the e-commerce reports in advance without signing up.