Why a gift card accounting integration starts with the liability, not the ledger

Most order feeds are built around a single assumption: an order arrives, therefore a sale has occurred. That assumption holds for almost everything a retailer sells, and it fails completely for vouchers. A gift card accounting integration has to recognise that selling a £50 gift card is not a £50 sale. It is £50 of cash received against a promise to supply goods at some unspecified point in the future, and until that supply happens the £50 belongs on the balance sheet, not in the profit and loss account.

The practical consequence of getting this wrong is visible within a month. If the feed posts the full order value to a sales nominal, revenue is overstated by the value of every voucher issued, output VAT is likely overstated too, and the obligation to the customer never appears anywhere in Sage. Worse, when the voucher is eventually redeemed, the redeemed value is usually posted as a second sale, so the same money is recognised twice. Finance teams normally discover this during a year-end review, by which point twelve months of comparatives are unreliable.

There are only four events that matter, and a well-scoped integration handles each of them explicitly. Everything else is a variation on these.

  • Issue — A voucher is purchased. Cash or card receipt increases, and a gift card liability account increases by the same amount. No revenue, and for most retailers no VAT at this point.
  • Redemption — The voucher is used as tender against an order. The liability decreases, revenue is recognised at the normal rate for the goods supplied, and output VAT is accounted for in the usual way.
  • Credit issued in lieu of refund — A return is settled with store credit rather than cash. The original sale is credited, and a liability is created. The bank is untouched, which is the detail feeds most often get wrong.
  • Breakage or expiry — The obligation ceases, under a documented policy. The liability is released to income. This is a finance decision, not something an interface should decide on its own.

Redemption is a tender, not a discount

The single most common modelling error is treating a redeemed voucher as a discount on the order. It is easy to see why it happens: on many order payloads, the voucher reduces the amount payable, and a discount also reduces the amount payable, so the numbers appear to reconcile. They do not. A discount reduces the value of the supply and therefore the VAT base. A voucher is a method of payment against a supply whose value is unchanged. Mapping a redemption to a discount line understates gross sales, understates output VAT and leaves the liability sitting on the balance sheet indefinitely.

Shopify makes the distinction reasonably clear in its data: a gift card purchase arrives as a line item of a distinct type, and a redemption arrives as an order transaction with a gift card gateway alongside any card payment. Magento models it differently again, with the redeemed amount appearing among the order totals rather than as a payment, which means the mapping work is genuinely platform-specific and cannot be lifted wholesale from one build to another. In discovery we pull real orders of each shape from the live store rather than working from documentation alone, because the edge cases live in the payloads.

In Sage 200 the cleanest structure is to post the sales invoice at its full value with the correct tax codes for the goods, then allocate a payment against it from a gift card control account rather than from a bank account. The invoice looks exactly like any other invoice, which keeps sales analysis and VAT reporting intact. The liability is relieved by the allocation, and the bank only ever sees the cash that genuinely arrived. Where an order is settled partly by voucher and partly by card, two allocations are posted against the same invoice, and the card element should reconcile to the payout file in the normal way.

Partial redemption is where balance tracking has to be per card rather than aggregate. A £100 voucher used for £38 leaves £62 of obligation attached to a specific card number, and at period end the control account must agree to the sum of those individual balances. An integration that only posts net movements will drift, and the drift is almost impossible to unpick six months later. Carry the card identifier on every journal line or allocation reference so the reconciliation is a report rather than an investigation.

VAT: single-purpose and multi-purpose vouchers behave differently

Since the voucher rules were revised for vouchers issued on or after 1 January 2019, the treatment turns on whether the voucher is single-purpose or multi-purpose. A single-purpose voucher is one where the place of supply and the VAT liability of the underlying goods are known at the time of issue. VAT is accounted for at issue, and the subsequent redemption is not treated as a further supply. A multi-purpose voucher can be spent across goods at different rates, so no VAT arises at issue and it is accounted for when the voucher is redeemed against actual goods.

For most general retailers the gift card is multi-purpose, because the range spans standard-rated and zero-rated items. That makes the integration relatively straightforward: post the issue to the liability with a non-VAT tax code, and let the redemption invoice carry the ordinary rates. The difficulty arises with businesses that sell a single rated category and also run promotional vouchers, or that operate both a UK and an overseas storefront. Two voucher types then coexist, and if they share one product record and one nominal, the VAT return will be wrong in a way that is hard to detect.

If single-purpose vouchers are in scope, they need their own product type, their own liability nominal and their own redemption path, because the redemption must not generate output VAT a second time. In practice that means the redemption invoice is posted with a zero-rated or outside-scope code against a separate revenue analysis code, with the VAT already accounted for at issue. It is more fiddly than it sounds, and it is a decision to be signed off by the client's accountant before code is written rather than after. We will build to a stated treatment and document it; we do not determine the treatment.

Store credit, refunds and goodwill: three liabilities that look identical

Store credit issued instead of a cash refund is the second place double-counting creeps in. The correct sequence is to raise the credit note against the original invoice, reversing revenue and output VAT, and to create a credit balance as a liability. What frequently happens instead is that the credit note is posted and a bank refund is also posted, because the return event in the platform looks the same whichever way the customer was settled. The bank then fails to reconcile by the value of every credit issued that month, and someone posts a suspense entry to make it agree.

Goodwill credit is different again and deserves its own nominal. When a customer service agent issues £20 of credit with no prior sale behind it, nothing has been received. The entry is a charge to a customer goodwill or marketing cost account, offset by the liability, and the eventual redemption recognises revenue at full value against goods supplied. Treating goodwill credit as deferred income creates income out of nothing and quietly flatters gross margin.

Three distinct sources — purchased vouchers, refund credit and goodwill credit — therefore need three distinct liability accounts, even though the customer sees one balance. The ageing profile and the breakage policy for each will differ, and finance will eventually be asked to explain the movement on each. Splitting them at design time costs nothing; splitting them retrospectively requires reprocessing history.

Breakage, ageing and proving the balance

Unredeemed balances accumulate, and at some point a proportion of them will never be used. Recognising that is a matter of accounting policy and, for anything material, a conversation with the auditors. Some businesses release breakage in proportion to the redemption pattern of each issue cohort; others wait until the obligation is legally extinguished under the voucher terms. Either way, the integration's job is not to decide. Its job is to produce a reliable ageing schedule by issue month and by source, and to post the journal that the agreed policy calls for.

We generally recommend that breakage journals are prepared by the interface but posted by a person. The integration writes a draft journal and the supporting schedule to a file or a queue, finance reviews it against the ageing, and it is posted on approval. Automatic, unreviewed releases of liability to income are precisely the sort of entry that attracts attention in an audit, and the time saved by automating the final step is trivial.

The control that holds all of this together is a period-end reconciliation between the gift card control accounts in Sage and the outstanding balances held in the storefront. Run it daily rather than monthly. A one-day variance is a traceable event; a thirty-day variance is a project. Manual balance adjustments made by staff in the platform admin are a common source of unexplained differences, because they move the customer's balance without generating an order, and many feeds ignore them entirely. They need to be captured and journalised like anything else.

Building it: scope, idempotency and the tests that matter

Our delivery model starts with discovery and data mapping, and for voucher work that means pulling genuine order, refund and adjustment payloads from the live platform and agreeing a posting for each one on paper before anything is built. The output is a mapping document that names the Sage nominal, tax code, department and analysis code for every event type, including the ones nobody expects. From that we produce a fixed scope and estimate, and the scope is agreed in writing before code is written.

Every posting needs an idempotency key derived from stable platform identifiers — the order identifier plus the transaction identifier, for example — so that a retried webhook or a replayed batch cannot create a second journal. Voucher events are particularly exposed here, because a single order can generate an issue, a redemption and later a partial refund, all referencing the same order number. Keys must be distinct at event level, not order level.

Acceptance testing should be scripted against a fixed set of cases rather than done by inspection. At minimum: a voucher-only order; an order paid partly by voucher and partly by card; a partial redemption leaving a balance; a full redemption; a refund of an order that was paid by voucher; a refund settled as store credit; a goodwill credit with no originating sale; a manual balance adjustment in the admin; and a voucher issued in one currency redeemed on a storefront in another. Each case is run end to end and the resulting trial balance, VAT return figures and control account balance are compared to an expected result agreed in advance.

On completion the code, the mapping document and the reconciliation report are handed over, so the finance team can prove the liability without reference to us. If you are working through voucher and store credit treatment for a Sage or Sage 200 ledger and want the mapping reviewed before committing to a build, we are contactable on 01303 883111 or at hello@api-integrations.co.uk.

Key points

  • A voucher sale is a liability, not revenue; recognise revenue only when the voucher is redeemed against goods, and post the redemption as a tender rather than a discount so the VAT base stays intact.
  • Purchased vouchers, refund credit and goodwill credit behave differently and belong in three separate liability accounts, with single-purpose and multi-purpose vouchers kept apart for VAT.
  • Reconcile the Sage control accounts to per-card outstanding balances daily, capture manual admin adjustments, and prepare breakage journals automatically but post them only after finance review.