Voucher Reconciliation for Mall Tenants: Why Manual Tracking Fails (and What to Do Instead)

A mall in Pune ran a Diwali voucher campaign in October 2025. They issued vouchers worth ₹2.4 crore across 18 tenant brands. Three months later, when the marketing team sat with finance to close the campaign, three numbers refused to agree. Issuance said ₹2.4 crore. Tenant claims said ₹2.31 crore. The gift-card platform reported ₹2.27 crore. The gap was ₹13 lakh nobody could decisively trace. This is not unusual. Most Indian malls running voucher programmes today live with a 3-7 percent drift, and the drift only gets worse during peak festival quarters.

This is not unusual. Most malls running voucher programs in India today operate with a five to seven percent reconciliation drift between issuance, redemption, and settlement. The leakage is rarely fraud. It is more often manual data entry errors, partial redemptions counted twice, voucher expiries handled inconsistently, and tenant brand teams reporting slightly different numbers than the mall's marketing team.

This post lays out a reconciliation model that holds up under audit. It is built around three principles: every voucher event is a row in a single ledger, every approval has a maker and a checker, and the source-of-truth for redemptions is the POS system not the brand's marketing dashboard.

Why spreadsheet-based voucher tracking fails at scale

A small voucher campaign of a few hundred vouchers can run on a spreadsheet. A program that issues tens of thousands of vouchers a year across 80 tenant brands cannot. The failure modes are predictable.

Multiple sources of truth. The mall's marketing team has their issuance file. Each brand has its own redemption sheet. The gift-card platform has its own database. Finance has its own GL entries. When five sources of truth diverge by even half a percent, the differences compound to lakhs.

No row-level immutability. Spreadsheets allow edits. An entry from January can be quietly changed in March. Audit cannot reconstruct the state of the program on any given date.

Manual approval trails. A voucher issued under exception (extra value, off-template recipient, retroactive backdating) typically gets verbal sign-off. Six months later, neither the marketing lead nor the finance head remembers the conversation.

No tenant-side visibility. The brand team at a tenant's outlet does not see the master issuance file. They cannot tell which voucher codes are valid. Disputes get resolved by phone calls.

Partial redemption ambiguity. A ₹2000 voucher used against a ₹1800 bill leaves ₹200. Different brands handle this differently. Some forfeit, some leave as a credit. Without a uniform rule, the program drifts.

The cumulative effect of these failure modes is a three to seven percent value gap that grows during peak quarters like Diwali, the wedding season, and end-of-financial-year campaigns.

The four-table reconciliation model

A defensible voucher program runs on four tables, not one. Each table has a single purpose. Together they make every event traceable and every dispute resolvable.

Table 1: Voucher master

One row per voucher code. Captures the immutable details set at issuance: voucher SR number (VIS-2026-... or similar), value, brand ID, campaign ID, recipient identity, issuance date, expiry date, status, and a hash of the issuance metadata.

A voucher master row is created once and never updated. Status changes write to the events table instead. This makes the issuance count cleanly reportable at any point in time.

Table 2: Voucher events

One row per state change. Issued, approved, sent, redeemed, partially redeemed, expired, revoked, refunded. Each row carries voucherid, eventtype, eventat, actorid, source_system, and reference (e.g. POS invoice number for redemptions).

Events are append-only. A revoked voucher does not delete its issuance row, it adds a revocation event that supersedes earlier events for reporting purposes.

Table 3: Maker-checker audit log

One row per approval-style action. Every issuance, every exception, every reject-and-request-changes, every revocation has a maker, a checker, a makerrole, a checkerrole, a justification field, and a timestamp.

The maker-checker pattern is borrowed from banking software for good reason. It prevents single-person fraud, creates a clean accountability trail, and means audit work can sample maker-checker pairs efficiently.

Table 4: Settlement reconciliation

One row per settlement period (usually monthly) per tenant. Captures total redemption value as reported by the tenant, total as reported by the POS, total as reported by the gift-card platform, and a settlement delta with a free-text note.

The reconciliation table is the only place where the three external sources meet. Differences are not papered over here. They are recorded with a delta and a note.

These four tables, plus a sensible API on top, take a voucher program from a spreadsheet operation to an auditable system. The tables are not exotic. The discipline is in keeping events append-only and forcing every approval through the maker-checker workflow.

The five reconciliation runs every voucher program needs

Once the data model is right, reconciliation becomes a set of scheduled runs. Five of them, each catching a different class of error.

Run 1: Issuance integrity. Every voucher master row must have at least one corresponding event (the issuance event). Orphan rows mean issuance metadata was created without committing the event. Run nightly. Investigation target: under five orphans per quarter.

Run 2: Redemption sourcing. Every redemption event must carry a POS invoice number that exists in the POS system. Brand-reported redemptions without a POS reference are pending until reconciled. Run weekly. Target: under one percent unreferenced redemptions.

Run 3: Expiry sweep. Vouchers past their expiry date with no redemption or revocation event should be auto-marked expired. Late expiries leave value sitting in active state on dashboards and create reconciliation noise. Run daily as a cron.

Run 4: Maker-checker compliance. Every issuance event of value above a threshold (say ₹5000) must have a corresponding maker-checker audit row. Issuances above threshold without a checker are flagged for finance review. Run weekly.

Run 5: Tenant settlement. Monthly. Compare three numbers per tenant: tenant-reported redemption total, POS-aggregated redemption total, and gift-card-platform-reported redemption total. Differences over half a percent get a settlement note. Differences over two percent escalate to a settlement call.

These five runs replace the ad-hoc "let's all sit together and figure out why the numbers don't match" meeting that most mall finance teams know too well.

What a single voucher's life looks like in the model

To make this concrete, here is the same Diwali voucher tracked end to end.

A mall marketing manager opens the Voucher Issuance wizard on Day 1. They pick the brand (Zara), set the value (₹3000), select the recipient (a Platinum tier shopper), and submit for approval. A voucher master row is written with status Pending. A maker-checker row is written with the marketing manager as maker.

The brand manager at the tenant's head office receives an approval notification. They review the campaign brief, check the recipient eligibility, and click Approve. The maker-checker row is updated with checker details. The voucher master status flips to Active. An event row records the approval.

The voucher is dispatched to the shopper via WhatsApp on Day 1. An event row records the send.

On Day 5, the shopper visits the Zara outlet inside the mall. They make a purchase of ₹2400. The store associate scans the voucher code on the POS. The POS calls the voucher API. The API checks the voucher status (Active), the brand match (Zara), the expiry (still valid), and writes a redemption event with the POS invoice number. The voucher master remains untouched. A new event row records the partial redemption of ₹2400 against a ₹3000 voucher, leaving ₹600 forfeited or credited per the campaign rules.

On Day 30, the month closes. The reconciliation job runs. It pulls Zara's reported redemption from the brand-side report. It pulls the POS-aggregated total. It pulls the gift-card-platform total. All three agree on this voucher. The settlement table records the match.

At any point during this life cycle, an auditor asking "what happened to voucher VIS-2026-031459?" gets a clean, timestamped sequence of events with maker-checker context for every approval. That is what reconciliation should produce.

Common failure scenarios and how the model handles them

A voucher was issued by mistake to the wrong shopper. The marketing manager creates a revocation event with a justification. The voucher status flips to Revoked. The original master row stays intact. A fresh voucher can be issued. The audit trail shows the revocation, the reason, and the replacement.

A brand reports a redemption that the POS does not show. The redemption event is held in Pending state. The reconciliation team investigates. Either the POS sync was late (the event eventually appears and the redemption is confirmed), or the brand's report was in error (the event is cancelled with a note).

Partial redemption rules differ across brands. Each campaign carries a partial_redemption_policy field (forfeit, credit, or no-partial). The POS API enforces the policy at redemption time. Reconciliation reads the same field to compute expected value. No verbal agreements.

A voucher is redeemed twice. Cannot happen. The voucher status is checked atomically at redemption time. The second redemption attempt fails at the API layer with a clean error code that the POS can surface to the store associate.

A voucher expires while a shopper is at the till. The expiry rule is configurable. Some campaigns use a strict cutoff. Some use a grace period of 48 hours. The rule is in the voucher master and enforced at the API.

Tenant brand changes leadership and disputes a quarter's reconciliation. The settlement table holds every monthly run. The new leadership can read the same closed numbers. Disputes that escalate get the full event timeline as evidence.

Where Portcart's voucher module fits

Portcart's voucher management module was built around this four-table model from day one.

The eight-step issuance wizard captures campaign metadata, recipient details, and value tiers. Every step writes to the voucher master and the events table. The maker-checker step is mandatory above the campaign-configured threshold. The audit log table records each approval row.

The voucher history view shows the full event timeline for any voucher with one click. Filters cover status, brand, campaign, date range, maker, and checker. CSV export drops a clean reconciliation-ready file.

The settlement reconciliation runs as scheduled jobs that feed the operator dashboard. Mall finance leads see the variance bands at a glance. Drill-downs show the row-level evidence.

The bulk-assign drawer added in mid-May 2026 lets a mall add hundreds of brands, services, or zones to a property in one round trip. The same drawer pattern is being extended to bulk voucher issuance for use cases like festival employee gifting (a mall HR team issuing 800 vouchers to staff at once).

We are not the first vendor to do voucher management for malls. We are the first to do it for Indian malls with maker-checker, multi-source settlement, and tenant-side visibility built in from the start.

What to do this month

If your mall is running a voucher program on spreadsheets today, the migration to a proper model does not have to be a six-month project.

Week one: get the issuance, events, and audit log tables in place even as flat CSVs with timestamps and a no-edit rule. The discipline matters more than the platform.

Week two: agree partial-redemption rules across all tenants and document them per campaign. This conversation alone usually surfaces three to four percent of the drift.

Week three: set up the five reconciliation runs as weekly or monthly jobs. Even Excel macros that run on a schedule are better than ad-hoc.

Week four: have the first reconciliation conversation with two pilot tenants using the new tables. Use the gaps you find to refine the model before rolling to all tenants.

By month three of the new model, the drift should drop to under one percent. By month six, it should be under half a percent. That recovered value is straight-to-bottom-line for the mall and a far better operating posture for every audit cycle.

Frequently asked questions

Does this model work for gift-card platforms like Qwikcilver or Pine Labs?

Yes. The four tables sit above the gift-card platform. The platform is the issuer of record for the gift instrument. The mall operates the program on top.

What is the minimum maker-checker threshold to enforce?

For most malls in India, ₹2500 to ₹5000 per voucher is the right threshold. Below that, the operational friction of a two-person approval is not worth the fraud risk reduction. Above that, every voucher should have a maker and a checker.

Can the reconciliation runs catch employee fraud?

They are not designed for fraud detection on their own. They catch the operational gaps that mask fraud. A serious fraud control programme layers anomaly detection on top of the clean event history.

How long should voucher records be retained?

Seven years for the financial event records (tax and audit). Personal identifiers in voucher records should be pseudonymised after the campaign window plus a defensible retention period for dispute resolution, often two to three years.

The cost of running a voucher program on spreadsheets in 2026 is no longer just operational. It is reputational with tenants, financial in leakage, and increasingly legal under DPDP. Move the data model. The rest follows.

How Portcart handles this

The four-table reconciliation model is the exact architecture behind Portcart's voucher and loyalty modules.

• [Voucher Management](/platform/vouchers) — eight-step issuance wizard with mandatory maker-checker above configurable thresholds, immutable event log, partial-redemption policy enforcement at the API layer, and tenant-side visibility.
• [Loyalty Ledger](/platform/loyalty) — the same append-only event pattern for points-on-invoice and POS-linked transactions, so one reconciliation discipline covers both programs.
• [Communication Engine](/platform/communication) — sends voucher-issued, voucher-reminder, and voucher-expiry messages tied back to the source consent record.

If your mall is closing campaigns with a percentage gap nobody can decisively explain, request a demo and we will walk you through how Portcart customers close to under half a percent.