The short answer
A custom POS system is point of sale and billing software for businesses whose pricing, units of sale or account customers don't fit a retail till. AR Digital Solutions builds them in Australia, covering offline trading, account billing and accounting sync. Most businesses don't need one, and we'll say so.
What a build has to cover
- Products, and the rules that change their price for a given customer.
- Quantities that aren't whole numbers, with rounding and minimum charges.
- Account customers, credit limits, statements and payment allocation.
- Tax invoices numbered correctly whether or not the connection is up.
- Card, cash, split payments and refunds, with an end of day that matches.
- A daily push into the accounting file that reconciles.
Most businesses asking for a custom POS should buy Square instead
We turn this work down more often than we take it, so here's the honest version.
If you sell products with a price on them, take card and cash, and want stock counts and a sales report, buy Square or Lightspeed and spend a week building the catalogue properly. A custom equivalent costs far more to build and the same again to keep alive across five years of firmware and tax changes.
Most custom POS enquiries are a configuration gap, not a software gap. Nobody built the modifier groups, so staff type notes the kitchen misreads. Nobody mapped the tax codes, so the accountant fixes it quarterly. A fortnight of work, not a build.
Four situations where the off the shelf till genuinely runs out of road.
Price depends on the customer, not the product.
Retail POS puts the price on the item. In trade and wholesale it lives at the intersection of a customer and an item: contract rates, price levels, quantity breaks. When the till can't hold that, staff key manual discounts and margin leaks where nobody sees it.
You sell by measure or by time.
Timber by the metre, soil by the tonne, equipment by the day with part days and late returns. Retail POS assumes a unit that scans. Once quantity is a decimal off a scale or a clock, rounding and minimum charges become business rules, and they belong in software rather than in the head of whoever's on the counter that day.
Account customers with statements and credit limits.
Charging to account isn't a payment method, it's a receivables system. Limits get checked before goods leave, orders go on hold when they're breached, statements go out at month end, part payments get allocated across invoices. Most retail tills record an IOU and leave the rest to a spreadsheet. The hardware store management page covers that counter in detail.
You have to keep trading when the connection goes.
That one gets its own section.
Wanting a lower monthly fee isn't one of them. That never survives a five year comparison.
Every POS claims offline mode. Ask what it does offline
This is the hardest part of any point of sale build, and the part that gets one reassuring line in a sales deck.
Offline isn't one feature. It's separate questions with different answers. Can you look up a product and its price for that customer? Can you take payment? Can you issue a tax invoice with a number that won't collide with the one the other till just produced? Can you accept a return, or open an account? A good design says yes to the first, yes to cash, no to new accounts, and makes each answer deliberate.
The hard part isn't the sale, it's the reconnect. Two tills have traded for ninety minutes from the same starting stock and both sold the last four of something. A sale queued at 10:42 goes twice because the first attempt timed out after the server had already taken it. Handle that badly and you have duplicate sales in the accounts and a stock file nobody trusts.
The fixes are unglamorous. Cache what has to be readable offline: products, pricing rules, account balances, tax settings. Give each till its own block of invoice numbers. Queue transactions with a key generated on the till, so a replay is recognised as the same sale instead of a new one. Decide whether stock can go negative, because at a busy counter it will. Put an offline banner and a queue count in front of staff so nobody assumes it synced.
Whether a card can be taken while your systems are down is your payment provider's call, not the POS vendor's. Our Stripe integration work covers where those limits sit.
Test it by pulling the cable during a trading hour, not in a meeting.
How it goes in
We watch a trading day
Counter, phone orders, accounts, end of day.
We agree scope and price
Fixed number, dates in writing.
3. We run it alongside until it survives a full month end.
We connect the money
Payments, statements and a daily push into Xero or QuickBooks.
Who it's for, and who it isn't
It suits trade suppliers, hire businesses, wholesalers with counter sales, and anyone selling by weight, length or time to customers with their own pricing.
It isn't for a cafe or a single site retailer selling catalogue items at list price. Buy the platform and configure it properly.
Why bring this here
Developers in house, who also run the servers underneath. The rest of our software work sits on the apps and custom software page.
No lock in contracts, the code and data are yours, and one account manager knows your setup without you re explaining it.
"The last quote was three times this."
Usually because it included rebuilding what the platform already does.