Bitta Retail POS guide
Per-tender settlement
Settling each tender slice of a posted document into its own G/L or bank account: cent-exact settlement entries, the retry action, and why On Account stays open in Accounts Receivable.
status: verified applies-to: 1.0.0.121rev: 1
Per-tender settlement makes end-of-day posting settle each tender of a document into its own account, instead of settling the whole document through the dominant tender's payment method. Split tenders land cent-exact in the right cash, clearing, or bank accounts: one applying payment per tender slice, posted against the settlement account configured on each tender method.
What it does
With the toggle on (the default), a posted POS document carries no balancing payment method of its own. The settlement runner then posts one applying payment per tender slice of the document:
- The cash slice posts into the cash tender's settlement account (typically a cash drawer G/L account).
- The card slice posts into the card tender's settlement account (typically a card clearing G/L account or the processor's bank account).
- A tender with no settlement account anywhere - deliberately, On Account - posts nothing, and that slice stays open in Accounts Receivable.
A sale split 10.00 cash / 15.00 card therefore closes its customer ledger entry via two applying payments: 10.00 into the cash account and 15.00 into the card settlement account.
Settlement amounts are cent-exact: the entries for a document sum exactly to the posted document total, with any rounding remainder folded into the largest slice. Settlement never mutates a tender's own recorded amounts.
Setup
| Field | Where | Default | What it does |
|---|---|---|---|
| Per-Tender Settlement | POS Setup, posting section | on | On: settle per tender slice as described here. Off: exact legacy behavior - the largest tender's payment method settles the whole document. |
| Settlement Account Type | each Tender Method | G/L Account | G/L Account (cash drawer, card clearing) or Bank Account (processor deposits). Changing the type clears the account number so a G/L number can never linger behind a Bank Account type. |
| Settlement Account No. | each Tender Method | blank | The account this tender's slices post against - validated against live, unblocked, direct-posting accounts. Blank is meaningful: see below. |
Resolution order per tender: a configured settlement account on the tender method wins; if it is blank, the balancing account of the tender's linked Business Central payment method is used; only no account anywhere leaves the slice open in AR - which is exactly the intended configuration for On-account sales.
Recommended configuration:
- Keep the toggle on.
- Assign a cash G/L account to CASH and a card clearing or bank account to CARD.
- Leave ONACCT with neither a settlement account nor a payment method balancing account, so its slice intentionally remains open AR.
TIP
Give every card-type tender its own settlement account matching how the money actually arrives - a clearing account you relieve when the processor deposit lands makes bank reconciliation a two-line exercise.
Settlement entries and retry
Every slice writes a settlement entry, visible on a read-only list page: which document, which tender, the amount, and the posting outcome. Slices that could not post (for example, a settlement account blocked after configuration) can be re-run from the list's retry action once the cause is fixed. Slices with no account are marked Not Applicable rather than failed - staying open in AR is their correct outcome.
NOTE
Completed payment lines snapshot their tender identity at sale time, so settlement always follows the tender the sale was actually paid with - editing the tender catalog later never redirects money from already-completed sales.
Interaction with end of day
Per-tender settlement rides the normal day-close: sales are grouped and posted by Consolidated posting, and each posted document is then settled slice by slice. Single-sale posting settles the same way. While the toggle is on, the balancing payment method is suppressed on the posted document so nothing settles twice. A dual-pricing adjustment changes the document total before slicing, so surcharged card slices settle at their charged amount - see Dual pricing and surcharges.
Turning the toggle off restores legacy behavior exactly: the whole document settles through the largest tender's payment method, open or closed depending on that method's balancing account.
See End of day for the operator's day-close flow and Tender screen and split payments for the tender method catalog the accounts live on.