Analyzing retail sales history in Business Central and LS Central

Reporting · 7 min read

“What sold, where, and when?” sounds like one question. In Business Central it is really a question about where the answer lives. Posted retail sales do not sit in a single sales-history table waiting for a report — they land as entries, spread across ledgers that each record a different part of the truth. Analysis gets fast, and stays honest, once the starting point is the right ledger for the question being asked.

Where posted sales actually live

Start with the mechanics Microsoft documents for posting. When a sales order is posted, Business Central updates the customer's account, the general ledger, and the item ledger entries. For each sales line that carries an item number, an item ledger entry is created; the order itself is also recorded in the sales shipment and sales invoice header tables. Retail sales posted through LS Central statements follow the same destination logic: the sale only becomes analysable history once it has posted into entries.

That gives the analyst three distinct starting points, each suited to a different question. Item Ledger Entries hold the movement story — which item moved, in what quantity, at which location, on which posting date. Posted Sales Invoices hold the document story — what a given sale was billed as. Customer Ledger Entries hold the money story — what customers were charged and what remains outstanding. Microsoft's ad-hoc analysis guidance lists exactly these list pages — along with Sales Orders, General Ledger Entries, and Sales Return Orders — as the places to analyse sales processes. Picking the wrong one is the most common reason a “quick” sales question turns into an afternoon of reconciling numbers that were never meant to agree line-for-line.

Quantity history is not value history

The second distinction is between quantities and values. Item ledger entries answer in units. The money attached to those movements lives in value entries: Microsoft's inventory valuation design documentation explains that the value of inventory for a date is calculated by summing positive and negative value entries, and that the Inventory Valuation report totals the Cost Amount (Actual) field on those value entries, using posting dates as filters. Two practical consequences follow. A quantity question — how many units of an item sold at a store last month — belongs in the item ledger, full stop. A margin or cost question belongs with the values, and its totals depend on costs having been posted; the same documentation notes that valuation figures count as reconciled with the general ledger only for value entries that have actually been posted there. Comparing a quantity view against a value view and expecting them to explain each other, unit for dollar, is a category error.

The core procedure: what sold, where, and when

Business Central's analysis mode is the fastest honest route to the three-part question, because it works directly on the list pages — Microsoft positions the Data Analysis feature as analysis done in place, without running a report or switching to another application such as Excel, using tabs that each hold a different view of the same data. The inventory guidance documents the pattern on Item Ledger Entries, and it maps directly onto sales history:

1. Open the Item Ledger Entries list and turn on analysis mode. This list is the movement record: every posted sale of an item appears here as movement.
2. Clear the columns. In the Columns menu, remove all columns so the view starts empty rather than fighting the default layout.
3. Put Location Code in Row Groups. This is the “where” — each location gets its own grouped row.
4. Put Quantity in Values. The grouped quantities are the “what, how much” in units sold and returned.
5. Add Item No. and Posting Date. Item No. breaks each location down by product, and adding Posting Date lets the same view track movements over time — the “when”. Microsoft's guidance calls out exactly this pairing: Location Code and Quantity as the skeleton, with fields such as Item No. added, and Posting Date used to follow movements over time.
6. Name the tab after the question. For example, “Sales by store — last quarter”. A named tab survives the session and can be revisited next period with the same shape, which is what turns a one-off answer into a repeatable check.

What success looks like: one screen shows, per location, the items sold and their quantities across the chosen dates, the returns appear as their own movements rather than vanishing into a net figure, and the grand total of sale movements for a sample day can be tied back to that day's posted sales. If the tie-out fails, the analysis is not finished — something has not posted yet, and finding that gap is the real result.

Breaking the same history down other ways

The same analysis-mode approach works on the neighbouring ledgers when the question changes shape. For customer volume, Microsoft's sales guidance gives the pattern on Customer Ledger Entries: analyse with Customer Name, Document No., Amount, and Remaining Amount to see which customers purchase the most, or owe the most. For expected rather than posted volume, the corresponding pattern opens Sales Orders with Sell-to Customer Name, Sell-to Customer No., Amount, and the document date broken into year and month. And where the question is simply “what were this item's movements, all of them?”, the built-in Inventory – Transaction Detail report (704) reviews sales, purchases, and transfers for a selected item over a period — slower than analysis mode, but a fixed, shareable format.

Two built-in reports cover the recurring, formatted versions of the history question. Inventory Customer Sales (713) analyses customer sales per item, including how discounts, sales amounts, and volume relate, while Customer/Item Sales (113) analyses item sales per customer on the same basis. The Inventory Top 10 List (711) gives the ranking view — highest or lowest sellers by quantity and amount over a selected period. A useful rule of thumb: analysis mode for questions asked once, these reports for questions asked every week. The reports worth running guide places them in a weekly routine.

Dimensions: tomorrow's breakdowns are decided at posting

Dimensions are the values that categorise entries so they can be tracked and analysed — Microsoft's example splits entries by an AREA dimension (Americas, Europe, and below) and a DEPARTMENT dimension (administration, production, sales), and the two global dimensions can be used as filters on general ledger entries and on all reports. For a retailer, the lesson is blunt: a breakdown that was not captured when the sale posted cannot be reconstructed later from the entries alone. If sales need to be compared by channel, region, or department next year, the dimension has to exist and be populated this year. Auditing which dimensions are actually being filled in on posted sales is therefore part of sales-history hygiene, not an accounting nicety.

Choosing the right layer for the question

The last row deserves its boundary to be stated plainly. The LS Central analytics layer is a separate Power BI system fed by a data warehouse; it answers pattern questions across long periods better than any list page can. But it can only display what the entries underneath contain, and it will happily present an unposted day as a quiet day. When a dashboard number and a ledger number disagree, the ledger is the arbiter — investigate the posting, not the chart.

Accuracy note: sales-history analysis is only as good as the postings behind it. Before figures are used for buying commitments, supplier negotiations, or financial reporting, confirm the period is fully posted and reconciled, and involve the accountant or partner who owns the setup where the amounts carry financial consequences. This guide is orientation, not financial advice.