LS Central tender types: how each one posts
A tender type looks like a button on the POS. In the ledger it is a posting instruction: this tender's money goes to that account, this tender gets counted at close, a difference on that tender goes here. Set the instruction wrong and the statement still posts — it just posts the money to the wrong place, every day, quietly. This guide walks the three tender families every store runs — cash, card, and gift card or voucher — through their setup and through statement posting, so you can check each one against your own configuration. Account choices here are accounting setup; confirm them with whoever owns your chart of accounts. This is general information, not professional advice.
A tender type is a posting instruction
Three setup decisions on the tender type (and, for cards, on the Tender Type Card Setup under it) decide everything that happens later:
- Account Type and Account No. The Account Type field specifies the type of account the payment is posted to, and the documented options are G/L Account and Bank Account. The account type you select determines which accounts you can pick in the Account No. field. On card setup, the account type is copied from the tender type when the card is filled in — and it can be set differently for an individual card, which is how one card brand ends up in a different account from its siblings.
- Counting Required. This flag shows whether counting of the tender is required. If it is not marked, the system automatically fills the Counted Amount on the statement line with the Trans. Amount when the statement is calculated — the tender effectively declares itself.
- Difference G/L Account. The account that receives the difference between the Counted Amount and the Trans. Amount on the statement line. No difference account, no clean home for shortages and overages.
At the POS, the tender key itself is just an identifier: the TENDER_K command takes a Tender Type Code as its parameter, and LS Retail's documented examples use 1 for cash, 2 for check, 3 for card, and 6 for currency. What those codes do financially is entirely the setup above.
The comparison table: cash, card, gift card and voucher
| Behaviour | Cash | Card | Gift card / voucher |
|---|---|---|---|
| Typical account target | Cash or clearing G/L account | Bank Account, or a card-clearing G/L account | Gift card liability G/L account |
| Counting Required | Yes — physically counted at declaration | Usually no — counted amount auto-fills from Trans. Amount | Usually no — system knows the redeemed amount |
| Difference handling | Shortage or overage posts to the Difference G/L Account | Differences point at settlement or fee issues, not the drawer | Differences should not occur; any that do are a red flag |
| What statement posting moves | Declared cash from sales clearing into the cash account | Card totals into the bank or clearing account, to be matched against settlement | Redemption value out of the gift card liability against the sale it paid for |
| What it is not | Not revenue — revenue came from the sales lines | Not revenue, and not the net deposit — fees settle outside the statement | Not revenue at redemption, and not a discount |
The pattern to notice: the statement moves money per tender while the sales lines carry the revenue. A tender total and a revenue total answer different questions, and forcing them to match is how reconciliation habits go wrong.
Cash: counted, declared, differences posted
Cash is the tender the whole declaration ritual exists for. When a tender declaration is performed on the terminal, the counted amount on the posted statement line is filled automatically from the declaration entries. If the tender is marked Counting Required and no declaration filled it, the counted amount must be entered by hand. Either way, posting compares it against the Trans. Amount — the total tendered in that tender type across the transactions summed into the statement line, filled at calculation from the payment entries. The gap between the two is the Difference Amount, and before posting it should be 0.00 on every line, or a real, explained number that posts to the tender's Difference G/L Account. There is also a guardrail: the maximum difference allowed to post is defined in the Max. Diff. to Allow Post. field, and the system warns when a counted amount is zero while the Trans. Amount is greater than zero.
Card: bank account or G/L account, and why it matters
For card tenders the Account Type choice is the whole decision. Point the card tender at a Bank Account and statement posting lands the money in the bank account record, ready to reconcile against the processor's settlement. Point it at a G/L Account and the money sits in a clearing account until someone journals it onward — a fine pattern when settlements arrive net of fees or batched across days, and a mess when nobody owns the clearing step. The behaviour is real enough that LS Retail users have asked in the community forums how to split card amounts at statement posting, describing cash posting to one G/L account and card brands to another. Two practical checks: every card setup under the tender should carry the same account type and target unless there is a documented reason, because the card level can override the tender level; and card tenders normally skip counting, because there is nothing physical to count — if Counting Required is marked, staff will be asked to "count" a number only the processor can confirm.
Gift card and voucher tenders: payment, not revenue
A gift card is a mode of payment at checkout, and it can be redeemed for the total amount or a partial amount depending on the order total. That one fact drives the posting: redemption is the customer paying with value the store already holds, so the tender's account target is the gift card liability — the redemption reduces what the store owes the cardholders, while the revenue belongs to the items sold on that redemption transaction, exactly as it does for a cash sale. The two errors to hunt in an existing setup are a gift card tender pointed at a sales account (which books the same revenue twice: once when the card was sold, once when it is redeemed) and a gift card tender set up like a discount (which understates the redemption sale and leaves the liability untouched). If either has happened, the liability account balance will not agree with the outstanding card balances, and that disagreement — not the statement — is where you will see it first.
Procedure: from tender declaration to posted statement
- Finish the end-of-day declaration on the POS (and the Z-Report if your setup uses one). Counted tenders get their counted amounts from the declaration entries.
- Create the statement for the store and the transaction date range, then run Calculate Statement. Check the Tender Type codes on the lines are the ones you expect; Tender Type 1 is usually Cash.
- Review each statement line: Trans. Amount is what the POS recorded, Counted Amount is what was declared or auto-filled, and Difference Amount is the gap. For tenders without Counting Required, counted should equal trans by construction; investigate any line where it does not.
- Clear or explain every difference before posting — the target state is a Difference Amount of 0.00 on all lines, or a difference you can name that will post to the Difference G/L Account.
- Post the statement, then spot-check one line per tender family in the G/L: cash on its account, card on the bank or clearing account, gift card against the liability. (Our end-of-day routine covers the wider close.)
What success looks like
A healthy close posts a statement where every tender line's counted amount ties to its transaction amount or to a declared, explained difference; the G/L then shows card totals in the account your bank reconciliation expects, cash in the cash account, and the gift card liability moving only by sales of cards (up) and redemptions (down). If the liability moves on a cash sale, or card money lands in cash's account, the tender setup — not the cashier — is where to look.
IndexBack to all guides →