POS Software Development: What AI Adds, And What It Cannot Touch
Most pages from an AI POS software development company show a dashboard. Your existing point of sale probably already has one. What it does not have is anything that acts on the data in the two seconds a customer is standing at the till, and that is the only reason to do this work.
So this covers four things a feature list skips. What AI adds beyond reporting. The compliance line it cannot cross, which is cardholder data and is not negotiable. What it costs per store at 20, 100 and 500 sites. And the three constraints a till imposes that no other software environment does.
Every figure is a planning assumption written out so you can substitute your own. Illustrative, not a claim about any particular deployment.
Reporting tells you what happened. The useful features act while something is still happening, or predict something before it does. Four that earn their place.
Basket suggestions at the terminal. The screen suggests the item that goes with what has already been scanned, based on this store, this hour, this basket. Reporting can tell you that coffee and pastry sell together. It cannot put the pastry on the screen while the customer is still standing there.
Void and refund review. Every POS logs voids. Almost nobody reviews them, because at 8,400 transactions a store a month the volume defeats a person. A model reviewing void patterns against till, hour and operator flags the anomalies worth a human look. This is usually the feature with the clearest payback and it is rarely the one in the demo.
Put a number on that payback, because it is the one worth defending in a meeting. A 100 store estate runs 840,000 transactions a month, so voids at 2 percent are 16,800. Nobody reviews those. If a model surfaces the worst 0.1 percent, that is 17 cases a month a manager can actually read, and if even a quarter of them turn out to be real at an average of 40 USD each, the feature returns about 170 USD a month against roughly 60 USD of inference for that feature across the estate. Positive, but small in absolute terms, and that is the honest shape of it. The feature becomes worth building because the same integration carries the other three, which is the argument for doing the integration once rather than one feature at a time.
Demand forecast per store per day. How much to prep, how much to order, how many staff. Chains already do this centrally and badly, because central forecasting smooths away exactly the local variation that matters.
Receipt and invoice reconciliation. Supplier invoice against goods received against what the POS actually sold. This is document extraction work rather than POS work, and it usually sits with finance rather than operations.
Notice what is not on that list. Anything touching the payment itself. That is the next section and it is the one that decides your architecture.
A model must never see cardholder data. Not the primary account number, not the full magnetic stripe or chip data, not the security code. This is the single hardest boundary in POS work and it is the one most proposals fail to mention.
The reason is scope. Under PCI DSS, any system that stores, processes or transmits cardholder data falls inside the assessed environment. Send a primary account number to a third party model provider and you have pulled that provider into your scope, along with every question about where it is logged, how long it is retained and who can read it. No model output is worth that conversation.
The practical consequence is simple and it is good news. A well built modern POS barely sees the card anyway. With a point to point encrypted terminal, the card data is encrypted inside the reader and passes through the POS as ciphertext it cannot read. What comes back is a token and the last four digits. Your AI features work on the token, the amount, the items, the time and the store, which is everything they actually need.
So the rule for the build: the model sees the basket, never the card. Write it into the architecture diagram and into the contract. If a vendor's design requires anything more, ask which of your compliance obligations they have read.
Two related boundaries worth stating at the same time. Staff data used for void analysis identifies individuals and carries employment law obligations in most jurisdictions, so agree what is reviewed and who sees it before you build. And customer identity attached to baskets is personal data under most privacy regimes, which is a separate consent question from the payment itself.
Four systems, and the effort is mostly here rather than in the model.
The POS itself, for transactions, voids, items and the terminal screen. If suggestions appear on the till, you need a supported way to draw on that screen, which not every POS platform offers. Check this before anything else, because a platform with no extension point turns a feature into a replacement project.
Inventory, for stock on hand and lead times. A demand forecast that cannot see stock produces advice nobody can act on.
The payment gateway, for tokens and settlement, read only. You are reading the token and the amount, never the card.
Staff scheduling, if the forecast is meant to drive rotas rather than just inform them. This is usually phase two and usually where the real saving is.
A useful early question: how many of those four have a documented API with a sandbox? Each one that does not adds weeks. A POS platform with a closed extension model and an inventory system with a nightly CSV export is a very different project from four systems with documented interfaces, often double.
Stores are the unit. Assumptions, all substitutable: 8,400 transactions per store per month, basket suggestions on 40 percent of them, voids at 2 percent of transactions, one demand forecast per store per day, and a blended 3 USD per million input tokens and 12 USD per million output.
|
Stores |
Transactions |
Inference |
Per store |
|
20 |
168,000 |
about 195 USD |
about 9.75 USD |
|
100 |
840,000 |
about 975 USD |
about 9.75 USD |
|
500 |
4,200,000 |
about 4,875 USD |
about 9.75 USD |
Work the 20 store row. Basket suggestions fire on 40 percent of 168,000 transactions, which is 67,200 calls at roughly 600 input and 60 output tokens. That is 40.3 million input tokens at 3 USD per million, about 121 USD, plus 4 million output tokens at 12 USD per million, about 48 USD. Void review covers 2 percent of transactions, 3,360 calls at about 1,200 tokens, near 12 USD. Daily forecasts are 600 calls at roughly 8,000 tokens of history, about 14 USD. Total 195 USD, so 9.75 USD per store.
Inference is linear and it is not the interesting number. The interesting number is what sits beside it.
Integration and model operations are close to fixed. Whatever it costs to build and run the four integrations, it costs roughly the same for 20 stores as for 500. At 20 stores that fixed cost dominates completely. At 500 it disappears into the noise. This is why POS AI work rewards estate size more than almost any other project type, and why a 20 store chain should be much more selective about which features to build.
Size the fixed half so the comparison is honest. If integration and model operations run to, say, 18,000 USD in the first year across the four systems, then at 20 stores that is 75 USD per store per month on top of 9.75 USD of inference, so the fixed part is 88 percent of the bill. At 500 stores the same 18,000 USD is 3 USD per store, and inference becomes the larger line for the first time. Nothing about the software changed. Only the divisor did.
Basket suggestions are the line to watch. They are 87 percent of the inference above and they fire on the most latency sensitive surface. Running them on a smaller, faster model, or on a local model on the terminal for the common cases, changes both the bill and the experience. Treat the large model as the fallback rather than the default.
No other software environment has all three at once, and they are why POS work is harder than it looks.
It has to sell when the network is down. Not degrade, not queue. Sell. Every AI feature therefore needs a stated behaviour for the offline case, and the answer is almost always "the feature disappears quietly and the sale completes". A suggestion that fails to load must not block the transaction, must not show an error, and must not be retried in a way that delays anything.
There is a queue. A basket suggestion that takes 1.2 seconds is not a slow feature, it is an abandoned one. Budget under 300 milliseconds on the terminal surface. That rules out large models on that path and it is a design constraint rather than a preference.
The hardware is old. A realistic estate has terminals between five and eight years old, running whatever the vendor shipped, often with 2 to 4 GB of memory and a screen resolution nobody would choose today. Anything requiring a modern runtime, a large local model or a browser engine from this decade needs a hardware refresh costed into the project, and that cost usually exceeds the software.
The design that follows from all three: compute centrally, cache aggressively, degrade silently, and keep the terminal doing as little as possible.
Worth knowing before you choose, because store managers switch off anything that costs them time.
Void review is used because it saves a person from a task they were not doing anyway. Nobody was reviewing 168 voids a month by hand. The feature produces a short list instead of a spreadsheet.
Demand forecasting is used when it writes into the existing order process and ignored when it produces a separate report. This is the difference between a project that changes ordering and one that adds a dashboard nobody opens.
Basket suggestions are used if they are fast and quiet. A suggestion that appears instantly and can be ignored gets a small steady uptake. One that interrupts, or that has to be dismissed, gets disabled within a fortnight and the store manager will not tell you.
Anything that adds a step at the till is switched off. Every time. If the feature requires the operator to do something extra while a customer waits, it does not survive contact with a Saturday.
The forecast is right and nobody changes the order. The most common failure and it is not technical. If the ordering process still runs on a manager's habit and a paper sheet, a better number changes nothing. Fix the process first or build the forecast directly into the order screen.
Suggestions degrade in a new store. The model was tuned on the estate it saw. Open a store with a different customer mix and suggestions get noticeably worse before they get better. Plan a cold start rule for new sites rather than letting them look broken for two months.
Offline behaviour was never tested properly. It works in the office where the network is good. Test by pulling the cable during a transaction, on the oldest terminal in the estate, not on a developer laptop.
Void flags become noise. If the flag rate is too high, managers stop opening them. Tune for a small number of high confidence flags rather than completeness. Twelve flags a month that are worth reading beats two hundred that are not.
Hardware attrition changes the picture. Terminals fail and get replaced with whatever is available, so an estate drifts towards more variation rather than less. Whatever you build has to tolerate three or four hardware generations at once, permanently.
When the estate is small. Below roughly 20 sites, the fixed integration cost is hard to justify against inference near 10 USD a store. Buy what your POS vendor already offers, or wait.
When the POS has no extension point. If you cannot draw on the terminal screen or read transactions in near real time through a supported interface, the project becomes a POS replacement wearing different clothes. Price it as one or choose features that live entirely off the terminal.
When the data is not clean. Item level data with inconsistent product codes across stores will produce forecasts nobody trusts. That cleanup is worth doing on its own and has to come first.
When the process will not change. Covered above and worth repeating, because it is the most common reason these projects deliver nothing while working perfectly.
When someone proposes sending card data anywhere. Not a scoping judgement. Stop and get a different design.
A reasonable first project for a mid sized estate is one feature, on one integration, measured for a quarter. Void review is usually the right pick because it needs no terminal surface, has no latency budget to meet and no offline behaviour to design. It proves the integration works and produces a number before anyone commits to the parts that touch the till.
AI in a point of sale system earns its place on the things reporting cannot do: suggesting at the terminal while the customer is still there, reviewing voids nobody had time to review, and forecasting demand per store rather than centrally.
The hard boundary is cardholder data. A model never sees the primary account number, and with a point to point encrypted terminal it does not need to, because the token, the amount, the items and the time carry everything the features actually use.
On the assumptions above, inference lands near 9.75 USD per store per month and is linear. Integration and model operations are close to fixed, which is why this work suits larger estates and why a 20 site chain should build one feature rather than four.
And three constraints shape every design decision: the till sells through outages, there is a queue so the terminal budget is under 300 milliseconds, and the hardware is older than anyone's screenshots. Compute centrally, cache hard, degrade silently.
Four things that reporting cannot. Suggest the next item at the terminal while the customer is still there, review voids and refunds for anomalies at a volume no person covers, forecast demand per store per day rather than centrally, and reconcile supplier invoices against goods received and sold. The first three touch the POS directly; the fourth is document work that usually sits with finance.
No, and it should not need to. Any system that stores, processes or transmits cardholder data falls inside PCI DSS scope, and sending a primary account number to a third party model provider drags that provider in with it. With a point to point encrypted terminal the POS never reads the card anyway. The model works on the token, the amount, the items, the time and the store.
On planning assumptions of 8,400 transactions a store each month, suggestions on 40 percent of them, voids at 2 percent and one forecast a day, inference lands near 9.75 USD per store per month and stays roughly linear from 20 to 500 stores. Integration and model operations are close to fixed, so the per store total falls sharply as the estate grows.
The sale completes and the feature disappears. Every AI feature needs a stated offline behaviour, and for a till that behaviour is almost always silent disappearance. A suggestion that fails must not block the transaction, show an error, or retry in a way that adds delay.
Under about 300 milliseconds. There is a queue, and a suggestion arriving after 1.2 seconds has already been overtaken by the operator. That budget rules large models off the terminal path, so run a smaller model there and keep the larger one for work that happens away from the till.
Probably, if you compute centrally and keep the terminal thin. A realistic estate has hardware five to eight years old with 2 to 4 GB of memory. Anything needing a large local model or a current browser engine implies a hardware refresh, and that usually costs more than the software.
Below roughly 20 sites the fixed integration cost is hard to justify. Also when the POS has no supported extension point, when product codes are inconsistent across stores, or when the ordering process will not change regardless of how good the forecast is. The last one is the most common and the least technical.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
