POS operations guide
POS RFP template and 12-point selection checklist
Write one POS request for proposal before vendor demonstrations, then test the records your business must create and the failures it must survive. Ask every candidate the same 48 questions, keep mandatory failures separate from weighted scores and require evidence for each answer.
Evidence and review scope
Evidence reviewed 2026-08-23. Current selection-intent results, nine public POS procurement documents plus three public notice or opportunity records dated 2016 to 2026, primary standards, a pinned Posnic release and repeatable acceptance evidence.
Stable release: v1.3.0, source commit b531ef4. The procurement review is a bounded qualitative sample, and this vendor-neutral method is not a certification, ranking promise or substitute for local tax, payment, privacy, accessibility, procurement or legal review
What the current evidence establishes
Counter session: 49 bounded checks
At the pinned v1.3.0 source commit, one compressed synthetic HTTP API session opened and closed a register, received stock, stored 12 sales, guarded duplicate sale and return replays, and reconciled INR 2,622 net sales. It did not drive the packaged interface, count physical cash, connect hardware or run a clock-length trading day.
Inventory lifecycle: 21 bounded checks
A separate synthetic HTTP API run reconciled receiving, a two-unit sale, a partial return, stock logs and INR 138 net sales without duplicate replay changes. It did not use customer production data, physical devices or an external payment network.
Backup drill: 20 collections and 53 documents
A disposable Windows profile restored a synthetic backup and preserved the expected earlier item and sale while excluding a post-backup item. That establishes one reproducible test boundary, not a production recovery time or proof for another machine, database size or operating environment.
Hardware remains an implementation test
Thirty-five receipt, report and scale protocol tests passed in the pinned source review, but no physical printer, scanner, drawer, scale, display or payment terminal was connected. Exact model, driver, firmware, cable, paper and reconnect behavior still need observation.
Score evidence, not demo polish
Use evidence levels consistently across every shortlisted POS. A lower-level claim can justify another test, but it cannot substitute for an observed result on the exact implementation.
| Evidence level | What it establishes | What to retain |
|---|---|---|
| 1. Vendor statement | A capability or service is claimed. | Dated page, proposal and exact wording. |
| 2. Documentation | The release describes a workflow, dependency or limit. | Versioned manual, release and configuration. |
| 3. Source or interface | A code path, schema or user surface exists. | Commit, file, route, screen and configuration. |
| 4. Automated test | A bounded case passed in its test environment. | Command, result, fixtures, version and limitations. |
| 5. Synthetic runtime | Representative records reconciled in a controlled run. | Inputs, outputs, logs, screenshots and equations. |
| 6. Exact implementation acceptance | The planned staff, devices, providers and controls passed together. | Signed record, failures, owners, rollback and retest date. |
Original procurement evidence review
What twelve public POS procurement records asked vendors to address
We coded nine public procurement documents and three public notice or opportunity records from Australia, Canada, New Zealand, South Africa, the United Kingdom and the United States. Each source was checked against the same twelve buyer controls. A yes means at least one explicit requirement was located in that broad category; it does not mean the source covered every question or that any vendor passed.
| Buyer control | Sources with an explicit requirement | What the RFP should require |
|---|---|---|
| Mandatory counter workflow | 12 of 12 | One representative open-to-close workflow with retained transaction and close records. |
| Exceptions and reconciliation | 10 of 12 | Returns, voids, discounts, retries and a reconciliation equation, not only a normal sale. |
| Reliability and dependency failure | 7 of 12 | A dependency map plus outage, reconnect, capacity and service evidence. |
| Inventory and traceability | 9 of 12 | Receiving, movement, sale, return, count and variance evidence for required item types. |
| Tax, receipts and local obligations | 9 of 12 | Configured documents and named local acceptance, with unsupported obligations visible. |
| Payment scope and security | 11 of 12 | Separate POS, terminal, processor, settlement and payment-security responsibilities. |
| Hardware and platform fit | 11 of 12 | Exact makes, models, interfaces, lifecycle and repeated physical acceptance tests. |
| Roles, audit and updates | 8 of 12 | Permitted and denied actions, attributable history, update ownership and rollback. |
| Backup and clean restore | 5 of 12 | An isolated backup restored into a clean environment and reconciled to known records. |
| Data ownership, exit and integrations | 11 of 12 | Usable exports, interface failure rules, migration and post-contract access terms. |
| Support, training and implementation | 10 of 12 | Named owners, measurable support, observed training and a reversible rollout plan. |
| Total operating cost and contract | 11 of 12 | Comparable multi-year pricing with processing, support, renewal and exit costs visible. |
This review contains twelve English-language public procurement records dated 2016 to 2026: nine full documents and three public notice, overview or opportunity records. NSW, Wellington and Telford are coded only from their public pages because full tender files were not reviewed. The matrix uses the issue or open date where the source publishes one; for the Joburg and Telford records it uses the dated closing or quote deadline shown because a separate publication date was not located. The 144 manually coded checks are not a market-frequency study, legal template or current requirement for another buyer. Not observed means the control was not located in the reviewed scope; it does not prove the source omitted it everywhere.
Practical workflow
1. Mandatory counter workflow
Write the shortest complete shift your business must run: open, sell, take each payment type, print or issue the required document, retrieve the sale and close. Include peak volume, item types, taxes, currencies, languages and accessibility needs. Mark this as a gate: if ordinary staff cannot finish it accurately, weighted extras do not rescue the candidate.
2. Exceptions and reconciliation
Test line removal, price override, discount, void, return, exchange, split or partial payment, cash in and out, duplicate submission and receipt reprint. Every approved exception should leave an attributable record, and sales, cash, processor settlement, refunds, tax and open orders should reconcile without hidden manual edits.
3. Reliability and dependency failure
Draw the dependency path for till, local network, internet, cloud service, identity, payment, printer and power. Interrupt each dependency before save, during save and after save. Record what remains available, what is queued or blocked, how staff are warned, and whether reconnect creates duplicates or missing records.
4. Inventory and traceability
Use representative simple, variant, weighed, batch, serial or service items only where the business actually needs them. Test receiving, sale, partial return, transfer, waste, correction and a physical count. The expected balance should be reproducible from an opening quantity and retained movements, not only from the current stock number.
5. Tax, receipts and local obligations
List required invoice fields, numbering, tax treatment, rounding, returns, retention, fiscal devices, e-invoicing and record-access duties for each market. Have the responsible local adviser accept samples from the exact configuration. A generic tax toggle or attractive receipt template is not jurisdiction approval.
6. Payment scope and security
Separate the POS record from authorization, terminal behavior, settlement, chargebacks and merchant validation. Confirm which system handles payment data, what happens during timeout or duplicate retry, and who owns PCI DSS and provider requirements. Never infer payment compliance from a POS feature list.
7. Hardware and platform fit
Inventory exact computer, operating system, printer, scanner, drawer, scale, display, terminal, ports, drivers and firmware. Test install, repeated operation, sleep, reboot, cable removal, reconnect and replacement. Protocol support in code or a compatibility list is useful evidence, but only the planned model can pass implementation acceptance.
8. Roles, audit and updates
Create realistic cashier, supervisor, owner, accountant and administrator roles. Attempt forbidden refunds, discounts, tax edits, exports and closes, then inspect the audit trail. Record supported versions, advisory route, patch owner, secret handling, remote-support controls, update rehearsal and rollback procedure.
9. Backup and clean restore
Define recovery time and recovery point objectives before choosing the storage model. Create an off-device or otherwise isolated backup, restore it into a clean supported environment, and reconcile representative sales, stock, users, settings and attachments. Synchronization alone may copy deletion or corruption and is not proof of recoverability.
10. Data ownership, exit and integrations
Export items, customers, suppliers, stock, sales, returns, tax, payments, users and audit records in documented usable formats. Open them independently, map identifiers and dates, and test one migration or neutral-tool import. For integrations, define the system of record, event identity, retry, conflict, reconciliation and cancellation behavior.
11. Support and training ownership
Name the first and second owner for cashier, device, network, hosting, database, payment, tax and security incidents. Give ordinary staff the failure procedure and observe training time. Record support hours, channels, exclusions, response terms, escalation, remote-access controls and the person authorized to approve a workaround.
12. Total operating cost and contract
Compare the same term and volume: software, terminals, computers, peripherals, installation, migration, training, payment charges, support, connectivity, backups, updates, integrations, extra locations, tax changes, replacement devices and exit work. Keep quoted, estimated and unknown amounts separate, and treat undisclosed mandatory costs as unresolved risk.
A six-stage POS selection process
Run the stages in order so requirements and observed evidence shape the shortlist before price negotiation or rollout pressure does.
Define
Freeze mandatory workflows, volumes, records, markets, devices, dependencies, recovery objectives and named approvers.
Shortlist
Remove candidates that cannot disclose operating model, full cost, data exit, update ownership and support boundaries in writing.
Configure
Use equivalent representative products, users, taxes, stock and hardware for each candidate; keep synthetic data out of production.
Exercise
Run normal sales, exceptions, outage, reconnect, close, restore and export cases with the same script and evidence rules.
Reconcile
Explain every sales, stock, tax, cash and processor difference; classify failures, workarounds, owners and retest conditions.
Pilot
Approve a reversible supervised pilot, retain the old path, measure a real close and restore, then sign off or roll back.
What to prepare before vendor demonstrations
Business inputs
- One ordinary shift and its exception paths, written in staff language.
- Representative items, tax groups, payment methods, receipts and opening stock.
- Peak transactions, concurrent tills, outlets, users and retention period.
- Exact devices, operating systems, networks, power and provider dependencies.
- Local tax, payment, privacy, accessibility, labor and record obligations with named reviewers.
- Recovery objectives, maximum tolerable outage, rollback trigger and approval owner.
Evidence package
- Stable version, build source, release notes, support lifecycle and rollback package.
- Completed scorecard with mandatory gates and weights agreed before testing.
- Inputs, timestamps, record identifiers, screenshots, logs, exports and reconciliation equations.
- Device model, firmware, driver, interface, payment provider and configuration details.
- Backup hash, storage location, restore duration and post-restore checks.
- Open failures, workaround owner, retest date, pilot sign-off and exit procedure.
Setup sequence
- Copy the blank scorecard, adjust weights before seeing vendor demos and mark non-negotiable controls as mandatory gates.
- Create a disposable tenant or profile with synthetic but representative items, users, taxes, payments and stock; never place unapproved personal or production data in a trial.
- Record the exact candidate version, operating model, plan, devices, providers, integrations and configuration under test.
- Run one reference sale and retain its item, stock, payment, receipt, tax, user and report identifiers.
- Run approved exceptions and denied-role attempts, including return, void, discount, duplicate submission and reprint.
- Interrupt every required network or service dependency separately, reconnect in both safe orders and reconcile queues or retries.
- Close a mock shift and explain sales, cash, non-cash settlement, refunds, tax, open orders and stock movement.
- Create an isolated backup, restore it into a clean supported environment and verify representative records and configuration.
- Export the complete required business dataset, open it independently and test identifier, date, tax and relationship usability.
- Score only retained evidence, list every unresolved gate, obtain local reviews and approve a reversible pilot rather than an irreversible cutover.
What each person sees
Cashier
Needs fast ordinary work, truthful failure states and a safe next action without permission shortcuts or duplicate sales.
Owner or manager
Needs explainable exceptions, stock, cash, settlement, close, audit, support and operating-cost records.
Accountant or local adviser
Needs accepted tax documents, numbering, returns, exports, retention and reconciliation for the planned market.
Technical or service owner
Needs version, dependency, device, security, backup, restore, monitoring, update, rollback and incident evidence.
Mistakes to avoid
Avoid these during rollout
- Starting with brands or feature counts before writing mandatory workflows and failure limits.
- Allowing a vendor-led demonstration to replace the same scripted test for every candidate.
- Averaging away a failed mandatory gate with many low-value feature points.
- Calling local, cloud, hybrid, online or offline a result without testing each dependency and task.
- Treating a stored POS payment label as proof of authorization, settlement or PCI responsibility.
- Assuming a scanner, printer, drawer, scale, display or terminal works because its category is listed.
- Calling synchronization a backup without an isolated, clean and reconciled restore.
- Accepting an export button without opening complete data in an independent tool.
- Comparing subscription price while omitting processing, hardware, migration, support, recovery and exit costs.
- Removing the old system before a supervised shift, close, restore and rollback decision have passed.
Use one scorecard for every shortlisted POS
The editable CSV provides twelve default weights totaling 100, a mandatory-gate column, pass conditions, evidence fields and blank scores. Score 0 for failed or unproved, 1 for partial or workaround-dependent, and 2 for passed with retained evidence. Weighted points equal weight multiplied by score divided by two; any failed mandatory gate still blocks approval.
Local evidence comparison
Compare two POS options without hiding mandatory failures
Score the same twelve controls for both options. A failed or unproved mandatory gate blocks approval; a partial mandatory gate remains conditional. The weighted total helps organize evidence but cannot choose the winner or replace a supervised pilot.
Primary sources used
UTEP concessions POS RFP
The 2021 public procurement separates counter workflow, tenders, hardware, offline operation, inventory, reporting, training and security questions.
City of Ann Arbor RFP 966
The 2016 public requirements classify POS, inventory, payments, receipts, backups, data conversion, implementation, support and training with explicit response codes.
University of Maine retail solution RFP
The 2020 public document covers storefront and in-person POS, hardware, payments, security, privacy, inventory, reporting, restore tests, implementation, support and multi-year cost.
City of Vancouver POS solution RFP
The 2018 public procurement links core sales and inventory to PCI, SAP integration, availability, backup, implementation, support and multi-year commercial response fields.
Broward County Convention Center POS RFP
The 2023 public document asks for fixed and mobile hardware, offline operation, payment settlement, inventory, supported workflows and itemized implementation and processing costs.
Coastal Alabama Community College POS RFP
The 2025 public document covers stationary and mobile checkout, exact retail hardware, payments, inventory, reporting, customer engagement, ecommerce synchronization and exportable records.
Boerne ISD child-nutrition POS RFP
The 2024 public document specifies 32 cafeteria locations, browser terminals that continue through internet interruption, integrations, reports, privacy, restore, support, rollout and multi-year cost.
NSW TrainLink onboard POS opportunity
The 2026 public notice covers regional and remote rail operation, transaction reconciliation, approved payments, onboard hardware and systems, testing, pilot rollout, controlled transition and support. Full tender files were not reviewed.
NRF iThemba LABS canteen POS RFI
The 2024 South African RFI specifies cashier roles, orders, PCI DSS, hardware, inventory traceability, D365 integration, support and a five-year total-cost response.
Wellington City Council POS replacement
The 2023 New Zealand public RFP overview identifies reliability, reconciliation, five council-system integrations, data migration, testing, training and support. Full tender files were not reviewed.
Telford and Wrekin hospitality EPOS opportunity
The 2025 United Kingdom public opportunity specifies restaurant and bar workflow, stock, multi-site mobile POS, Spektrix integration, PCI compliance and one-year cost. Full tender files were not reviewed.
Joburg City Theatres hospitality POS tender
The 2023 South African tender specifies POS and back-office terminals, drawers, printers, UPS units, stock and debtor functions, installation, configuration, training and monthly licensing.
Public POS research catalog
The machine-readable catalog publishes row counts, byte sizes and SHA-256 hashes for this evidence matrix, the RFP, scorecard and other bounded Posnic research files.
PCI SSC merchant resources
Primary merchant guidance separates people, process and technology, provides vendor questions and explains that payment-data responsibilities depend on the payment environment.
CISA Secure by Demand
Official software-buyer guidance recommends asking security questions before procurement, carrying requirements into procurement and continuing assessment after purchase.
NIST CSF 2.0 quick-start guides
NIST provides small-business and supply-chain risk guidance for identifying, protecting, detecting, responding and recovering; it is a risk framework, not a POS certification.
NIST contingency planning
SP 800-34 Rev. 1 supplies recovery terminology and a test-and-maintain discipline. This federal guidance is used as a method reference, not asserted as a retail mandate.
GS1 EAN/UPC barcodes
GS1 identifies EAN/UPC as the long-established retail barcode family and publishes implementation guidance. Exact symbols and scanner behavior still depend on the business and products.
Open Source Definition
When a candidate is described as open source, the OSI definition provides the license criteria to verify. Public code alone does not prove release quality or production fit.
Pinned Posnic v1.3.0 source
The exact source commit used for the bounded product examples, so documentation and test references do not drift to a later branch.
Posnic product facts
Human- and machine-readable release facts, runtime observations and explicit limitations used by the current Posnic examples.
Questions
What should a POS RFP include?
A useful POS RFP defines the operating profile, mandatory counter and exception workflows, outage behavior, inventory, local documents, payments, exact hardware, roles, backup and restore, data exit, implementation, support and comparable total cost. It should require evidence, version, limitations, dependencies and acceptance ownership for every important answer.
Is this POS RFP template an official procurement standard?
No. It is an ungated vendor-neutral worksheet derived from a bounded review of twelve public procurement records and primary security, recovery, barcode and payment guidance. Adapt it with qualified procurement, legal, tax, payment, privacy, accessibility and technical owners for the actual market.
What should I look for when choosing a POS system?
Start with mandatory sales and exception workflows, then evaluate failure behavior, inventory traceability, local tax documents, payment scope, exact hardware, roles, updates, backup and restore, data exit, support ownership and total operating cost. Use observed evidence instead of feature-count claims.
How should I test POS software before buying?
Use a disposable environment and synthetic but representative products, taxes, users, payments and stock. Run the same normal sale, exception, outage, reconnect, close, clean restore and complete-export script against every candidate, then retain identifiers, logs, screenshots and reconciliations.
Should the highest weighted POS score always win?
No. Agree mandatory gates before testing. A failed payment, legal, recovery, data-exit or core-workflow gate should block approval even when optional features produce a high weighted total.
Is free POS software really free?
Software price is only one cost. Include hardware, payment charges, migration, setup, training, support, connectivity, backup, updates, integrations, replacement devices and exit work. Keep quoted, estimated and unknown costs separate.
Does offline POS mean every feature works without internet?
No. Test each task and dependency separately. Local item lookup or cash sales may continue while card authorization, hosted ordering, identity, remote dashboards, updates or synchronization still require a network or provider.
Will a POS work with any barcode scanner or receipt printer?
Do not assume that. Match operating system, driver, protocol, interface, firmware, paper width and workflow, then test the exact model through repeated operation, sleep, reboot, disconnect and reconnect.
Does choosing a POS make a merchant PCI compliant?
No. PCI DSS scope and validation depend on the merchant's payment environment and payment-brand or acquirer requirements. Separate the POS record from terminal authorization and settlement, and confirm responsibilities with the relevant provider.
How do I avoid POS vendor lock-in?
Require complete documented exports before purchase, open them independently, map identifiers and relationships, record cancellation and deletion terms, and estimate migration work. Open source can improve inspectability, but it does not replace a tested data exit or operating owner.
What does the current Posnic evidence prove?
At the pinned v1.3.0 source commit, bounded synthetic counter, inventory and backup runs plus focused source tests passed within their stated environments. They do not prove a packaged end-to-end shift, physical hardware, external payment settlement, local compliance, customer production recovery or universal business fit.
Where Posnic fits
Posnic Community Edition v1.3.0 is one candidate that can be evaluated with this method. The current evidence includes bounded synthetic counter, inventory and backup runs plus focused source tests, while physical devices, external payments, a clock-length shift, customer production data, local compliance and a complete implementation remain unaccepted. Use the same scorecard for Posnic and every alternative, keep failed mandatory gates visible, and approve only the exact configuration that passes a reversible pilot.