How a POS sale becomes inventory and G/L entries

Statements & posting · 8 min read

A cashier scans an item, takes payment, and hands over a receipt. That is the end of the story at the till — and the start of it in Business Central. Between the receipt and the financial statements, one sale passes through five records. When inventory values in Business Central stop matching what is on the shelf, the mismatch lives in exactly one of those five places. This guide follows the chain, then uses it as a diagnostic map.

General information only, not professional accounting advice. Posting setup decisions affect your financial statements — confirm them with your accountant or Business Central partner.

Step 1: the POS transaction and the statement

Nothing posts to Business Central ledgers at the moment of sale. The POS records a transaction, and the transaction waits for the statement process. After selling on the POS and finishing the end-of-day or tender declaration (and the Z-Report, if the store uses one), the back office calculates and posts statements:

1. Create an open statement for the store and enter the transaction start and end dates the statement should cover.
2. Run Calculate Statement. The statement collects the transactions in that range and presents them by tender type.
3. Check the lines before posting. The Difference Amount should be 0.00 on every line, and the Counted Amount should equal the Trans. Amount. A difference at this point is a counting or declaration problem — fix it here, not after posting. (Our end-of-day routine covers the declaration side in detail.)
4. Post the statement. Posting is the moment the retail activity becomes Business Central entries.

One variation to know about: if a store location is activated for Aggregated Inventory, the item ledger entries created by posting show the inventory at the aggregated location, while separate Aggregated Inventory Entries keep track of the inventory at the individual store location. Preview Posting shows both sets of entries before anything is committed, which makes it a useful check on high-volume setups.

Step 2: item ledger entries — the quantity story

Posting creates item ledger entries: the quantity record. Each sold item reduces inventory at its location by the quantity sold. If a sale is missing from Business Central inventory, this is the first place to look — filter the item ledger entries by item, location, and posting date. Either the entry is there (the quantity side worked, and the problem is downstream in value) or it is not (the statement covering that transaction was never posted, was posted for a different date range, or the transaction never reached the back office — see POS posting troubleshooting for that branch).

Keeping quantity and value separate in your head is the whole trick. Item ledger entries answer how many. They do not answer how much.

Step 3: value entries — the money story

Attached to the inventory activity are value entries. When inventory transactions such as sales, purchase invoices, or inventory adjustments are posted, the changed item costs are recorded in value entries. The value entry is the bridge: it carries the cost of what was sold, and it is the basis on which general ledger entries are later created.

Costs on value entries are not frozen at posting time. Automatic Cost Adjustment — set to Always by default — forwards cost changes from inbound entries, such as purchases, to the related outbound entries, such as sales. So a purchase invoice posted after the sale, at a different cost than expected, can still change the cost carried by the earlier sale's value entry. That is correct behaviour, and it is also why a COGS figure can move after the day it was first reported. Where automatic adjustment is set to a time band or to Never, the same forwarding happens only when the Adjust Cost - Item Entries batch job runs.

Step 4: from value entries to the general ledger

Which G/L accounts receive the amounts is a setup question, answered before any sale happens:

• Inventory Posting Setup combines each item's inventory posting group with a location code, and maps that combination to the inventory accounts — the Inventory Account, the interim inventory account, the WIP account, and variance accounts. A missing or wrong combination here sends values to the wrong account, or stops posting with a setup error.
• The COGS account for a sale is resolved through General Posting Setup, not Inventory Posting Setup. Looking for COGS in the wrong setup page is a common dead end.
• Inventory Setup decides when value becomes G/L, through the Automatic Cost Posting setting, which is on by default.

If Expected Cost Posting to G/L is also enabled, the batch job additionally posts the difference between expected cost amounts and what has already been posted to interim accounts, so received-but-not-invoiced value shows in the G/L as an estimate until the actual cost lands.

When the numbers do not match: a diagnostic procedure

Work the chain in order. Each step either finds the break or clears one link:

1. Name the mismatch precisely. Quantity wrong, value wrong, or both? A physical count that disagrees with item ledger quantity is a different problem from a G/L inventory balance that disagrees with the inventory valuation.
2. Check for unposted statements. If quantities are wrong, confirm every statement covering the period is posted. An unposted statement explains missing sales quantities exactly.
3. Verify one sale end-to-end (spec verification). Pick one receipt from the period. Find its item ledger entry. Open the related value entries. Follow the value entry's cost into the G/L entries. The first link where the trail stops is where the problem is.
4. If quantity is right but G/L value lags: check Automatic Cost Posting in Inventory Setup. If it is off, run Adjust Cost - Item Entries, then Post Inventory Cost to G/L, and re-check.
5. Open Inventory - G/L Reconciliation. This page compares what is recorded in the G/L against the inventory ledger's value entries, shows the difference per account type, lets you filter by date, item, and location, and explains discrepancies in warning messages. Drill down from any total to the entries behind it.
6. Only then treat it as a count problem. If the full chain ties out and the shelf count still disagrees, the difference is real-world: shrinkage, breakage, receiving errors, or items sold under the wrong item number. That is corrected with an inventory adjustment — not by editing entries.

What success looks like

Pick any recent receipt and trace it without hitting a dead end: POS transaction, posted statement, item ledger entry with the right quantity and location, value entry with a plausible cost, and a corresponding G/L effect in the inventory and COGS accounts. Then open Inventory - G/L Reconciliation for the period: the Difference column is zero, or every remaining difference is a named, explainable item — for example value entries created after the last Post Inventory Cost to G/L run. If both checks hold, the chain is healthy and a shelf-count disagreement is a store-operations issue, not a posting issue.

FAQ

Why did COGS change for a day that was already reported?
Cost adjustment forwards later inbound cost changes to earlier outbound entries. When a purchase invoice lands after the sale at a different cost, the sale's value entry — and the G/L amounts posted from it — are adjusted. The original sale did not change; its cost did.

The item ledger quantity is right but the G/L inventory balance is old. Why?
That pattern points at cost posting, not at the statement. Either Automatic Cost Posting is off and Post Inventory Cost to G/L has not been run for the period, or cost adjustment has not run, so the batch job would post stale costs anyway. Run Adjust Cost - Item Entries first, then Post Inventory Cost to G/L.

Does every store get its own item ledger entries?
On a standard setup, entries carry the store's location. On an Aggregated Inventory setup, item ledger entries sit at the aggregated location and the per-store detail lives in Aggregated Inventory Entries — which changes where you look, but not the chain itself.