Where AI Fits in POS Systems: Forecasting, Recommendations, Fraud, Inventory

A point-of-sale system is a ledger that happens to have a screen. It takes money, prints a kitchen ticket or a receipt, and must still work if the internet is sad. AI belongs around that ledger — forecasts, recommendations, fraud hints, inventory exceptions — not as a model that “decides” a sale in a way you cannot audit at close of day. If you run restaurants, retail counters, or a franchise group in the US, UK, Europe or Australia, this is where we would look first.

DayDecoder has shipped POS-related software (without naming client products on this site) and adds AI the same way we add it to other Laravel and Node apps: queues, flags, and a human for anything that moves money. See restaurants, POS and hospitality and AI integration.

What POS already does well without a model

Tax, payments, voids, refunds, clock-in, and kitchen routing are solved problems with painful edge cases (split tender, service charge, local tax). Do not put an LLM in that path. If a completion hallucinates a VAT rate, you have a legal problem dressed as innovation.

Where models help is everything around the ticket: what might sell tomorrow, which SKU is drifting, which refund pattern looks odd, which modifier the guest might want if you still have it.

Forecasting

Demand forecasting is usually a numbers model (and often a simple one) plus features you already have: day of week, weather if you can get it, local events, store, channel (dine-in vs delivery). An LLM can narrate the forecast (“Friday looks busy because of the match”) after the number exists. It should not invent the number.

Start with one store, one category (for example prep-heavy items). Measure against a naive baseline (last week same day). If you cannot beat last week, you are not ready to auto-order from a supplier. Auto-ordering is a later, dangerous slice.

Illustrative ROI worksheet, not a client result: if over-prep throws away a few hours of food cost a week, a modest error reduction is worth a trial. Count waste for two weeks before you believe a vendor slide.

Recommendations

At the till or kiosk: “guests who ordered X often add Y”, filtered by stock and by allergen flags you actually maintain. If allergen data is messy, do not recommend. A wrong nut suggestion is not a conversion problem.

In the app: the same rules, plus quiet hours for notifications. Ranking can be classical; copy can be generated and then templated. Cache suggestions per store and day-part so you do not call a model on every tap. See Redis in Laravel if the POS backend is Laravel.

Fraud, voids, and shrinkage

Patterns: void after close, refund spikes by cashier, discount keys used as a round-off, item not on the ticket but in the kitchen (harder). A model or even a rules engine can rank exceptions for the manager in the morning. Do not auto-fire a staff member from a score. Labour law and decency both apply, in every market you asked us to write for.

Card testing and bot orders on a public ordering API are more like ordinary web fraud: rate limits, device signals, 3-D Secure. AI may help score, still with a review queue. Fail closed on payments you cannot explain.

Inventory

Theoretical vs actual, 86’d items, recipe explosion, delivery notes that do not match the invoice. Document extraction on supplier invoices is a strong first AI slice (schema plus human confirm), similar to SMB document automation. Computer vision of a fridge is a research project; counting boxes from a goods-in PDF is a product.

When stock hits zero, the POS must know before the kiosk recommends it. That is integration, not intelligence.

Architecture next to a till

Edge device: can sell. Cloud: trains, forecasts, trains fraud scores, stores pictures of invoices. Sync is a queue, not a chatty LLM call from the till. If the WAN is down, guests still pay. The model catches up.

Multi-store tenancy in every cache key and every embedding, if you use RAG on manuals and recipes. Franchise manuals are a RAG case; see RAG for business owners. Recipes change; stale vectors 86 the wrong dish.

What we will not put on a receipt

Generated health claims, invented discounts, or a “you saved X% this year” number that is not in the ledger. If it prints, it must be computed from the same numbers as finance.

DayDecoder: 10+ years, 103 customers, Ahmedabad. We keep client product names off public pages. Email contact@daydecoder.com.

Kitchen, kiosks and the 90-second ticket

A recommendation that adds three make-heavy modifiers during a Friday rush is not “upsell”. It is how tickets slip and reviews get worse. Any suggestion engine should know current ticket time or at least day-part load, even a crude flag. If you cannot know load, be conservative at peak. The model does not get to be braver than the kitchen.

Kiosks need large type, allergen gates, and a way to skip suggestions entirely. Accessibility is not an AI feature, but an AI overlay that traps a guest in a generated upsell is an accessibility and a hospitality failure.

Offline, sync and split brains

Two tills selling the last portion of a dish while offline will oversell. That is an old POS problem. AI must not make it worse by recommending the dish from a cloud cache. When in doubt, the local stock flag wins. After sync, exceptions (negative theoretical) go to a manager list, possibly ranked by a model, never silently “fixed” by adjusting sales.

Generated comments on a ticket (“guest asked for extra sauce”) should be stored as staff text, not as a hallucination from a nearby conversation the mic picked up. If you do not have a mic product, do not start one to feed a model. Start with buttons.

Franchise reporting without mixing tenants

HQ may see aggregates. Store managers see their store. A model that trains on all stores’ baskets can still be served per store if you are careful; a RAG index that is not filtered cannot. Tests should include a cross-store question, the same way we test SaaS tenancy. “What did store 19 do with discount keys?” asked from store 4’s login must 404 or refuse, not summarise.

Publishing a case study with another franchisee’s numbers on your public site is how you lose a franchisee. We do not publish those numbers here either.

Payments, PCI and where models must not sit

Card data stays in the payment integration. Models do not see PAN. Logs do not see PAN. If a vendor wants raw payment payloads to “train fraud”, that is a PCI and contract conversation, not an AI one. Score on tokens and behavioural features you are allowed to keep. When in doubt, the existing acquirer’s fraud tools plus a manager queue beat a custom brain on day one.

Staffing the review without opening a lab

A GM or area manager already looks at voids and waste. Give them a ranked list in the back office they already log into, not a new “AI portal” with a different password. The list should show the evidence (tickets, timestamps, camera if you already have one and are allowed to use it). The action is still theirs: coach, count, or ignore. Track ignore rate. If they ignore everything, the model is noisy or the incentives are wrong. Either way, do not crank the sensitivity to look busy.

Labelling: a month of “this void was fine / not fine” from a manager is more valuable than a generic shrinkage dataset from the internet. Your stores are not that dataset. Fine-tunes, if any, wait until this labelling exists. See preparing your own model.

Hardware, printers and the unfashionable constraints

Printers, cash drawers, scales, and fiscal devices (where the law requires them) do not speak JSON Schema. The POS already has drivers. AI features should not sit in those drivers. If a country requires a certified fiscal module, we will not route receipts through a model. We will put suggestions on a screen that is not the fiscal one. This is how you stay in business in markets that audit software, not how you win a hackathon.

Older terminals have little CPU. Inference belongs in the cloud or a store server, with a cache. The terminal renders a list. If the list is late, show nothing rather than last week’s specials that you 86’d. A blank suggestion slot is better hospitality than a wrong one.

Delivery channel mappings (marketplace item ids versus in-store SKUs) are a master-data project. A recommendation engine that does not know the mapping will upsell an item the marketplace marks unavailable, or worse, an item with a different allergen set. Fix mapping before “personalisation”. We will say that on a call even if it delays the fun demo. The demo is not the close-of-day report.

Gift cards, house accounts, and comps have their own fraud patterns. Start with voids and discounts, which managers already understand, before you score gift-card drains. Each payment type you add is a new eval set, not a checkbox. If the POS vendor already flags some of this, start by exporting their flags into the same manager list rather than arguing with their black box from day one.

Handover checklist

Store-level AI should ship with: which tills are flagged, how the back-office list is authorised, the allergen source of truth, the 86 workflow, the forecast baseline (last week same day), and a disable switch that does not take the till down. Include a written rule for what prints on a receipt (ledger only). Include a test that tenant A cannot read tenant B’s voids. If the POS is a third-party black box, include the vendor ticket number for API access so you are not rediscovering it next quarter. Add the fiscal or tax module’s name in markets that certify software, so nobody “just routes” a receipt through a completion later. That sentence belongs in the runbook because future vendors will ask.

Train a GM on the ranked list in the real back office, not in a slide. If they cannot complete a review in their normal morning, the UX is wrong. Fix the screen before you tune the model. Models do not fix unread queues. Sit with them for one close of day and watch where they skip; those skips are the next tickets, and they are cheaper than another vendor demo that does not fit the morning they already have.

FAQ

Can ChatGPT run my till?

It should not. The till must be deterministic, auditable, and offline-tolerant. Use models around it.

Do we need to train our own model?

Usually no. Start with your sales history in a simple forecast, extraction models for invoices, and maybe RAG on procedures. Training from scratch is a last resort; see preparing your own AI model.

What about delivery marketplaces?

Treat them as another channel with their own fees and item mappings. Do not let a recommendation engine sell a mapped item you 86’d in the local POS.

How do we handle tips, tax, and service charge in AI features?

You don’t, except by reading the ledger. Generated text should not recompute tax. Finance owns those rules in code you already tested.

Typical first-project shape?

Indicative: invoice extraction plus a manager exception list, or a one-category forecast with a baseline comparison. Five-figure software when APIs exist, more if the POS is a closed black box. Not a quote.