Consolidated posting

This page explains the accounting mechanics behind End of day: how completed POS sales are grouped into consolidated Business Central documents, how the two posting modes differ, how failures are isolated, and where the permanent daily record lives.

Consolidation groups

Sales are grouped by a fixed seven-part signature plus the return flag - one consolidated document per unique combination:

Group key field	Notes
Posting Date	The sale's date (the date you run EOD for).
Customer No.	POS customer (mapped to a BC customer for posting).
POS Store Code	Blank stores group together.
POS Terminal ID	Blank terminals group together.
Payment Method Code	The header method derived at tender time.
Salesperson Code
Currency Code
Sale vs Return	Return sales always form their own groups and post as Credit Memos - never netted against sales.

The grouping rules are fixed in this version; there are no setup toggles to include or exclude individual group-by fields. Because Payment Method Code is part of the key, cash-dominant and card-dominant sales split into separate documents even for the same customer.

Consolidation trades per-receipt invoices for one document per group, but the individual POS lines are still copied one-to-one onto the consolidated document - no item-level merging - so traceability is preserved. Credit-memo lines carry positive quantities in BC (the document type expresses the credit direction).

Posting modes: invoices or deferred orders

The EOD dialog's Create Sales Orders (Not Posted) switch picks between two modes:

• Off (default): one Sales Invoice per group, posted immediately.
• On: one Sales Order per group, created but not posted, for accounting flows that review consolidated orders before invoicing. The covered sales are marked Partially Posted.

The dialog's initial value comes from POS Setup's Create Sales Orders by Default field; a one-run override never changes the company default. Return groups always post their credit memo regardless of the mode.

Document references and statuses

Every document the app creates carries an External Document No. back-reference:

• Consolidated EOD document: POS <store>/<terminal> yyyy-mm-dd (locale-invariant date, truncated to the field's 35 characters if needed).
• Single-sale posting: the cashier-entered External Document No. if present, otherwise the POS sale's own document number - the backward link is never blank.

On the POS side, each sale's status tells you where it stands:

Sale status	Meaning	Posted Invoice No. holds
Open	In progress.	blank
Released	Tendered and completed; awaiting posting.	blank
Partially Posted	Covered by an EOD-created Sales Order not yet posted.	the Sales Order number
Posted	Invoiced or credited.	the posted Sales Invoice / Credit Memo number

The Sales Card's Navigate -> Posted Invoice action opens the posted document (resolving to the Posted Credit Memo for a return). Reopening a Partially Posted or Posted sale is blocked - reopening a sale already covered by an EOD order would let the next run bill the same goods twice. For a consolidated group, many sales share one Posted Invoice No.; filtering POS Sales by that number lists the batch's members.

Single-sale posting

Besides the batch, one POS sale can be posted individually to its own Sales Invoice via the Post action on the POS Sales Card (with multi-select posting from the POS Sales list, which reports a posted-of-total summary). The flow validates the sale - Released, unposted, mapped customer and items - then posts through the standard Sales-Post engine. Single-sale posting always posts an invoice; the Orders mode exists only in the batch. A sale posted individually disappears from the next EOD scope.

Per-group failure isolation

Every consolidation group is processed in isolation: one bad group never kills the run and never rolls back groups that already posted.

• Up-front checks per group, before any document is created: the POS customer exists and is mapped to a live, unblocked BC customer; every sale line's item is mapped to a live BC item; adjustment-carrying groups have their adjustment account configured. Any failure marks only that group, with a reason naming the offending customer, item, and sale.
• Posting failures: if the standard posting engine itself fails, the error is captured, the created (unposted) document is deleted so retries never stack orphans, and the run moves to the next group.
• Integrity boundary: the moment a group's invoice posts, its source sales are flagged Posted and committed immediately - there is no window in which a rerun could double-post.
• Skipped sales: sales with a blank customer join no group; they are counted and reported, never aborted on.

The run summary ends with an actionable hint: fix the issues, then rerun - groups that already posted will not post again. For mapping issues, open POS Customers or POS Items and use Map to BC.

Posted Daily Sales archive

One archive row is written per successfully posted consolidation group - the permanent daily summary for reporting and audit. Each row stores the posting date, the POS and BC customer, transaction count, total quantity, totals excluding and including tax, tax amount, total discount, the group's aggregated price adjustment and cash rounding amounts, average transaction value, currency, the terminal IDs involved, the BC posted invoice number (or Sales Order number in Orders mode), status, and who processed it when.

Find it via Tell Me -> Posted Daily Sales Archive (also linked from the admin role center). The list is read-only, and Posted rows cannot be deleted. The archive write is deliberately isolated from the posting transaction: if it ever fails, the group stays correctly posted and the miss is reported in the run summary. The archive summarizes the sales' amounts; per-tender detail lives in Per-tender settlement entries, and per-drawer detail in Shifts.

Money that posts with the group

Two POS-specific amounts ride along on the consolidated document:

• Price adjustments from dual pricing (cash discount / card surcharge) post as one aggregated G/L line per group. EOD refuses such a group up front if the Price Adjustment G/L Account is not configured.
• Cash rounding differences post as their own G/L line to the rounding account snapshotted on each sale - one non-tax line per distinct account within the group - so the posted document reconciles to the rounded cash actually taken.

How each tender's share of the posted document then settles into its own G/L or bank account is covered on Per-tender settlement.