Vendors / Open source & self-hostable
Open Source Point of Sale
Open Source Point of Sale (opensourcepos / OSPOS)
dossier live legacy rubric
- Claims in scope
- 257
- Scored
- 257
- Assessed
- 257
- Unknown
- 0
- Not applicable
- 57
- Values challenged
- 22
Identity
- Owner
- Community open-source project on GitHub (opensourcepos/opensourcepos). No single commercial owner identified; no corporate parent or paid edition found. Unlike Floreant/OROCUBE there is no documented vendor upsell.
- Founded
- Project dates to 2010 per the license/footer copyright ("© 2010 - current year · opensourcepos.org"); LICENSE credits contributions since 2012. Current GitHub org: opensourcepos.
- Scale
- unknown. No published install base, ARR, or market share. Only proxies available: ~6,741 commits on master, 221 open issues, 38 open PRs on GitHub; 71 SourceForge reviews averaging 4.6/5. None of these establish deployed store counts.
- Who it is for
- Single-site small retailers, market stalls, workshops and simple counter-service operations with an in-house technical operator willing to run and patch a PHP 8.2+/MySQL server. Not a restaurant product: the only restaurant feature (table mode) is documented as "Currently only works with 2 tables".
- Site
- https://github.com/opensourcepos/opensourcepos
Pricing
transparency: published · unit: free · processor lock-in: no
- Software
- $0. MIT-licensed free download from GitHub; no paid tiers, no editions, no hosted SaaS offering. The only monetization is a donation link. The one non-monetary condition is a license clause: the footer signature ("© 2010 - current year · opensourcepos.org · version - commit") "MUST BE RETAINED, MUST BE VISIBLE IN EVERY PAGE and CANNOT BE MODIFIED."
- Card processing
- N/A — the project is not a payment processor and integrates no card processing. Card sales are run on a standalone terminal and the tender is recorded manually in OSPOS.
- Contract
- None. MIT license, no subscription, no term.
- Early termination
- None — no contract exists.
API posture
public API: none
- Cost to integrate
- $0 in fees — no partner program, no certification, no revenue share, and no commercial terms of any kind exist. The cost is entirely developer time against the source.
- Webhooks
- None documented. The Development Index covers dev environment, error logging, database layout, item attributes, custom reports and translations only — no REST/GraphQL API, no webhooks, no plugin or extension architecture. It is a monolithic CodeIgniter 4 app; integration means writing PHP against the codebase or querying MySQL directly.
- Data export on exit
- Complete and unconditional. The operator holds the MySQL database, so a mysqldump is a full export of orders, line items, payments, customers, employees and inventory. The UI additionally offers spreadsheet export on employees, items, customers and reports, and CSV import for items/customers/employees. No fee, no window, no vendor involvement.
- Notes
- Practical integration surface is direct SQL against a documented schema (wiki "Database Layout") plus the ability to fork the app. That is genuinely more open than any commercial POS on this list, but it is not an API: there is no order-injection endpoint, no menu write API, no OAuth, no rate limits, no versioning/deprecation policy, and no sandbox distinct from just installing the software. Mailchimp and SMS are the only named outbound third-party integrations in the feature datasheet.
Capabilities
Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.
Order capture & FOH workflow
Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.
order-capture-floor-plan-editor
No floor plan. Tables are text labels on suspended sales; docs say "Currently only works with 2 tables" (issue #1933). https://github.com/opensourcepos/opensourcepos/wiki/Sales-Restaurant · retrieved 2026-08-01
Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.
order-capture-seat-level
No seat concept; table is a label attached to a suspended sale. https://github.com/opensourcepos/opensourcepos/wiki/Sales-Restaurant · retrieved 2026-08-01
Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.
order-capture-coursing-hold-fire
No kitchen firing path exists at all — no KDS, no course construct in the feature datasheet. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
Datasheet enumerates suspend/resume, receipts, invoices, quotes and returns; no split or merge of checks. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
No card processing integration exists, so no pre-auth is possible. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.
order-capture-transfer-audit
Suspended sales can be resumed by another logged-in employee, but no transfer object or transfer audit log is documented. https://github.com/opensourcepos/opensourcepos/wiki/Sales-Restaurant · retrieved 2026-08-01
Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.
order-capture-native-handheld
Responsive browser UI only; docs state "Works on mobile but PC/Mac is recommended" and mobile barcode reading is "not yet" available. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
Server-rendered CI4 web app with no offline client and no published offline behavior. A LAN-hosted server survives internet loss, but a terminal that loses the server cannot transact. https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator
order-capture-qr-same-check
No guest-facing ordering channel of any kind in the feature datasheet. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator
order-capture-voice-ai
No AI features and no partner/API program; the project publishes no public API. https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator
order-capture-throttling
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.
order-capture-scheduled-orders
Quotes and work orders can be held for later conversion, but there is no fire-time scheduling or make queue. https://github.com/opensourcepos/opensourcepos/wiki/Work-Orders · retrieved 2026-08-01
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
Built from quotes plus invoices with balance due. But the datasheet's POS cannot-do column disclaims exactly the mechanisms a catering deposit flow needs: 'Advanced Transaction Types such as Special Orders, Back Orders and Layaways, Credit accounting sales', and separately 'no A.R. features'. A retail quote-to-invoice path with no deposit, no event date, no BEO and no credit sales is not a rough catering flow. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator
order-capture-order-ready-signal
No marketplace integrations exist. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.
order-capture-void-comp-controls
Per-module permissions gate access and payments record employee ID and timestamp, but no reason codes, no manager-approval prompt, no exception report documented. https://github.com/opensourcepos/opensourcepos/wiki/Menu-and-Permissions · retrieved 2026-08-01
Menu, modifiers & pricing engine
Payments & money movement
The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator
payments-processor-choice
Maximally open in that nothing is bundled, but there is no integrated processing and no documented gateway list — card runs on a standalone terminal and the tender is keyed in manually. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
Project is not a processor and publishes no card rates. https://opensourcepos.org/ · retrieved 2026-08-01
Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator
payments-dual-pricing
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator
payments-surcharge-guardrails
No BIN-level card data is ever seen by the application. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
Hardware datasheet lists "Credit Card Readers" under not supported; there are no first-party terminals. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator
payments-softpos-tap-to-pay
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.
payments-pay-at-table
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator
payments-qr-guest-pay
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.
payments-tip-adjust
No tip handling appears in the feature datasheet or payment processing docs. https://github.com/opensourcepos/opensourcepos/wiki/Payment-Processing · retrieved 2026-08-01
Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator
payments-tip-pooling
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator
payments-offline-store-and-forward
No card path at all, therefore no store-and-forward. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator
payments-offline-decline-liability
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.
payments-gift-cards
Native gift cards with balance tracking are in the feature datasheet; single install means one shared balance pool, but there is no online channel to redeem through. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
The project's own feature datasheet lists this under 'What cannot do' verbatim: 'Accounts Receivable / House Accounts, OSPOS has CRM features but no A.R. features'. The researcher built a partial from the Payment-Processing page's balance-due mention, but that page itself admits balance-due tracking is still under development (#3072). Vendor-affirmed absence beats an inferred partial. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.
payments-split-tender
Upheld, but not from the cited source. The Payment-Processing wiki page does not document split or multiple payments at all. The support is in the datasheet: 'apply multiple payments (inclusivelly different types) to the sale'. Partial is correct — multiple tenders yes, no split by seat, item or even shares. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.
payments-refund-void-controls
Payments record amount, refunded amount, timestamp and employee ID; permissions are per-module. No approver-attributed override flow and the log is a mutable app table, not immutable. https://github.com/opensourcepos/opensourcepos/wiki/Payment-Processing · retrieved 2026-08-01
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
https://github.com/opensourcepos/opensourcepos/wiki/Payment-Processing · retrieved 2026-08-01
Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator
payments-card-on-file
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
Not a processor; funds never flow through the project. https://opensourcepos.org/ · retrieved 2026-08-01
Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.
payments-p2pe-pci4
No P2PE, no AOC, no vendor entity to attest. PCI scope sits entirely with the merchant and its separate card terminal. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Kitchen & production
Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.
kitchen-station-routing
No KDS in the product. Printing docs cover receipt/label/PDF/fiscal printing only. https://github.com/opensourcepos/opensourcepos/wiki/Printing · retrieved 2026-08-01
An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.
kitchen-expo-consolidation
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator
kitchen-course-firing
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator
kitchen-order-throttling
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator
kitchen-channel-pause-propagation
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator
kitchen-order-ready-callback
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
Hardware datasheet names only scanners, receipt printers and browsers; no KDS or bump bar. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
Printing is browser/OS-mediated per the hardware datasheet; no routing engine and therefore no failover. https://github.com/opensourcepos/opensourcepos/wiki/Printing-support · retrieved 2026-08-01
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator
kitchen-pizza-fractional-display
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
Receipts can be reprinted, but there is no kitchen ticket lifecycle to recall or refire. https://github.com/opensourcepos/opensourcepos/wiki/Printing · retrieved 2026-08-01
Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator
kitchen-order-modification-alerts
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
SMS messaging to customers exists as a platform feature, but it is not wired to any kitchen/order-ready state — there is no KDS to bump. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Partial credit was given for the Expenses module 'absorbing' waste. The datasheet says expenses are for 'basic expenses, no accounting needs' and that 'Accounting with expenses over the sales are out of scope'. There is no kitchen surface, no reason codes, no waste record type. This is a workaround, not a feature. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
No ticket-time capture exists. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.
kitchen-prep-forecasting
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Digital ordering & guest-facing channels
Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.
digital-first-party-web
OSPOS is a back-of-house/register web app for staff; there is no guest ordering site. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.
digital-account-saved-payment
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator
digital-upsell-engine
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.
digital-scheduled-pacing
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.
digital-fulfillment-modes
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.
digital-qr-table
https://github.com/opensourcepos/opensourcepos/wiki/Sales-Restaurant · retrieved 2026-08-01
Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator
digital-kiosk
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.
digital-group-ordering
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator
digital-catering-portal
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator
digital-voice-ai-phone
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.
digital-drivethru-ai
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
SMS messaging exists as outbound customer messaging only; no conversational ordering. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator
digital-google-order
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.
digital-apple-business-connect
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.
digital-loyalty-attach
Customer rewards exist in-store only; there is no digital channel to attach them to. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.
digital-subscriptions
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.
digital-promo-parity
Single channel only, so parity is vacuous rather than achieved. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator
digital-guest-data-ownership
Self-hosted: operator holds the MySQL database and the UI offers customer CSV import and spreadsheet export. No vendor, no fee, no approval. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.
digital-checkout-pci-sca
No digital checkout exists and no PCI DSS attestation is published. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator
digital-surcharge-transparency
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Guest data, loyalty & marketing
Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.
guest-loyalty-unified-profile
Single customer table for one in-store channel; no cross-channel identity merge because no other channel exists. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator
guest-loyalty-thirdparty-identity-attach
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.
guest-loyalty-accrual-models
"Customer rewards" is listed as a shipped feature, but the wiki does not document configurable accrual models; only one scheme appears to exist. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
Customer price/tax tiers exist but are not loyalty status tiers with automatic promotion/demotion. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
No offline mode exists and none is documented. https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator
guest-loyalty-targeted-offers
Mailchimp integration means audiences can be built in Mailchimp; nothing rules-based exists inside OSPOS itself. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator
guest-loyalty-rfm-segmentation
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.
guest-loyalty-lifecycle-automation
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator
guest-loyalty-native-email-sms
Native SMS messaging and email (receipt/invoice email) ship; bulk email marketing is delegated to Mailchimp rather than sent natively. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.
guest-loyalty-consent-management
Customer profiles capture GDPR registration consent. No per-channel consent, timestamp/source record or revocation workflow is documented. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
SMS is sent through the operator's own gateway credentials; 10DLC registration is entirely the operator's problem and is not documented. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator
guest-loyalty-campaign-attribution
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator
guest-loyalty-data-export-portability
Customers module supports spreadsheet export including PII, and the operator has direct MySQL access to full transaction history. No fee, no ticket. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator
guest-loyalty-review-capture-routing
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.
guest-loyalty-referral-program
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator
guest-loyalty-wallet-pass
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.
guest-loyalty-privacy-rights-tooling
GDPR consent capture is documented and the operator can delete/export records directly in the database, but no in-app DSAR tooling exists. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.
guest-loyalty-redemption-fraud-controls
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator
guest-loyalty-ai-offer-recommendation
No AI/ML features anywhere in the product. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.
guest-loyalty-stored-value-gift
Native gift cards ship; single-install so balances are shared across all stock locations, but no documented binding to a guest loyalty profile. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Labor & workforce
Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.
labor-clock-in-at-pos
No time clock. The Employees module manages user accounts and permissions only. https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator
labor-photo-punch-verification
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator
labor-offline-time-punch
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.
labor-granular-rbac
Permissions are granted per menu module (Office/Home grouping) per employee, and grants are independent of menu visibility — but not per discrete action or per location. https://github.com/opensourcepos/opensourcepos/wiki/Menu-and-Permissions · retrieved 2026-08-01
Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.
labor-manager-override-audit
No manager-override construct documented; sale and payment rows carry an employee ID but there is no approver field or immutable trail. https://github.com/opensourcepos/opensourcepos/wiki/Payment-Processing · retrieved 2026-08-01
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator
labor-demand-labor-forecast
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator
labor-realtime-labor-percent
No labor cost data exists in the system. https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator
labor-overtime-prevention
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator
labor-break-compliance-by-state
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.
labor-tip-pooling-rules
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.
labor-tip-distribution-audit-trail
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).
labor-payroll-export-formats
Employees export to a generic spreadsheet, but there are no hours to export and no named payroll provider format or integration. https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator
labor-shift-swap-workflow
https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
Scored partial on 'derivable via SQL' reasoning with confidence 'inferred'. The vendor explicitly states there is no Top Sales / Best Selling / Top Customers reporting. Derivable-from-the-database is not a capability; by that standard nearly every cell in this dossier would be partial. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
Inventory, purchasing & cost control
Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.
inventory-recipe-bom-costing
Item Kits give a one-level BOM whose sale depletes component stock. No sub-recipes and no documented automatic plate-cost recalculation on ingredient cost change. https://github.com/opensourcepos/opensourcepos/wiki/Item-Kits · retrieved 2026-08-01
Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.
inventory-unit-conversion-yields
CLAIM: purchase, recipe and count units per item with explicit conversion factors, plus a yield/waste %. VERDICT: partial -- a purchase-to-stock conversion factor exists; there are no recipe units, no separate count unit and no yield/waste percentage. EVIDENCE: items carry 'receiving_quantity' (en label "Receiving Quantity", app/Language/en/Items.php:85) and receiving multiplies it into stock: "$items_received = $item_data['receiving_quantity'] != 0 ? $item_data['quantity'] * $item_data['receiving_quantity'] : $item_data['quantity'];" (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Receiving.php#L154). Sell-side packs: Item model fields 'qty_per_pack', 'pack_name', 'low_sell_item_id' (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Item.php#L40-L42), labels "Quantity per pack" / "Pack Name" / "Low sell item", default pack name "Each". Item kits are sale bundles, not recipes. SHORTFALL: no recipe/ingredient model and no yield/waste field anywhere in the code. SURFACE: shallow clone of the current release tag 3.4.1 (commit 5f395d987b02562092b838073cb2e23a22d2bca4, released 2025-06-05), a complete census of the application code: 509 tracked text files (binaries and the 42 non-English locale dirs excluded, app/Language/en kept). Cross-checked against master b610ae28 (2026-09-10, 292 commits ahead, 558 files): same 21 report models in app/Models/Reports, same control results. CONTROLS (tokenised: snake_case and camelCase split, word-boundary, case-insensitive, over all 509 files; script .cache/q316/opensourcepos/controls.mjs, output controls.json): tips|gratuity|tipping 0; comps|comped|complimentary 0; yield|waste|wastage|recipe|ingredient|uom|unit of measure -> 0 business hits (poison: 'yield' is English in a TODO in Models/Cashup.php, 'convert' is SQL CONVERT TO CHARACTER SET); expiry|expiration|expire|best before|shelf life|use by|spoilage|lot|batch -> 0 business hits (poison: cookie/session/CSRF 'expires' in app/Config, 'batch' is Appconfig batch_save); variance|discrepancy|over/short|overage|shortage -> 0 business hits (poison: 'expected' in code comments; Cashups.cash_difference is an EMPTY en string referenced nowhere in code); reason|reason code -> 0 business hits (all framework comments); approve|approval|manager -> only two EMPTY language strings; void -> PHP return type (poison, 912 hits); alert|notify|threshold -> Bootstrap 'alert' CSS classes, log level 'alert', and the toast-position setting notify_*_position (poison); drawer|till|shift -> 0 (poison: 'register' = the sales register screen). Retrieved 2026-09-16. https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Receiving.php#L154 · retrieved 2026-09-16 adversarially verified
Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator
inventory-theoretical-vs-actual
Stocktake records counts against system on-hand, producing a variance at count time; no theoretical-usage-from-recipe vs actual report in units and currency. https://github.com/opensourcepos/opensourcepos/wiki/Stocktake · retrieved 2026-08-01
Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator
inventory-realtime-depletion
Challenged as the dossier's most load-bearing 'yes' and it survives. Sales wiki, verbatim: 'At the point of sale all stock items are checked to see if there is sufficient quantity on hand to satisfy the sale', and 'If the Item Type is set to non-stock then the validation will not take place'. Item Kits wiki confirms components stay individually tracked ('The quantity of each item in the package can continue to be tracked as if it were not in the package'). Native, first-party, no add-on. https://github.com/opensourcepos/opensourcepos/wiki/Sales · retrieved 2026-08-01 adversarially verified
Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator
inventory-86-auto-sync
Stock shortfall is flagged at the register, but there are no other channels to sync to. https://github.com/opensourcepos/opensourcepos/wiki/Sales · retrieved 2026-08-01
Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.
inventory-count-modes
A dedicated Stocktake module supports full and partial counts; scheduled recurring cycle counts and per-count variance history retention are not documented. https://github.com/opensourcepos/opensourcepos/wiki/Stocktake · retrieved 2026-08-01
Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.
inventory-mobile-count-offline
Hardware datasheet states mobile barcode reading "isn't yet available"; the app is online-only web with no offline count capture. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator
inventory-vendor-catalogs-edi
Purchasing supports suppliers and purchase orders, but no named distributor EDI catalogs or electronic PO transmission. https://github.com/opensourcepos/opensourcepos/wiki/Purchasing · retrieved 2026-08-01
Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator
inventory-invoice-ocr
CSV import is the only bulk ingest path; no OCR or invoice parsing. https://github.com/opensourcepos/opensourcepos/wiki/Import-data-from-CSV-file · retrieved 2026-08-01
Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator
inventory-price-change-alerts
CLAIM: per-item purchase price history across invoices plus an alert when a received price exceeds the prior/contracted price by a configurable threshold. VERDICT: no -- the history half exists, the alert does not. EVIDENCE: each receivings_items row stores both "'item_cost_price' => $cur_item_info->cost_price" and "'item_unit_price' => $item_data['price']" (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Receiving.php#L147-L148); on a difference the code only optionally re-averages cost: "if ($cur_item_info->cost_price != $item_data['price'] && $config['receiving_calculate_average_price'])" -> change_cost_price (#L157-L158). No comparison raises a warning, notification or threshold setting. BOUND: the whole application source (census below); the only 'alert'/'notify' tokens are Bootstrap alert CSS classes for form messages in Views/receivings/receiving.php, log levels, and the toast-position setting. SURFACE: shallow clone of the current release tag 3.4.1 (commit 5f395d987b02562092b838073cb2e23a22d2bca4, released 2025-06-05), a complete census of the application code: 509 tracked text files (binaries and the 42 non-English locale dirs excluded, app/Language/en kept). Cross-checked against master b610ae28 (2026-09-10, 292 commits ahead, 558 files): same 21 report models in app/Models/Reports, same control results. CONTROLS (tokenised: snake_case and camelCase split, word-boundary, case-insensitive, over all 509 files; script .cache/q316/opensourcepos/controls.mjs, output controls.json): tips|gratuity|tipping 0; comps|comped|complimentary 0; yield|waste|wastage|recipe|ingredient|uom|unit of measure -> 0 business hits (poison: 'yield' is English in a TODO in Models/Cashup.php, 'convert' is SQL CONVERT TO CHARACTER SET); expiry|expiration|expire|best before|shelf life|use by|spoilage|lot|batch -> 0 business hits (poison: cookie/session/CSRF 'expires' in app/Config, 'batch' is Appconfig batch_save); variance|discrepancy|over/short|overage|shortage -> 0 business hits (poison: 'expected' in code comments; Cashups.cash_difference is an EMPTY en string referenced nowhere in code); reason|reason code -> 0 business hits (all framework comments); approve|approval|manager -> only two EMPTY language strings; void -> PHP return type (poison, 912 hits); alert|notify|threshold -> Bootstrap 'alert' CSS classes, log level 'alert', and the toast-position setting notify_*_position (poison); drawer|till|shift -> 0 (poison: 'register' = the sales register screen). Retrieved 2026-09-16. https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Receiving.php#L147-L158 · retrieved 2026-09-16 adversarially verified
Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator
inventory-par-auto-suggest
Upheld on the fact but the citation is wrong and should be corrected. The cited Inventory-Items wiki page contains nothing about reorder levels — it covers module access and CSV import only. The supporting text is on the Items page, which lists 'reorder level' among item settings. Partial stands (reorder level exists, no forecast-driven suggested PO quantities). https://github.com/opensourcepos/opensourcepos/wiki/Items · retrieved 2026-08-01 adversarially verified
Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.
inventory-waste-logging
Manual inventory adjustments with a comment and the Expenses module can absorb waste, but there is no structured reason-coded waste workflow or separate waste-cost report. https://github.com/opensourcepos/opensourcepos/wiki/Expenses · retrieved 2026-08-01
Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.
inventory-shelf-life-expiry
CLAIM: expiration/use-by dates on received and prepped items plus an expiring-soon report or alert. VERDICT: no. EVIDENCE: the complete report enumeration is the 21 models in app/Models/Reports (Detailed_receivings, Detailed_sales, Inventory_low, Inventory_summary, Report, Specific_customer, Specific_discount, Specific_employee, Specific_supplier, Summary_categories, Summary_customers, Summary_discounts, Summary_employees, Summary_expenses_categories, Summary_items, Summary_payments, Summary_report, Summary_sales, Summary_sales_taxes, Summary_suppliers, Summary_taxes) with matching Controllers/Reports.php methods; the only inventory reports are low-stock and summary. receivings_items has no expiry or lot column (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Receiving.php#L138-L149). A user could define a DATE-type item attribute (Models/Attribute.php), but nothing reports or alerts on it. BOUND: whole-source census, 0 business hits for expiry vocabulary. SURFACE: shallow clone of the current release tag 3.4.1 (commit 5f395d987b02562092b838073cb2e23a22d2bca4, released 2025-06-05), a complete census of the application code: 509 tracked text files (binaries and the 42 non-English locale dirs excluded, app/Language/en kept). Cross-checked against master b610ae28 (2026-09-10, 292 commits ahead, 558 files): same 21 report models in app/Models/Reports, same control results. CONTROLS (tokenised: snake_case and camelCase split, word-boundary, case-insensitive, over all 509 files; script .cache/q316/opensourcepos/controls.mjs, output controls.json): tips|gratuity|tipping 0; comps|comped|complimentary 0; yield|waste|wastage|recipe|ingredient|uom|unit of measure -> 0 business hits (poison: 'yield' is English in a TODO in Models/Cashup.php, 'convert' is SQL CONVERT TO CHARACTER SET); expiry|expiration|expire|best before|shelf life|use by|spoilage|lot|batch -> 0 business hits (poison: cookie/session/CSRF 'expires' in app/Config, 'batch' is Appconfig batch_save); variance|discrepancy|over/short|overage|shortage -> 0 business hits (poison: 'expected' in code comments; Cashups.cash_difference is an EMPTY en string referenced nowhere in code); reason|reason code -> 0 business hits (all framework comments); approve|approval|manager -> only two EMPTY language strings; void -> PHP return type (poison, 912 hits); alert|notify|threshold -> Bootstrap 'alert' CSS classes, log level 'alert', and the toast-position setting notify_*_position (poison); drawer|till|shift -> 0 (poison: 'register' = the sales register screen). Retrieved 2026-09-16. https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Reports/Inventory_low.php · retrieved 2026-09-16 adversarially verified
Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.
inventory-bar-partial-bottle
Hardware datasheet names no scale support; scales are absent from the supported-device list. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.
inventory-cogs-gl-export
Reports export to generic spreadsheets only; no QuickBooks/Sage/NetSuite format and no GL account mapping. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator
inventory-native-not-partner
Inventory, item kits, stocktake and purchasing are core first-party modules — inventory is arguably the product's primary purpose, not an add-on. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Reporting, BI & data access
Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.
reporting-realtime-dashboard
Datasheet cannot-do column, verbatim: 'There are reports, but no dashboard that shares Top Sales, Top Suppliers, Best Selling Items, Top Customers, etc. See #1433'. That is an affirmative statement of absence, not merely undocumented. Reports existing is not a dashboard, and there is no mobile app. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.
reporting-eod-closeout
CLAIM: one daily close-out document reconciling gross, net, tax, tips, discounts, refunds, tender types and expected cash deposit. VERDICT: partial -- the Payments summary report reconciles sales by type against tenders and refunds for a date range, but it is not the full EOD packet. EVIDENCE: Summary_payments columns trans_group, trans_type, trans_sales, trans_amount, trans_payments, trans_refunded, trans_due, with a Sales block grouped by POS/Invoice/Return and a Payments block grouped by payment_type, gift cards merged (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Reports/Summary_payments.php#L14-L22, #L55-L100); "At this point in time refunds are assumed to be cash refunds." Expected cash is computed only on the separate Cashups form (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Controllers/Cashups.php#L110-L178). SHORTFALL: no tips concept exists at all (0 tokens); tax, discounts and net are on other reports (Summary_sales: subtotal/tax/total/cost/profit; Summary_discounts), not on this one; expected cash deposit is on no report. SURFACE: shallow clone of the current release tag 3.4.1 (commit 5f395d987b02562092b838073cb2e23a22d2bca4, released 2025-06-05), a complete census of the application code: 509 tracked text files (binaries and the 42 non-English locale dirs excluded, app/Language/en kept). Cross-checked against master b610ae28 (2026-09-10, 292 commits ahead, 558 files): same 21 report models in app/Models/Reports, same control results. CONTROLS (tokenised: snake_case and camelCase split, word-boundary, case-insensitive, over all 509 files; script .cache/q316/opensourcepos/controls.mjs, output controls.json): tips|gratuity|tipping 0; comps|comped|complimentary 0; yield|waste|wastage|recipe|ingredient|uom|unit of measure -> 0 business hits (poison: 'yield' is English in a TODO in Models/Cashup.php, 'convert' is SQL CONVERT TO CHARACTER SET); expiry|expiration|expire|best before|shelf life|use by|spoilage|lot|batch -> 0 business hits (poison: cookie/session/CSRF 'expires' in app/Config, 'batch' is Appconfig batch_save); variance|discrepancy|over/short|overage|shortage -> 0 business hits (poison: 'expected' in code comments; Cashups.cash_difference is an EMPTY en string referenced nowhere in code); reason|reason code -> 0 business hits (all framework comments); approve|approval|manager -> only two EMPTY language strings; void -> PHP return type (poison, 912 hits); alert|notify|threshold -> Bootstrap 'alert' CSS classes, log level 'alert', and the toast-position setting notify_*_position (poison); drawer|till|shift -> 0 (poison: 'register' = the sales register screen). Retrieved 2026-09-16. https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Reports/Summary_payments.php · retrieved 2026-09-16 adversarially verified
Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.
reporting-pmix-modifier-level
Item-level sales reporting exists; there are no modifiers to report on, and daypart/revenue-center filtering is not documented. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.
reporting-comps-voids-audit
CLAIM: audit report of comps, voids, discounts and price overrides with the employee who applied them, the approving manager, reason codes and timestamps. VERDICT: partial. EVIDENCE: deleting a sale is a soft cancel -- "When a sale is "deleted" it is simply changed to a status of canceled." (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Sale.php#L776-L818); the Detailed sales report has a 'canceled' sale-type filter ("case 'canceled': $builder->where('sale_status', CANCELED);") with columns sale_id, type_code, sale_time, employee_name ("Sold By"), totals and comment (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Reports/Detailed_sales.php#L30-L45, #L154-L156); Summary_discounts and Specific_discount report discounts with sale_time and "Sold By". Price changes are a grantable permission ('sales_change_price', sqlscripts/3.3.2_saleschangeprice.sql). SHORTFALL: no approval/manager step (the only 'manager' tokens are empty language strings), no reason codes, the canceller is recorded only in an inventory row (trans_user, comment "Deleting sale N"), not in the report; comps do not exist; price overrides are neither logged nor reported. SURFACE: shallow clone of the current release tag 3.4.1 (commit 5f395d987b02562092b838073cb2e23a22d2bca4, released 2025-06-05), a complete census of the application code: 509 tracked text files (binaries and the 42 non-English locale dirs excluded, app/Language/en kept). Cross-checked against master b610ae28 (2026-09-10, 292 commits ahead, 558 files): same 21 report models in app/Models/Reports, same control results. CONTROLS (tokenised: snake_case and camelCase split, word-boundary, case-insensitive, over all 509 files; script .cache/q316/opensourcepos/controls.mjs, output controls.json): tips|gratuity|tipping 0; comps|comped|complimentary 0; yield|waste|wastage|recipe|ingredient|uom|unit of measure -> 0 business hits (poison: 'yield' is English in a TODO in Models/Cashup.php, 'convert' is SQL CONVERT TO CHARACTER SET); expiry|expiration|expire|best before|shelf life|use by|spoilage|lot|batch -> 0 business hits (poison: cookie/session/CSRF 'expires' in app/Config, 'batch' is Appconfig batch_save); variance|discrepancy|over/short|overage|shortage -> 0 business hits (poison: 'expected' in code comments; Cashups.cash_difference is an EMPTY en string referenced nowhere in code); reason|reason code -> 0 business hits (all framework comments); approve|approval|manager -> only two EMPTY language strings; void -> PHP return type (poison, 912 hits); alert|notify|threshold -> Bootstrap 'alert' CSS classes, log level 'alert', and the toast-position setting notify_*_position (poison); drawer|till|shift -> 0 (poison: 'register' = the sales register screen). Retrieved 2026-09-16. https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Reports/Detailed_sales.php · retrieved 2026-09-16 adversarially verified
Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.
reporting-cash-over-short
CLAIM: cash over/short per drawer, per shift and per employee, counted vs expected from tenders and paid-outs. VERDICT: no (merge-time downgrade from partial: the claim requires REPORTING over/short; the Cashups module pre-fills expected cash but the closer overwrites it with the count, no over/short amount is stored or reported anywhere in the 3.4.1 or master source, and the cash-difference label is never used). The earlier note's "no shift/drawer construct" is WRONG: the code has a Cashups module. EVIDENCE: Models/Cashup.php "Cashups are used to report actual cash on hand, expenses and transactions at the end of a period." with fields open_date, close_date, open cash ("Open Cash"), transfer_amount_cash ("In/Out Cash"), closed_amount_cash ("Closed Cash"), closed_amount_card/check/due, open_employee_id ("Opened By"), close_employee_id ("Closed By") (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Models/Cashup.php#L12-L35). On close the form pre-fills expected cash: "The closed amount starts with the open amount -/+ any trasferred amount", adds cash payments from Summary_payments for the open-to-close window, and subtracts "expenses paid in cash" (https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Controllers/Cashups.php#L110-L175). SHORTFALL: the expected figure is only a pre-fill that the closer overwrites with the counted amount, so expected and counted are never both stored and no over/short is computed or reported (en string Cashups.cash_difference is empty and referenced nowhere, also on master 2026-09-10); there is no drawer/register entity; the cashup list is a CRUD table, not a report. SURFACE: shallow clone of the current release tag 3.4.1 (commit 5f395d987b02562092b838073cb2e23a22d2bca4, released 2025-06-05), a complete census of the application code: 509 tracked text files (binaries and the 42 non-English locale dirs excluded, app/Language/en kept). Cross-checked against master b610ae28 (2026-09-10, 292 commits ahead, 558 files): same 21 report models in app/Models/Reports, same control results. CONTROLS (tokenised: snake_case and camelCase split, word-boundary, case-insensitive, over all 509 files; script .cache/q316/opensourcepos/controls.mjs, output controls.json): tips|gratuity|tipping 0; comps|comped|complimentary 0; yield|waste|wastage|recipe|ingredient|uom|unit of measure -> 0 business hits (poison: 'yield' is English in a TODO in Models/Cashup.php, 'convert' is SQL CONVERT TO CHARACTER SET); expiry|expiration|expire|best before|shelf life|use by|spoilage|lot|batch -> 0 business hits (poison: cookie/session/CSRF 'expires' in app/Config, 'batch' is Appconfig batch_save); variance|discrepancy|over/short|overage|shortage -> 0 business hits (poison: 'expected' in code comments; Cashups.cash_difference is an EMPTY en string referenced nowhere in code); reason|reason code -> 0 business hits (all framework comments); approve|approval|manager -> only two EMPTY language strings; void -> PHP return type (poison, 912 hits); alert|notify|threshold -> Bootstrap 'alert' CSS classes, log level 'alert', and the toast-position setting notify_*_position (poison); drawer|till|shift -> 0 (poison: 'register' = the sales register screen). Retrieved 2026-09-16. https://github.com/opensourcepos/opensourcepos/blob/3.4.1/app/Controllers/Cashups.php#L110-L178 · retrieved 2026-09-16 adversarially verified
Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.
reporting-labor-productivity
No clocked hours exist in the system, so sales-per-labor-hour cannot be computed. https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator
reporting-server-scorecards
No packaged per-employee scorecard report documented. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator
reporting-channel-profitability
Only one fulfillment channel exists. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.
reporting-scheduled-delivery
Reports are exported manually to spreadsheet; no scheduling or recipient lists documented. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator
reporting-public-api
Held to the highest bar as instructed and confirmed. No API controllers or endpoints are documented anywhere in the wiki, and a REST API remains an open, unimplemented feature request on the tracker (issue #2463, plus #1400 requesting an outbound REST call on card payment). The related no-scores (webhooks, order-injection, menu-write, OAuth, rate limits, headless) all follow. https://github.com/opensourcepos/opensourcepos/issues/2463 · retrieved 2026-08-01 adversarially verified
Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator
reporting-webhooks
https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator
reporting-api-not-upcharged
No API exists to charge for, but raw data access is total and free via direct database access — nothing is paywalled because there is no paywall. https://github.com/opensourcepos/opensourcepos/wiki/Database-Layout · retrieved 2026-08-01
Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator
reporting-tier-paywall
Single free edition; every report and module ships in the same MIT-licensed build with no tiers or add-on SKUs. https://opensourcepos.org/ · retrieved 2026-08-01
Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator
reporting-history-retention
Self-hosted, so retention is unlimited and operator-controlled with no truncation or archive fee — but the project publishes no retention commitment because there is no service. https://github.com/opensourcepos/opensourcepos/wiki/Database-Layout · retrieved 2026-08-01
Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator
reporting-anomaly-alerts
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.
reporting-nl-query
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator
reporting-guest-cohorts
Customer records and sales history exist in the database but no packaged new-vs-returning or LTV cohort reporting is documented. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator
reporting-sales-forecast
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.
reporting-tip-tax-compliance
No tip capture exists. Tax reporting exists for sales tax/VAT/GST, not tips. https://github.com/opensourcepos/opensourcepos/wiki/Taxes · retrieved 2026-08-01
Multi-location, franchise & enterprise governance
Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.
multi-location-org-hierarchy
One install = one business. "Multi-location" in the datasheet means stock locations for inventory, not an org hierarchy. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.
multi-location-price-zones
Same misreading as channel-price-books: the only documented tiering is taxation tiering, and one item carries one Retail Price. There is additionally no location construct to zone against — the datasheet states 'No multi tenancy with one deployment'. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.
multi-location-consolidated-reporting
Separate installs mean separate databases with no aggregation layer. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.
multi-location-cross-location-giftcard
Scored partial by inference from 'one shared database'. The criterion is cross-location, and OSPOS has no locations: 'No multi tenancy with one deployment'. Separate stores mean separate installs and separate gift-card tables. The vendor also disclaims 'Management of accounting gift cards', so no liability reporting exists either. A single-store install trivially sharing its own balances is not cross-location support. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.
multi-location-cross-location-loyalty
Identical inference chain, identical refutation: 'No multi tenancy with one deployment'. One customer table inside one store is not cross-location loyalty, and the vendor further disclaims 'expired dates on rewards'. https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md · retrieved 2026-08-01 adversarially verified
A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator
multi-location-multi-brand
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.
multi-location-multi-tax-jurisdiction
Strong single-location tax engine: multiple simultaneous rates, VAT/GST modes, customer tax tiers/exemptions, India GST support. Configuration is per-install, not per-location. https://github.com/opensourcepos/opensourcepos/wiki/Taxes · retrieved 2026-08-01
Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.
multi-location-central-labor-policy
No labor module exists. https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
"Any hardware running Firefox or a modern web browser. Works on mobile but PC/Mac is recommended." No proprietary terminal exists or is sold. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
Partial stands but two details in the note are wrong. Client requirements ARE version-named on the Minimum Server Requirements page (Firefox/Pale Moon 34+ ESR recommended, Chrome/Chromium 40+ supported, Safari/Edge 'Modern' may work), contradicting 'only a modern browser with no named versions'. Conversely the dossier's best_at overstates deployment breadth: IIS is documented as 'May work', not supported, and Apache 2.4+ is the only 'officially supported' web server. Still partial: no client OS versions or device specs. https://github.com/opensourcepos/opensourcepos/wiki/Minimum-Server-Requirements · retrieved 2026-08-01 adversarially verified
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
No devices are sold and no handheld is named; mobile is a responsive browser view. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.
hardware-handheld-lte
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).
hardware-offline-mode
Browser client with no offline store; the project publishes no offline degradation matrix. A LAN-hosted server keeps working during an internet outage, but that is a deployment property, not a documented feature. https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
Multi-vendor by design: Star TSP 1431IU and Epson TM-88VI are the named recommendations, with printing mediated by browser/OS so any driver-installed printer works. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.
hardware-peripherals
Scanners: "Any scanner will work if programmed to hit return after scanning" (Datalogic QuickScan recommended). Cash drawers: "out of scope due to the system being web based", only via printer kick. No scales, no customer display. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
Credit card readers are listed as not supported; card entry happens entirely outside the application on the merchant's own terminal, and no SAQ guidance is published. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
No hardware is sold, so no SKU prices are published; recommended models are named without prices. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Ownership is the only model — the operator buys commodity hardware from any third party. No lease, rental or subscription-bundled hardware exists. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
Nothing to churn from: no vendor account, no device activation, no remote kill. Hardware is generic browser/printer/scanner gear the operator already owns. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
No hardware program, so no warranty or exchange SLA. Operator relies on the OEM's own warranty. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
Responsive UI runs in any phone browser and permissions are per-employee, but no BYOD security model (device trust, MDM, session policy) is documented and mobile scanning is unavailable. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator
hardware-remote-device-management
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Integrates with specialty beverage hardware — self-pour tap walls, flow meters, or liquor pour spouts — such that pours post to a POS tab automatically.
hardware-selfpour-scales
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.
hardware-callerid-integration
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
Developer docs are code-contribution oriented; no API reference exists. The substitute is the published database schema and MIT source. https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
No API to price. Nothing in the product is fee-gated, but the criterion asks about API access, which does not exist. https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator
extensibility-free-sandbox
The stated reason for partial is factually wrong: 'it is a local install, not a hosted sandbox with seeded data'. A free hosted demo instance is live at demo.opensourcepos.org with published credentials (admin/pointofsale) and seeded data, plus dev.opensourcepos.org tracking master, both advertised on the project homepage and README. I loaded the demo login page myself. Nothing is gated, no sales contact, no cost. (No API credentials exist because no API exists — that is the API cell's problem, not the sandbox cell's.) https://opensourcepos.org/ · retrieved 2026-08-01 adversarially verified
Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).
extensibility-oauth-partner-apps
Authentication is local employee username/password with reCAPTCHA; no OAuth, no scoped third-party grants. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator
extensibility-webhook-reliability
https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.
extensibility-order-injection-api
https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means when it says the roster is tracked in real time, and it is a CENSUS rather than a floor: every provider integrated with DoorDash appears in it with a tier, so a vendor that is absent altogether is not in the programme at any tier. This vendor appears nowhere in the 64 entries, under any provider id or friendly name — checked mechanically against both fields, with the only near-misses being substring coincidences (Speedline against Lightspeed, vroom_restaurant against Restaurant365) that were read and rejected. SUPERSEDES the 2026 announcement post most of this corpus cited: that post introduces its ten names with the word `include`, which makes it a floor and never a ceiling, and reading it as a ceiling is what produced this cell's prior grade. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11
Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator
extensibility-first-party-delivery-integrations
https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
OSPOS is not a listed endpoint for Deliverect, Chowly, Otter or Checkmate; it exposes no API for middleware to target. https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.
extensibility-accounting-connectors
Only Mailchimp and SMS are named third-party integrations; accounting export is generic spreadsheet. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.
extensibility-payroll-export
No hours are captured and no payroll provider is named. https://github.com/opensourcepos/opensourcepos/wiki/Employees · retrieved 2026-08-01
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
No marketplace. Community extensions, where they exist, are forks. https://opensourcepos.org/ · retrieved 2026-08-01
The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.
extensibility-headless-embedded
Monolithic CI4 app with server-rendered views; no headless transaction engine. https://github.com/opensourcepos/opensourcepos/wiki/Development-Index · retrieved 2026-08-01
A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator
extensibility-data-portability-exit
There is no exit — the operator already holds the source and the MySQL database. Full machine-readable export is a mysqldump, plus per-module spreadsheet exports in the UI. https://github.com/opensourcepos/opensourcepos/wiki/Database-Layout · retrieved 2026-08-01
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
No browser-side offline mode. A LAN-hosted install keeps registers working through an internet outage, but a lost LAN or server means no order entry. Not documented as an offline feature. https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
No card processing path exists at all. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator
reliability-offline-decline-liability
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator
reliability-lan-degraded-multi-terminal
All terminals are thin browsers against one LAN server, so shared check/table state survives an internet outage by construction — but the project does not document this as a degraded-mode feature and the server is a single point of failure. https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator
reliability-local-transaction-engine
The entire transaction engine is on-premise by default: PHP/CodeIgniter 4 plus MySQL on hardware the operator runs (documented for LAMP, LEMP, XAMPP, IIS, Docker and Raspberry Pi). https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
No KDS; receipt printing depends on the browser session reaching the server. https://github.com/opensourcepos/opensourcepos/wiki/Printing-support · retrieved 2026-08-01
The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.
reliability-printer-fallback
No printer routing engine, therefore no failover or alerting. https://github.com/opensourcepos/opensourcepos/wiki/Printing-support · retrieved 2026-08-01
The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).
reliability-sync-conflict-handling
Architecture makes it moot — a single central MySQL server means no partitioned edits to reconcile. No conflict policy is documented because none is needed. https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).
reliability-offline-feature-matrix
No offline feature matrix is published anywhere in the 50-page wiki. https://github.com/opensourcepos/opensourcepos/wiki · retrieved 2026-08-01
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
No hosted service exists to have a status page; uptime is the operator's own server. https://opensourcepos.org/ · retrieved 2026-08-01
24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.
reliability-247-live-support
Support is community-only: GitHub issues/PRs, Element/Gitter chat, wiki FAQ. No phone support at any price. https://opensourcepos.org/ · retrieved 2026-08-01
The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator
reliability-onsite-install
Self-install only, via written wiki guides for Docker/LAMP/LEMP/XAMPP/IIS/Ubuntu/Windows/Raspberry Pi. No first-party or dealer install network. https://github.com/opensourcepos/opensourcepos/wiki/Getting-Started-installations · retrieved 2026-08-01
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.
reliability-pci-dss-4-attestation
No AOC, no P2PE listing, no vendor entity to attest. Card data never enters the app because card readers are unsupported. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Role/module permissions per employee plus reCAPTCHA brute-force protection are documented; no MFA is documented for back-office or POS logins. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.
reliability-self-serve-training
Free public wiki with ~50 pages including Getting Started usage; no video/LMS library and no terminal training mode. Several wiki pages are marked "work in progress". https://github.com/opensourcepos/opensourcepos/wiki/Getting-Started-usage · retrieved 2026-08-01
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
Terminals are browsers; the single web/DB server is the master with no documented automatic failover. https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview · retrieved 2026-08-01
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Commercial, compliance & data ownership
Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator
commercial-month-to-month-contract
No subscription exists. MIT license, free download, stop using it at any time with zero notice or cost. https://raw.githubusercontent.com/opensourcepos/opensourcepos/master/LICENSE · retrieved 2026-08-01
Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator
commercial-no-early-termination-fee
No contract, no term, no fee of any kind. https://raw.githubusercontent.com/opensourcepos/opensourcepos/master/LICENSE · retrieved 2026-08-01
The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.
commercial-autorenew-terms-published
Publicly published terms (the MIT license) contain no renewal or cancellation-notice mechanism because there is no subscription. https://raw.githubusercontent.com/opensourcepos/opensourcepos/master/LICENSE · retrieved 2026-08-01
The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator
commercial-processing-not-bundled
No processing is bundled or available; the operator uses whatever merchant account and standalone terminal it likes. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
Not a processor; publishes no rates of any structure. https://opensourcepos.org/ · retrieved 2026-08-01
The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator
commercial-rate-increase-clause
No processing agreement exists to contain such a clause. https://opensourcepos.org/ · retrieved 2026-08-01
Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).
commercial-pricing-published
$0, published: free MIT download with unlimited terminals and users. Only donations are solicited. https://opensourcepos.org/ · retrieved 2026-08-01
Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator
commercial-module-unbundling
Every module ships in one free build and can be hidden per employee via Menu and Permissions; the Office menu can be toggled off entirely. Nothing to reprice. https://github.com/opensourcepos/opensourcepos/wiki/Menu-and-Permissions · retrieved 2026-08-01
All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.
commercial-hardware-purchase-outright
All hardware is commodity gear bought outright from third parties; no lease or rental exists. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator
commercial-hardware-not-locked
Everything is non-proprietary: any modern browser on PC/Mac/tablet, any return-programmed barcode scanner, Star or Epson ESC/POS receipt printers. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.
commercial-data-export-self-serve
Spreadsheet export on employees, items, customers and reports, plus unrestricted mysqldump against a documented schema. No support ticket, no fee. https://github.com/opensourcepos/opensourcepos/wiki/Database-Layout · retrieved 2026-08-01
Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator
commercial-export-customer-and-loyalty
Customer records export to spreadsheet; rewards and gift-card balances are operator-owned tables in the operator's own MySQL database. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator
commercial-post-termination-export-window
Not applicable in the operator's favor: there is no termination and no cutoff — the data never leaves the operator's server. https://raw.githubusercontent.com/opensourcepos/opensourcepos/master/LICENSE · retrieved 2026-08-01
Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator
commercial-data-ownership-clause
Self-hosted MIT software with no vendor telemetry or hosted service; the project never receives transaction or customer data and so cannot use or resell it. https://raw.githubusercontent.com/opensourcepos/opensourcepos/master/LICENSE · retrieved 2026-08-01
Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.
commercial-pci-p2pe-tokenization
No P2PE, no tokenization, no SAQ guidance. Card readers are explicitly unsupported, so PCI scope determination is entirely the merchant's own responsibility. https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet · retrieved 2026-08-01
Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.
commercial-pci-dss-4-controls
No MFA is documented for application logins and no script-integrity or PCI DSS 4.0.1 control documentation exists. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.
commercial-privacy-dsar-tooling
GDPR registration consent is captured on customer profiles and the operator can locate/export/delete records directly in MySQL, but no in-app DSAR workflow and no DPA (there is no processor to execute one with). https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator
commercial-wcag-kiosk-accessibility
No kiosk or consumer ordering surface exists, and no VPAT/ACR is published for the Bootstrap-based staff UI. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator
commercial-dual-pricing-compliant
No surcharge or cash-discount engine, and no card data in the app to classify debit vs credit. https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet · retrieved 2026-08-01
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 22 values — 12 upheld, 9 downgraded, 1 upgraded. It separately resolved 0 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Pricing and identity
| Field | Verdict | What the verifier found |
|---|---|---|
| pricing.software | upheld | Verified directly against the LICENSE file and the project homepage, not a roundup. Free under MIT, only a donation ask, no commercial edition and no paid support SKU found anywhere on opensourcepos.org. The footer-signature clause is correctly reported and is the only non-monetary condition. source |
| pricing.processing_rate | upheld | Verified verbatim in the hardware datasheet table: 'Credit Card Reader | Not supported' (and 'Digital Signature Capture | Not supported yet'). This is affirmative absence from first-party docs, so every downstream payments/offline-card no-score is properly grounded rather than merely undocumented. source |
| pricing.hardware | upheld | Verified. Note one unreported nuance: the recommended-hardware links are Amazon affiliate links ('Use our referral links to support the project!'), which is a small monetization channel the dossier's 'the only monetization is a donation link' claim misses. No prices are published and no hardware is sold, so the score is unaffected. source |
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| payments-house-accounts | partial | downgrade-to-no | The project's own feature datasheet lists this under 'What cannot do' verbatim: 'Accounts Receivable / House Accounts, OSPOS has CRM features but no A.R. features'. The researcher built a partial from the Payment-Processing page's balance-due mention, but that page itself admits balance-due tracking is still under development (#3072). Vendor-affirmed absence beats an inferred partial. source |
| reporting-realtime-dashboard | partial | downgrade-to-no | Datasheet cannot-do column, verbatim: 'There are reports, but no dashboard that shares Top Sales, Top Suppliers, Best Selling Items, Top Customers, etc. See #1433'. That is an affirmative statement of absence, not merely undocumented. Reports existing is not a dashboard, and there is no mobile app. source |
| labor-server-performance-metrics | partial | downgrade-to-no | Scored partial on 'derivable via SQL' reasoning with confidence 'inferred'. The vendor explicitly states there is no Top Sales / Best Selling / Top Customers reporting. Derivable-from-the-database is not a capability; by that standard nearly every cell in this dossier would be partial. source |
| menu-pricing-channel-price-books | partial | downgrade-to-no | The partial rests on 'customer price tiers'. I found no customer price tiers in any first-party doc. What the datasheet actually says is 'VAT and multi tiers taxation' under Customers, and the homepage says 'Multiple taxation options (VAT, GST, customer, multi-tier)'. That is tax tiering, not a price book. Item pricing is a single 'Items Price Management' entry with one Retail Price field per item (Items wiki: 'UPC/EAN/ISBN, Item Name, Category, Supplier, Cost Price, Retail Price, Tax 1, Tax 2, Quantity in stock'). This looks like a misreading of 'multi tiers taxation' as tiered pricing. source |
| multi-location-price-zones | partial | downgrade-to-no | Same misreading as channel-price-books: the only documented tiering is taxation tiering, and one item carries one Retail Price. There is additionally no location construct to zone against — the datasheet states 'No multi tenancy with one deployment'. source |
| multi-location-cross-location-giftcard | partial | downgrade-to-no | Scored partial by inference from 'one shared database'. The criterion is cross-location, and OSPOS has no locations: 'No multi tenancy with one deployment'. Separate stores mean separate installs and separate gift-card tables. The vendor also disclaims 'Management of accounting gift cards', so no liability reporting exists either. A single-store install trivially sharing its own balances is not cross-location support. source |
| multi-location-cross-location-loyalty | partial | downgrade-to-no | Identical inference chain, identical refutation: 'No multi tenancy with one deployment'. One customer table inside one store is not cross-location loyalty, and the vendor further disclaims 'expired dates on rewards'. source |
| order-capture-catering | partial | downgrade-to-no | Built from quotes plus invoices with balance due. But the datasheet's POS cannot-do column disclaims exactly the mechanisms a catering deposit flow needs: 'Advanced Transaction Types such as Special Orders, Back Orders and Layaways, Credit accounting sales', and separately 'no A.R. features'. A retail quote-to-invoice path with no deposit, no event date, no BEO and no credit sales is not a rough catering flow. source |
| kitchen-waste-logging | partial | downgrade-to-no | Partial credit was given for the Expenses module 'absorbing' waste. The datasheet says expenses are for 'basic expenses, no accounting needs' and that 'Accounting with expenses over the sales are out of scope'. There is no kitchen surface, no reason codes, no waste record type. This is a workaround, not a feature. source |
| extensibility-free-sandbox | partial | upgrade-to-yes | The stated reason for partial is factually wrong: 'it is a local install, not a hosted sandbox with seeded data'. A free hosted demo instance is live at demo.opensourcepos.org with published credentials (admin/pointofsale) and seeded data, plus dev.opensourcepos.org tracking master, both advertised on the project homepage and README. I loaded the demo login page myself. Nothing is gated, no sales contact, no cost. (No API credentials exist because no API exists — that is the API cell's problem, not the sandbox cell's.) source |
| menu-pricing-size-style-matrix | no | upheld | Upheld and strengthened. The researcher inferred this from the Items page; the datasheet states it outright in the cannot-do column: 'Inventory Matrix, Track items features, colors, materials'. This is one of the few 'no' scores that is affirmative absence rather than silence, and the confidence should read documented-explicit. source |
| inventory-par-auto-suggest | partial | upheld | Upheld on the fact but the citation is wrong and should be corrected. The cited Inventory-Items wiki page contains nothing about reorder levels — it covers module access and CSV import only. The supporting text is on the Items page, which lists 'reorder level' among item settings. Partial stands (reorder level exists, no forecast-driven suggested PO quantities). source |
| inventory-menu-margin-linkage | partial | upheld | Upheld, wrong citation again. Inventory-Items says nothing about cost. The Items page does enumerate 'Cost Price, Retail Price' per item, so per-item gross margin is computable; no packaged contribution-margin report exists, consistent with the vendor's own 'no dashboard / no Best Selling Items' admission. source |
| payments-split-tender | partial | upheld | Upheld, but not from the cited source. The Payment-Processing wiki page does not document split or multiple payments at all. The support is in the datasheet: 'apply multiple payments (inclusivelly different types) to the sale'. Partial is correct — multiple tenders yes, no split by seat, item or even shares. source |
| inventory-realtime-depletion | yes | upheld | Challenged as the dossier's most load-bearing 'yes' and it survives. Sales wiki, verbatim: 'At the point of sale all stock items are checked to see if there is sufficient quantity on hand to satisfy the sale', and 'If the Item Type is set to non-stock then the validation will not take place'. Item Kits wiki confirms components stay individually tracked ('The quantity of each item in the package can continue to be tracked as if it were not in the package'). Native, first-party, no add-on. source |
| inventory-unit-conversion-yields | unknown | upheld | Unknown is right, but the researcher missed the relevant evidence and used the wrong page. The Items wiki documents work-in-progress pack selling with 'Quantity per Pack', pack names such as CASE or CARTON, and a low-sell-unit reference — a real purchase-to-sell conversion, but explicitly under development and with no recipe units and no yield percentages. Unknown remains the honest score; the note should cite this rather than weighted barcodes. source |
| hardware-os-platforms | partial | upheld | Partial stands but two details in the note are wrong. Client requirements ARE version-named on the Minimum Server Requirements page (Firefox/Pale Moon 34+ ESR recommended, Chrome/Chromium 40+ supported, Safari/Edge 'Modern' may work), contradicting 'only a modern browser with no named versions'. Conversely the dossier's best_at overstates deployment breadth: IIS is documented as 'May work', not supported, and Apache 2.4+ is the only 'officially supported' web server. Still partial: no client OS versions or device specs. source |
| reporting-public-api | no | upheld | Held to the highest bar as instructed and confirmed. No API controllers or endpoints are documented anywhere in the wiki, and a REST API remains an open, unimplemented feature request on the tracker (issue #2463, plus #1400 requesting an outbound REST call on card payment). The related no-scores (webhooks, order-injection, menu-write, OAuth, rate limits, headless) all follow. source |
| extensibility-doordash-preferred | no / B, cites get.doordash.com preferred-integration-partners: "Not in DoorDash's 2026 Preferred Integration Partner cohort (Checkmate, Chowly, De..." | upheld | The cited URL is dead: it redirects to merchants.doordash.com and returns HTTP 404 at 428,095 bytes, byte-identical in size to a fabricated path in the same directory, so the large body is a soft-404 shell rather than the article. I located the successors via merchants.doordash.com/sitemap-0.xml: the program is now documented at /en-us/learning-center/doordash-preferred-integrations-program (HTTP 200, real body) and it directs readers to the integrations page for the roster. The integrations page payload names its Preferred Partners explicitly (Qu, Toast, ChowNow/Cuboh, Chowly, Deliverect, PAR, Square, Checkmate, Stream, Otter, UrbanPiper, OrderOut, MYR, Crisp, RPOWER, Peppr, MOBI, SpotOn, FoodTec, Meal.co); Open Source POS is absent and no case-insensitive form of its name occurs. That is a live enumeration, which is the positive evidence of absence a `no` requires. Value unchanged; citation re-pointed and the note's stale ten-name cohort corrected. source |
Sources
Every URL this record cites. 32 in total.
- https://github.com/opensourcepos/opensourcepos/wiki/Sales-Restaurant
- https://github.com/opensourcepos/opensourcepos/wiki/Complete-feature-datasheet
- https://github.com/opensourcepos/opensourcepos/wiki/Supported-hardware-datasheet
- https://github.com/opensourcepos/opensourcepos/wiki/Webserver-Overview
- https://github.com/opensourcepos/opensourcepos/wiki/Development-Index
- https://github.com/opensourcepos/opensourcepos/wiki/Work-Orders
- https://raw.githubusercontent.com/wiki/opensourcepos/opensourcepos/Complete-feature-datasheet.md
- https://github.com/opensourcepos/opensourcepos/wiki/Menu-and-Permissions
- https://github.com/opensourcepos/opensourcepos/wiki/Item-Attributes
- https://github.com/opensourcepos/opensourcepos/wiki/Item-Kits
- https://github.com/opensourcepos/opensourcepos/wiki/Sales
- https://github.com/opensourcepos/opensourcepos/wiki/Items
- https://opensourcepos.org/
- https://github.com/opensourcepos/opensourcepos/wiki/Payment-Processing
- https://github.com/opensourcepos/opensourcepos/wiki/Printing
- https://github.com/opensourcepos/opensourcepos/wiki/Printing-support
- https://github.com/opensourcepos/opensourcepos/wiki/Employees
- https://github.com/opensourcepos/opensourcepos/wiki/Stocktake
- https://github.com/opensourcepos/opensourcepos/wiki/Purchasing
- https://github.com/opensourcepos/opensourcepos/wiki/Import-data-from-CSV-file
- https://github.com/opensourcepos/opensourcepos/wiki/Expenses
- https://github.com/opensourcepos/opensourcepos/issues/2463
- https://github.com/opensourcepos/opensourcepos/wiki/Database-Layout
- https://github.com/opensourcepos/opensourcepos/wiki/Taxes
- https://github.com/opensourcepos/opensourcepos/wiki/Minimum-Server-Requirements
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026
- https://github.com/opensourcepos/opensourcepos/wiki
- https://github.com/opensourcepos/opensourcepos/wiki/Getting-Started-installations
- https://github.com/opensourcepos/opensourcepos/wiki/Getting-Started-usage
- https://raw.githubusercontent.com/opensourcepos/opensourcepos/master/LICENSE
- https://merchants.doordash.com/en-us/integrations
- https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program