The problem
Gift cards, discount codes, and loyalty points are easy to bolt onto a checkout screen and hard to actually manage - a lost gift card with no way to void it, a coupon with no usage limit that gets shared publicly, or a loyalty program with no visibility into what a customer's points are actually worth.
How AccountDesq solves it
Gift Cards is a back-office lookup, void, and reissue tool - it deliberately never creates a card (that only happens at POS checkout, where the code is generated and handed to the customer). Every card's detail view shows its balance, redemption history, and reissue chain (old and new codes cross-link to each other), and voiding requires a typed reason. Gift card sales post to a real Gift Card Liability account on the ledger, not an off-books number. Coupons carry a full set of real constraints - valid-from/valid-to dates, a total redemption limit across all customers, a per-customer limit, and a minimum purchase amount - and usage counts are computed live from actual redemptions, never cached or estimated. Loyalty Points is intentionally the simplest of the three: it's off by default, earns points on a completed POS sale, and redeems through the same discount mechanism coupons use (mutually exclusive with a coupon on one sale) - with no GL postings, because it's a customer-engagement mechanic, not an accounting entry.
How it works, step by step
Sell at POS, manage in the back office
Gift cards are sold and coupons/points are redeemed at checkout; lookups, voids, reissues, and program settings live in their own admin screens.
Set real constraints
Coupons get valid dates, total and per-customer limits, and a minimum purchase amount - not just a code and a percentage.
Void or reissue with a reason
A lost or stolen gift card gets voided (with a typed reason) or its remaining balance reissued onto a new code - both cross-linked in the card's history.
Turn on loyalty deliberately
Nothing earns or redeems until you explicitly enable it and set an earn rate and redemption value.
Connected to the rest of AccountDesq
Nothing here works in isolation - it posts through the same ledger as everything else.
In practice
A retailer runs a festive-season promotion: a ₹500-off coupon with a total use limit so it can't be shared indefinitely, alongside a percent-off welcome code for new customers. Meanwhile, a customer's gift card is stolen - the back office voids it with a reason on file, and reissues the remaining balance onto a fresh code, with both cards cross-linked in the history so there's a clean audit trail from the original sale.
What this means for your business
- Gift cards are real, auditable liabilities - not a spreadsheet of codes someone has to track by hand.
- Coupons carry real usage limits and expiry dates instead of a discount code that quietly gets shared or abused.
- Loyalty points are off by default and dead simple to configure - no risk of a program silently running with numbers nobody set on purpose.
Frequently asked questions
Can I create a gift card directly from the back office?
No - the Gift Cards page is deliberately lookup/void/reissue only. Gift cards are created by selling them at POS checkout, where the redeemable code is generated for the customer.
What happens when a gift card is voided?
Voiding requires a typed reason and is logged. A voided card can't be redeemed further; if the balance should move to the customer, it's reissued onto a new code instead, and the old and new cards cross-link in each other's history.
How are coupon usage limits enforced?
A coupon can carry a total redemption limit (across every customer, ever) and a separate per-customer limit - both computed live from actual redemptions, never cached, so the count is always accurate.
Do loyalty points post to the accounting ledger?
No - loyalty points are deliberately not a GL entry. They're a customer-engagement mechanic (earn on a completed sale, redeem like a coupon), off by default until you explicitly turn the program on.