Customer Credit in a Shop: Keeping the Daftar Without Losing Track

Selling on credit to regulars: the rules to set first, debts kept in dollars and paid in either currency, partial payments, and following up politely.

5 min readPublished 8 October 2026

Table POS Management, Receivables screen for the Beit Aley demo shop: $226.50 owed by 6 customers, $154.50 of it past due across 4 customers, the oldest debt 133 days old, aging bands of $72.00 current, $101.00 at 1–30 days, $20.50 at 31–60, $15.00 at 61–90 and $18.00 past 90 days, and Nadine Aoun marked Near limit at 81% of a $150.00 limit — Receivables: who owes what, how late it is, and how close each customer is to their limit. Shown with the fictional Beit Aley demo shop.

Many neighbourhood shops in Lebanon sell on credit to people they know. The daftar is how it has always been done: a name, what they took, what they owe, crossed out when they pay. It works while the list is short and the person writing in it is the person who remembers. It stops working when two people serve at the counter, when payments come in pieces, or when a page goes missing.

What a daftar has to answer

Whatever you keep it in, a credit book has to answer five questions without relying on anyone's memory: who owes money, how much, since when, for what, and what they have paid back so far. If yours cannot answer the last two, every disagreement at the counter becomes your word against the customer's.

Set the rules before the first sale on account

Decide four things and write them down. With the rules on paper, the awkward conversation is about the shop's rule, not your mood that day.

A limit per customer: the most they can owe at once. A regular who has paid on time for years can have a higher one than someone new.
A payment term: how long a debt can stay open before it counts as late, such as 30 days.
Who may go over the limit: the owner, or one trusted person, and nobody else.
What happens when someone is late: you ask before they take more, and you stop extending credit after a set point.

Dollars, lira and partial payments

Keep each debt in dollars. A balance written in lira is worth less in dollars every time the lira falls, and nobody wants to argue about which day's rate applies. The customer can still pay in either currency: take the lira at the day's rate and note the dollar amount it settles.

People rarely pay a debt in one go. Apply each payment to the oldest debt first unless the customer asks otherwise, so old items do not linger. If someone pays more than they owe, the difference is a credit for their next visit, not a mistake to fix later.

Following up without losing the customer

Sort what is owed by how late it is: not yet due, up to 30 days late, 31 to 60, 61 to 90, and more than 90. A customer a few days late needs nothing. One two months late needs a polite word before their next purchase. One three months late needs a decision.

A short WhatsApp message with the exact amount and a thank-you is easier on everyone than a reminder at the counter in front of other customers. And when a small leftover will never be paid, writing it off is cleaner than carrying it for a year.

How Table keeps the daftar

In Table

Sales on account. A sale can go on a named customer's account and each unpaid document keeps its own balance. The server checks the customer's credit limit, payment term and blocked status; going over needs a user at the credit-override level (5 by default), which is noted on the sale. The receipt shows the previous and new balance.
Limit: There are no instalment plans with scheduled due dates; a customer's balance can be paid down in any amounts.
Payments and write-offs. Credit payments are taken in USD and LBP, applied oldest-first or to documents the cashier picks, and any overpayment becomes store credit. Part of a debt can be written off without cash entering the drawer, and a recorded payment can be voided.
Limit: The final Z report, other tills' figures, the delivery check before closing, saving changes in Management and Settings, the reports, the delivery board (a delivery rung offline reaches it when its sale syncs), reservations and QR-menu orders need an internet connection. Offline, the cash drawer, the X report and closing a shift use the till's own figures (the last totals it loaded plus what it did since), and the server writes the final Z report when the close syncs, after the sales rung before it. A refund made offline is checked against its sale only when it syncs; one the server refuses is shown to the cashier to redo. Offline, a manager's approval of settings, users, documents or payroll needs the connection, a sale rung offline that syncs after its stock ran out is recorded below zero, and one left on a customer's account is recorded even if the account went over its limit or was blocked by then (the owner is notified of both). Offline, a sale left on a customer's account can be refunded only with no cash back, and the account's balance and documents cannot be shown: a plain payment is still taken and is applied to the oldest debts when it syncs.
Who owes what. Who owes what, split into current, 1–30, 31–60, 61–90 and 90+ days, with limit use and days late, exportable to CSV. A daily check flags overdue and near-limit customers and birthdays in the owner's notifications, and the owner phone app can open a pre-filled WhatsApp reminder for the owner to send.
Limit: Automatic WhatsApp messages from Table's number (sale alerts, order alerts, daily summaries and the owner's WhatsApp assistant) are not offered as a dependable feature yet. They are sent as plain messages, which WhatsApp delivers only within 24 hours of the recipient's last message to Table's number.
Store credit. A customer can hold a credit balance from overpayments, refunds to credit or owner top-ups. The Store-credit liability report totals what the shop owes customers.

Share this guideShare on WhatsApp