# Why Does My POS Make Me Create a Product Before I Can Ring Up a One-Off Sale?

> Published: 2026-08-04
> Updated: 2026-08-04
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/blog/pos-one-off-sale-open-item

Some POS systems will not ring up an item unless it already exists in the catalog, so cashiers create throwaway products or ring the sale against the wrong SKU. Why that happens, what it skews, and what an open item at checkout should look like.

Because your POS treats the product catalog as the only source of truth, and a one-off sale has no place in that model. Every line on a receipt must map to a product record, and many systems ship with no open item: no line type where a cashier types a name and a price and moves on. When a customer hands you something that was never entered as a product, the register has no button for it.

So the cashier improvises, usually in one of two ways: create a throwaway product mid-sale while the line grows, or ring the sale against the closest real product and hope nobody checks. Both put wrong data in your books.

## Why does every sale have to map to a catalog record?

Because in a catalog-first POS, the product record does all the work. It carries the price, the tax rule, the inventory link, and the reporting category, so checkout is a lookup rather than data entry. That design is right for the vast majority of retail transactions, and it is why scanning a barcode feels instant.

The gap shows up at the edges: a repair fee, a special order, a delivery charge, the odd consignment piece a vendor dropped off this morning. Old electronic cash registers handled these with an open department key (a button that accepted a typed price and filed it under a category). Plenty of modern cloud POS systems quietly dropped that capability when they moved to catalog-first design and never rebuilt it.

## What do staff actually do when there is no open item button?

They build workarounds, and the workarounds cost more than the gap.

- Throwaway products created mid-sale. A cashier stops the transaction, opens the catalog editor, and creates a "misc item" with today's price. Do this for a month and your catalog fills with junk records that pollute search, exports, and reports.
- The dummy-product grid. Some systems push merchants to create products named "custom sale 1" and "custom sale 2," each with a variant per price point ($1.00, $2.00, and so on), so the cashier picks whichever variant sits closest to the real amount. That is a catalog pretending to be a keypad, and it rounds your revenue to whatever variants exist.
- Ringing it against the nearest real product. Fastest at the counter, worst in the books. The substituted SKU (stock-keeping unit, the product record) loses inventory it never sold, reorder suggestions fire on phantom demand, and your sales report credits the wrong product.
- The quantity trick. A $1 product rung at quantity 37 produces a $37 line and a units-sold number that means nothing.

![Sticky notes and a handwritten price notebook around a tablet POS, the workaround for a missing open item button](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/e340aafa3e594d70-open-item-pos-workaround-notes.png)

Each of these is invisible in the moment and expensive at reporting time. It is the same failure pattern as [the duct-tape POS](/blog/pos-workarounds-duct-tape-system): the workaround becomes the system, and the reports stop describing the store.

## Which workarounds hold up until you fix it?

If your current POS cannot do this and you are not switching this week, contain the damage:

1. Create one miscellaneous product per tax treatment, centrally, with price override enabled at the till. Name them clearly, for example "Misc taxable" and "Misc non-taxable," so at least the tax on the line is right.
2. Lock catalog editing at the register. Workaround products should be created once by a manager, never mid-sale by whoever is on shift.
3. Review the misc lines weekly. If miscellaneous sales are more than a sliver of revenue, you are flying blind on what actually sells, the same way [nightly CSV exports](/blog/nightly-csv-exports-not-a-reporting-strategy) hide drift until month end.

This is triage. It keeps totals and tax consistent, but every one-off still lands in one undifferentiated bucket, and none of it undoes the inventory skew from substituted SKUs.

![Shop owner finding an inventory count that does not match the sheet after one-off sales were rung against the wrong product](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/fcddad30d2b37084-open-item-pos-inventory-mismatch.png)

## What should a one-off sale look like at checkout?

Like a first-class line type, not a catalog hack. The cashier types a name, types a price, chooses whether tax applies and which tax group, and adds the line to the cart. It behaves like any other item at payment, prints its own name on the receipt, shows as its own line in reports, and never touches inventory. Legacy registers did this decades ago; there is no technical reason a modern POS cannot.

Final ships this as a custom sale: a tab beside the catalog on the selling screen where you enter a name and an amount on a keypad, optionally pick a tax group, and [add it to the cart](https://finalpos.com/help/ring-up-a-sale) like any other line. It is live today, and the full steps are in the help center: [how to make a custom sale](https://finalpos.com/help/make-a-custom-sale). The same principle covers the other checkout edge cases a flexible system should absorb, from [tax-exempt sales](/blog/pos-tax-exempt-sale-remove-tax) to [split payments](/blog/pos-cant-do-split-payments): line-level and payment-level decisions belong at the counter, not in catalog surgery.

One guardrail: an open item is for genuine one-offs. If you ring the same "one-off" every week, it has earned a product record. The difference is that adding it becomes a deliberate catalog decision instead of a mid-sale emergency with a queue watching.

![Typing a price for a one-off sale on a POS keypad instead of creating a product first](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/7a1e19ccbf1a4ea6-open-item-pos-typed-price.png)

## So why does your POS make you create a product first?

Because it was designed on the assumption that the catalog is complete, and the counter is where that assumption breaks several times a week. The fix is not more staff discipline or a tidier grid of dummy products; it is an open item line type that takes a typed name, a typed price, and a tax choice. Rule of thumb: if a one-off charge takes longer than typing its price, your POS is missing a line type, not a workaround. Count how many "misc" lines hit your reports last month, and if the number surprises you, [audit the rest of your workarounds](/blog/pos-workarounds-duct-tape-system) while you are at it.

## FAQ

**Q: What is an open item on a POS?**
A: A line you ring up by typing a name and a price instead of picking a catalog product. Older cash registers called this an open department key; Final calls it a custom sale.

**Q: Is it OK to ring a one-off item against a similar product?**
A: No. It lowers that product's inventory count and credits its sales history, so stock counts and sales reports both drift a little further with every substitution.

**Q: How should tax work on a one-off sale?**
A: The cashier should choose at the line level whether tax applies and which tax group to use. In Final's custom sale that is an Apply tax toggle plus a tax group dropdown.

**Q: Does a custom sale affect inventory?**
A: No. A custom sale is not linked to a product record, so it never changes stock counts. That is exactly why it beats ringing the sale against a real product.

**Q: Why do modern POS systems lack an open item button?**
A: Catalog-first designs attach price, tax, and reporting to product records, and many vendors never rebuilt the typed-price line that legacy registers offered.