Gift card administration in LS Central: setup, issuing records, and balance checks

Store operations · 7 min read

Selling a gift card at the till is the easy part. The administration underneath it — which data entry type the card lives on, how its balance is looked up, what happens when a sale is cancelled — is where gift card programs quietly go wrong. This guide covers the back-office side only. (Search results will try to sell you Lightspeed guides here; Lightspeed is a different product. Everything below is LS Central.)

How gift cards are built: data entries, not items

The mental model that makes LS Central gift cards make sense: a gift card's value is tracked through data entries — the same machinery LS uses for vouchers. Three pieces of LS documentation, read together, establish this:

• The POS command reference lists two internal commands for this area: VIEW_DATAENTRY_BAL, a lookup for data entry balance, and VIEW_VOUCHER_ENTRIES, a lookup for voucher entries. Both carry the parameter type Data Entry. Balance questions and entry history are therefore data-entry questions.
• The infocodes documentation states that infocodes of type Create Data Entry and Apply to Entry are used by the system — with no prompting of the cashier — when application entries are assigned to vouchers and gift cards. In other words, issuing and applying a card writes entries behind the scenes; the till operator never fills in an infocode to make it happen.
• The LS Commerce tenant configuration names the setup value directly: GiftCard_DataEntryType — the Data Entry Type used for gift cards in LS Central. If your environment connects a web store or apps, that value has to point at the same gift card data entry type the stores use.

LS's own training structure confirms where this sits in an implementation: the LS Central for retail general base course covers Gift card and voucher as its own module, alongside Tender management and Data distribution. Gift cards are a tender-and-entries system with a card attached — administer them that way.

The setup pieces an administrator owns

The data entry type. Gift cards run on a designated data entry type (the GiftCard_DataEntryType value above). Before changing anything here, find out what is already using it: vouchers and gift cards share the entry machinery, and the POS lookup commands do not care which program issued the entry.

The tender. At checkout, a gift card is used as a mode of payment — a tender. Where LS Commerce is connected, tender types are mapped explicitly: the tenant configuration's TenderType_Mapping pairs Commerce tender type IDs with LS Central tender type IDs, and LS's documented example reads Cash is 1=1, GiftCard is 10=10. A mapping mismatch does not stop the till selling; it stops the channels agreeing about what was sold, which surfaces later and uglier.

The currency rule. Gift cards do not support multi-currency. LS's rule is strict: the currency format of the applied gift card must be the same as the currency used in the web store, because the card needs to be generated on the POS. LS's example: a gift card worth USD 100 created on the POS requires the web store currency to be USD to reflect the USD 100 value — if the currency is different, it will not convert automatically. For a single-currency retailer this never bites. The day a second currency appears, it bites immediately, and no setting converts the card for you.

What the customer sees. The gift card code is generated from the POS. At an eCommerce checkout the customer applies the code and the amount, can redeem the total amount or a partial amount depending on the order total, and can see the gift card number and amount in the order summary — and afterwards in order history. Partial redemption is therefore normal, documented behaviour: a balance after a sale is expected, not an error state.

Issuing: what records a sale creates

When a card is sold or topped up, the system-side infocodes (Create Data Entry, Apply to Entry) assign the application entries to the card without prompting the operator. Those entries are the card's ledger: the balance is the sum of what the entries say, which is why the balance lookup and the entries lookup are the two commands that matter for support work.

Two documented edge cases belong in every admin's head:

• Cancelled sales and zero-value entries. LS Central 28.0 added a cleanup to clean the income/expense account number when cancelling a sell of a gift card, specifically to avoid adding a gift card data entry with zero value. On older behaviour, a cancelled gift card sale could leave a zero-value entry behind. If an old card's history shows an entry that added nothing, this is the likely explanation — noise, but noise you can explain instead of chase.
• The balance print after a top-up. The same release notes record a fixed issue where the gift card balance print variable did not return the correct outstanding balance after a top-up transaction — it showed only the top-up amount instead of the total remaining balance. On an affected version, a customer insisting "the receipt says $25 but I had $40 already" may be right about the receipt and wrong about the balance. Verify against the entries, not the paper.

Checking a balance and tracing entries: the procedure

1. Start with the balance lookup. At the POS, use the data entry balance lookup (VIEW_DATAENTRY_BAL) for the card. This answers "what is on it now" from the entries, not from anyone's memory of the last sale.
2. Then read the entries. Use the voucher entries lookup (VIEW_VOUCHER_ENTRIES) to see the entry history the balance is built from: issuing, top-ups, and redemptions, including any partial redemption that left the remainder.
3. Reconcile the story. The entries should explain the balance exactly. A redemption lower than the sale total is consistent with documented partial redemption; a zero-value entry points at the cancelled-sale case above; a receipt total that disagrees after a top-up points at the balance-print issue, not at missing money.
4. Check the configuration only if the entries make no sense. Confirm the gift card data entry type is the one the environment is configured to use, and — where a web store or app is connected — that the tender mapping still pairs the gift card tender correctly (LS's example mapping: GiftCard 10=10).
5. Record what you found against the card before closing the query, so the next balance question starts from your reconciliation instead of from scratch. Gift card balances surface again at statement time — the habits in our end-of-day routine apply.

Administration gotchas the docs scatter

• Blocking a problem card is a newer capability. LS Central 28.0's release notes list "Blocking of Vouchers / Data Entry" as an added feature, noting that previously there were no existing functions that allowed users to temporarily block or unblock vouchers. On an older version, "just freeze the card" may not be an available move at all — check your version before promising it to a manager mid-incident.
• Currency is a hard wall, not a conversion. No multi-currency support, no automatic conversion (see the setup section). Cards are denominated in the currency they were generated in.
• The printed balance is not the system of record. The entries are. The 28.0 top-up print fix exists precisely because paper disagreed with data.
• Zero-value entries are a known artefact of cancelled gift card sales on older behaviour — explain them, don't "correct" balances around them.

When something looks wrong: decision notes

• Balance lower than the customer expects: read the entries first. Partial redemption is documented behaviour and explains most gaps without any fault.
• Receipt shows a different balance than the lookup: suspect the print variable (post-top-up) before suspecting the data; the lookup reads the entries directly.
• Card will not apply at a web checkout: check the currency match first — card currency and store currency must be the same, with no conversion — then the tender mapping.
• A card needs freezing (lost, disputed, suspected misuse): if your version supports voucher/data-entry blocking (28.0 onwards), block it and document why; on older versions, escalate rather than improvising — there was no supported block function.
• Entries exist but the balance lookup disagrees with them: stop and treat it as a data problem for your LS partner, with the entry list as evidence. Do not adjust the customer's balance on till-side arithmetic.

What success looks like

• For any card, you can produce the balance and the full entry history that explains it, using the two documented lookups.
• Every discrepancy a customer raises maps to a documented behaviour — partial redemption, a zero-value entry from a cancelled sale, or the post-top-up print issue — or is escalated with evidence.
• The gift card data entry type and the tender mapping are documented for your environment, and the currency rule is written into the program's terms before a second currency appears.

FAQ

Is a gift card an item we sell? The sale happens at the till, but the value lives in data entries: system infocodes assign application entries to the card at issuing and redemption. Administration — balances, history, blocking — works on those entries.

Can a customer spend part of a card and keep the rest? Yes. LS documents redeeming the total amount or a partial amount depending on the order total; the remainder stays on the card and shows in its entries.

A card was bought in one currency and the store now trades in another. Can it still be used? Gift cards do not support multi-currency and amounts do not convert automatically — the card's currency must match the currency it is applied in. Treat cross-currency cards as a policy decision to make explicitly, not a system setting.

General information only, based on LS Retail documentation and LS Central 28.0 release notes checked 2026-10-17. Gift card obligations (expiry, unredeemed balances) are also governed by consumer law in your jurisdiction — this guide covers system administration, not legal advice.