Tracing a POS sale to the G/L: the posted-statement audit trail

Audit trail · 6 min read

An auditor picks one receipt and asks the hardest simple question in retail accounting: show me this sale in the general ledger. The answer is a chain of four records, and the trace only feels difficult because each hop changes the shape of the data — one sale becomes part of a tender total, which becomes part of a posting. Learn the chain once and the question takes minutes.

The chain at a glance

Why one sale is never one line

Statement calculation groups transactions according to the store's statement method. With method Staff, the program creates a statement line for each tender type for each staff member; with POS Terminal, a line for each tender type for each terminal; with Total, one line for each tender type overall. So the sale is traceable — but as a component of a tender total, not as a line with its receipt number on it. Anyone hunting for a single receipt inside G/L entries without going through the statement first is looking in the wrong shape.

Procedure: trace one sale end to end

1. Start from the receipt. Note the store, the date, the terminal or staff member, and the transaction number. These four facts decide which statement can contain the sale.
2. Find the statement for that store and date range. Statements are calculated for a store over a transaction starting and ending date, after the end-of-day or tender declaration. A transaction belongs to exactly one statement — the first one calculated over a range that includes it while it belongs to no statement.
3. Open the posted statement and its lines. When the statement was posted, its statement line values were transferred to the Posted Statement Line table. Find the line for the sale's tender type and grouping (staff or terminal, per the statement method) and confirm the counted amount equaled the transaction amount with a difference of 0.00 at posting — that was the pre-posting control.
4. Jump to the related financial entries. From a posted document or entry, use Find Entries (Ctrl+Alt+Q, or the Find entries action): it finds documents and entries related by common information such as document number and posting date — the ledger entries that resulted from the transaction.
5. Verify in the G/L Registers. The G/L Registers page gives an overview of all transactions posted to the general ledger and lets you navigate to related subledger entries such as VAT entries or Customer Ledger Entries. It also shows the type of transaction, the user who posted it, and when it was recorded — the facts an auditor asks for next.
6. Confirm the origin with the source code. All posted entries are automatically assigned a source code so transactions can be traced to their origin. Filter General Ledger Entries by source code to prove the entries came from the posting you think they came from.

When the numbers do not tie: investigate by hop

Do not start in the G/L and dig upward. Compare totals at each hop, in order, and stop at the first hop where the totals part company — that is where the problem lives:

The framework behind the table: a discrepancy can only be introduced at one hop, and each hop preserves its own totals. Two agreeing neighbours clear the ground between them, so three comparisons isolate any variance to a single stage — replication, calculation, or posting. This is also the fastest month-end check: run the same comparisons per store, per day, before the period closes (see the period-close checklist).

Record the trace as you go: statement number, posted statement line, register, and the G/L entry range it produced. An investigation that ends with "it balances now" but no trail will be repeated from scratch at the next audit, while a recorded chain becomes the store's worked example for every future question about retail postings.

What success looks like

• The receipt's store, date, and transaction number lead to exactly one statement, and that statement is posted.
• The posted statement line for the sale's tender and grouping includes the sale in its total, with the counted-versus-transaction difference at zero.
• Find Entries from the posting shows the related G/L and subledger entries, and the G/L Register records who posted them and when.
• Source codes on the G/L entries match the posting origin — no orphan entries, no missing ones.

FAQ

Why can I not find my receipt number in the general ledger? Because retail posting is aggregated by design: the statement groups transactions into tender-type lines by staff, terminal, or total. The receipt number lives at hop 1; the G/L holds the posting's totals at hop 4. The statement is the bridge between them.

What does the G/L Register add that G/L Entries do not? Context for the posting as a whole: the register holds one row per posted transaction to the general ledger, and the page shows the transaction type, the user, and when it was recorded, with navigation into related subledger entries. Microsoft notes the page is particularly useful during audits for exactly this reason.

A day's total is short but every statement posted. Where else can a sale hide? In a neighbouring statement. A statement includes every transaction for the store not already belonging to a statement within its date range, so a late-arriving transaction can be swept into the next day's statement — present in the G/L, but on the "wrong" day.