Fixing retail mistakes with journals — and knowing when not to

Corrections & journals · 8 min read

Every retail system accumulates mistakes: a sale rung under the wrong item, a count that was never real, a tender declared against the wrong type. Business Central's journals can fix some of these safely. Used on the wrong kind of mistake, a journal does something worse than nothing — it makes Business Central agree with itself while disagreeing with LS Central, and the next statement, replication run, or audit pulls the two apart again. The skill is sorting the mistake before opening a journal.

General information only, not professional accounting advice. Corrections to posted periods affect reported figures — agree the approach with your accountant or Business Central partner first.

First question: where does the mistake live?

A retail mistake lives in one of three places, and the place decides the fix:

• The retail transaction itself is wrong — wrong item sold, wrong price, a sale that should never have happened. The source record is the LS Central transaction.
• The transaction is right, but Business Central's inventory position is wrong — the shelf count and the item ledger disagree because of breakage, shrinkage, or a receiving error that has nothing to do with the sale.
• Only the finance view is wrong — quantities are right, the transaction is right, but an amount sits in the wrong G/L account.

There is also a timing gate that outranks all three: has the statement posted? Before posting, the statement can still be checked line by line — Difference Amount should be 0.00 and Counted Amount should equal Trans. Amount — and source-side problems can still be dealt with at source. After posting, the entries exist, and every correction is a new entry, never an edit. That constraint is not an LS quirk: posted transactions in Business Central cannot be deleted, and corrections happen by reversal and re-posting, not by changing history.

The decision framework: four kinds of retail mistake

The pattern in the table is the whole framework: if the retail record is wrong, fix the retail record; journals are for the differences that remain in Business Central after the retail record is right.

Fix at source: when the LS transaction itself is wrong

LS Central's correction route for a posted transaction is Void Posted Transaction. The cashier enters the receipt number; the query is sent to the web service, which retrieves the corresponding transaction from the remote database; the transaction is copied to the POS database and is automatically refunded during the process. The error handling is equally specific: if the remote database is unavailable, the POS says so; if the transaction is not in the remote database, the POS reports that it was not found; if the transaction has already been refunded, the POS returns an error. In other words, the void is a controlled, auditable reversal of the original retail event — which is exactly what a journal entry against the G/L is not.

Why insist on the source fix? Because the LS transaction feeds more than one Business Central number. A journal that reverses the G/L effect of a wrong sale leaves the item ledger, the sales history, and the store's retail reporting still carrying the wrong sale — and leaves the next person to reconcile three records that tell three stories. Our POS posting troubleshooting guide covers the related case where transactions fail to post at all.

Safe in a journal: quantities, values, and G/L-only errors

Quantities. Inventory quantities are adjusted by posting the Item Journal. A count variance, breakage write-off, or shrinkage adjustment is exactly this: the sale history stays untouched, and a new item ledger entry records the difference between the system quantity and reality. Locations that use directed put-away and pick work one level down first: unplanned positive and negative quantity changes are registered in the Warehouse Item Journal — the documented examples are items posted as missing that show up unexpectedly, and losses due to breakage — and those warehouse adjustments are brought onto the item ledger through the Item Journal's Calculate Warehouse Adjustment action.

Values. When the quantity is right but the value of existing inventory is wrong, the Revaluation Journal is the standard tool: run Calculate Inventory Value, enter the revalued unit cost (or the revalued inventory value) on each line, and post. Posting creates new value entries reflecting the revaluation — again, history is added to, never rewritten.

G/L-only errors. A general journal correction moves an amount between G/L accounts without touching inventory. Where the original entry came from a general journal line, Reverse Transaction is cleaner than a hand-built offset: a reversal is an entry identical to the original but with the opposite sign in the Amount field, using the same document number and posting date, after which the correct entry is posted. Two hard limits apply — only entries posted from a general journal line can be reversed, and an entry can be reversed only once. Statement postings do not originate from general journal lines, which is one more reason they cannot be “reversed” from the G/L side.

Never touch: posted LS transaction data

The boundary, stated plainly:

• Never edit or delete posted LS transaction records directly to make a number come right. The correction routes are the void/refund flow at the POS and new Business Central entries — there is no supported “fix the posted transaction in the table” route, and posted Business Central transactions cannot be deleted either.
• Never journal the G/L to match a retail record you know is wrong. That bakes the wrong sale into the accounts and leaves item ledger and sales history disagreeing with both.
• Never use an item journal to “correct” a specific wrong sale. An adjustment changes the quantity on hand; it does not change which item was sold, at what price, or by which tender — and the statement totals will still tell the original story.

A correction procedure, in order

1. Stop and identify. Write down the receipt or statement, the item, and the exact wrongness: transaction, quantity, value, or account. Do not post anything yet.
2. Check the statement status. Not posted yet? The mistake can still be handled at source before calculation and posting. Posted? Work with new entries only.
3. If the transaction is wrong, fix it in LS Central — correct it before posting, or use Void Posted Transaction by receipt number so it is refunded through the controlled flow. Let the corrected data flow through the statement.
4. Re-check Business Central after the source fix. Compare the item ledger and G/L against what the correction should have produced. In many cases nothing further is needed.
5. Journal only the residual. A remaining quantity difference goes through the Item Journal; a remaining value difference through the Revaluation Journal; a remaining account error through a General Journal or a qualifying Reverse Transaction. Use Preview Posting where available, and a document number that names the correction.
6. Record what was done against the original receipt or statement, so the new entries can be explained without detective work.

What success looks like

After the correction, three records tell the same story: the LS transaction history shows the sale as it should have been (or shows it voided and refunded), the item ledger quantity for the item and location matches a physical count, and the G/L balances agree with the inventory valuation — the same tie-out used in the end-of-day routine, applied to the correction. Every correcting entry is a new, dated, documented entry; no posted record has been edited. If any one of the three records still tells the old story, the correction is not finished — it has just moved.

FAQ

Can a posted statement be unposted so the transaction can be fixed?
No. Posted transactions cannot be deleted, and statement postings do not qualify for Reverse Transaction, which is limited to entries posted from general journal lines. The correction is a source-side void or new correcting entries.

A cashier sold item A but the customer took item B. Item journal?
No — the retail transaction is wrong, so it is fixed at source in LS Central. An item journal would leave the sales history showing A sold at A's price and tender, which is the part that is actually wrong.

The count found three fewer units than the system shows, and no sale looks wrong. Item journal?
Yes. That is the textbook item-journal case: a negative adjustment records the variance, the sales history stays as it happened, and the quantity on hand now matches the shelf.