Vouchers in shop and store: one balance for every channel

Vouchers are a Christmas topic, and the holiday season carries particular weight for retail. Retail generates 18.5 percent of its annual revenue in the last two months of the year (HDE); for November and December 2025 the association had forecast revenue of 126.2 billion euros (HDE). Among planned gift purchases, gift vouchers came first with 29 percent of respondents, just ahead of toys (HDE consumer barometer).

Purchase and redemption do not necessarily happen in the same channel. 73 percent of respondents aged 16 and over planned to order Christmas gifts online in 2025, and one in five (20 percent) to buy them roughly half online and half in local stores (Bitkom). 15 percent planned to buy all their gifts in stores (Bitkom). A voucher that one person buys online can therefore easily end up with someone who prefers to shop in a store, or the other way around.

As long as shop and POS keep separate voucher lists, the same error patterns keep appearing. They rarely show up at the sale, but at redemption, when a customer stands at the till and the code is unknown there, or during the January reconciliation, when the total of open vouchers does not match the account in accounting.

The basics of a POS integration, such as shared inventory, click and collect and returns in store, are covered in the article on connecting the POS system to the shop. This article is about an object that does not appear there: the voucher and its balance.

The central decision is this: which system holds the authoritative balance? All other systems query it, reserve there and book there. They may display the balance, but they must not decide on a redemption based on a copy of their own. In practice, four places come into question, each with its own strengths.

The ERP or a dedicated service in the middleware is often the obvious choice, because orders, payment methods and the export to accounting already come together there. What matters is less the location than the rule: exactly one balance, one movement journal and one defined interface through which shop, POS and, where relevant, partners access it. A nightly reconciliation between two equal voucher lists does not solve the problem; it finds double redemptions only after the goods have left the store. How conflicts between systems can be resolved in general is described in the article on bidirectional sync.

The most dangerous gap opens when two channels use the same voucher almost simultaneously: one customer shows the code at the till while someone else types it into the checkout. If both systems read the same balance, both deduct their amount and both write the result back, more value is redeemed than the voucher carried. No later reconciliation prevents that; only a redemption in clear steps does.

Technically, an atomic operation decides: the reservation is only booked if the free balance at the time of booking covers at least the requested amount, for example through a conditional update in the database or a version number on the voucher account. If the condition fails, the channel receives a clear rejection. Over HTTP, status 409 Conflict fits this case, as it reports a conflict with the current state of the resource (RFC 9110). POS and shop then show the actual balance instead of silently retrying the redemption.

An idempotency key per redemption attempt belongs to this as well. If the connection drops after the booking and the POS sends the request again, the leading system must not deduct the amount a second time but return the result of the first booking. How such keys and retries are built is shown in the article on idempotency and retry strategies.

Cancellations and returns are where voucher balances drift apart most often. If a receipt on which a voucher was redeemed is canceled, the redemption must go back to the voucher account as a reversing movement, referencing the canceled receipt. The same applies to an abandoned online order: the redemption is reversed, not deleted. If, on the other hand, the sale of a voucher itself is reversed, the leading system blocks the code before the money flows back.

A return adds a business decision: does the refund go back to the voucher, to the customer as a new voucher or as money to the original payment method? One possible rule is to refund to the voucher first; another is a proportional split by how the purchase was paid. If an 80 euro order was paid with 30 euros from a voucher and 50 euros by card and one item is returned, the rule has to define which part is refunded first. That rule belongs in the middleware or the ERP, not in the memory of the store staff.

The document reference in both directions matters: the credit to the voucher carries the return number, and the return in the ERP carries the voucher as the refund route. The process from return request to credit note is described in the article on the RMA process between shop and ERP. When a consumer withdraws from an online purchase, separate rules on the refund route apply, which the article on the withdrawal button in the shop covers.

Every movement on the voucher account is a transaction that accounting needs to see. At the sale, a liability toward the holder usually arises; for balance-sheet preparers, no income has been realized at that point (DSFinV-K). At redemption, the liability is released and the revenue for the goods purchased is booked, and writing off a time-barred balance usually leads to income. Which accounts and tax codes apply is something you agree with your tax advisor. The interface makes sure every movement arrives with the voucher number as its document reference.

The routes there differ. The shop delivers individual documents per order, the POS a daily closing with totals per transaction type, and the leading system the complete journal. It makes sense to use the journal as the authoritative source for voucher bookings and to reconcile shop and POS data against it. How invoices, credit notes and payments reach the DATEV batch is shown in the article on DATEV integration in e-commerce; we set up the ongoing handover through our DATEV integration.

The journal has to last longer than any single voucher. Books and records must be kept for ten years, accounting documents for eight years (Section 147(3) AO). Storage of the journal, access rights and reconciliations therefore belong in the process documentation, as described in the article on GoBD process documentation for interfaces. Matching remaining payments with payment providers works the same way as for any other payment method; see the article on payment reconciliation.

An integration like this can be added to existing systems. POS and shop do not have to be replaced as long as both allow checks and reservations through an interface. How we connect ERP and shop is described on the page about ERP and inventory integration; the additional interfaces we develop are covered under API development.