POS for Small Retail

The problem

• Sales tax is not one number. Clothing, groceries, and some goods are exempt or reduced in many states, and a reseller with a valid certificate pays nothing, so a flat rate on the whole cart overcharges customers and misreports what you owe.
• Cash is real money that disappears. Split tenders, change, and drawer payouts happen all day, and without an opening float and an expected-versus-counted close, an over or short at night is invisible instead of investigated.
• The count drifts within a week. Every sale, return, and void has to touch inventory the same way, or the number on the screen and the number on the shelf part ways before the next order goes out.
• You are paying per-terminal rent to a vendor that owns your catalog. Prices, categories, receipts, and reports live inside their box on their domain, and customizing any of it means waiting on their roadmap.

A day in the system

1. Open: the cashier logs in and opens a drawer session with a counted opening float, say 150 dollars in small bills. The register is now live and every sale this shift ties to that session.
2. First sale: you scan barcodes, items land in the cart at their price and tax class, a 10 percent coupon applies as a line discount, and tax computes only on the taxable lines at your store rate, then sums and rounds once.
3. Tender: the customer pays part cash, part card. The card leg goes to your payment processor and only a token, the last four digits, and the brand come back; change is figured on the cash leg, the receipt emails, and each line deducts its product quantity.
4. Return: someone brings an item back with a receipt. You look it up by receipt number and issue a refund as a new, linked record that reverses the exact tax and tender and puts the item back on the shelf.
5. Correction: a mis-scan gets voided before tender and never touches stock; a completed sale that was wrong is refunded, not deleted, so the audit trail and the counts both stay intact.
6. Exempt sale: a reseller with a resale certificate buys tax-free. You flag the whole sale exempt, capture the certificate number, and no tax is charged on any line.
7. Restock check: mid-afternoon the low-stock view lists everything below its reorder point, so you place vendor orders before the weekend rush instead of after you run out.
8. Close: the cashier counts the drawer. The system shows expected cash (opening float plus cash sales minus cash refunds and payouts) against counted cash, logs the over or short, and prints a Z-report of sales, tax collected, and tender totals, all hosted on ybuild.

Where AI trips up

• Storing the full card number. A naive build saves the whole card to make refunds or receipt reprints easier, which drops you straight into PCI DSS scope and turns the shop into a breach liability. The app must hand the card to a payment processor and keep only a token, the last four digits, and the brand, and never see the raw number.
• Taxing the whole subtotal at one rate. Tax has to be computed per line by tax class, only on taxable items, then summed and rounded to the cent once. Apply a single flat rate to the cart and you overcharge on exempt goods, undercharge elsewhere, and misstate what you remit, which is exactly what triggers an audit.
• Editing or deleting completed sales. Voids and refunds must be new records linked to the original, never edits or deletes. The moment a completed sale can be changed, your Z-report, your tax total, and your inventory stop reconciling and you cannot survive an audit. Sales are append-only.
• Modeling cards but forgetting cash. Real shops run split tenders, make change, and take payouts from the drawer, then reconcile over or short at close. Without a drawer session and expected-versus-counted math, cash simply vanishes with no way to see where.
• Letting stock drift on the edges. A refund must add the item back, a void must not deduct, and quantity should never silently go negative. Miss one of these and the count is fiction within a week, and reorder points become a guess.

FAQ

Can I store customers' card numbers so refunds and receipts are easier?

No. Storing full card numbers puts you in PCI DSS scope and is a serious liability. Route the card to your payment processor and keep only a token, the last four digits, and the card brand. Refunds reference the processor's transaction ID, so you never need the raw number, and a breach of your database exposes no usable card data.

How does the system get sales tax right on exempt items?

Every product carries a tax class such as standard, exempt, or reduced. Tax is calculated per line, only on taxable lines, at your store rate, then summed and rounded to the cent once. For a tax-exempt customer like a reseller with a valid certificate, you flag the whole sale exempt and capture the certificate number, so the paperwork exists if you are ever asked for it.

What happens when a customer returns something?

You look up the original sale by receipt number and issue a refund as a new, linked record. It reverses the exact tax and tender from the original, adds the item back to inventory, and appears on your Z-report as a refund. The original sale is never edited or deleted, so the day still reconciles.

Does it handle cash, or only cards?

Both, including split tenders on one sale. A cashier opens a drawer session with a counted float, the system tracks cash sales, refunds, and payouts through the shift, and at close it shows expected cash versus what you counted and logs any over or short. That daily reconciliation is the line between a real POS and a card-only toy.

How do I get off my current POS's per-terminal fees and subdomain?

You describe the register, catalog, tax classes, and reports you want, and ybuild builds and hosts the running app on your own domain. Your products, prices, and sales history live in a managed database that is yours, not locked inside a vendor terminal, and there is no per-register rent for the privilege of ringing a sale.