--- title: "The gift voucher register: the money you already spent, and still owe" subtitle: "Every voucher you sell is a debt with your name on it, so one list holds what is left on each one, the till checks it before anything leaves the shop, and month end produces the outstanding total your accountant has never been able to ask you for" url: "https://rxed.ai/blueprints/gift-voucher-liability-register.html" id: "gift-voucher-liability-register" version: "1.0" published: "2026-08-24" kind: "workflow" setup_effort: "A weekend" setup_hours: "6-12" running_cost_usd_per_month: "0-12" paid_software_usd_per_month: "0" time_saved: "medium" time_saved_basis: "An hour or two a month stops going into hunting for whether a voucher was already used and reconstructing the year-end figure from memory, but the real return is the voucher you did not honour twice and an outstanding balance you can put a number on at any moment instead of once a year" runs_by: "" data_location: "" data_location_note: "" first_to_break: "" failure_signal: "" problem: "You sold a pile of vouchers before Christmas and the money is long spent. Nobody can tell you how many are still out there, what they are worth, or whether the one on the counter has already been used." fix: "One list holds every voucher you have ever sold, with what is left on it and the day it runs out, and the till checks that list before anything is handed over. Once a month it tells you the total you still owe, which is the number your bookkeeper has been asking for." tools: [] tech: ["NocoDB", "n8n", "Gotenberg", "Docling", "Ollama"] repos: - name: "NocoDB" url: "https://github.com/nocodb/nocodb" - name: "Baserow" url: "https://github.com/baserow/baserow" - name: "n8n" url: "https://github.com/n8n-io/n8n" - name: "Gotenberg" url: "https://github.com/gotenberg/gotenberg" - name: "Docling" url: "https://github.com/docling-project/docling" - name: "Ollama" url: "https://github.com/ollama/ollama" categories: ["Payments", "Bookkeeping", "Reporting", "Self-hosted", "n8n"] source: "RXed AI News — https://rxed.ai" --- # The gift voucher register: the money you already spent, and still owe > Every voucher you sell is a debt with your name on it, so one list holds what is left on each one, the till checks it before anything leaves the shop, and month end produces the outstanding total your accountant has never been able to ask you for A voucher is not a sale. It is cash today against goods you owe for years, and in most small businesses the only record of that debt is a drawer, a photo on someone's phone, and the hope that nobody spends the same one twice. Build the register first. The automation is easy once the number exists. ### The problem December was good. You sold a pile of vouchers, the money went into the account, and by February it had been spent on stock like any other money. Now someone puts a printed voucher on the counter and three things are true at once: you do not know whether it has already been used, you do not know how much is left on it, and you do not know how many more of them are out there. So you honour it, because arguing with a customer over your own paperwork is the worst trade in retail. Every accounting framework treats that voucher the same way, and it is not the way most owners think about it. The sale creates a liability , not revenue. Revenue arrives when the customer actually takes the haircut, the meal or the shoes. Under both ASC 606 in the US and IFRS 15 in Europe, the unredeemed remainder — the industry calls it breakage — only becomes income either in proportion to real redemptions or at the point where redemption has become remote, and it has to be estimable from your own history. You cannot have a history you never wrote down. Then there is when the thing is allowed to die, and that answer is not yours to invent. In Ireland , the Consumer Protection (Gift Vouchers) Act 2019 has applied since 2 December 2019 : where a voucher carries an expiry date it must be at least five years from purchase, a contract that is silent is deemed to be five years, the buyer must get the expiry in writing on a durable medium, and you cannot force the whole value to be spent in one visit or cap how many vouchers go into one transaction. In the US , the Credit CARD Act rules in Regulation E ( 12 CFR § 1005.20 ) set a federal floor: funds cannot expire earlier than five years from issue or last load, dormancy and inactivity fees are banned unless the card has sat unused for at least a year and then at no more than one fee a month with clear disclosure, and you cannot charge to replace an expired card while the funds behind it are still good. In Canada , Ontario and British Columbia both stop ordinary retail gift cards expiring at all, while a voucher for one named service, a massage at a spa, is treated differently. In Belgium there is no dedicated statute, so the general consumer-contract duties carry the weight: you may set the terms, and you must tell the buyer clearly and in advance what they are. In England and Wales there is likewise no single statutory minimum, only the requirement that the expiry term be clear, prominent and not unfair. VAT adds a second axis that has to be decided the day you sell, not the day it comes back. Under Directive (EU) 2016/1065 , in force across member states since 1 January 2019 and applying to vouchers issued after 31 December 2018, a single-purpose voucher — one where the place of supply and the VAT due are already known at issue — is taxed when it is issued or transferred. A multi-purpose voucher is taxed when it is redeemed. A voucher for "one wash and cut" and a voucher for "€50 to spend here" are not the same instrument, and a code on its own will not tell you which one you sold eighteen months later. And in the US, expiry does not always mean the money is yours. Roughly half the states treat unredeemed balances as unclaimed property after a dormancy period of typically three to five years; on one January 2025 count, 37 states including California, Illinois, Florida, Ohio, Pennsylvania and Texas either exempt gift cards outright or have no rule requiring them to be handed over. That line moves. Arizona is the live case: a June 2026 amendment struck gift certificates, electronic gift cards and stored-value cards out of the definition of property with effect from 12 September 2026 , and on 31 July 2026 the Arizona Department of Revenue published ruling UPR 26-1 saying it does not read the amendment as expanding what has to be reported. Published coverage does not even agree on the bill number. You are not going to track that. What you can do is hold the data — issue date, face value, redemptions, last activity, balance — so that whoever does track it can answer in an afternoon instead of a forensic exercise. ### The architecture [ counter sale ]   [ webshop order ]   [ the old paper stubs ]        │              │                │   one-off migration        └───────────┬──────────────┘                  ▼ [ n8n — issue ]         ├─ random code, long, never the next number         ├─ Gotenberg: HTML → PDF voucher with a QR         └─ email to the buyer, row written before it sends                 ▼ [ the voucher file — NocoDB ]   one row per voucher         │  code · type (single/multi purpose) · face value         │  issued · expires · balance · last activity         └─ child table: one line per redemption , never overwritten         ▼ [ REDEEM ]  one page, works on the till tablet and on a phone         ├─ scan or type the code → shows the balance, live         ├─ take an amount, not a tick box         └─ writes the line before the customer walks [ n8n — the clock ] nightly     [ n8n — the number ] monthly         └─ 90 / 30 days out         └─ outstanding balance, aged            tell the buyer               to you and the bookkeeper Four moving parts and one rule. The file is the only truth. Nothing hands over goods without asking it, and nothing asks it without writing back. Redemptions are appended as lines, never as a field that gets edited, because a balance you can recompute from its own history is a balance you can defend and a single overwritten cell is not. ### Tool choices — and why First, the honest one: if your till already issues gift cards with a real ledger behind them, stop reading and use it. This build is for the shops that sell printed or emailed vouchers alongside a till that knows nothing about them, which is most salons, most restaurants, most small retailers, and every business that started selling vouchers because a customer asked in December. NocoDB (64.7k stars, release 2026.08.1 on 19/08/2026) is the voucher file. Parent table for the voucher, child table for redemptions, and a grouped view that shows you outstanding balance by year of issue without writing a query. Note the licence: NocoDB moved from AGPL to the Sustainable Use License on 29 January 2026 , which is free for internal business use and stops you reselling it as a hosted service. Running your own voucher book is internal use. If you would rather stand on a permissive licence, Baserow (5.7k stars, 2.3.3 on 21/07/2026) has an MIT open-source core with premium and enterprise directories licensed separately and does the same job. n8n (Sustainable Use License, 202.1k stars, n8n@2.35.7 on 21/08/2026) is issue, redeem, clock and month-end report. Four workflows on a box you may already be running for the late-invoice chaser or the review request engine. The redeem workflow is the one worth care: it must read and write in the same call, and it must refuse rather than guess when the code is unknown. Gotenberg (MIT, 12.9k stars, v8.36.0 on 14/08/2026) turns an HTML template into the PDF voucher, QR code included. It is a container you post to, it holds no state, and it means the voucher a customer receives is generated from the same row that the till will later check. Print-shop vouchers work too. They just need the code printed on them and the code entered into the file before they leave the building. Ollama (MIT, 179.3k stars, v0.32.15 on 19/08/2026) with Docling (MIT, 65.4k stars, v2.121.0 on 20/08/2026) is the only AI in this build, and it does one unglamorous job: reading the mess you already have. Photographs of old paper stubs, a webshop's order confirmation emails, a spreadsheet somebody kept in 2023. Docling gets the text out, a small local model pulls four fields — code, value, date sold, expiry — and it is explicitly allowed to answer UNKNOWN, which routes to a person. It never decides whether a voucher is valid and it never invents a date. A hallucinated expiry looks exactly like a real one, and the first time you find out it was wrong is at the counter with a customer watching. Monthly cost. Software €0 across the stack. One small VPS at roughly €5–12 a month runs NocoDB, n8n and Gotenberg together, and €0 extra if it rides on a box you already own. Emailing the voucher goes through the mailbox you already pay for. Realistic range: €0–12 a month . The commercial gift-card modules bolted onto booking and POS software typically run €15–60 a month per location, so this pays for itself the first year and keeps paying when you open the second shop. ### Setup outline 1. Write down what you actually sell. Value vouchers ("€50 here") and service vouchers ("one massage") are different instruments for VAT and, in some places, for expiry. Decide the list now, because it becomes a field. 2. Fix your terms before you build anything, and check them against the rules where you trade rather than against what the last shop did. Expiry period, whether part-spending is allowed, what happens on loss. Put them on the voucher and on the receipt. 3. Build the file: one row per voucher with code, type, face value, issue date, expiry date, buyer contact, current balance, last activity. Then a child table with one line per redemption: date, amount taken, who served, which till. 4. Generate codes randomly and long. Twelve characters from an unambiguous alphabet, produced by the workflow, never by counting up from the last one. 5. Build the issue workflow. Row first, PDF second, email third. If the email fails you still have the voucher; if the row fails you have sold something that does not exist. 6. Build the redeem page and make it faster than the paper it replaces. Scan the QR or type the code, see the balance in one screen, enter the amount taken, done. If it takes longer than writing in the notebook, the notebook wins and your data dies. 7. Migrate the shoebox. Photograph every outstanding paper voucher, run it through the reader, and review every extracted row by hand against the image before you accept it. This is a one-off afternoon and it is the only chance you get to draw a line under the old system. 8. Build the nightly clock: at 90 and 30 days before expiry, email the buyer that they still have money with you. This is not a compliance step. It is the cheapest marketing in the build, and it brings people through the door holding a reason to spend more than the voucher. 9. Build the month-end report: total outstanding, split by year of issue and by voucher type, sent to you and to whoever does your books. That single number is what an accountant has been unable to ask you for. 10. Run it in parallel with the notebook for two weeks. Compare them on a Friday. Where they disagree, the notebook is usually right about what happened and the file is right about what it was told, and the gap is the training you still owe your staff. ### Pitfalls — the real ones Sequential codes are an open till. If voucher 1043 exists, so does 1044, and anyone who bought one can work out the rest in an evening. Random codes, long enough to be pointless to guess, and rate-limit the page that checks them so nobody can grind through the space. Partial redemption is the entire product. A €100 voucher against a €38 service is the normal case, not the edge case. A system that can only mark a voucher "used" will make you choose between giving away €62 and quietly keeping it, and both of those decisions get made at the counter by whoever is on shift. A photo of a PDF works exactly as well as the PDF. The same voucher can turn up at two branches on the same Saturday. Redemption has to write to one shared file at the moment it happens. A per-branch notebook typed up on Sunday is not a control, it is a delayed discovery. The expiry date you print is not always the one you get to choose. Ireland's five-year floor, the US federal five-year floor and the Canadian provinces that stop retail gift cards expiring at all are set by somebody else. Even where nothing forbids a short expiry, an unclear or buried one is unfair-terms territory in both the UK and the EU. Expired does not mean the money is yours. In the US, roughly half the states may want the unredeemed balance handed over as unclaimed property, and the accounting rules for recognising breakage are separate again from the date on the card. Do not book the balance as income on the day the date passes because it tidies the ledger. That is precisely the entry an auditor reverses. Record the VAT type at issue, not at redemption. Single-purpose and multi-purpose vouchers have VAT falling due at different moments under the 2019 EU rules, and there is no way to reconstruct which one you sold from a code and a face value a year later. It is one field, and it has to be filled the day you sell. The count is not the number. "We sold about three hundred vouchers" tells you nothing. "€14,200 outstanding, €3,100 of it issued more than three years ago" is a number you can act on, and it is the one that belongs on the balance sheet. December cash is somebody else's goods. A big voucher run is an interest-free loan from your customers, repaid in haircuts. In a UK insolvency the holders rank as unsecured creditors, and unsecured distributions in retail failures are routinely under a penny in the pound. Knowing the outstanding balance in real time is how you avoid being the business that finds out in March. This is a build guide, not legal, tax or accounting advice. The dates, thresholds and rules named here are the position as published for the specific jurisdictions mentioned, they change, and Arizona in 2026 is the standing proof of how fast. Check where you actually trade, and put the outstanding-balance report in front of your accountant before you decide what any of it means for your books. ### Verified repos [NocoDB](https://github.com/nocodb/nocodb) — Sustainable Use License (changed from AGPL 29/01/2026), 64.7k stars, release 2026.08.1 (19/08/2026) [Baserow](https://github.com/baserow/baserow) — MIT open-source core, premium/enterprise dirs licensed separately, 5.7k stars, 2.3.3 (21/07/2026) [n8n](https://github.com/n8n-io/n8n) — Sustainable Use License (free internal business use), 202.1k stars, n8n@2.35.7 (21/08/2026) [Gotenberg](https://github.com/gotenberg/gotenberg) — MIT, 12.9k stars, v8.36.0 (14/08/2026) [Docling](https://github.com/docling-project/docling) — MIT, 65.4k stars, v2.121.0 (20/08/2026) [Ollama](https://github.com/ollama/ollama) — MIT, 179.3k stars, v0.32.15 (19/08/2026) All figures checked against the GitHub API on 24/08/2026. Every repo had a commit within the last four days. Get the next blueprint as it publishes — free, practical, verified tooling only. [Subscribe](https://subscribe.rxed.ai) · Want this audited or extended for your business? DM [@RXed_EU](https://x.com/RXed_EU)