X and Z reports in LS Central: reading the numbers before you post the statement

Daily operations · 8 min read

Most end-of-day problems are visible on the X report an hour before they become statement problems. The report is usually printed, glanced at, and filed — and then the difference that was sitting in plain sight gets discovered after posting, when fixing it is ten times the work. This guide is about reading the report properly: what each section is telling you, what to check against the physical count, and which strange numbers are not errors at all.

X vs Z: the one distinction that matters

That is why the X report is the working tool. Because it can be run repeatedly without changing anything — the classic definition of an X report across POS systems is exactly that: a snapshot of till activity so far that doesn't reset the day — it costs nothing to print one before the tender declaration and read it properly. The Z report's role is finality. On the LS Central POS, the end-of-day flow runs through the tender declaration: the TD_ENDDAY command invokes the End of Day form, where tender is declared — counted, with the value of each tender that requires counting marked in. Only after that does the statement get calculated and posted.

One honesty note before the field-by-field detail: the exact sections and field names on an X/Z report vary by LS product and version, and availability itself varies — LS Retail's published X/Z documentation is written for LS Express and notes the reports aren't supported in every country's app. Treat the section walk below as the documented anatomy of the report, and confirm the layout on your own version before building a store procedure around any single field name.

What the report shows, section by section

Header. Company name and VAT registration number, Store No., the period the report covers (From/To Datetime), and the identifiers that scope it: Staff ID if the report was run for one staff member, POS ID, and Drawer ID. Read this first, always — a surprising number of "the numbers are wrong" incidents are a report run for the wrong drawer, the wrong terminal, or one staff member instead of the store.

Sales and returns summary. Sales and returns are reported separately, each broken into gross amount, the discount taken out of it, and the resulting net. Grand total net sales is the two combined. This is the shape of the day: if returns are eating an unusual share of gross, you'll see it here before anywhere else.

Statistics. The counts behind the money: number of sales transactions, voided transactions (sales deleted at the POS), returned transactions, items sold and returned, drawer openings with no active sale, suspended sales and their amount, and deleted payment lines. This section is the report's honesty check — money totals can look plausible while the void and drawer-opening counts tell a different story.

Float cash. The fixed float at the start of the period, cash added to the drawer outside a sale, cash removed outside a sale, and the net float cash — the ending fixed float carried into the next period. Note that net float cash is not simply added minus removed; it's the float that remains in the drawer for the next period.

Customer account activity. Sales and returns posted to a customer account instead of settled at the POS, and payments received against previously posted invoices. These amounts explain why the day's cash and card totals are lower than the sales totals suggest: that money was never supposed to be in the drawer.

Sales by item category and tax breakdown. Net sales per item category with a combined total, and sales broken down by tax/VAT percentage with the tax charged at each. Category totals that don't add to the combined total, or a tax rate appearing that the store doesn't use, are both worth a question before posting.

Payment method breakdown. Sales, returns, and refunds broken down by payment method — the section that has to agree with what was physically counted in the tender declaration.

Before you post: the reading procedure

1. Print the X report before declaring tender. It changes nothing, so there's no cost to having it in hand during the count.
2. Check the header scope. Store, period, drawer, terminal, and staff filter all match the count you're about to do. A mismatch here invalidates every comparison below.
3. Count the drawer and complete the tender declaration through the End of Day form: count and mark the value of each tender that requires counting.
4. Compare the payment method breakdown to the count, method by method. Cash first, then card and the rest. Small cash differences are a counting problem until proven otherwise — recount before investigating the system.
5. Scan the statistics for outliers. Voided transactions, drawer openings without a sale, suspended sales, and deleted payment lines should each have a story you already know. An unexplained count is the finding, even when the money agrees.
6. Reconcile the float. Added and removed cash outside of sales should match the day's known float movements — the safe drop, the change run — and the ending float should be the float tomorrow starts with.
7. Check the account activity so on-account sales aren't chased as missing cash.
8. Only then calculate the statement. In the back office, create the statement for the store with the transaction starting and ending dates and run Calculate Statement. Before posting, the Difference Amount should be 0.00 on every line, with Counted Amount equal to Trans. Amount — if a Counted Amount is 0.00, it can be entered to match. Tender types appear as codes (Tender Type 1 is usually Cash), so confirm you're reading the right line.
9. Post the statement, and the Z report is the record of the closed-out summary — after which those transactions belong to that summary and won't appear in a later one.

(The posting side of this routine is covered in our end-of-day statement guide.)

Odd numbers that are not errors

• A payment method total is negative. The breakdown is net of refunds, returns, and amounts posted to a customer account — so a method that saw more refunds than sales for the period legitimately goes negative. Expected behaviour, not a defect.
• Net float cash doesn't equal added minus removed. It isn't meant to. It's the ending fixed float remaining in the drawer for the next period.
• Cash is short by exactly the on-account sales. Sales posted to a customer account were never collected at the POS. The account activity section exists to explain precisely this gap.
• The mid-day X doesn't match the evening X. It shouldn't — the X report covers activity since the last Z, so each print is a later snapshot of the same open period.

When the numbers genuinely don't agree

Work the boring causes first: wrong drawer or staff filter on the report (step 2), a miscount (recount), a float movement nobody recorded (step 6). Only after those are eliminated is it a posting problem. Whatever the cause, find it now: the difference amount on an unposted statement is a question; the same difference discovered after posting is a correction.

What success looks like

The count matches the payment method breakdown method-for-method, or every difference has a named cause; the statistics counts all have explanations; the float reconciles to tomorrow's starting float; and the statement's Difference Amount reads 0.00 on every line before Post Statement is touched. At that point the Z report is a formality — which is exactly what a close should feel like.

FAQ

Can printing an X report mess up the day's totals?
No. The X report is a preview of the still-open summary and printing it does not change any data. Print it as often as useful — mid-day, at shift change, and before the count.

Can a transaction end up in two Z reports?
No. Once a close-out summary is posted, the sales and return data behind it is marked as belonging to that Z report and cannot be included in a later summary.

The statement shows a non-zero Difference Amount. Post anyway?
That's the signal to stop. The documented expectation before posting is Difference Amount 0.00 on all lines with Counted equal to Trans. Amount. Go back to the X report and the count; the cause is almost always there.