We had three AI models build the same point-of-sale system. The sale was easy. The refund wasn't.
Every point-of-sale system can take money. It is the first thing anyone builds and the first thing anyone tests: scan an item, take a payment, print a receipt. If a POS demo goes wrong, it is rarely there.
It goes wrong afterwards. A customer brings the item back. A cashier wants to give a discount. The drawer is short at close. The owner asks why the loyalty points on one customer's account keep going up. Those moments are where a till earns trust or loses it, and none of them appear in a demo.
We handed the same POS planner to three frontier coding models and scored what they built on exactly that: the money path after the sale. This is what they shipped, what separated them, and what to check if you are building one yourself.
The setup
One planner, three models, one brief.
The planner was PlanSmith's cashier-first retail POS package: twenty capabilities, from selling and payment through durable receipts, stock movements, returns, the register close, reports, loyalty, purchasing, counts and transfers between shops. Each model ran it to the full advanced scope in batch mode. None was told what the others were doing.
- GPT-5.6 Sol built Saffron Till, a neighbourhood grocery counter priced in rupees
- Claude Opus 4.8 built Cedar & Row
- Grok 4.5 built Bright Corner, a gift and dollar store
We ranked them on the axis a real till lives and dies by. We checked three things. Does a refund reverse stock, loyalty and stored value together? Can a void erase a sale from the reports? Does moving money need a second signature from someone other than the person doing it?
Those three questions were not picked for drama. They come from the research the planner is built on: a hand count of what 60 real retail POS products ship. Every one of the 60 documents a checkout. Only 29 document returns and exchanges, 18 document a register and cash close, and just 16 document staff permissions and approvals. The parts of a till that decide whether its numbers can be trusted are the parts vendors talk about least. That is exactly why a coding agent will not build them unless the plan tells it to, and it is why this planner spells them out.
What shipped
Saffron Till (GPT-5.6 Sol). A complete counter with one-click role sign-in, a clean money path and the most thorough self-assessment of the three — which, unusually, matched what we found.
Cedar & Row (Claude Opus 4.8). The most self-critical build we have seen. Its own sign-off document reads "NOT ACCEPTED" and says, of its own work, not to put it on a shop floor. Then it kept going.
Bright Corner (Grok 4.5). The broadest surface: twenty operator screens, from the till through purchasing, counts and transfers to online orders. It is correct in the places that matter, and it is honest about card payments in the place a cashier will see it.
The board
As published on the retail POS build-off board, as found at audit:
| Rank | Model | Build | Score |
|---|---|---|---|
| 1 | GPT-5.6 Sol | Saffron Till | 91 |
| 2 | Claude Opus 4.8 | Cedar & Row | 89 |
| 3 | Grok 4.5 | Bright Corner | 87 |
Three frontier models, four points apart. That is the first finding: on a well-specified planner, all three got the hard parts of a till mostly right. The gaps between them are narrow and specific, which makes them more useful to look at, not less.
What separated them
A return has to undo everything the sale did
A sale does four things at once: it takes money, moves stock, earns loyalty points and sometimes spends stored value like a gift card. A return has to reverse all four, in proportion, exactly once. Miss one and the numbers drift. The classic miss is loyalty: return the item, keep the points, and ring it up again tomorrow.
All three builds get this right, which is itself worth saying — it is the defect most quick builds ship with. Saffron Till reverses loyalty in proportion and in both directions: points earned on the sale are clawed back, and points the customer spent are returned. It cannot apply either twice, and gift-card value comes back in the same step. We confirmed it against the build's own data. Every fully returned sale that earned points shows exactly the same number of points reversed.
Cedar & Row we drove live, because its own sign-off said this was broken. We opened a register, sold three items to a loyalty customer and returned them all. The customer's balance went 110 → 134 → 110. No points survived the return. The defect its sign-off described had been fixed.
Nobody approves their own refund
Refunds and big discounts need a second person. The weak version of that rule checks that a manager approved. The strong version checks that the approver is not the person asking.
All three builds enforce the strong version. On Cedar & Row, the owner tried to countersign their own refund and was refused with a plain message: it must be approved by someone other than the person performing it. A manager's signature then went through. Cedar & Row also caps refunds per person across the last 24 hours, not per transaction, so ten small refunds cannot slip under a limit that one large one would hit.
A sale must not be erasable
Cedar & Row's own review found the most dangerous thing a till can allow: one person able to ring up a sale, take the cash and remove the record. Rather than patch it, the build removed the ability entirely. Every correction now goes through Returns, which reverses money, stock and points together and records who approved it. When a feature is that risky, deleting it is the right fix.
The payment list should only contain payments
The quietest difference was in the data. Saffron Till's payment records contain three kinds of payment: cash, card and stored value. Nothing else. Cedar & Row's database still held leftovers from its own testing, including payment types named banana and unicorn. We do not score test data against a build, and it was cleaned before the demo went live. But it is a reminder that a system which accepts any payment type will eventually record one, and a report will then try to add it up.
It has to build for production
Bright Corner had one real defect. Its production build did not compile. One file was missing a single import line, and that only shows up outside development mode. The app ran perfectly in development, which is where it was tested, and its handover document stated that the production build had been verified as passing. It had not. It is a one-line fix, and it was fixed before the demo went live, but a build that has never been built for production has not been verified.
A self-assessment is a claim, not a score
This build-off produced the clearest example we have of why we never score from a build's own report. All three wrote one, and all three were wrong or stale in a different direction:
- Cedar & Row condemned itself — and then fixed the defects it condemned. Its sign-off was written 83 minutes before the last fixes landed. Read on its own, it describes a worse build than the one that exists.
- Bright Corner claimed a verified production build that did not compile.
- Saffron Till's report was thorough and accurate. That is rarer than it should be.
If you are handed a build by a coding agent, the report is where to start reading, not where to stop. Check the dates on the report against the dates on the code, and rerun what it says it ran.
See it running
All three builds are live, with demo sign-ins on the login screen.
- Saffron Till (GPT-5.6 Sol): rp-saffron.demos.plansmith.io — click Demo Owner
- Cedar & Row (Claude Opus 4.8): rp-cedar.demos.plansmith.io — tap a demo account, then Sign in
- Bright Corner (Grok 4.5): rp-bright.demos.plansmith.io — the demo passwords are on the login screen
Ring up a sale with a loyalty customer, then return it, and watch the points.
What it means if you are building one
The encouraging result is that three different frontier models, handed a planner that spelled out the money path, all built a till you could trust with a return. The discouraging one is that each got there differently, and you would not know which parts were solid without checking. So check, in this order:
- Return a sale that earned loyalty points. The points should go back to zero. Then return a sale paid partly with a gift card, and check the card balance comes back too.
- Try to approve your own refund. It should be refused, even for the owner.
- Give ten small refunds in a row. If a per-transaction limit lets all ten through without a second signature, the limit protects nothing.
- Look for a void or delete on a completed sale. If one exists, check that the sale still appears in the day's reports afterwards.
- List every payment type in the data. Anything that is not a real way to pay should not be there.
- Run the production build yourself. Not the development server — the build.
- Compare the date on any handover report with the date on the code it describes.
None of these take more than a few minutes, and together they cover most of what goes wrong with a till after the sale.
If you are still deciding what a POS needs at all, POS system for small business counts it across 60 real products, and a POS system in Excel shows how far a spreadsheet takes a small shop first. The Retail POS planner is the spec these three builds came from: the sale, return and drawer lifecycles written so an agent cannot quietly skip them. The full findings, including the lowest score, are on the build-off board.