Nine requirements to test before you sign a contract, and the exact questions that separate a system built around a single source of truth from a standalone point of sale with an ERP connection bolted on.

Why This Decision Is Bigger Than the Register

A point-of-sale purchase looks like a decision about a register and a screen. In practice, it is a decision about where a business's inventory counts, prices, customer records, and financial data will actually live going forward, because every one of those systems touches the point of sale on every transaction. Two vendors can demo the same buttons and the same receipt printer and still be selling fundamentally different architectures underneath.

We call this category ERP-Led POS™: a retail operating model in which the ERP serves as the system of record for inventory, pricing, customers, fulfillment, and financials, while the point of sale functions as a transaction and engagement endpoint rather than a second system of its own. The checklist below turns that definition into questions a buyer can actually use in a demo, an RFP, or a reference call, without needing to name or rule out any specific vendor.

The Nine Requirements

Single Source of Inventory Truth: The inventory count the register works from should be the same inventory count the ERP, the warehouse, and the e-commerce storefront work from, not a separate POS-side count that has to be synced or reconciled on a schedule. A separate inventory count is where oversells, phantom stock, and end-of-day reconciliation work all originate.

Single Source of Customer Truth: Credit terms, order history, loyalty balances, and contact details should be one record shared across every channel a customer touches, not a duplicate record that the POS and the ERP each maintain and periodically compare. Duplicate customer records are the most common source of pricing and credit-limit disputes at the counter.

Single Source of Pricing Truth: Pricing, promotions, and negotiated contract terms should be set once, in the ERP, and enforced identically everywhere a sale can happen. A POS that keeps its own price list is a second place pricing errors can creep in, and a second place someone has to update.

Single Source of Financial Truth: A completed sale should flow into the ERP's own accounting and financial reporting as a native transaction, not into a separate POS ledger that is imported or reconciled into the ERP later. A delayed batch import means the financial picture is only ever as current as the last import, not the last sale.

One Fulfillment Network: An order should be fulfillable from any location or channel (in-store, buy-online-pick-up-in-store, buy-online-return-in-store, or warehouse) without a separate system managing that logistics layer on the side. Fulfillment options are usually the first casualty of a POS that was not built with multi-location, multi-channel operations in mind.

Resilience When Connectivity Drops: Ask specifically what happens to sales, credit card processing, gift cards, and tax calculation during an outage, and how long it takes to write everything back to the ERP once connectivity returns. Many POS platforms fall back to cash-only sales during an outage, which is a real gap the vendor should disclose rather than gloss over.

Deployment and Administration Footprint: Count the separate applications, servers, and admin consoles store staff and IT have to install, patch, and keep in sync just to run one register. Every extra component is another thing that can be misconfigured, another login, and another point of failure.

Platform and Device Flexibility: Confirm whether the register is tied to specific hardware or operating systems the business does not already standardize on, or whether it can run on the devices already in use. Hardware lock-in turns a software decision into a forced hardware refresh.

Proven at Mid-Market Volume, Not Just Promised: Ask for a reference customer running thousands of SKUs, multiple registers per store, and multiple store locations, not just a single small storefront demo. An architecture that has not been proven at volume is a risk the business absorbs after the contract is signed, not before.

Questions to Ask Any Vendor

Ask every vendor being compared the same nine questions, in the same order, and write down the exact answer rather than a paraphrase. A vendor that cannot explain the mechanism behind a claim, only the marketing language for it, has usually told you the answer already.

Self-Check: Before You Sign

Red Flags: Signs of a Bolted-On POS

• The sales team cannot explain where the master inventory record lives without a slide.

• "Integration" is used to describe the connection between the POS and the ERP, rather than a single shared data model.

• Offline behavior is described only in general terms, with no specific answer for credit cards, gift cards, or tax calculation.

• The only reference customers offered are single-location, low-SKU-count businesses.

• Every device or platform claim is followed by a request for a separate quote or a hardware refresh.

• "Real time" is used to describe the sync, but nobody on the call can say how often data actually moves or what happens if it fails.

How to Use This Checklist

Bring the same nine questions to every vendor being evaluated, in a live working session rather than a scripted demo, and ask to see the answer rather than hear it described. Request the written answers as part of the proposal, not just the verbal walkthrough, so there is a record to hold the eventual contract against. If an answer only restates a marketing term without explaining the mechanism behind it, ask the question again in different words.

None of these nine requirements are unique to any one vendor. They are simply what "ERP-Led POS™" actually means once it is turned into a set of testable questions, rather than left as a phrase on a slide.