POS-Linked Loyalty in Indian Malls: The Reconciliation Pattern That Holds Up

A mall and a top tenant brand agree to integrate POS-linked loyalty. The brand's POS pings the mall's loyalty engine every time a loyalty member transacts. Points credit in real time. Shopper happy. Mall happy. Brand happy. Three months in, the brand's finance team says they were over-credited by ₹2.4 lakh. The mall's finance team says no, it was actually under-credited by ₹80,000. Both pull data. Both have evidence. Neither matches. This is the standard 90-day dispute that POS-linked loyalty integrations generate when the reconciliation pattern isn't laid down at the start.

Three months in, the brand's finance team says they were over-credited by ₹2.4 lakh. The mall's finance team says no, it was actually under-credited by ₹80,000. Both pull data. Both have evidence. Neither matches.

This is the standard 90-day dispute that POS-linked loyalty integrations generate when the reconciliation pattern isn't laid down at the start. This piece walks through why disputes arise and the four-table pattern that prevents them.

Where the disputes come from

Five sources, each accountable for a typical 0.5-2% of the discrepancy:

1. Cancelled transactions. Customer pays, then changes mind 5 minutes later. POS voids the sale. Did the void message reach the loyalty engine? Sometimes yes, sometimes no.

2. Partial refunds. Customer returns one item of three. POS posts a negative adjustment. Did the loyalty engine apply a proportional point reversal, or full reversal, or none?

3. Gift card redemption at POS. Customer pays with a gift card. POS records a transaction. Did the loyalty engine treat it as cash-equivalent for points, or exclude it because the gift card was a reward in itself?

4. Split-payment transactions. Customer pays with 60% loyalty points and 40% UPI. POS records the gross transaction. Did the loyalty engine debit points and credit points for the cash portion, or just one?

5. Tax handling differences. GST on the customer's bill. Did the loyalty engine compute points on gross-of-GST or net-of-GST? The brand may have agreed to one and the mall to the other.

Each of these creates 50-200 small discrepancies per month at a high-volume tenant. Compounded over 90 days they produce the kind of variance that breaks trust.

The four-table reconciliation pattern

The fix is structural. Every transaction event lands in four parallel tables, owned by the mall, that together form an indisputable audit trail.

Table 1 — Transaction master

One row per original sale. Captures: tenant id, POS transaction id, shopper id, gross amount, GST, net amount, payment method breakdown, timestamp.

Immutable. Never updated. Cancellations and refunds get their own rows in table 2.

Table 2 — Transaction events

One row per state change. Original sale, partial refund, full refund, void, exchange, gift card top-up. Each event references the original transaction id from table 1. Append-only.

This means a transaction that goes through 4 states ends up with 5 rows total (1 in table 1, 4 in table 2). The final state is computable by playing all events forward.

Table 3 — Loyalty calculation log

One row per loyalty calculation triggered by an event. References the source event. Captures: rule applied (points-per-rupee rate, tier multiplier, brand multiplier, exclusion rule), points credited or debited, calculation timestamp.

This is the table that answers "why did this transaction get X points." If a brand disputes points, the row is the answer.

Table 4 — Settlement reconciliation

Monthly aggregation. Per tenant, per month. Aggregates:

• Brand-reported gross sales
• Mall-computed gross sales from table 1 + 2
• Brand-reported loyalty points awarded
• Mall-computed loyalty points awarded from table 3
• Variance (difference)

Difference under 0.5% = settle without escalation. Difference 0.5-2% = automated investigation, usually closes within 3 days. Difference above 2% = manual review.

How the pattern actually plays out in production

The first 30 days of a new POS-linked tenant: lots of small variances as the integration finds edge cases. The four-table pattern catches them in real time, so problems get fixed before the brand notices.

Day 60: 80% of variance categories resolved. Remaining variance under 1% typically.

Day 90: settlement runs cleanly. Brand and mall agree on numbers. Annual audit becomes a 1-week project instead of a 4-week dispute.

Without the pattern, the same 90-day window is the dispute window. With the pattern, it's the settling-in window.

What about cash transactions

POS-linked loyalty fundamentally depends on the POS knowing the transaction is loyalty-eligible. For cash transactions where the customer doesn't present their loyalty identifier at the till, the loyalty event never fires. This is a known limitation.

The mitigation: invoice-upload loyalty (covered in our invoice-based loyalty piece) catches the long tail. Cash-paying loyalty members who forget to scan their card at the till can upload the bill within 7 days. The mall's loyalty engine reconciles the upload against POS records.

What about online sales from in-mall stores

Most tenant brands now sell online (Zara online, Lifestyle online, etc.). Online sales should NOT credit mall loyalty points unless explicitly negotiated. The lease agreement defines the scope; the loyalty engine respects it. Be explicit about this with each tenant or you'll have an ugly month-end conversation.

Frequently asked questions

How long does POS integration take per tenant?

For tenants on modern POS (Petpooja, Posist, Restroworks), 2-4 weeks per tenant including testing. For tenants on bespoke POS, 6-12 weeks. Most malls integrate top 10-15 tenants by footfall and put the rest on invoice-upload.

What's the right points-per-rupee rate?

Two points per ₹100 spent (2% effective rate) is the most common Indian mall calibration. Higher rates (3-5%) work for tier-up unlocks but should be exception, not default.

Should we use a third-party loyalty provider (Capillary, etc.) or build our own?

Third-party providers handle multi-tenant integration headaches but rarely produce mall-specific four-table reconciliation. If you go third-party, insist on raw event access so you can build the reconciliation layer yourself.

What happens when a tenant brand leaves the mall?

POS integration disconnect. Loyalty points already credited remain valid for the configured redemption window. Brand's customer service desk redirects shoppers to the brand's own loyalty programme (if any) for queries beyond that point.

How Portcart handles this

The four-table reconciliation pattern is exactly the architecture behind Portcart's loyalty ledger module.

• [Loyalty Ledger](/platform/loyalty) — transaction master, transaction events, loyalty calculation log, settlement reconciliation as separate tables with explicit source-type discriminators on every row. Single source of truth across POS-linked, invoice-upload, manual award, birthday, event-reward, and ADSR sources.
• [POS Integration](/platform/pos-integration) — connectors for Petpooja, Posist, Restroworks, and a generic webhook for custom POS systems.
• [Voucher Management](/platform/vouchers) — same maker-checker audit pattern applied to loyalty point disputes.

If your mall's POS-linked loyalty has been generating monthly disputes with tenant brands, request a demo and we'll model the four-table pattern on your actual integration data.