Software carries assumptions from the market it was written for, and the ones about money are the hardest to see. A system built for a country where every customer pays at the counter treats credit as an exception: something that happens occasionally, gets a small screen, and is otherwise ignored.
In the Maldives credit is not an exception. Island shops carry customers between salary dates. Wholesalers carry guest houses for a month at a time. A supplier delivering to a resort is a bank with a boat. When software assumes otherwise, the assumption does not announce itself. It shows up as numbers that feel wrong.
Where the assumption surfaces
The day looks bad on a good day. If a system counts a sale only when it is paid, then a strong day of credit trade reports as a weak one. Owners stop trusting the dashboard, which means they stop looking at it, which means the software has been reduced to a receipt printer.
The balance sits with the sale rather than the customer. Unpaid sales that are not attached to a person are a pile of documents. Attached to a person, they are a balance you can chase, hand to somebody else, and print as a statement.
There is no aging. A total tells you how much you are owed. Aging tells you how worried to be. Forty thousand rufiyaa from the last three weeks is a business. The same forty thousand at four months old is a loss that has not been admitted yet.
Part payments are awkward. Here people pay in pieces, and the system has to take two thousand today against an invoice from last month, print a receipt for it, and leave the remainder visible to both sides.
Nothing stops the quiet growth. Without a limit per customer, credit is a decision made in front of a queue by whoever is on the counter, every single time.
Why this is a supplier question, not a feature question
You can find a credit screen in almost any system if you look hard enough. What you are actually testing is whether the people who built it think credit is normal. That shows in small places: whether a due sale is one action or five, whether the dashboard puts what you are owed next to what you owe, whether a statement is a document or an export you assemble yourself.
Ask a supplier to show you a customer who owes money across four invoices, then ask them to take a part payment and print the receipt. Watch how many screens it takes.
The number worth checking every Monday
Take what customers owe you and divide it by an average month of sales. Under a month is ordinary. Over a month means your customers are being financed by you, and one slow season stands between that and being unable to pay a supplier. It takes five minutes and it is the single most useful habit a credit trading business can have.
What we did about it
We built RekordPOS in a market where credit is the norm, so dues are not a module bolted to the side: a customer has a balance, an aging view exists, part payments print receipts, and what you are owed sits beside what you owe on the first screen you see. That is not cleverness on our part. It is what happens when the people writing the software live in the market that uses it.
The same subject from the other side of the counter, written for the person using the till rather than choosing it, is on the product's own blog: selling on credit without losing money.
If you have a book of names and want to see what it looks like inside a system, bring the book.