Help Center

Lightspeed X Series Sales Data Validation

Keith Autio
Keith Autio
  • Updated

How to validate sales data pulled from a client's Lightspeed X Series (LSX) account, and the two report quirks that will throw off a naive comparison every time.

Applies to: Lightspeed X Series (LSX) integrations     Audience: Support / Implementation     Last updated: August 2026

01  Overview

Recent changes to how we pull data from the LSX API mean we can now validate sales data at the individual order level — a level of detail that wasn't available before. That's a real improvement, but LSX's own reporting still has a couple of quirks that will make totals look “wrong” if you don't know to account for them.

This article covers where those quirks show up and the correct way to validate a client's LSX sales data against what we've pulled into our system.

02  Why the Sales Summary report runs high

LSX's Sales Summary report counts an order as a sale even when its status is AWAITING_PICKUP or AWAITING_DISPATCH — meaning the customer hasn't actually taken the merchandise yet.

Observed case
Sales Summary showed $205,000 in sales for Location 1, Aug 1–20 — well above what our system had pulled in for the same window and location.

We deliberately exclude orders in those two statuses, since they aren't completed sales yet — so a Sales Summary total will typically run higher than our number, and that's expected. If a client's business needs those statuses counted as sold (e.g. sale recognized at pickup scheduling rather than fulfillment), that inclusion can be turned on for their account.

03  Validating with Sales History instead

Sales Summary isn't a reliable comparison point, so validate against LSX's Sales History report instead — it exports a full order-by-order list with each order's subtotal for a date range.

1   In LSX, open Sales History and export all sales for the date range you're validating, keeping the subtotal column for every order.

2   Match each exported order against the corresponding order our system pulled in through Shuttle, comparing subtotals line by line.

Export can silently drop days
An export requested for Aug 1–20 in one pass actually started on the 6th — the 1st through 5th were missing entirely, with no warning from LSX.
Don't trust one large export. Run it in smaller chunks — for example 1–10 and 11–20 separately — then combine the results, and confirm each chunk actually starts on the date you asked for before using it.

04  Known discrepancy: exchanges

Even with a clean, complete export, one order type will still show a real difference: exchanges. LSX's Sales History keeps the subtotal of the original sale rather than reflecting the exchange, so an even exchange appears at its original non-zero value.

Our system correctly nets an even exchange to $0. If exchanges are the only line items not matching during a validation pass, that's this reporting quirk — not an error in our pulled data.

05  Quick reference

 

✓  Use Sales History for validation, not Sales Summary — Summary includes AWAITING_PICKUP / AWAITING_DISPATCH orders we intentionally exclude.

✓  Export in smaller date ranges and confirm the start date actually came through — large ranges can silently truncate.

✓  Expect exchanges to show a mismatch — LSX keeps the original subtotal instead of netting to zero. This is expected, not a data error.

Retail Orbit Integrations · Lightspeed X Series     |     Internal knowledge base

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.