Tender types in LS Central: setting up cash, card, and every other way customers pay

Implementation · 9 min read

Cash, card, cheque, customer account, foreign currency: at the till these look like buttons. In LS Central setup, a tender type is more than a button — it is a code the POS command uses, a counting decision that shapes the end-of-day statement, and an account mapping that decides where the money posts. Set up only the button and the sale works; set up the rest and the statement reconciles. This guide builds tender types in that order, using only behaviour LS Retail documents.

A note on sources and versions: much of the precise tender behaviour in LS Central is documented at field level — one page per field on the Tender Type Card setup — and in the POS Commands table. Those pages are the evidence base here. Field names and example codes follow that documentation; a given implementation may use different codes, and the code list in use should be confirmed before adding new tenders to a live store.

A tender type is an accounting rule, not just a button

Three documented layers make up a working tender. The first is identification: the POS command TENDER_K takes a Tender Type Code from the Tender Type table as its parameter, and when called it defines the tender type used in the transaction. The second is counting: a Counting Required setting decides whether the tender must be counted, and what the statement does if it is not. The third is posting: an Account Type and Account No. say where payment by that tender type card is posted, and a Difference G/L Account receives any gap between what was counted and what the system expected. A tender missing any layer will still take money; it will cause its trouble later, at declaration or at statement calculation, when the store is trying to close.

The documented tender codes and TENDER_K

TENDER_K is a pre-entry command: it takes the current input as its parameter, and it can be combined with other commands, such as the Amount command. The TOTAL command is what moves the application from sales mode to payment mode in the first place, so the sequence at the till is consistent — total the sale, then define the tender, then take the amount. Tender Type Offers sit on top of this foundation: LS Retail documents offers created for a specific tender type, with examples for Tender Type Cash and for a Visa card, and notes that such offers are calculated last and that a transaction can only be fully paid with the tender type of the offer. An offer-driven tender is therefore a reason to keep tender codes clean and distinct, not a reason to multiply them casually.

Counting Required and the statement

Counting Required is the field that decides how honest the end of day has to be. LS Retail's field help states that it shows whether counting of the tender type card is required. If the field is not marked with a check mark, the program automatically fills in the Counted Amount field with the contents of the Trans. Amount field when the statement is calculated. Read that carefully: an uncounted tender does not produce a difference, because the system assumes the counted amount equals the transaction amount. That is a sensible default for a tender nobody physically holds, and a dangerous one for cash.

The declaration flow enforces the same distinction. The TENDER_D command starts a Tender Declaration transaction, and only tender types that have a check mark in Counting Required can be entered in it. A tender that should be declared but was set up without Counting Required cannot be declared at all — the failure appears at close, not at setup, which is why the counting decision belongs in the setup checklist rather than in end-of-day troubleshooting.

One nuance from the field help: the Counting Required value is copied automatically from the tender type to the tender type card when the Card No. is filled in, and it can be marked differently for the card. Store-level variation is therefore possible, but it should be deliberate: if one store counts a tender and another does not, that difference should be a decision, not an accident of setup order.

Account Type, Account No. and the Difference G/L Account

Posting is the second half of the setup. The Account Type field on the Tender Type Card setup specifies the type of account that payment by the tender type card is posted to, and the documented options are G/L Account and Bank Account. The account type selected determines the accounts that can be selected in the Account No. field — choose Bank Account and the lookup offers bank accounts; choose G/L Account and it offers general ledger accounts. As with Counting Required, the Account Type is copied automatically from the tender type when the Card No. is filled in, and a different account type can be selected for the card.

Differences need a home before they happen. The Difference G/L Account field holds the number of the G/L account to which the difference between Counted Amount and Trans. Amount for the card is posted in the Statement Line. It, too, is copied from the tender type when the Card No. is filled in and can be changed for the card. Leaving it unconsidered does not prevent differences; it only decides that the first real difference will be investigated under time pressure, at close, instead of being routed to an account finance chose in advance.

Cash handling after the sale: safe management

For physical tenders, the story continues after the statement. LS Retail's Safe Management documentation describes tender being tracked through a store safe: each POS can be connected to one safe, and tender types can be placed in bags, counted or not counted, re-counted, and transferred between the POS, the safe, and the bank, with all transfers logged. Rules can be applied per tender type — for example, whether money is counted as a total amount or by denomination, and whether coins are excluded from the bank transfer, since some banks charge extra to accept coins that could instead remain as the next day's float. The setup implication is direct: tender decisions made on the Tender Type Card and in safe rules have to agree, or the same cash will be counted twice in one place and not at all in another.

Decision framework: which tenders to create

1. One tender per distinct counting and posting behaviour. If two payment methods count the same way and post to the same account, they are candidates for one tender; if either differs, split them.
2. Cash gets Counting Required. Physical money that will be declared through TENDER_D must carry the check mark, or it cannot be entered in a declaration.
3. Non-physical tenders get an explicit counting decision anyway. Without Counting Required, the statement will auto-fill Counted Amount from Trans. Amount — acceptable only when that assumption is true by design.
4. Every counted tender gets a Difference G/L Account chosen by finance before go-live, not during the first discrepancy.
5. Foreign currency is its own case: the documented currency example uses tender type 6 with CURR_K and a currency code, so plan currency tenders separately from local cash.

Setup procedure: add cash, card and customer account tenders

1. List the payment methods the store actually accepts and map each to a Tender Type Code, using the documented examples as the pattern: cash, check, card, customer account, and currency where needed.
2. Create each tender type with its code and description, keeping codes distinct so TENDER_K parameters and any tender type offers point at exactly one tender.
3. For each tender type card, set Account Type — G/L Account or Bank Account — and then select the Account No. that type permits.
4. Set Counting Required deliberately: marked for tenders that must be counted and declared, unmarked only where auto-filling Counted Amount from Trans. Amount at statement calculation is the intended behaviour.
5. Set the Difference G/L Account for every tender that can produce a counted-versus-expected difference.
6. Wire the POS keys: define the tender keys with TENDER_K and the tender's code as the parameter — and, for customer account, the TOACCOUNT pattern with TENDER_K post parameter 4; for currency, TENDER_K with post command CURR_K and the currency code.
7. If Safe Management is in use, connect the POS to its safe and set the per-tender handling rules, such as counting by denomination or excluding coins from bank transfers.

What success looks like

Run test sales in a sandbox or training mode and close the loop. Press TOTAL to move from sales mode to payment mode, pay one sale in cash and one by card, and confirm each payment is recorded under the intended tender type. Start a Tender Declaration with TENDER_D and confirm the counted tenders appear — and that only Counting Required tenders can be entered. Calculate a statement with a small deliberate counting difference on the cash tender and confirm two things: the Counted Amount behaves as documented for counted and uncounted tenders, and the difference posts to the Difference G/L Account set on the card. Success is a statement that calculates, a declaration that accepts exactly the tenders it should, and differences landing in the account finance chose.

Disclaimer: tender codes in the examples are the documentation's examples, not a required numbering scheme, and payment processing, card services, and tax treatment involve providers and rules outside this guide. Confirm codes and accounts with finance and the implementation partner before changing live tenders.

FAQ

Why does the statement show no difference for a tender that was never counted? Because, per the field help, without Counting Required the program fills Counted Amount with Trans. Amount when the statement is calculated. No count, no difference — by design.

Why can't a tender be entered in a Tender Declaration? TENDER_D only accepts tender types with Counting Required marked. Check the tender's counting setting first.

Can one store post a tender differently from another? The documented fields — Account Type, Counting Required, and Difference G/L Account — are copied from the tender type to the card and can be changed for the card, so per-card variation is supported and should be documented when used.