Skip to content

Every customer's balance, on your books and on theirs

A running ledger per customer, and one payment settled against the oldest unpaid bills first. Your customer signs in with their phone number, a password and your shop code, and reads their own khata. The API ships today; the phone app is in testing.

One ledger per customer

Credit sales live or die on the khata. Polaris keeps one per customer: every bill, payment, and adjustment posts to a running balance, so the number you quote at the counter is the current one.

Running balance
Bills raise it, payments lower it, and every adjustment is recorded. Each entry shows the balance after it posted — the same arithmetic a paper khata does, without the evening spent re-adding it.
Credit limits, off until an operator turns them on
Enforcement is a switch on the operator’s own account and it ships off. Turn it on and a bill that would push the customer past their limit fails before it saves. Leave it off and the operator still sees the outstanding balance on the bill screen before extending more credit.
One payment settles the oldest bills first
A customer pays PKR 20,000 against six unpaid bills and Polaris works down them oldest first, locking 50 bills at a time while it allocates. Two people taking payments at the same counter cannot settle the same bill twice.

Your customer checks their own balance

Your customer signs in with their phone number, a password, and your shop’s code — one phone can belong to several Polaris shops — and lands on their own khata: bills, payments, refunds, quotations, loyalty points, and 9 views of how they are actually paying you. The running balance they read is the same one you quote at the counter.

Iqbal Fabrics
Current balance
PKR 18,500
Purchase · INV-249611 Aug 2026
+ 9,500Bal 18,500
Payment · Bank transfer05 Aug 2026
− 15,000Bal 9,000
Purchase · INV-246728 Jul 2026
+ 24,000Bal 24,000
Signed in with a phone number and your shop code
Seen by the customer on their own phone · Sample data

Points on purchases, more for regulars

Loyalty in Polaris is shopkeeper economics: points post with the bill, regulars earn at higher multipliers, and every point that moves leaves a row you can read back.

Earning that posts with the bill
Points are credited the moment a bill posts, at an earn rate per rupee that you set. No separate loyalty register, no end-of-day reconciliation between the two.
Four tiers at 0, 100, 500 and 2,000 points
A walk-in earns at 1.00x. Customers who keep coming back cross 100, 500 and 2,000 points and earn at 1.10x, 1.25x and 1.50x on the same purchase — the extra margin goes to the people who already buy from you.
Every balance change is a ledger row
Each earn, redemption and adjustment writes one immutable row: the signed delta, the balance after it, who did it, and an idempotency key — so a double-tap posts once. A refund claws points back pro-rata against the bill that earned them, and cannot be applied twice.
Bonus events and voucher batches
Run a bonus-points event for a slow week, or generate a batch of discount vouchers with unique codes, expiry dates, and usage limits — then see which codes actually came back to the counter.

The app your customer signs in to

Your customer signs in with their phone number, a password and your shop code, and reads their own khata. The API ships today; the phone app is in testing. One phone can belong to several Polaris shops, and each sign-in lands on that shop's khata, not a shared one.

Phone number, password, shop code
Three fields, and the shop code is the one that matters: a customer who buys from two Polaris shops keeps one phone number and two separate ledgers, and never sees the wrong one.
The same numbers you see
Current balance, every bill and payment with its date, and the running balance after each entry. Refunds, quotations and loyalty points sit on the same screens — the customer reads the ledger you keep, minus the ability to touch it.
9 views of how they are actually paying you
Beyond the balance, the app breaks down how the money has moved: what has been paid, what is still open, and how their payment behaviour has run over time. The argument at the counter starts from a number you both already have.

Who to call, and what was already said

Chasing receivables is mostly memory work. Polaris keeps the memory: how far each balance has aged, who to call, and what was said the last time you called them.

Aging in 5 buckets
Outstanding amounts age through Current, 1–30, 31–60, 61–90 and 90+ days, so the ledger tells you not just who owes, but how long they have owed it. The 90+ total is the one to work first — that is the call list.
Reminder campaigns reach everyone carrying a balance
A receivables campaign resolves its audience the one way the product allows: every customer whose balance is above zero. There is no bucket filter on it, so the aging report is what tells you who to chase, and the campaign is how the reminder goes out to the people who owe.
RFM segmentation
Every customer is scored on recency, frequency, and monetary value — when they last bought, how often they buy, how much they spend. The slipping-away list is the recency column, sorted.
Communication log
WhatsApp messages, SMS, emails, and calls are logged against the customer, so whoever is at the counter can see the last conversation before starting the next one. No reminder gets sent twice in one morning.

Watch PKR 50,000 settle four bills

One payment works down the unpaid bills oldest first, locking 50 bills at a time while it allocates, so nothing is settled twice. The fourth bill is left part-paid and stays open for the balance.

Tap simulate to watch a payment match itself

PKR 15,000

Due Jan 5

unpaid

PKR 12,000

Due Jan 12

unpaid

PKR 20,000

Due Jan 20

unpaid

PKR 10,000

Due Feb 1

unpaid

PKR 15,000

Due Feb 10

unpaid

Sample data

Put every customer’s balance where they can read it.

Your customers read the same khata you keep, and points post from the bills you already write — no separate setup.

14 days free, no card.