NexoPOS

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

Gastro creates tables and areas in list form with a visual occupancy overview. Graphical drawing of tables/chairs is an open roadmap issue. https://github.com/Blair2004/NexoPOS/issues/2319 · 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

Gastro's documented table operations are move/merge/split between tables. No seat concept appears in docs or source. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

Gastro kitchen states are in-preparation / ready / rejected per item. No course assignment or fire action. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

Verified against the Gastro item page myself: 'Move/merge/split orders between tables', areas-as-tables, visual overview of tables and active orders — no seat concept, no split by amount or share. Same page independently upholds kitchen-station-routing=partial (categories → kitchens, e.g. Drinks→Bar), kitchen-sla-alerts=no ('organized by priority or time, with notifications for new requests' only), kitchen-recall-refire=no (states are in-preparation/ready/rejected), menu-pricing-nested-modifiers=no (one level, single-or-multiple choice, optional quantity) and order-capture-floor-plan-editor=no https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · retrieved 2026-09-17 adversarially verified

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 exists in the product, so no pre-authorization is possible. https://my.nexopos.com/en/documentation/user-guide/orders/managing-payment-type · 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

Table-to-table order transfer documented; no audit-log entity exists in source to record both employees. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

Product is a browser app plus an Android barcode utility and a Windows desktop app. No handheld ordering device or app. https://my.nexopos.com/en/marketplace · 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

The marketplace blurb is real, but the item page explains what it actually is: a bundled Nginx + PHP + SQLite local server with HTTPS, i.e. self-hosting on one Windows box. That is a deployment mode, not offline order capture. The web client has no offline layer at all — public/ contains no service worker and no web manifest (only .htaccess, build, css-manifest.json, mix-manifest.json, images, svg, fonts, web.config). Lose the link to the server and the terminal has nothing. Scoring this as partial reads a hosting installer as an offline feature. https://my.nexopos.com/en/marketplace/item/nexopos-for-windows · retrieved 2026-08-01 adversarially verified

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 surface; the Store Front module is an open roadmap issue. https://github.com/Blair2004/NexoPOS/issues · 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

No kiosk product in the marketplace or docs. https://my.nexopos.com/en/marketplace · 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

Documented order types are Take Away and Delivery only. https://my.nexopos.com/en/documentation/user-guide/sales/order-type · 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

Proposition: drive-thru speed-of-service timers captured and reported by segment (order, total, window) against individual orders. OrdersService::getTypeOptions() is the product's complete order-type list and contains exactly two entries, 'takeaway' (Take Away) and 'delivery' (Delivery) - no drive-thru lane exists to time. OrdersService::getProcessStatuses() is the whole kitchen-facing vocabulary and is four unordered labels (pending / ongoing / ready / not-available) with no elapsed-time or segment semantics, and the orders table (database/migrations/create/2020_06_20_000000_create_orders_table.php) carries only Laravel's created_at/updated_at - no order_placed_at, window_at, ready_at or promised_at column on which a segment timer could be computed. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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 voice agent. The core ships an MCP server for AI data access, which is not order capture. An 'Oxen AI' module is an open roadmap issue. https://github.com/Blair2004/NexoPOS/tree/master/app/Mcp · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Proposition: per-channel capacity limits per time slot with automatic quote-time extension once kitchen load crosses a threshold. NexoPOS v6.2.2 has no channel axis to limit: OrdersService::getTypeOptions() enumerates two order types (takeaway, delivery) and the core ships no ordering channel other than the cashier POS screen - there is no storefront, kiosk or marketplace intake anywhere in the tree. There is likewise no quote time: the order schema has no promised_at or prep-duration column, and OrdersService::getProcessStatuses() carries no time value. The only throttling in the product is Laravel HTTP rate limiting (app/Http/Middleware/ThrottleMiddelware.php extends Illuminate\Routing\Middleware\ThrottleRequests, and routes/ai.php applies 'throttle:mcp'), which limits API requests per minute, not kitchen load. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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

CLAIM: accepts future-dated/scheduled orders with a per-channel lead time and fires them into the make queue at a computed time. VERDICT: no. EVIDENCE: the order-type doc enumerates the order types: "By default, NexoPOS supports 2 order types : | Take Away | Delivery" (Gastro adds dine-in), with no date/time attribute. The core Order model's full @property block (app/Models/Order.php) is id, description, code, title, type, payment_status, process_status, delivery_status, discount fields, shipping fields, totals, tax fields, tendered, change, final_payment_date, total_instalments, customer_id, note, note_visibility, author_id, uuid, register_id, voidance_reason, created_at, updated_at - no scheduled/fire/pickup time (final_payment_date belongs to instalments, per user-guide/orders/orders-with-instalments). SOURCE: git clone --depth 1 of github.com/Blair2004/NexoPOS at 6061a93 (2026-08-25, config/nexopos.php version 6.2.2), 3,536 tracked files. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. BOUND/CONTROLS over the 318 pages: "scheduled orders?" 0, "pre-?orders?" 0, "future orders?" 0, "order later" 0, "fire time" 0, "lead time" 1 (Bellsera spa booking reminder, not food orders). POISON named: "scheduled" 31 hits in 12 files are all Nexo SaaS billing lifecycle jobs, scheduled expense transactions, scheduled stock counts or a promo end date; "pickup" 16 hits are the Take Away definition and the NexoPOS Rental module's equipment pickup/return dates; "future" 8 hits are prose. The Gastro and QR Menu listings (the only restaurant ordering modules among the 32 marketplace items) mention no scheduling. Retrieved 2026-09-16. https://my.nexopos.com/en/documentation/user-guide/sales/order-type · retrieved 2026-09-16 adversarially verified

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

Instalments and partially-paid orders provide a deposit-like mechanic, but there is no catering flow, quote or event schedule. https://my.nexopos.com/en/documentation/user-guide/orders/orders-with-instalments · retrieved 2026-08-01

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

Proposition: an order-ready signal pushed back to a third-party marketplace from POS or KDS state. There is no third-party marketplace connection to push to: the GPL core at v6.2.2 contains zero occurrences of DoorDash, Uber Eats, Grubhub or Deliveroo on word boundaries across app, routes, database, config, resources/ts and the 3,412-key UI string table lang/en.json, and the saved docs.api.nexopos.com reference (121 headings) has no marketplace, partner or callback section. The core does record readiness - OrdersService::getProcessStatuses() returns pending/ongoing/ready/not-available and POST api/orders/{id}/processing sets it - but it is a local status only; the product publishes no webhooks (product.yaml api_posture.webhooks: None) so there is no outbound mechanism at all. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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

Granular role permissions gate actions and a one-time passcode for discounts was added in v6. No reason codes, no exception report, no audit-log entity. https://my.nexopos.com/en/documentation/developers-guide/roles-permissions/creating-permissions · retrieved 2026-08-01

Supports modifier groups nested at least three levels deep, each level with independent min/max selection counts and a forced-selection (required) flag.

menu-pricing-nested-modifiers

Gastro documents a single level: modifier groups with single-or-multiple choice and optional quantity, assigned to a product. No nesting, no min/max, no forced-selection flag. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · retrieved 2026-08-01

A single modifier can carry different prices depending on the parent item and the selected size, configured as a matrix rather than by duplicating the modifier.

menu-pricing-modifier-price-by-parent-size

Modifiers act as products with their own price; no per-parent or per-size price matrix. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · retrieved 2026-08-01

Supports fractional/sectioned modifier placement (at minimum halves, ideally quarters) with independent pricing per section. differentiator

menu-pricing-fractional-placement

Proposition: fractional/sectioned modifier placement (halves or quarters) with independent pricing per section. The GPL core at v6.2.2 has no modifier concept at all - 'modifier' appears in 0 files across app, routes, database, config, resources/ts and lang/en.json - so there is no object that could carry a section. The order line schema in app/Models/OrderProduct.php is fully enumerated in its docblock (product_id, unit_id, unit_quantity_id, quantity, discount, unit_price, tax fields, total_price, uuid, status) with no section, placement, portion or fraction attribute, and 'topping', 'quarter' and 'section-placement' are 0 across the tree and 0 in the 121-heading API reference. Modifiers in NexoPOS are supplied by the paid Gastro module on the robots-barred my.nexopos.com; this record's already-cited menu-pricing-nested-modifiers cell records Gastro's model as flat modifier groups with an optional quantity, which has no section axis. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/OrderProduct.php · retrieved 2026-09-05 adversarially verified

The half-and-half pricing rule is operator-configurable among at least two of: charge the higher-priced half, average the halves, or charge each topping at a fraction of full price. differentiator

menu-pricing-half-and-half-rule

Proposition: an operator-configurable half-and-half pricing rule (higher half / average the halves / fraction of full price). This presupposes the sectioned placement that the preceding cell establishes does not exist in the readable product: the core has no modifier entity (0 files), no half or quarter concept, and app/Models/OrderProduct.php enumerates the whole order-line schema with no section or portion field. There is correspondingly no setting: the complete settings surface is 25 files under app/Settings (General, Orders, POS actions/features/layout/printing/registers/scale-barcode/shortcuts/vat, Invoice, Customers, Accounting, Reports, Media, Reset, Workers) and none defines a pricing rule for split items. The 121 headings of docs.api.nexopos.com contain no 'half', 'fraction' or 'portion' string. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/OrderProduct.php · retrieved 2026-09-05 adversarially verified

Supports modifier quantity tiers (light / regular / extra / double) with a configurable price multiplier per tier, distinct from adding the modifier twice.

menu-pricing-topping-quantity-tiers

Modifier groups can require a quantity, equivalent to adding the modifier N times. No light/regular/extra tier with price multiplier. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · retrieved 2026-08-01

Item base price can be defined as a grid across two variant axes (e.g. size x crust/preparation) with a per-cell price override. differentiator

menu-pricing-size-style-matrix

Products carry per-unit prices via unit groups (one axis, e.g. size). No second axis, no per-cell override. https://my.nexopos.com/en/documentation/user-guide/units-of-measure/creating-unit-group · retrieved 2026-08-01

Items can define an included-modifier allowance (e.g. three toppings included) that automatically charges only for overage and credits or forbids substitutions per configuration. differentiator

menu-pricing-included-allowance

Proposition: an included-modifier allowance (e.g. three toppings included) that charges only for overage and credits or forbids substitutions per configuration. The core's only item-composition entity is ProductSubItem (table nexopos_products_subitems), whose complete field list is parent_id, product_id, unit_id, unit_quantity_id, quantity, sale_price, total_price, author_id - a fixed bundle with a fixed component price. There is no included-count, no allowance, no overage rule and no substitution-credit field; 'allowance' is 0 files across app, routes, database, config, resources/ts and lang/en.json, as is 'modifier'. Included-modifier allowances would have to hang off a modifier system the GPL core does not have; modifiers are supplied by the paid Gastro module on the robots-barred my.nexopos.com. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/ProductSubItem.php · retrieved 2026-09-05 adversarially verified

Supports combo/meal construction where components can be swapped with a price delta, and the system can automatically detect and convert eligible a-la-carte items in the cart into the combo price.

menu-pricing-combos

Grouped Products bundle components into one sellable item. No component swap with price delta and no automatic a-la-carte-to-combo detection. https://my.nexopos.com/en/documentation/user-guide/products/create-grouped-products · retrieved 2026-08-01

Upsell/suggestive-sell prompts can be configured per item and per channel (POS, kiosk, online), and the vendor reports attach-rate on those prompts. differentiator

menu-pricing-upsell-prompts

Proposition: per-item, per-channel upsell prompts plus vendor-reported attach rate. Neither half exists. 'upsell' is 0 files across app, routes, database, config, resources/ts and the 3,412-key lang/en.json, and 0 in the 121-heading docs.api.nexopos.com reference. On the reporting half, database/permissions/reports.php is the vendor's own complete enumeration of the shipped report set - See Sale Report, See Products Report, See Best Report, See Transaction Report, See Yearly Sales, See Customers, See Inventory Tracking, See Customers Statement, Read Sales by Payment Types, Read Low Stock Report, Read Stock History - eleven reports, none of which measures prompt attach rate. There is also no channel axis to configure a prompt per: the core ships only the cashier POS screen (kiosk 0 files, no storefront code). https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/permissions/reports.php · retrieved 2026-09-05 adversarially verified

A single 86 action propagates automatically to POS, KDS, the vendor's own online ordering, kiosk, and connected third-party marketplaces, with a documented propagation latency.

menu-pricing-86-propagation

Proposition: one 86 action propagating to POS, KDS, first-party online ordering, kiosk and connected marketplaces with a documented latency. NexoPOS's availability mechanism is a single stock-driven POS-grid filter: the setting ns_pos_hide_exhausted_products ('Hide Exhausted Products' - 'Will hide exhausted products from selection on the POS'), with a companion ns_pos_hide_empty_categories. It has no propagation target, because the readable product has no other surface: 0 files match storefront|store.?front|online.?order|webshop|ecommerce, 0 match kiosk, and 0 match doordash|uber.?eats|grubhub|deliveroo across app, routes, database, config, resources/ts and lang/en.json. No latency is documented because there is no cross-surface hop. The kitchen surface itself is the paid Gastro module on the robots-barred my.nexopos.com. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Settings/pos/features.php · retrieved 2026-09-05 adversarially verified

Supports per-item countdown/par counts that decrement on sale and automatically 86 the item at zero, with a scheduled auto-restore. differentiator

menu-pricing-countdown-auto-86

Stock quantity gates POS visibility and low-stock notifications exist, but no per-item countdown/par with auto-86 and scheduled restore. https://my.nexopos.com/en/documentation/user-guide/products/low-stock-notification · retrieved 2026-08-01

Menus, individual items, and prices can be scheduled to activate and deactivate automatically by day and time in the location's own timezone.

menu-pricing-dayparting

Proposition: menus, items and prices scheduled to activate and deactivate automatically by day and time in the location's timezone. The core does have a time-window mechanic, but it is on discounts, not on menus, items or prices: app/Models/Coupon.php declares valid_until, valid_hours_start and valid_hours_end, so a coupon can be limited to an hours-of-day window (and there is no day-of-week axis even there). The price-carrying entity, ProductUnitQuantity, has no date or window field in its full property list (sale_price, wholesale_price, custom_price, cogs, barcode, scale_plu, low_quantity, expiration_date - an expiry date for stock, not a price schedule), and app/Models/Product.php has no availability window either. There is no menu entity at all in the core. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/Coupon.php · retrieved 2026-09-05 adversarially verified

Supports distinct price books per channel (dine-in, pickup, delivery, kiosk, each third-party marketplace) including percentage-markup rules applied to a base price rather than manual per-item entry.

menu-pricing-channel-price-books

Customer groups can carry differentiated pricing — a customer axis, not a channel axis. No per-channel price books. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · retrieved 2026-08-01

Supports dual pricing / cash-discount at the item level with the card price displayed as the base price, applied consistently across POS, kiosk, and online ordering, and printed on the receipt. differentiator

menu-pricing-dual-pricing

Proposition: item-level dual pricing / cash discount with the card price shown as base, applied across POS, kiosk and online, and printed on the receipt. Dual pricing requires the price to vary by tender, and NexoPOS's tender entity cannot carry a differential: app/Models/PaymentType.php (table nexopos_payments_types) exposes only active, readonly and accounting_account_id with an author and an accounting account - no rate, fee, percentage or discount field. Nothing in the tree matches 'cash discount', 'dual pricing', 'non-cash' or 'convenience fee' (0 files each across app, routes, database, config, resources/ts and the 3,412-key lang/en.json); 'surcharge' matches 1 file, two comment lines in resources/ts/pos-init.ts about a room fee on a service line. The product also integrates no card processing at all (its own docs: 'Creating a payment type does not automatically connect NexoPOS to an external payment provider'), so there is no card price to price against, and there is no kiosk or online surface to apply it consistently across. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/PaymentType.php · retrieved 2026-09-05 adversarially verified

Stores allergen flags and nutrition values per item and publishes them to online ordering and third-party menus, and can derive nutrition from linked recipe components rather than manual entry.

menu-pricing-allergen-nutrition

Product creation documentation enumerates no allergen or nutrition fields. https://my.nexopos.com/en/documentation/user-guide/products/create-product · retrieved 2026-08-01

Menu items and modifiers can be linked to recipes/bills of materials so that a sale depletes theoretical inventory and yields item-level theoretical food cost. differentiator

menu-pricing-recipe-linkage

The only evidence is a marketplace sales page for a closed-source $20 module ('Automatic Stock Deduction', 'Recipe Builder', 'Cost Tracking'). That is marketing copy, not product documentation — there is no Raw Material Tracker section in the documentation library and no source to inspect. The item page also shows Downloads: 2 and 5 ratings, so there is essentially no independent corroboration. Claim-level, so partial at best on a weighted differentiator. https://my.nexopos.com/en/marketplace/item/raw-material-tracker · retrieved 2026-09-17 adversarially verified

Pushes menus to third-party marketplaces through a certified direct integration (not scraping or a menu-management middleman) and surfaces per-item sync status and rejection errors to the operator.

menu-pricing-3p-menu-push

Proposition: certified direct menu push to third-party marketplaces with per-item sync status and rejection errors surfaced to the operator. No marketplace integration exists to push to: DoorDash, Uber Eats, Grubhub and Deliveroo are 0 files each on word boundaries across app, routes, database, config, resources/ts and lang/en.json; the complete API route set is 27 files under routes/api (categories, crud, customers, dashboard, fields, forms, marketplace, medias, modules, notifications, orders, permissions, procurements, products, providers, registers, reports, reset, rewards, scan-utility, settings, system, taxes, transactions, units, update, users) with no partner or channel router, and routes/api/marketplace.php is the NexoPOS paid-module store, not a food marketplace. The 121-heading docs.api.nexopos.com reference has no menu-sync section, and the product publishes no webhooks, so there is no error channel either. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

Supports rule-based dynamic pricing where item price varies automatically by time, demand, or channel, with configurable floor/ceiling guardrails.

menu-pricing-dynamic-pricing

A Dynamic Pricing module is an open roadmap issue, not a shipped product. https://github.com/Blair2004/NexoPOS/issues · retrieved 2026-08-01

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

No in-house processing lock — any external terminal works — but no gateway integration and no supported-processor list. Payment types only record how money arrived. https://my.nexopos.com/en/documentation/user-guide/orders/managing-payment-type · 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

Proposition: the vendor publishes a specific card-processing rate. NexoPOS is not an acquirer and processes no card, so no rate exists to publish. OrdersService's payment check builds its variable, literally named $allowedPaymentsGateways, from PaymentType::active()->map(identifier) — the 'gateways' are nothing but operator-created label rows in nexopos_payments_types, validated by string membership and then summed. There is no authorization, no capture, no HTTP call to any processor. composer.json's 31 require entries name no Stripe/Adyen/Square/PayPal/Braintree SDK, and a word-boundary search for stripe|braintree|adyen|paypal|worldpay|authorize.net|mollie|razorpay|payfast|flutterwave|paystack over app/, config/, composer.json and resources/ts returns zero. Consistent with the record's already-verified grade-A commercial-processing-not-bundled. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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

Proposition: two prices per item, with both cash and card totals printed on the guest check and receipt. The core does store three prices per sellable unit — sale_price, wholesale_price and custom_price, each with _edit/_net/_gross/_tax siblings — but this is a manual cashier price-mode toggle, not a tender-linked dual price: app/Settings/pos/features.php gates it behind the ns_pos_allow_wholesale_price switch ('Define if the wholesale price can be selected on the POS.') and ns-pos-cart.vue:775 requires the nexopos.cart.product-wholesale-price action permission per line. Nothing binds a price mode to a tender: nexopos_orders_payments has no card-type column and nexopos_orders carries a single total. No receipt prints two totals. Word-boundary 'cash discount' and 'dual pric' each return 0 files over app, routes, database, lang/en.json, config and resources/ts. The paid module catalogue at my.nexopos.com/en/marketplace — the endpoint the core itself calls at app/Services/MarketplaceService.php:58 — is robots-barred to this corpus, so what a paid module adds is a question we cannot ask; this verdict is about the shipped GPL core. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_products_unit_quantities.php · retrieved 2026-09-05 adversarially verified

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

Proposition: a surcharging engine with BIN/product-code debit-and-prepaid exclusion, network cap enforcement and a per-location toggle. The word 'surcharge' occurs in exactly two places in the scored tree, both prose comments in resources/ts/pos-init.ts describing a once-per-line 'line_extra' amount ('an appointment room fee attached to a service line'), i.e. a flat per-line fee hook for modules, not a card surcharge. Card-type exclusion is impossible here: NexoPOS never sees a card, so no BIN or product code exists to test — the 365 distinct column names across all 96 migrations contain no card, pan, bin, cvv, last4 or masked column. No per-location scope either; multi-location is the separate paid Multistore module. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.

payments-emv-nfc

Proposition: the vendor's first-party payment terminals accept EMV chip and NFC including Apple Pay and Google Pay. The vendor's own enumeration of its ecosystem is core + official modules + mobile companion apps + desktop utilities + developer tools + documentation + services — hardware is not a category it sells, so there are no first-party terminals for the claim to be about. Corroborating absence over the tree: word-boundary emv, nfc, contactless, 'apple pay' and 'google pay' each return 0 files repo-wide. Census basis: the v6.2.2 tag (commit 6061a93cf2d3fa0e0fb2896873315485fccc4ba1) checked out whole; 96 migration files yield 365 distinct column names and lang/en.json holds 3,412 UI strings. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/README.md · retrieved 2026-09-05 adversarially verified

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

Proposition: contactless acceptance directly on a phone with no separate reader. Foreclosed by the payment schema: nexopos_orders_payments has exactly seven columns — id, order_id, value, author_id, identifier, uuid, timestamps — and only two later migrations ever touch the table (an author-column rename and a float-to-decimal conversion), neither adding a column, so this create migration is the whole schema. A payment is an amount recorded against a label; there is no card-present, entry-mode, reader or authorization field anywhere to carry a tap. Word-boundary 'tap to pay' and 'contactless' return 0 files repo-wide. The paid module catalogue at my.nexopos.com/en/marketplace — the endpoint the core itself calls at app/Services/MarketplaceService.php:58 — is robots-barred to this corpus, so what a paid module adds is a question we cannot ask; this verdict is about the shipped GPL core. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_orders_payment_table.php · retrieved 2026-09-05 adversarially verified

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

Proposition: a vendor handheld taking EMV/NFC payment at the table, with tip prompt and check splitting. The vendor's complete first-party mobile line-up is two apps, both named in README.md's Mobile Applications section: Barcode Utility (turns a phone into a wireless barcode scanner) and NexoPOS Authorizer (grants sensitive-action permission via a QR code). Neither takes payment, and the vendor sells no handheld. The other two conjuncts also fail in core: 'tip' has zero occurrences in the 3,412-key lang/en.json and zero in any PHP, TypeScript or migration file, and seat/item check splitting is already recorded as absent at payments-split-tender. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/README.md · retrieved 2026-09-05 adversarially verified

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

Proposition: a guest scans a QR on the check or table tent, views and pays from their own phone, and the payment closes the check automatically. NexoPOS does generate QR codes — simplesoftwareio/simple-qrcode is a composer dependency — but every QR surface in the product is enumerable and none is guest payment. All seven QR strings in the 3,412-key lang/en.json are: API-token handoff ('This QR code is provided to ease authentication on external applications.'), manager permission escalation ('Access to this feature requires temporary permission from an administrator. Scan the QR code to proceed.'), wireless barcode-scanner pairing, plus 'Scan QR Code', 'Generating QR...', 'Failed to generate QR code' and 'The QR code was copied'. Guest payment is separately foreclosed by the absence of any card capture. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/popups/ns-token-output-popup.vue · retrieved 2026-09-05 adversarially verified

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

Proposition: both pre-auth-then-tip-adjust and on-device tip prompt, with a documented batch/adjust window and a manager screen for unadjusted tips. Every conjunct fails at the schema. nexopos_orders_payments stores id, order_id, value, author_id, identifier, uuid and timestamps — no tip, no pre-auth amount, no adjusted amount, no batch id. nexopos_orders carries tendered and change but no tip column. The documented API request body for POST api/orders/{order}/payments is exactly {identifier, value, register_id}. Pre-authorization is impossible in any case since the product performs no card authorization. The uncited rationale is upheld, now with documents. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_orders_payment_table.php · retrieved 2026-09-05 adversarially verified

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

Proposition: configurable tip pooling and distribution rules producing a per-employee allocation exportable to payroll. Both required inputs are absent from the core. (1) No tip is ever captured: no tip column among the 365 distinct migration columns and zero '\btip' occurrences in the 3,412-key English UI string table. (2) No labour substrate to allocate against: word-boundary payroll, timeclock and 'time clock' each return 0 files repo-wide, and there is no shift or hours-worked table. The nexopos_orders money fields are exhaustively discount, shipping, tax, subtotal, the totals, tendered and change. The paid module catalogue at my.nexopos.com/en/marketplace — the endpoint the core itself calls at app/Services/MarketplaceService.php:58 — is robots-barred to this corpus, so what a paid module adds is a question we cannot ask; this verdict is about the shipped GPL core. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_orders_table.php · retrieved 2026-09-05 adversarially verified

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

Proposition: card payments captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. The POS is a Vue SPA with no local persistence: every order, including its payments array, is submitted synchronously to the Laravel server at pos-init.ts:1145. There is no service worker (public/build/manifest.json is Vite's asset manifest, not a PWA manifest), no IndexedDB or localforage, and no queue-and-replay path. Word-boundary 'offline' returns 0 files across app, routes, database, lang/en.json, config and resources/ts; repo-wide it hits only two vendored bundles (Pusher and socket.io transport listeners under public/build/assets) and CODE_OF_CONDUCT.md. And there is no card capture to defer in the first place. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

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

Proposition: the vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect failed-payments report. There is no store-and-forward feature to have a liability policy about: the order submit path is a single synchronous HTTP call with no local queue, and no card is ever authorized. Correspondingly the API reference's Orders section (27 endpoints, from Retrieve Orders through Delete Order Product) contains no offline, replay or failed-payment report endpoint, and lang/en.json holds no offline string among its 3,412 keys. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

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

No gift-card entity in source. Customer account credit is a house-account balance, not a bearer gift card. https://github.com/Blair2004/NexoPOS · retrieved 2026-08-01

House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.

payments-house-accounts

Customer Account tender, add/deduct credit, running balance, full account history (purchase, refund, funding, unfunding) and a customers-statement report. Per-account credit limits not documented. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · retrieved 2026-08-01

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

Docs state an order can contain one or multiple payment entries, so multi-tender works. Splitting by seat, item or even shares is not supported. https://my.nexopos.com/en/documentation/user-guide/orders/managing-payment-type · retrieved 2026-08-01

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

Role-based permissions gate refund/void/discount; no immutable audit log naming the approver. https://my.nexopos.com/en/documentation/developers-guide/roles-permissions/creating-permissions · 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

Proposition: an in-product dispute/chargeback dashboard listing open disputes with evidence submission assembled from the POS record. Nothing in the product models a dispute. Word-boundary 'chargeback' and 'dispute' each return 0 files across app, routes, database, lang/en.json, config and resources/ts, and 'chargeback' returns 0 files repo-wide. The 365 distinct migration column names contain no dispute, case or evidence column. The complete documented API surface (121 headings) has 27 Orders endpoints; the closest are 'Get Order Refunds' and 'Make Order Refund', which are merchant-initiated refunds, not issuer-initiated disputes. A dispute cannot arise anyway where the vendor is not in the card flow. https://docs.api.nexopos.com/ · retrieved 2026-09-05 adversarially verified

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

Proposition: tokenized card-on-file on a guest profile, reusable across online ordering, phone orders and in-store, with no PAN stored by the merchant. The tree contains exactly two token columns and neither is a payment token: personal_access_tokens.token (64 chars, Laravel Sanctum API bearer tokens) and users.activation_token (email account activation). No vault, no card table, no PAN/last4/expiry/brand column among the 365 distinct migration column names; the customer record carries an account credit balance (a house account, already scored at payments-house-accounts) but no stored instrument. Word-boundary 'card on file' returns 0 files repo-wide. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/2019_12_14_000001_create_personal_access_tokens_table.php · retrieved 2026-09-05 adversarially verified

Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator

payments-payout-timing

Proposition: the vendor publishes its deposit schedule and offers next-day or same-day/instant funding. NexoPOS holds and moves no merchant funds — a payment is an amount written against an operator-created label row, validated only by string membership in the active PaymentType identifiers, and posted to an accounting account. There is no settlement, batch, deposit or funding concept: word-boundary 'payout' returns 0 files across app, routes, database, lang/en.json, config and resources/ts, and no settlement or deposit column appears among the 365 distinct migration columns. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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

Proposition: the vendor provides point-to-point encryption and a current PCI DSS 4.x AoC or P2PE listing available to merchants on request. P2PE is foreclosed at the root: a NexoPOS payment type is an accounting label — label, identifier, priority, description, author, active, readonly, accounting_account_id and an incoming-effect enum — with no gateway, key, terminal or encryption field, and no cardholder data ever enters the system (no card/PAN/BIN column among the 365 distinct migration columns; no processor SDK among composer.json's 31 requires). Word-boundary 'p2pe' and 'pci dss' return 0 files repo-wide. Residual gate stated rather than glossed: whether an AoC PDF sits on my.nexopos.com is unreadable to this corpus, but the product half of the conjunction is provably false. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_05_25_131104_create_nexopos_payments_types_table.php · retrieved 2026-09-05 adversarially verified

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

Product categories are assigned to specific kitchens (Drinks to Bar, Grill to Main), routing only that category's items. No routing by item, order type or revenue center. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

Multiple kitchen screens supported but no expo screen consolidating across stations. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

Proposition: items assigned to courses, held, then fired to the kitchen on demand. The core's entire kitchen-facing vocabulary is one order-level status set, OrdersService::getProcessStatuses() = pending / ongoing / ready / not-available, driven by POST api/orders/{id}/processing in the API reference; there is no per-item state, no hold state and no fire action. app/Models/OrderProduct.php enumerates the order-line schema with no course, seat, hold or fire attribute. The kitchen screen itself is the paid Gastro module on the robots-barred my.nexopos.com, and this record's own order-capture-coursing-hold-fire cell already records Gastro's documented per-item states as in-preparation / ready / rejected with no course assignment or fire action, so the absence holds at both layers that can be read. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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

CLAIM: per-item cook times are configurable and the KDS staggers item start/display so an order finishes together. VERDICT: no. The robots gate the previous note named no longer exists, so the Gastro documentation was read. EVIDENCE: Gastro's own listing states the opposite dispatch model: "Core Features | Dedicated kitchen screen | Orders are sent instantly to kitchen | Multiple kitchens support | Assign categories to specific kitchens" and "The Gastro kitchen screen lets chefs view incoming orders in real time with item details, notes, and modifiers, then manage each item by marking it as in preparation, ready, or rejected. Orders are organized by priority or time". The vendor's restaurant use case repeats it: "Each item is automatically transmitted to the kitchen display in real time, ensuring immediate preparation without delays or miscommunication" (https://my.nexopos.com/en/use-case/restaurant-cafe). Core: Product.php declares no cook_time/prep_time/duration (prior note; 6.2.2 re-cloned at 6061a93). CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "cook(ing)? times?" 0, "prep(aration)? time" 1 (NexoPOS Rental equipment preparation, not food), "pacing" 0, "stagger(ed|s|ing)?" 0, "cours(e|es|ing)" 0. POISON: "fire/fired/firing" 4 hits and "timers?" 9 hits, none on Gastro/restaurant pages. SHORTFALL OF THE BOUND: Gastro's source is not public (not among Blair2004's 146 public GitHub repos), so this rests on the vendor's affirmative "sent instantly" / "immediate preparation" statements, not a code census. Retrieved 2026-09-16. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos/details · retrieved 2026-09-16 adversarially verified

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

Proposition: kitchen load throttling that paces or delays release of incoming digital orders, or extends quoted prep times, above a configured threshold. Both inputs are missing from the readable product. There are no incoming digital orders to pace: 0 files match storefront|store.?front|online.?order|webshop|ecommerce, kiosk is 0 files, and the marketplace connectors are 0 files each, so orders arrive at the cashier POS screen. There is no quoted prep time to extend: no duration field on Product or ProductUnitQuantity, and OrdersService::getProcessStatuses() is four untimed labels. And there is no threshold setting: the complete settings surface is 25 files under app/Settings and none defines a volume or ticket-time limit. The only 'throttle' code in the tree is Laravel HTTP rate limiting. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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

Proposition: pausing a store or 86ing an item from POS/KDS propagates the change back to DoorDash, Uber Eats or Grubhub. There are no connected marketplaces: those three names, plus Deliveroo, are 0 files each on word boundaries across app, routes, database, config, resources/ts and the 3,412-key lang/en.json, and the 121-heading docs.api.nexopos.com reference has no partner or callback section. There is also no store-pause concept - the availability levers in app/Settings/pos/features.php are ns_pos_hide_exhausted_products and ns_pos_hide_empty_categories, both local POS-grid filters driven by stock. With no outbound integration and no webhook surface in the product, nothing can propagate. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Settings/pos/features.php · retrieved 2026-09-05 adversarially verified

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

Proposition: bumping an order ready on the KDS sends an order-ready event back to the third-party marketplace so couriers dispatch on real readiness. The readiness state exists locally - OrdersService::getProcessStatuses() includes 'ready' and the API reference documents POST api/orders/{id}/processing - but there is no recipient and no transport. No marketplace name appears in the tree (0 files each for doordash, uber.?eats, grubhub, deliveroo), and the product ships no webhook or callback code at all; its own record notes the API reference has no event-subscription section, and the 169 event classes in app/Events are in-process Laravel events consumable only by PHP modules on the same server. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.

kitchen-bump-bar-hardware

Gastro's kitchen screen is a browser view; no bump-bar or keypad support and no supported-model list. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

CLAIM: an all-day view aggregating outstanding quantities per item/modifier across open tickets on a station. VERDICT: unknown (note refreshed; the robots gate the old note cited is gone). NEW SURFACE: Gastro's details + instructions pages and every restaurant blog post on my.nexopos.com were read. Gastro's kitchen screen description: "view incoming orders in real time with item details, notes, and modifiers ... marking it as in preparation, ready, or rejected. Orders are organized by priority or time, with notifications for new requests, and can be filtered per kitchen (e.g. bar or main kitchen)". That is a ticket view; it neither describes nor excludes an aggregate count screen, and it is a feature summary, not a screen enumeration. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "all[- ]day" 0, "aggregat(e|ed|es|ion)" 1 (Oxen tool search_product_sales, not kitchen), "outstanding" 8 (customer/account balances), "totals? (per|by) item" 0. Gastro source is not public, so the screen cannot be censused; not published as no. Retrieved 2026-09-16. || 322nd: NEW SURFACES (322nd): crt.sh %.nexopos.com lists ~330 names (mostly *.my.nexopos.com customer cloud tenants). Vendor hosts probed: docs.api.nexopos.com (already in the record sources; re-read against these cells) answers 200 - a Slate "API Reference" (661,908 B, one page) for the CORE REST API: Authentication, Categories, Customers, Customer Groups, Crud, Fields, Forms, Medias, Modules, Notifications, Products, Product Categories, User, Orders (create/update/void/refund/instalments/print/delivery status). It documents no Gastro/kitchen, Multistore, clock-in or report endpoint: "kitchen" 2 hits (a sample notification "Kitchen Print Failure" about kitchen printers), NsGastro only as an item in the List Modules sample response; "stores?" 0, "reports?" 0, "offline" 0, "clock" 0. gastro.nexopos.com, v4-gastro, v4-multi, v46x, v48x, platform, cloud, api, server, ws do not answer; demo.nexopos.com and dev.nexopos.com 404; Wayback CDX for gastro.nexopos.com holds only a 2017 v3 sign-in page and AdminLTE assets (no app source); the others have no captures. The paid Gastro and Multistore modules have no vendor-published source (GitHub search: only third-party copies, not used). Still unknown. Retrieved 2026-09-17. || 330th: 330th, NEW SURFACE (still unknown): the Gastro item page's screenshots live inside an EditorJS JSON blob (data-initial-tab-data), not in <img> tags, so prior passes never opened them. Five were downloaded and READ AS IMAGES 2026-09-18, incl. the one the vendor labels 'Dedicated Kitchen Screen' (nimshot-2026-04-19-122914-j0hff.jpg): it shows a per-ORDER card layout - heading 'First Kitchen', 'No description is provided.', then a card '#210427-001 | 11 hours ago | Table: Stage 1 Table 1 | Type: Dine In' with one line item 'Spinaci Bolliti (Piece)' carrying a 'Pending' badge and per-card 'Cancel' / 'Start' buttons. No aggregate quantity panel, no per-item totals row, no item/modifier roll-up appears in the vendor's own picture of the screen; the 'Create a new kitchen' form screenshot (nimshot-2026-04-19-123201-ptqre.jpg) enumerates the kitchen object's whole settings set as Name, Status (Enabled/disabled), Supported Categories, Description - nothing that would configure an all-day view. WHY STILL UNKNOWN: one marketing screenshot of one kitchen with one ticket is not a screen census, and NsGastro remains closed source (my.nexopos.com/api/nexoplatform/marketplace/items/1 gives github_repository 'blair2004/NsGastro', which api.github.com returns 404 for anonymously - the repo is private). Also newly read and empty on this cell: the anonymous marketplace API (24 published items, one row per module, with each module's latest release notes) and the new doc /en/documentation/natives/nexopos-for-windows/network-mode. Retrieved 2026-09-18. adversarially verified

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

Orders can be ordered by priority or time with new-request notifications, but no configurable target cook time, colour escalation or breach alert. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

Printer failure is a recurring unresolved complaint rather than a handled case; no backup routing exists. https://github.com/Blair2004/NexoPOS/issues?q=is%3Aissue · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator

kitchen-offline-operation

CLAIM: KDS keeps receiving/displaying tickets from on-site POS terminals when internet/cloud is unreachable. VERDICT: unknown. NEW SURFACES: (1) vendor doc "Local Network Configuration": "After having installed NexoPOS, you might need to make it accessible on the local network ... (example: 192.168.1.1/nexopos/public)"; (2) vendor blog https://my.nexopos.com/en/blog/self-hosted-restaurant-pos-solutions: "Local server deployment: the POS runs on equipment at the restaurant" and "Choose a local deployment when the restaurant has strong on-site technical support and wants the POS to remain available on its own network" - but the same post leaves "What happens if the internet drops?" as a question for the operator to plan; (3) Nexo Print Server listing: "Works offline and online" (printing incl. kitchen tickets - not the screen). WHY NOT yes/partial: Gastro's kitchen screen updates "sync instantly with waiters", and the core's real-time transport is configurable between self-hosted Laravel Reverb and cloud Pusher (.env.example: BROADCAST_DRIVER, PUSHER_APP_*, REVERB_*; composer.json requires both laravel/reverb and pusher/pusher-php-server; 6.2.2 at 6061a93). Which transport Gastro's screen needs, and whether it survives an internet loss on a LAN install, is documented nowhere in the 318-page my.nexopos.com census ("offline" 9 hits: Windows app, SaaS suspension pages, print server, a buyer checklist). An inference from self-hosting is not a KDS statement. Retrieved 2026-09-16. || 322nd: NEW SURFACES (322nd): crt.sh %.nexopos.com lists ~330 names (mostly *.my.nexopos.com customer cloud tenants). Vendor hosts probed: docs.api.nexopos.com (already in the record sources; re-read against these cells) answers 200 - a Slate "API Reference" (661,908 B, one page) for the CORE REST API: Authentication, Categories, Customers, Customer Groups, Crud, Fields, Forms, Medias, Modules, Notifications, Products, Product Categories, User, Orders (create/update/void/refund/instalments/print/delivery status). It documents no Gastro/kitchen, Multistore, clock-in or report endpoint: "kitchen" 2 hits (a sample notification "Kitchen Print Failure" about kitchen printers), NsGastro only as an item in the List Modules sample response; "stores?" 0, "reports?" 0, "offline" 0, "clock" 0. gastro.nexopos.com, v4-gastro, v4-multi, v46x, v48x, platform, cloud, api, server, ws do not answer; demo.nexopos.com and dev.nexopos.com 404; Wayback CDX for gastro.nexopos.com holds only a 2017 v3 sign-in page and AdminLTE assets (no app source); the others have no captures. The paid Gastro and Multistore modules have no vendor-published source (GitHub search: only third-party copies, not used). Still unknown. Retrieved 2026-09-17. || 328th: 328th: the core source was RE-DERIVED at the current tag v6.2.3 (released 2026-09-10; prior passes held 6.2.2 at 6061a93) - api.github.com trees, truncated:false, 3,534 blobs. It adds nothing on this cell: core still ships no kitchen/KDS code of any kind (the only 'kitchen|kds|gastro' paths in the whole tree are database/json/kitchen-dinning.json, two product photos, tests/Feature/NsGastroAuthorMigrationTest.php and tests/phpunit.gastro.xml, i.e. a demo dataset and two test harness stubs pointing at the external NsGastro module). The Gastro module's code remains outside the repository, so the KDS's behaviour on an internet loss is still uncensusable. Retrieved 2026-09-18. || 330th: 330th, NEW SURFACE (still unknown): the vendor published a new documentation page since the last pass - a re-derived sitemap-docs.xml holds 145 locs today against the 144 the 315th censused, and the single new slug is /en/documentation/natives/nexopos-for-windows/network-mode. It documents an ON-PREMISES LAN server mode: 'Network Mode allows NexoPOS for Windows to serve approved NexoPOS Client devices over the local network ... such as an additional checkout, an office workstation, or a stock-management device'; Settings > General Settings > 'Operating mode' > 'Network mode'; a 'Network Access' page whose 'LAN gateway allows approved NexoPOS Client devices to reach this server' with a display name and an 'HTTPS gateway port'; discovery, pairing with a confirmation code, Approve/Revoke; troubleshooting is entirely local ('Confirm that the server and NexoPOS Client device are on the same local network'). The matching marketplace entry (NexoPOS Client for Windows, item 32, v4.0.0 'Initial Release') reads 'securely connects computers on the same local network to a NexoPOS installation - without manual IP setup, certificates, or hosts-file configuration'. WHY THIS STILL DOES NOT CARRY THE CELL: the words 'internet' and 'offline' appear 0 times in the whole page (tokenised, case-insensitive, over the script/style-stripped body); the page never mentions the kitchen screen or Gastro, and it describes a Windows-hosted deployment, not the behaviour of Gastro's real-time kitchen screen when the link drops. A LAN-served deployment is an inference about the KDS, not a vendor statement about it. Retrieved 2026-09-18. adversarially verified

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

Kitchen screen shows item details, notes and modifiers — full modifier breakout, but no recipe steps or portioning display. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

Proposition: sectioned/fractional topping placement rendered unambiguously on the make-line screen or ticket. There is nothing to render. The order line that a kitchen ticket is printed from, app/Models/OrderProduct.php, enumerates its whole schema with no section, placement, portion or fraction attribute, and the core has no modifier entity at all ('modifier' 0 files across app, routes, database, config, resources/ts and the 3,412-key lang/en.json), so a half or quarter cannot be recorded, let alone displayed. 'topping' and 'quarter' are 0 files; the one 'fraction' hit is a vendored countdown library. This record's already-cited menu-pricing-nested-modifiers cell records the paid Gastro module's modifier model as flat groups with an optional quantity, which likewise has no section axis to draw. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/OrderProduct.php · retrieved 2026-09-05 adversarially verified

A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.

kitchen-recall-refire

Documented item states are in preparation / ready / rejected; no recall, unbump or refire action. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

CLAIM: POS edits to an order already on the kitchen screen visually flag added/changed/removed items. VERDICT: unknown (note refreshed; the robots gate the old note relied on is gone and Gastro's docs were read). NEW SURFACE: Gastro details: "Orders placed on the table are likely to be customized by the waiter. This one can : | Cancel a meal | Add new note to a meal"; kitchen screen "with notifications for new requests ... All updates sync instantly with waiters". The vendor blog self-hosted-restaurant-pos-solutions asks "Who sees a modified meal?" only as a planning question and lists "place an order, modify it, route it to the kitchen, mark it ready" in a rehearsal checklist - modification exists, but how the kitchen ticket shows it is never stated. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "highlight(ed|s)?" 6 and "flag(ged|s)?" 1 hits, none on Gastro/kitchen pages; "modified item" 0; "updated order" 0. Gastro source is not public, so no census of the screen; not a no. Retrieved 2026-09-16. || 322nd: NEW SURFACES (322nd): crt.sh %.nexopos.com lists ~330 names (mostly *.my.nexopos.com customer cloud tenants). Vendor hosts probed: docs.api.nexopos.com (already in the record sources; re-read against these cells) answers 200 - a Slate "API Reference" (661,908 B, one page) for the CORE REST API: Authentication, Categories, Customers, Customer Groups, Crud, Fields, Forms, Medias, Modules, Notifications, Products, Product Categories, User, Orders (create/update/void/refund/instalments/print/delivery status). It documents no Gastro/kitchen, Multistore, clock-in or report endpoint: "kitchen" 2 hits (a sample notification "Kitchen Print Failure" about kitchen printers), NsGastro only as an item in the List Modules sample response; "stores?" 0, "reports?" 0, "offline" 0, "clock" 0. gastro.nexopos.com, v4-gastro, v4-multi, v46x, v48x, platform, cloud, api, server, ws do not answer; demo.nexopos.com and dev.nexopos.com 404; Wayback CDX for gastro.nexopos.com holds only a 2017 v3 sign-in page and AdminLTE assets (no app source); the others have no captures. The paid Gastro and Multistore modules have no vendor-published source (GitHub search: only third-party copies, not used). Still unknown. Retrieved 2026-09-17. || 330th: 330th, NEW SURFACE (still unknown): the vendor's own picture of the kitchen screen, extracted from the Gastro item page's EditorJS payload and read as an image 2026-09-18 (nimshot-2026-04-19-122914-j0hff.jpg). The ticket card carries a per-ITEM status badge ('Pending') and Cancel/Start actions, i.e. Gastro tracks item state on the live ticket, but the card shows no added/changed/removed marker, no strike-through and no 'modified' flag, and no colour legend. The POS-side screenshot the vendor added in 2026/07 (https://my.nexopos.com/storage/2026/07/order.jpg, read as an image) shows the cart lines each with a delete (bin) icon and a cutlery 'send to kitchen' icon plus a blue 'Kitchen' action button - so items can be removed or re-sent after the order is in the kitchen - but nothing in the published material says what the kitchen screen does when that happens. Not a census (NsGastro is private: api.github.com/repos/blair2004/NsGastro 404 anonymously), so no `no`. Retrieved 2026-09-18. adversarially verified

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

Ready status syncs to waiters only. The WhatsApp Notification module ($19) delivers system/module notifications to the operator, not guests. https://my.nexopos.com/en/marketplace/item/whatsapp-notification · 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

Stock Adjustment with reasons exists in the back office, but not at the kitchen screen and not tied to remakes. https://my.nexopos.com/en/documentation/user-guide/products/stock-adjustment · retrieved 2026-08-01

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

The shipped report set (sale, profit, best products, cash flow, stock, payment types, customer statement, yearly) contains no ticket-time report. https://github.com/Blair2004/NexoPOS/tree/master/resources/ts/pages/dashboard/reports · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Proposition: prep lists or predicted prep quantities generated from historical sales and forecast demand, surfaced to kitchen staff as a daily task list. database/permissions/reports.php is the vendor's own complete enumeration of the shipped reporting surface - See Sale Report, See Products Report, See Best Report, See Transaction Report, See Yearly Sales, See Customers, See Inventory Tracking, See Customers Statement, Read Sales by Payment Types, Read Low Stock Report, Read Stock History - eleven reports, none forecasting anything. 'forecast' is 0 files across app, routes, database, config, resources/ts and the 3,412-key lang/en.json, and 0 in the 121-heading docs.api.nexopos.com reference. The nearest shipped mechanic is procurement low-stock suggestions (routes/api/procurements.php: procurements/low-stock-suggestions), which reorders against a low-quantity threshold rather than predicting demand, and it is a purchasing tool, not a kitchen prep list. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/permissions/reports.php · retrieved 2026-09-05 adversarially verified

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

A Store Front module is an open roadmap issue; no consumer ordering site ships today. https://github.com/Blair2004/NexoPOS/issues · retrieved 2026-08-01

The web/app ordering menu is generated from the same POS menu record as in-store — one item edit propagates to all first-party digital channels without a separate digital menu build.

digital-menu-single-source

Proposition: one menu record feeds both in-store and first-party digital channels. There is no first-party digital channel to feed. The only unauthenticated page NexoPOS v6.2.2 serves is the root welcome view, whose own shipped, translated string tells the operator the product ships no storefront; every other web route is inside the `dashboard` prefix behind Authenticate middleware (routes/web-base.php:41) and every API group is behind auth:sanctum (routes/api-base.php:18). With no second menu surface, single-source propagation is undefined rather than achieved. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

The only mobile app is an Android barcode utility for staff. A Store Front mobile app is an open roadmap issue. https://my.nexopos.com/en/marketplace · 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

Proposition: guests get an account with saved addresses, tokenized cards and one-tap reorder across first-party channels. NexoPOS has no guest-facing channel at all (welcome view string, below), and the core stores no card data: word-boundary greps over app, routes, database, config and resources/ts for `tokeniz`, `saved card`, `3ds` and `pci` return zero files. Customer addresses exist (nexopos_customers_addresses) but only as staff-entered billing/shipping records on a POS order. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: digital checkout shows configurable or algorithmic upsell suggestions with attach-rate reporting. Word-boundary greps for `upsell` and `cross.sell` over app, routes, database, config and resources/ts return zero files, and there is no digital checkout to place them in - the product's own root page states it ships no frontend. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: future/scheduled orders with per-daypart capacity throttling that closes saturated slots. The core has no capacity, time-slot, prep-time or pacing concept: word-boundary greps for `capacity`, `time.?slot`, `prep.?time`, `pacing` and `throttl` over app, routes, database, config and resources/ts hit only HTTP rate limiting (ThrottleMiddelware, config/auth.php), password capacity in CreateUserCommand and ScaleRange. The orders table carries no scheduled-for datetime - only `final_payment_date`, which is the layaway/instalment due date. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: one digital ordering flow covering pickup, curbside with arrival check-in, dine-in/QR, and delivery, with mode-specific fees and prep timing. NexoPOS enumerates exactly two order types on the Order model - delivery and takeaway - both selected by the cashier at the POS; there is no guest flow to run them in, no curbside (`curbside` 0 files) and no dine-in/table type in the core (tables are the paid Gastro module). https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/Order.php · retrieved 2026-09-05 adversarially verified

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

Proposition: guest-facing QR scan-to-order or scan-to-pay that attaches to the POS check. Every QR-code use in NexoPOS v6.2.2 is staff-facing: pairing a phone as a wireless barcode scanner (ns-pos-grid-wirless-barcode-connect.vue), the API-token popup (ns-token-output-popup.vue), and the temporary manager-authorisation popup whose string reads 'Access to this feature requires temporary permission from an administrator. Scan the QR code to proceed.' No QR route is reachable without authentication. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: the vendor ships a self-order kiosk sharing POS menu and modifier logic with unattended EMV. A word-boundary grep for `kiosk` over app, routes, database, config and resources/ts returns zero files, and there is no unauthenticated ordering UI a kiosk could run - the product's own root page tells the operator it ships no frontend. The core also integrates no card processing at all (`EMV` 0, `tap to pay` 0), so unattended EMV is doubly foreclosed. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: a shareable link letting multiple participants add items to one order under a spend cap. There is no shareable guest link of any kind: `group order` returns zero files over app, routes, database, config and resources/ts, the word 'group' in this codebase means a customer group or a permission role, and the only unauthenticated pages are the welcome view, sign-in/sign-up and the installer. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: a distinct catering flow with catering menus, lead-time rules, quotes, deposits and invoice/house-account terms. `catering` returns zero files across app, routes, database, config and resources/ts. The one adjacent mechanic that does exist - customer house accounts with a credit limit, and order instalments - is a POS-side payment arrangement, not a catering ordering flow, and there is no guest ordering surface to host one. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

CLAIM: AI voice phone ordering, native or via a NAMED certified partner, injecting orders without staff transcription. VERDICT: no. The partner half the old note could not settle is now readable: the robots bar on my.nexopos.com is gone and the whole marketplace was censused. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. The 32 marketplace items: Gastro, PIN Login, NPS Adapter, Options Import/Export, Email Service Driver, Multistore, Bulk Importer, Stock Transfers, Raw Material Tracker, Socialite, Bulk Editor, Sales Commissions, AI Thumbnail Generator, Google reCAPTCHA, NexoPOS Authorizer, Racks Manager, Nexo Print Server, NexoPOS for Windows, SMS Utility, Google Authenticator, Football Academy app, WhatsApp Notification, Barcode Utility, Website Explorer SaaS, Nexo SaaS, Bellsera spa booking, QR Menu for Gastro, NexoPOS Rental, Oxen AI agent, Hotel Booking, Image Optimizer, NexoPOS Client for Windows - none telephony. The only AI agent, Oxen, is a text dashboard assistant + MCP server ("A conversational assistant available from the NexoPOS dashboard"); its documented write actions are products, categories, providers, customers, groups, units, taxes and coupons - not orders. CONTROLS over 318 pages: "voice" 0 tokenised (POISON: the raw substring "voice" is in 162 files, all "invoice"); "telephon[a-z]*" 0; "call cent(er|re)" 0; "phone orders?" 0; "phone" 26 hits = customer/provider phone fields, Barcode Utility phone camera, SaaS support phone. Core: "voice" word-boundary 0 in app/routes/database/config/resources/ts at 6.2.2 (prior note, tree re-cloned). Retrieved 2026-09-16. https://my.nexopos.com/en/marketplace/item/oxen-ai-agent-for-nexopos/details · retrieved 2026-09-16 adversarially verified

Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.

digital-drivethru-ai

Proposition: AI voice ordering at the drive-thru lane, integrated with POS menu/modifiers with human escalation. NexoPOS has no drive-thru surface whatsoever: `drive thru`, `drive-thru` and `voice` each return zero files over app, routes, database, config and resources/ts, and the order-type enumeration on app/Models/Order.php is exactly delivery and takeaway. The product ships no guest-facing frontend at all. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.

digital-sms-ordering

Proposition: conversational SMS/chat ordering or text-a-link that lands in the POS. The single occurrence of 'SMS' in NexoPOS v6.2.2 outside compiled assets is a field description on the supplier (provider) form saying a provider's phone number 'might be used to send automated SMS notifications' - a staff-facing supplier contact field, aspirational at that, with no sending code behind it. `twilio` returns zero files and app/Mail contains five mails, all staff account/auth. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Crud/ProviderCrud.php · retrieved 2026-09-05 adversarially verified

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

Proposition: the restaurant's direct ordering link is provisioned to its Google Business Profile as an ordering action. There is no direct ordering link to provision - the product ships no guest-facing frontend - and `google` returns zero files across app, routes, database, config and resources/ts, so there is no Google Business Profile integration of any kind. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow. Same precondition failure - there is no first-party ordering flow. The two `apple` hits in the tree are a `-apple-system` CSS font stack inside the MCP HTML report template and an `application/vnd.apple.installer+xml` MIME entry in config/medias.php; neither is a Business Connect integration. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: loyalty accrual and redemption run inside the first-party digital ordering flow on the same guest identity as in-store. The reward system and coupons are real and native (app/Services/CustomerService.php::computeReward, nexopos_customers_rewards, nexopos_customers_coupons) but they fire only from an order created in the authenticated POS, and there is no digital ordering flow for them to attach to. The claim fails on the channel, not on the loyalty engine. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: guest subscription/membership programs with recurring billing managed in the platform. `membership` returns zero files. The `subscription` hits are all RxJS observable subscriptions in Vue components, and the `recurring` hits are all accounting - Transaction::TYPE_RECURRING, the Recurring/Scheduled transaction fields and TriggerRecurringTransactionJob - i.e. the operator's own recurring expenses, not guest billing. NexoPOS also integrates no card processor, so there is nothing to bill a guest with. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: discounts, coupon codes and loyalty offers are defined once and honored identically across POS, kiosk and first-party digital, with channel eligibility controls. NexoPOS has exactly one transactional channel - the authenticated POS - so there is no second channel to be at parity with, and the coupon schema carries no channel column at all: nexopos_coupons scopes by product, category, customer and customer group only. The claim is vacuous here rather than satisfied. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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: the operator owns the database. Customers, rewards and coupons are readable/writable via the public API and CRUD export columns, at no fee. https://docs.api.nexopos.com · 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

Proposition: hosted fields or a hosted payment page plus a published PCI DSS 4.0 statement and 3DS support. There is no digital checkout - the vendor's own root page says the product ships no frontend - and `pci`, `3ds` and `tokeniz` each return zero files across app, routes, database, config and resources/ts. NexoPOS is not a payment processor: its own documentation states that creating a payment type does not automatically connect NexoPOS to an external payment provider. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: digital channels carry the same service-fee / dual-pricing / card-surcharge configuration as the POS, with guest disclosure and jurisdiction handling. Two things fail. There is no digital channel. And the POS itself has no surcharge feature to mirror: the only occurrences of 'surcharge' in the whole tree are two explanatory code comments in pos-init.ts about line-level fees such as a room fee, with no surcharge setting, column or UI string, and `service fee` returns zero files. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

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

A single customer record exists, but only one transactional channel (the POS) feeds it; no cross-channel identity merge or documented dedup behaviour. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · 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

Proposition: marketplace orders (DoorDash, Uber Eats, Grubhub) attach to a native guest profile rather than landing anonymous. NexoPOS integrates no third-party marketplace at all - `doordash`, `uber`, `grubhub` and `marketplace order` each return zero files across app, routes, database, config and resources/ts, and the only 'marketplace' in the code is the my.nexopos.com module store (app/Services/MarketplaceService.php). Every order is created through the authenticated POS or the bearer-token REST API with a customer_id the operator supplies, so the question of marketplace attachment does not arise. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/routes/api-base.php · retrieved 2026-09-05 adversarially verified

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

A configurable Reward System accrues points to customers and issues coupons on threshold. Visit/punch and spend-tier accrual are not documented as separate options. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · retrieved 2026-08-01

Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator

guest-loyalty-tiers

Proposition: status tiers with AUTOMATIC promotion and demotion driven by rolling-window spend or visits. NexoPOS does have tier-shaped structure - a reward system is attached to a customer group, and groups differ by reward program and minimal_credit_payment - but nothing moves a customer between groups automatically. The reward rules are per-order award bands (if the order total falls between `from` and `to`, add `reward` points), not status thresholds, and the only documented way to change group membership is the operator-driven bulk endpoint POST api/customers-groups/transfer-customers, which takes explicit ids or a '*' wildcard. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/CustomerService.php · retrieved 2026-09-05 adversarially verified

Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator

guest-loyalty-offline-behavior

CLAIM: the vendor DOCUMENTS what loyalty lookup/accrual/redemption do when the POS loses connectivity. VERDICT: no - the user guide the old note could not open (formerly robots-barred) is now held in full and says nothing of the kind. EVIDENCE: the loyalty documentation reads "Customer Rewards | The customer rewards are available when you have correctly defined a reward system. In order to see all the rewards earned by a customer, you need to use the 'Rewards' option available for each customer. | Coupons | Customers might earn 'coupons' as a reward from the Reward System" - no connectivity section. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "offline" 9 hits in 6 files, all non-loyalty (NexoPOS for Windows "created primarily for offline use", Nexo SaaS suspension "offline page", Nexo Print Server "Works offline and online", a buyer-checklist question in a pricing blog); "loyalty" 3 hits (features-page heading, a pricing blog) with no offline wording; "rewards?" 18 hits, none about connectivity. Mechanism side (prior note, 6.2.2): zero "offline", no service worker/IndexedDB; accrual runs server-side in CustomerService::computeReward. Retrieved 2026-09-16. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · retrieved 2026-09-16 adversarially verified

Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator

guest-loyalty-offer-stacking-rules

Proposition: the offer engine exposes explicit stacking and precedence rules - exclusive vs combinable, order of application - as configuration. The core coupon table carries name, code, type, discount_value, valid_until, minimum/maximum cart value, valid_hours_start/end, limit_usage, groups_id and customers_id, and nothing else; there is no exclusive/combinable flag, no priority and no application-order column, and the matching CouponCrud form exposes no such field. At order time OrdersService::__saveOrderCoupons simply iterates every attached coupon and sums their values into total_coupons, so multiple coupons always combine and precedence is undefined. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_01_23_225101_create_coupons_table.php · retrieved 2026-09-05 adversarially verified

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

Coupons attach to customers or customer groups, which are static manual sets, not rule-defined audiences. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · 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

Proposition: recency/frequency/monetary or equivalent lifecycle segments computed automatically. The customer record does carry the raw material - purchases_amount, owed_amount, total_sales_count, birth_date - but nothing derives a segment from it. `rfm`, `lapsed`, `churn` and `campaign` each return zero files across app, routes, database, config and resources/ts; the only two `segment` hits are a chart-label description in the MCP report tool and a URL fragment in the modules page. Customer groups, the only grouping that exists, are static sets an operator fills by hand or by the bulk transfer endpoint. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/core/2014_10_13_000000_create_users_table.php · retrieved 2026-09-05 adversarially verified

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

Proposition: triggered lifecycle automations - birthday, first-visit thank-you, lapsed win-back - shipped as configurable always-on campaigns. routes/console.php is the complete scheduler definition for NexoPOS v6.2.2 and contains 13 entries: a cron heartbeat, a symlink check, scheduled transactions, stock procurement, order-storage purge, hold-order clearing, low-stock detection, laid-away order tracking, product-history backfill, module temp cleanup, expired-option deletion and an update check. None is guest-directed. The customer record even carries a birth_date column, but nothing reads it on a schedule, and `birthday`, `lapsed`, `win.back` and `campaign` all return zero files. app/Mail holds exactly five mailables, all staff account/auth. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/routes/console.php · retrieved 2026-09-05 adversarially verified

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

A free Email Service Driver module configures transactional email delivery; no campaign builder and no SMS channel. https://my.nexopos.com/en/marketplace/item/email-service-driver · 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

Proposition: per-channel marketing consent captured with timestamp and source, with revocation honored by any reasonable means. The customer/user record has no consent column of any kind - username, active, author_id, email, password, group_id, names, gender, phone, pobox, activation fields, sales counters, birth_date, purchases/owed/credit/account amounts, activation_token, remember_token, timestamps - and `consent`, `opt.in`, `opt.out`, `gdpr` and `marketing` each return zero files across app, routes, database, config and resources/ts. There is also no marketing channel to consent to: app/Mail contains five staff account mailables and no SMS sender exists. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/core/2014_10_13_000000_create_users_table.php · retrieved 2026-09-05 adversarially verified

Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.

guest-loyalty-10dlc-registration

Proposition: the platform handles or explicitly documents A2P 10DLC brand and campaign registration for operator SMS. NexoPOS sends no SMS, so no registration path can exist. The single 'SMS' occurrence in the tree outside compiled assets is a description on the supplier form saying a provider's phone number might be used for automated SMS notifications; `twilio`, `10dlc` and `a2p` return zero files, and the outbound mail surface is five staff account mailables. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Crud/ProviderCrud.php · retrieved 2026-09-05 adversarially verified

Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator

guest-loyalty-campaign-attribution

Coupon order history and customer coupon history track which orders redeemed which coupon. No campaign object and no incremental-sales attribution. https://github.com/Blair2004/NexoPOS/blob/master/app/Crud/CouponOrderHistoryCrud.php · 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

Full guest list and transaction history via direct database access (self-hosted), CRUD export, and the customers/orders REST API. No fee, no ticket. https://docs.api.nexopos.com · 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

Proposition: post-transaction feedback requests are triggered and routed by score, low to private recovery and high to public review sites. NexoPOS captures no feedback at all: `nps` and `rfm` return zero files, the five `review` hits are English prose in a dashboard guide, three code TODOs and an unrelated unit warning, and the two `feedback` hits are marketplace-authentication notification identifiers. There is no survey table, no rating column on orders, and no guest messaging channel to send a request through. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/routes/api-base.php · retrieved 2026-09-05 adversarially verified

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

An affiliate/referral system exists on the my.nexopos.com marketplace for module sales, not as a guest referral mechanic in the POS. https://my.nexopos.com/en/help/terms-of-use · 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

Proposition: an Apple Wallet or Google Wallet loyalty pass with a push-updatable balance. Every 'wallet' in NexoPOS is accounting vocabulary for the customer's house deposit balance - the AccountingEventCatalog defines Wallet Addition as recording funds received that increase the customer deposit liability - and there is no pass at all: `passkit` and `google` return zero files, the two `apple` hits are a CSS font stack and a MIME-type entry, and no .pkpass generation or pass-update endpoint exists in the 121-heading REST API reference. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Accounting/AccountingEventCatalog.php · retrieved 2026-09-05 adversarially verified

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

Individual customer records can be viewed, exported and deleted from the customer list, and self-hosting gives direct DB access. No purpose-built DSAR workflow and no deletion-propagation guarantee. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · 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

Proposition: loyalty fraud controls - redemption velocity limits, manager approval on manual point adjustments, employee self-redemption flagging - backed by an audit log. None of the three is present and there is no audit log. A customer's reward balance is directly editable through CustomerRewardCrud, whose fillable set is exactly ['target','points'], gated only by the generic update permission; the nexopos_customers_rewards table carries no author_id and no history table shadows it, so an edited point balance leaves no trace. Two near-misses that are NOT this claim: coupons carry a limit_usage cap, which is a total-use ceiling rather than a per-time velocity limit, and the core POS discount button can sit behind a temporary manager-authorisation popup - which covers discounts, not point adjustments. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Crud/CustomerRewardCrud.php · retrieved 2026-09-05 adversarially verified

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

CLAIM: vendor documents AI/ML-generated recommendations for offer content, target audience or send timing (shipped). VERDICT: no - the paid catalogue the old note could not open is now held; its AI products are documented and none recommends offers. EVIDENCE: the marketplace's two AI items are AI Thumbnail Generator (product images) and Oxen, whose full listing describes "A conversational assistant available from the NexoPOS dashboard", a store-intelligence table whose promotions row is "Customers and promotions | Customers, customer groups, rewards, wallets, coupons, and eligibility rules", and "Supported management actions include creating and updating products, categories, providers, customers, customer groups, units, unit groups, taxes, tax groups, and coupons", each mutation "handled as a proposal" a user must approve. It reads and writes coupons on instruction; it documents no recommendation of offer content, audience or send time, and there is no campaign surface whose timing could be recommended (SMS Utility / WhatsApp Notification are transactional). Core MCP server app/Mcp/Tools = 19 tools, none offer-generating (prior note). CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "recommend(ation|ations|s|ed)?" 32 hits in 23 files - docs prose ("recommended way"), blog "Final Recommendation" headings, and "the Recommendation Service" in the 6.2 release blog, which has no file in the 6.2.2 tree (git ls-files | grep -i recommend = 0); "machine learning" 0. WEAKER THAN IDEAL: an LLM agent that can draft coupons on request is adjacent; a strict verifier may prefer unknown. Retrieved 2026-09-16. https://my.nexopos.com/en/marketplace/item/oxen-ai-agent-for-nexopos/details · retrieved 2026-09-16 adversarially verified

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

Proposition: native stored-value/gift balances tied to the guest profile and redeemable across all locations of the brand. NexoPOS ships more than the migrated `no` allowed. A prepaid balance is a first-class object: nexopos_users.account_amount holds it, OrderPayment::PAYMENT_ACCOUNT ('account-payment') is a built-in payment type installed by SetupService at setup, OrdersService refuses a payment larger than the balance, and nexopos_customers_account_history records every movement with previous_amount, amount, next_amount, an add/sub operation, an author_id and a description. SHORTFALL, which is why this is partial and not yes: it is a named house account, not a stored-value instrument - there is no gift-card entity, no bearer code, no activation, no issuance to a third party and no transferability (`gift`, `voucher` and `stored value` return no product hits) - and the balance lives in one installation, so 'across all locations of the brand' depends on the paid Multistore module at my.nexopos.com, which is robots-barred to this corpus and cannot be checked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/OrderPayment.php · retrieved 2026-09-05 adversarially verified

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

A PIN Login module authenticates staff and cash registers track opening/closing per cashier, but there is no timecard or clock-in/out entity anywhere in the source. https://github.com/Blair2004/NexoPOS · 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

328th, NEW SURFACE: the Clockin module's SOURCE was read this pass (prior passes named the repo and the 1.4 migration but never opened the UI component), via api.github.com trees + raw.githubusercontent.com. Census: Blair2004/Clockin, branch master, pushed 2026-08-18, tree truncated:false, 28 blobs - the whole module. IT IS A PHOTO-AT-PUNCH FEATURE AND IT STORES NO BIOMETRIC TEMPLATE. Public/src/js/components/ck-timer.vue imports `import { WebCam } from "vue-web-cam"` and renders <vue-web-cam ref="webcam" :selectFirstDevice="true"> above the punch buttons; the buttons ('Start Working', 'Start Break', 'Stop Working', 'Stop Break') are rendered only inside `<template v-if="cameraStarted">`, so a punch cannot be taken until the camera is running, and the fallback banner reads verbatim 'Camera Disabled / Missing'. The captured shot is attached to the timecard row: Migrations/1.4/add_image_url.php adds `image_url_start` and `image_url_end` (nullable strings) to table `clockin_timer`, and the History pane renders `<img :src="history.image_url_start">` plus a 'See Image' link per entry, next to From / To / Duration. The server side confirms it: Http/Controllers/ClockinController.php sets `$clockin->image_url_start = url( 'storage/' . $file )` (and image_url_end), i.e. it saves an uploaded image file and stores its URL. CONTROLS, tokenised, case-insensitive, over the module's OWN 22 source blobs (39,167 bytes; the 6 Public/dist/* webpack bundles and package manifests are EXCLUDED because they are third-party library code): facial 0, biometric 0, fingerprint 0, embedding 0, face 0; positive controls webcam 7, vue-web-cam 5, image_url 11. POISON NAMED, and it is why the exclusion matters: run over all 28 blobs (3,827,797 bytes) the same controls return face 1 - the SVG tag name `font-face` inside Vue's vendor.js - and fingerprint 1 - a comment about canvas fingerprinting in the same vendor bundle; `template` is useless at any scope (186 hits, all Vue/moment.js internals). So the module persists a URL to an image and nothing else, which is exactly the claim's 'photo-only mode ... stores no biometric template'. WHY PARTIAL AND NOT YES: this is a NexoPOS 4.x-era module (config.xml namespace Clockin, version 1.4; the repo description still reads 'Simple clockin application for NexoPOS 4.x') authored by the core maintainer, and the vendor's own FAQ supports only the latest two majors; it is not in the 32-item marketplace censused earlier, and the current core v6.2.3 tree (3,534 blobs) contains no clock-in, timesheet or punch code at all - the only 'clock' matches are three line-awesome icon SVGs (POISON). A positive taken from a retired-version copy carries at most partial. Retrieved 2026-09-18. https://raw.githubusercontent.com/Blair2004/Clockin/master/Public/src/js/components/ck-timer.vue · retrieved 2026-09-18 adversarially verified

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

Two independent foreclosures. (a) There is no time punch to record: punch/timecard/timesheet are word-boundary zero over the tree and the UI string table. (b) There is no offline mode to record it in - the record's own hardware-offline-mode cell is already `no`, and I confirmed no service worker, no client-side store and no sync layer in resources/ts. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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 discrete, individually creatable objects assigned to roles; docs walk through creating both roles and custom permissions. https://my.nexopos.com/en/documentation/developers-guide/roles-permissions/creating-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

Upgraded from the uncited `no`, which was wrong on its face. v6.2.2 ships a real POS manager-override system. app/Settings/pos/features.php:166 exposes 'Enable Action Permission' (ns_pos_action_permission_enabled); UsersService::requestAccess() writes a nexopos_permissions_access row per attempt, and UsersController::approveAccess() sets $access->granter_id = Auth::id(), so the INDIVIDUAL approver is persisted alongside requester_id, the permission namespace, the target url, a status enum (granted/denied/pending/expired/used), expired_at and timestamps. It is queryable after the fact: App\Crud\PermissionAccessCrud renders requester_username, granter_username, permission, url, status, expired_at, created_at and updated_at, joined to nexopos_users, and CRUD components are CSV-exportable. The approval UI is a QR code scanned with an administrator device (resources/ts/popups/ns-pos-permissions-popup.vue). NAMED SHORTFALL, which is why this is not `yes`: the trail is not immutable - PermissionAccessCrud declares 'delete' => true and registers a 'Delete Selected Entries' bulk action, and the row itself is mutated in place from pending to granted to expired, so prior states are overwritten; there is no reason code; and the grant is not linked to the order, discount or void it authorised, so an auditor can see that a manager approved permission X at time T but not which transaction it moved. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2025_07_19_232411_create_pending_aproval_table.php · retrieved 2026-09-05 adversarially verified

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

There is no shift, roster or schedule-publishing entity in v6.2.2. The word 'schedule' does occur in five files, and I opened every one: all are Illuminate\Support\Facades\Schedule, the Laravel cron facade - routes/console.php enqueues ten background jobs (low stock, hold-order clearing, procurement stocking, storage purge), routes/console/transactions.php cron-schedules recurring accounting transactions, and CoreService raises a 'Task Scheduling Disabled' notification. 'roster' and 'shift' (as a labor noun) are zero. There is also no timekeeping data for a schedule to sit beside. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/routes/console.php · retrieved 2026-09-05 adversarially verified

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

forecast, forecasting, predict and projection are word-boundary zero across the ENTIRE checkout (not just app/ - I ran it over the repository root excluding .git, node_modules and vendor), so NexoPOS computes no forward staffing recommendation of any kind, static or history-driven. It also holds no labor hours to recommend: see the sibling cells. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

The migrated rationale ('No labor cost data exists in the system') is not quite right and I am correcting it: labor cost DOES exist in v6.2.2, but only as a bookkeeping expense line. TransactionService seeds a default chart of accounts in which 5102 'Salaries & Wages' sits under operating_expenses, and database/seeders/TransactionSeeder.php creates an 'Employee Salaries' transaction group. That is a manually entered periodic expense, not a labor cost that can be divided into sales during service: there are no clocked hours, no wage rate on the user record, and none of the nine widgets in app/Widgets (BestCashiers, BestCustomers, ExpenseCard, IncompleteSaleCard, MyNexoPos, OrdersChart, OrdersSummary, Profile, SaleCard) shows a labor percentage. So no real-time labor-to-sales figure exists on any manager view or POS screen. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/TransactionService.php · retrieved 2026-09-05 adversarially verified

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

'overtime' is word-boundary zero across app/, routes/, database/, config/, resources/ts and the 3,412-key lang/en.json UI string table, and there is no clock-in event to warn or block at - punch and timecard are likewise zero, and the record's labor-clock-in-at-pos cell is already `no`. No threshold setting exists among the ns_-prefixed options. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

No break-rule engine, no jurisdiction table, no attestation prompt and no missed-break premium flag. The 75-file 'break' hit is a reader artefact and I opened it: filtering PHP `break;`, CSS word-break/page-break and JS labelled breaks leaves exactly one match in the whole tree, 'page_break' => '<div class="page-break"></div>' in app/Mcp/Tools/GenerateReportTool.php:192. 'breaks' as a noun is zero, and lang/en.json has no break string. The only place a break is a labor concept anywhere in the NexoPOS world is the maintainer's v4-era Clockin module, which sums total_break_time - not part of this product. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.

labor-minor-labor-rules

'minor' is word-boundary zero across app/, routes/, database/, config/, resources/ts and the lang/en.json UI table; the User model and UserAttribute carry no date of birth or age field, and there is neither a scheduler nor a clock-in at which such a rule could be enforced. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

The uncited rationale was right and I can now document it. tip, tips and gratuity are word-boundary zero both in code and across the 3,412 keys of lang/en.json, the vendor's own complete UI string table. Positively: the orders table carries discount, discount_type and discount_percentage, shipping, total, tax_value and voidance_reason - the money model of a NexoPOS order is fully enumerated in this one migration and there is no tip column to pool, no tip-out rule, and no shift to pool over. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_orders_table.php · retrieved 2026-09-05 adversarially verified

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

Foreclosed by the same schema fact as tip pooling: the orders table enumerates every monetary column an order has and none of them is a tip, so there is nothing received, contributed or distributed to retain per shift or per employee - and 'shift' is not a concept in this product either (its five matches are the keyboard modifier and month arithmetic). The CSV export surface documented at docs.api.nexopos.com #export-entries covers the CRUD components - customers, orders, procurements, payment types, coupons - and there is no tip component to export. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_orders_table.php · retrieved 2026-09-05 adversarially verified

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

Every element of this claim is absent. There is no payroll export at all ('payroll' word-boundary zero over code and over the 3,412-key UI string table), no tip data to separate into cash versus charged (tip/tips/gratuity zero), no occupation code field on the user record, and no W-2 or Box 12 string anywhere. app/Mail holds five classes and all five are account lifecycle (ActivateYourAccount, PasswordRecovered, ResetPassword, UserRegistered, Welcome). Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

NexoPOS is GPL-3.0 self-hosted software; the vendor operates a module marketplace, not a payroll bureau, and nothing in v6.2.2 files taxes or moves money to an employee. The only payroll-adjacent artefact in the whole product is a seeded chart-of-accounts expense line, 5102 'Salaries & Wages' under operating_expenses, which an operator posts by hand as a transaction. 'payroll', 'direct deposit' and 'tax filing' are word-boundary zero over the tree and over the UI string table. Note also that the product integrates no payment rails at all: the nexopos_payments_types table has ten columns - label, identifier, priority, description, author_id, active, readonly, accounting_account_id, accounting_incoming_effect and timestamps - with no gateway, credential or processor field, so there is no mechanism through which a direct deposit could be initiated. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/TransactionService.php · retrieved 2026-09-05 adversarially verified

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

I am REWRITING the migrated rationale, half of which was unaskable: 'no payroll connector in the marketplace' is a statement about my.nexopos.com, which this corpus may not read. The half that survives is documentable. There are no hours, wages or tips in v6.2.2 to export - payroll, timecard, timesheet, punch and overtime are word-boundary zero over the tree and over the 3,412-key UI string table - and the product's generic export surface is enumerated by the vendor: the API reference's Available Components table under #export-entries lists the CRUD components that GET api/crud/{namespace}/export can emit, and they are customers, customer groups, customer orders, product categories, procurements, procurement products, payment types, coupons and the order-history CRUDs. No timecard component exists, and Gusto, ADP, Paychex and QuickBooks are word-boundary zero. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

No shift entity, therefore nothing to swap or claim, and no employee-facing self-service app - the only client is the operator's own browser session against the self-hosted server. Both control words are reader artefacts I opened: 'shift' matches only ns-hotpress.ts's keyboard modifier, countdown.ts's borrowMonths(ref, shift) and a POS shortcut label; 'swap' matches only drag-and-drop reordering in ns-reorder-popup.vue and widget-drag-intent.js and a string-argument helper in app/Services/Helpers/App.php. 'roster' and 'open shift' are zero. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

Cash register history attributes sessions and sales to a cashier, and a Sales Commissions module exists. No per-server scorecard with average check, attachment or void/comp rate. https://github.com/Blair2004/NexoPOS/blob/master/app/Crud/RegisterHistoryCrud.php · retrieved 2026-08-01

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

Raw Material Tracker ($20) links ingredients to products via recipes and surfaces real prepared-product cost. Multi-level sub-recipes and automatic plate-cost recalculation on ingredient price change are not documented. https://my.nexopos.com/en/marketplace/item/raw-material-tracker · 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

Unit groups, units, unit conversion and stock conversion are first-class and documented. Yield/waste percentage on raw-to-usable conversion is not. https://my.nexopos.com/en/documentation/user-guide/units-of-measure/unit-conversion · retrieved 2026-08-01

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

Reports include stock, sold stock and combined stock, but no theoretical-vs-actual variance report in units and currency. https://github.com/Blair2004/NexoPOS/tree/master/resources/ts/pages/dashboard/reports · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Sales deplete product stock in real time with per-product stock-flow history; with Raw Material Tracker, ingredient stock is deducted from the recipe on sale. The vendor API reference carries both halves of the core claim verbatim. #get-product-history (GET api/products/{product_id}/history): "This endpoint will provide a full list of stock movement that has occurred on a specific product." #product-stock-adjustment (POST api/products/adjusments) enumerates the adjustment actions and SOLD is one of them, alongside procured, returned, defective and lost — i.e. a sale is a recorded stock movement, which is the depletion claim stated as a mechanism rather than as marketing. SCOPE OF THIS CITATION, stated so it is not over-read: the API reference establishes real-time depletion and per-product history in the free core. It does NOT carry the Raw Material Tracker recipe-depletion half — that rests on the paid module page, which is on the barred host and is not re-cited here. RE-EVIDENCED 2026-08-30: the cell previously rested on https://my.nexopos.com/en/documentation/user-guide/products/product-stock-flow, which is quarantined behind a host-wide robots bar on my.nexopos.com ("claudebot / Disallow: /", re-measured 2026-08-16) and was NOT re-fetched. The barred page is not recovered; a different document on a permitted host was found to carry the same proposition, so the quarantine stamps come off and the grade is set from the new source rather than restored from grade_before_quarantine. docs.api.nexopos.com serves no robots.txt (404, 25 bytes, body "No input file specified." — a PHP error, classified not-robots by scripts/lib/robots.mjs, so unavailable under RFC 9309 rather than absent-and-silent); raw.githubusercontent.com and api.github.com likewise 404; github.com robots.txt was parsed whole and returns not-refused for the repo and blob paths. No verification.jsonl row was added: a re-citation is not an adversarial pass. https://docs.api.nexopos.com/ · retrieved 2026-08-30

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

Zero stock removes an item from the POS grid, but there are no online or third-party channels to sync to. https://my.nexopos.com/en/documentation/user-guide/troubleshooting/products-not-showing-on-the-pos · 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

Stock adjustment supports counted corrections with reasons and writes product history. Distinct full/spot/scheduled cycle-count modes with separately retained variance histories are not documented. https://my.nexopos.com/en/documentation/user-guide/products/stock-adjustment · 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

The free Barcode Utility Android app performs stock control by scanning against a POS terminal. Offline queuing and sync-on-reconnect are not documented. https://my.nexopos.com/en/documentation/natives/barcode-utility/performing-stock-control-with-barcode-utility · 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

Providers and procurements are manual; no broadline distributor catalogs or EDI transmission. https://my.nexopos.com/en/documentation/user-guide/procurements/make-procurement · 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

Proposition: supplier invoices ingested from photo, PDF or email with line-item extraction into the inventory ledger. routes/api/procurements.php is the complete procurement API surface - 18 routes: list, procurementProducts, refreshProcurement, preload/{uuid}, low-stock-suggestions, set-as-paid, storePreload, procure, create, searchProcurementProduct, searchProduct, edit, change-payment-status, editProduct, bulkUpdateProducts and three deletes. Every write path takes a JSON body of already-structured line items; there is no upload, import, parse or scan endpoint. 'ocr' is 0 files across app, routes, database, config, resources/ts and lang/en.json, and 0 in the 121-heading API reference. The one procurement route named 'invoice' points the other way: routes/web/procurements.php exposes /procurements/edit/{procurement}/invoice, a printable invoice GENERATED from a procurement the operator already keyed in. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/routes/api/procurements.php · retrieved 2026-09-05 adversarially verified

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

Proposition: per-item purchase price history across invoices, plus an alert when a received price exceeds the prior or contracted price by a configurable threshold. The first limb is met and the migrated `no` was wrong on it. app/Services/ProcurementService.php:1082 writes ProductUnitQuantity::last_purchase_price from each procurement via ProductService::getLastPurchasePrice(); resources/ts/pages/dashboard/procurements/ns-procurement.vue:317 prefills the buyer's purchase-price field with that last price; and database/migrations/create/2020_06_20_000000_create_procurements_products_table.php persists gross_purchase_price, net_purchase_price, purchase_price and total_purchase_price on every procurement line - so a per-item price history exists across invoices and the prior price is put in front of the operator at the moment of receiving. SHORTFALL, which is why this is partial and not yes: there is no alert of any kind. No contracted or expected price field exists (app/Models/Provider.php and the providers migration define only name, email, phone, address, description, amount_due and amount_paid), no variance threshold appears among the ns_-prefixed options in the 25-file app/Settings surface, and none of the reports enumerated in database/permissions/reports.php is a price-variance report. The comparison is left to the human reading the prefilled figure. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/ProcurementService.php · retrieved 2026-09-05 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

Low-stock notifications plus a shipped product-suggestion-for-procurement-based-on-stock feature. No forecast-driven par mode. https://my.nexopos.com/en/documentation/user-guide/products/low-stock-notification · retrieved 2026-08-01

Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.

inventory-waste-logging

Stock adjustment records losses with a reason and debits inventory. Waste cost is not reported separately from usage variance. https://my.nexopos.com/en/documentation/user-guide/products/stock-adjustment · 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

Proposition: expiration or use-by dates tracked on received and prepped items, with an expiring-soon report or alert before spoilage. The GPL core (github.com/Blair2004/NexoPOS at commit 6061a93, v6.2.2) does half of this. DATES ON RECEIVED STOCK: the procurement product row has a nullable expiration_date column (create_procurements_products_table.php L33). ProcurementProductCrud L177-180 exposes it as 'Expiration Date' ('Define what is the expiration date of the product.'), and ProcurementService L469 writes it per procurement line when stock is received. PER-PRODUCT POLICY: ProductCrud L524-548 adds an 'Expiry' tab with 'Product Expires' (default No; 'Set to "No" expiration time will be ignored.') and 'On Expiration' (Prevent Sales / Allow Sales). Product.php defines EXPIRES_PREVENT_SALES = 'prevent_sales'. ENFORCEMENT: it exists at exactly one site. ProductsController::searchUsingArgument L636-642 throws 'Unable to add the product to the cart as it has expired.' when all four conditions hold: the lookup matched a procurement-line barcode (ProcurementProduct::barcode, which ProcurementService L475 generates as product barcode-unit id-procurement product id); that line's expiration_date is past; the product has expires on; and on_expiration is 'prevent_sales'. The route is GET api/products/search/using-barcode/{product}, which the POS grid's submitSearch calls (ns-pos-grid.vue L403). Adding the same item through its product or unit barcode, or through the POS search popup (POST api/products/search -> ProductService::searchProduct), never reaches the check. Nothing in the order or checkout path reads expiration_date. There is also a caveat on the form default: 'On Expiration' defaults to 'prevent-sales' with a hyphen (ProductCrud L548), which does not match the 'prevent_sales' constant; the database default (products migration L44) is correct. NAMED SHORTFALLS: (a) no expiring-soon report, notification or scheduled job. expiration_date is read nowhere else in app/, and routes/console.php schedules no expiry job. (b) no dates on prepped items. The ProductUnitQuantity expiration_date column is declared but never written in app/. (c) the only consequence of expiry is a hard block, and only when a procurement-line barcode is scanned; it is not a spoilage alert. Bound: this is the core only. Paid modules such as Raw Material Tracker, documented on robots-barred my.nexopos.com, are outside it. https://github.com/Blair2004/NexoPOS/blob/6061a93cf2d3fa0e0fb2896873315485fccc4ba1/app/Http/Controllers/Dashboard/ProductsController.php#L636-L642 · retrieved 2026-09-15 adversarially verified

Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.

inventory-bar-partial-bottle

Proposition: partial-bottle liquid inventory by weight or by bottle fraction. The bottle-fraction limb is met and the record was wrong to read as a flat no. NexoPOS's unit groups are conversion ladders, and the product ships a beverage one as a first-class example: FirstExampleUnitGroupSeeder creates the unit group 'Wine (Yalumba)' with base unit 'Shot (200ml)' (value 300) and non-base units 'Half Bottle (600ml)' (600), 'Bottle (1200ml)' (1200) and '6 Bottles Box (1200mlx6)' - so stock is held in shots, a bottle is six shots, and selling one shot leaves a five-sixths bottle on hand. POST api/products/{product_id}/units/conversion ('from', 'to', 'quantity') is documented in the API reference, and stock quantities are floats with an ns_pos_allow_decimal_quantities POS setting. SHORTFALL, and it is why this is partial not yes: resolution is the configured base unit, so an open bottle is counted in whole shots and not measured; there is no weight-based measurement of an open bottle and no pour-spout or bar-scale integration ('pour' 0 files, and the only weighing in the product is retail scale-barcode PLU - is_weighable and scale_plu on ProductUnitQuantity, the ScaleRange model and the ns_scale_barcode_enabled setting - for pre-packed weighed goods at the counter); and there is no par, depletion-by-pour or bar-specific count mode. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/seeders/FirstExampleUnitGroupSeeder.php · retrieved 2026-09-05 adversarially verified

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

An internal accounting module exists (transaction accounts, transactions, cash-flow report), but there is no QuickBooks/Sage/NetSuite export format or GL mapping. https://my.nexopos.com/en/documentation/user-guide/accounting · 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 is in the free core; recipe costing is a first-party vendor module ($20), not a separately contracted third-party product. https://my.nexopos.com/en/marketplace/item/raw-material-tracker · retrieved 2026-08-01

Joins recipe cost to actual item sales mix to report contribution margin per menu item, and flags items whose margin fell below a configured threshold after ingredient cost changes. differentiator

inventory-menu-margin-linkage

A profit report and a best-products report exist and, with Raw Material Tracker, cost is known per prepared item. No contribution-margin-by-item view with a configurable margin-breach flag. https://github.com/Blair2004/NexoPOS/tree/master/resources/ts/pages/dashboard/reports · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Dashboard widgets with day/month report jobs and a refresh-report event, reachable from any browser including a phone. No off-premise mobile app; computation is job/queue-driven rather than strictly live. https://github.com/Blair2004/NexoPOS/tree/master/app/Jobs · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Cash register opening/cashing/cashout/closing plus a daily computed report and a payment-types report cover most of it, but there is no single reconciling EOD document and no tips line. https://github.com/Blair2004/NexoPOS/tree/master/app/Fields · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Best-products and sold-stock reports give item-level quantity and sales. No modifier-level breakdown and no revenue-center filter. https://github.com/Blair2004/NexoPOS/tree/master/resources/ts/pages/dashboard/reports · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Upgraded from the uncited `no`, half of which was wrong. What exists: the orders table carries author_id, discount, discount_type, discount_percentage and a free-text voidance_reason with timestamps; OrdersService::void( Order $order, string $reason ) is documented as a public API endpoint ('Void Order' is one of the 121 headings at docs.api.nexopos.com) and its docblock says it voids 'by keeping a trace of what has happened'; App\Crud\OrderCrud renders an Author column and offers a filter on nexopos_orders.author_id alongside payment_status, so an operator can list voided orders by the employee who applied them; and manager approvals are separately persisted with the approver's identity in nexopos_permissions_access. NAMED SHORTFALL: none of this is a report. The ten shipped reports enumerated in routes/web/reports.php are sales, sales-progress, low-stock, sold-stock, stock-history, profit, transactions, annual, payment-types and customers-statement - there is no comps/voids/override report among them, no 'comp' concept anywhere in the product (word-boundary zero), no reason code on a discount or a price override, and no key joining a permission grant to the order it authorised. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_orders_table.php · retrieved 2026-09-05 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

Verified in source myself rather than taking the CRUD file at face value: RegisterHistory defines opening/closing/cash-in/cash-out/order-payment/refund actions with no explicit variance action, but CashRegistersService computes a session `$difference` from the closing value against the session's expected balance and passes it to the register-session view alongside closingBalance. Genuine per-session, per-cashier over/short. https://raw.githubusercontent.com/Blair2004/NexoPOS/master/app/Services/CashRegistersService.php · retrieved 2026-08-01 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

The shipped report set is enumerable and I enumerated it: routes/web/reports.php registers exactly ten report routes (sales, sales-progress, low-stock, sold-stock, stock-history, profit, transactions, annual-report, payment-types, customers-statement) and database/permissions/reports.php gates ten matching namespaces. None is a labor report, and none could be: there are no clocked hours in v6.2.2 - punch, timecard, timesheet and overtime are word-boundary zero over the tree and over the 3,412-key UI string table - so sales per labor hour and labor cost as a percentage of sales have no denominator. Labor exists only as the seeded 5102 'Salaries & Wages' expense account. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/routes/web/reports.php · retrieved 2026-09-05 adversarially verified

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

There is a real per-cashier surface, which the uncited `no` missed. ReportService::getCashierDashboard( int $cashier, ... ) returns, for one cashier and a date range, Total Orders and Today's Orders, Total Sales and Today's Sales (sum of Order::paid()->where('author_id', $cashier)->sum('total')), Total and Today's Refunds, Total and Today's Customers, Member Since, and - only if the NsCommissions module is enabled - today's and total earned commissions. Separately, getSaleReport(), getProductsReports() and getCategoryReports() all accept a $user_id filter, so the sales report can be scoped to one employee. NAMED SHORTFALL: three of the four metrics the claim names are absent. Average check is not computed (only the count and the total are returned, never the quotient); items per check is not computed; attachment rate for a named category does not exist in any form; and tips as a percentage of sales is impossible because there is no tip column on an order at all. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/ReportService.php · retrieved 2026-09-05 adversarially verified

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

Confirmed the migrated rationale from source. App\Models\Order declares exactly two order types, TYPE_DELIVERY = 'delivery' and TYPE_TAKEAWAY = 'takeaway', and both are in-house: there is no dine-in type, no online-ordering channel and no marketplace concept. DoorDash, Uber Eats, Grubhub, Deliverect, Chowly, Otter and Checkmate are word-boundary zero across the whole checkout - the only matches for 'uber' and 'otter' anywhere are the la-uber and la-otter glyph names inside the Line Awesome icon font, which I opened. There is therefore no commission or marketplace-fee column to net out, and the reporting layer has no channel dimension either: ReportService::getSaleReport( $start, $end, $type, ... ) switches $type between 'products_report', 'categories_report' and 'categories_summary', never a fulfillment channel. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/Order.php · retrieved 2026-09-05 adversarially verified

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

The most interesting row in my set, and it sharpens the migrated rationale rather than repeating it. NexoPOS's Report Settings page contains exactly one field: a switch named ns_reports_email labelled 'Enable Email Reporting', described as 'Determine if the reporting should be enabled globally.' It is an ORPHAN. I traced the option name across the entire checkout (excluding .git, node_modules and vendor) and it appears on exactly two lines, both inside this same settings form - the field's own 'name' key and the ns()->option->get() call that renders its current value. Nothing reads it. There is consequently no cadence setting, no recipient list, no per-report subscription and no shared destination anywhere, and app/Mail holds five classes, all account lifecycle (ActivateYourAccount, PasswordRecovered, ResetPassword, UserRegistered, Welcome) - not one report mailable. Cron does compute reports (routes/console.php enqueues ten jobs, and DashboardDay/DashboardMonth rows are built on a schedule), but computing is not delivering. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Settings/reports/general.php · retrieved 2026-09-05 adversarially verified

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

Public REST API with self-serve bearer tokens covers orders, order payments and refunds, products/menu, customers, procurements, registers, reports and rewards. Labor data does not exist to expose. https://docs.api.nexopos.com · retrieved 2026-08-01

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

The API documentation has no webhook section and the repository contains no webhook dispatch code. https://docs.api.nexopos.com · 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

API ships in the free GPL-3.0 core; no plan, per-location fee or revenue share gates it. https://github.com/Blair2004/NexoPOS · 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

All reports ship in the free core. Multi-location comparison is the only reporting behind a paid module ($42 Multistore). https://my.nexopos.com/en/marketplace · 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

Re-evidenced from source after the cited requirements page turned out to say nothing about retention. ReportService::getProductsReports() and getCategoryReports() build their query as Order::paymentStatus(PAID)->from($start)->to($end) — transaction-level order and order-product rows, over an operator-supplied range with no floor; the Sale Report UI (resources/ts/pages/dashboard/reports/ns-sale-report.vue) exposes that range as two unbounded ns-date-time-picker fields. getYearReportFor(int $year) accepts any year in 2019-2099 and ns-yearly-report.vue lets the operator recompute a past year on demand via POST /api/reports/compute/yearly. The only truncate() in app/Jobs is PurgeOrderStorageJob, which clears the OrderStorage scratch table, not order history; nothing prunes orders. No vendor archive-retrieval fee is possible because the data sits in the operator's own MySQL/MariaDB. Caveat: the vendor documents no retention window in words, and the aggregate dashboard/monthly figures come from DashboardDay/DashboardMonth rows that only exist for periods when the operator's cron and Supervisor were actually running. https://raw.githubusercontent.com/Blair2004/NexoPOS/master/app/Services/ReportService.php · retrieved 2026-08-02 adversarially verified

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

Low-stock notification is the only threshold alert; no metric-deviation alerting. https://my.nexopos.com/en/documentation/user-guide/products/low-stock-notification · 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

Verified directly: app/Mcp/Servers/POSServer.php plus 19 tool classes (SearchOrders, SearchProductSales, GenerateReport, GetDashboardSummary, BulkUpdateProducts, UpdateSettings, SearchWalletHistory, …) and routes/ai.php is present in the repo tree. The dossier's '~18 tools' is 19. Partial is right — it is an external-client surface, not an in-product NL query UI. https://api.github.com/repos/Blair2004/NexoPOS/contents/app/Mcp/Tools · retrieved 2026-08-01 adversarially verified

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

A customer statement report exists, but no new-vs-returning counts, visit frequency or lifetime-spend cohorts. https://github.com/Blair2004/NexoPOS/tree/master/resources/ts/pages/dashboard/reports · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

forecast, forecasting, predict and projection are word-boundary zero across the entire checkout, not merely app/. ReportService's 28 public methods are all backward-looking aggregations over recorded orders and stock history - computeDayReport, computeDashboardMonth, getYearReportFor, getProductSalesDiff, getSaleReport, getCategoryReports, getStockReport, getAccountSummaryReport - and none projects forward. There is no forecast surface in the reporting UI and nothing for a scheduling or ordering workflow to consume, since neither of those workflows exists either. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

Foreclosed at the schema. The orders table enumerates every monetary column an order carries - discount, discount_type, discount_percentage, shipping, tax_value, total, voidance_reason - and there is no tip column, declared or charged. tip, tips and gratuity are word-boundary zero in code and across the 3,412 keys of lang/en.json. There is therefore no declared-versus-charged comparison, no pool distribution detail and no tip tax liability summary by jurisdiction; nor is there a tip pool, since there is no shift and no timekeeping. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_orders_table.php · retrieved 2026-09-05 adversarially verified

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

Resolving an unknown upward, but only to partial. The Multistore guide documents exactly two levels — a main/master dashboard and sub-stores reached through a store switcher, optionally on wildcard subdomains. There is no region/district/brand tier and no named hierarchy object. https://my.nexopos.com/en/marketplace/item/multistore-for-nexopos · retrieved 2026-08-01 adversarially verified

A corporate-level menu can be authored once and published to a chosen set of locations in a single action, with a publish/version history showing what was pushed, when, and by whom.

multi-location-central-menu-publish

The premise is wrong: the Multistore marketplace item page carries a full user guide (dashboard changes, sub-store creation via queue workers, access control, wildcard subdomains, Sanctum stateful-domain config). It states affirmatively that every store has its own Products, Product Categories, Customers, Customer Groups, Units, Providers, Procurements, Settings, Orders, Expenses and Notifications, and closes with 'Every store is isolated and therefore isn't sharing the same resources (products, orders, customers, etc).' That is affirmative documentation of the absence of central menu publish. https://my.nexopos.com/en/marketplace/item/multistore-for-nexopos · retrieved 2026-09-17 adversarially verified

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

Multistore docs show products and settings are per-store and unshared; there is no shared catalogue on which a price zone could operate, and no zone concept appears in the guide. https://my.nexopos.com/en/marketplace/item/multistore-for-nexopos · 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

330th, NEW SURFACE THAT FALSIFIES THE STANDING NOTE: the Multistore module's own documentation page carries SCREENSHOTS that no prior pass opened (prior passes read only the page's prose; the images are inside an EditorJS JSON payload in `data-initial-tab-data`, not in <img> tags, which is why an <img> scrape missed them). Downloaded and read as images 2026-09-18. EVIDENCE: https://my.nexopos.com/storage/2026/04/multistore-nexopos-4x-1024x549.jpg is the master dashboard the prose calls 'a new main dashboard' (header 'Warehouse', a 'Stores 2' switcher). IT IS AN ABOVE-STORE VIEW: three aggregate tiles 'Complete Sales EUR73.00 / Today: +EUR73.00', 'Income EUR67.03', 'Waste EUR0.00'; a 'Stores Income' panel listing EACH store side by side - 'Store B EUR67.03 | Complete Sales: EUR73.00 | Total Expenses: EUR0.00 | Total Taxes: EUR11.57' and 'StoreC EUR0.00 | Complete Sales: EUR0.00 | Total Expenses: EUR0.00 | Total Taxes: EUR0.00'; and an 'Other Details' panel with 'Total Expenses', 'Total Discounts', 'Partially Paid Orders (x0)', 'Total Taxes', each with a Yesterday comparison. So sales, expenses, taxes and discounts DO aggregate across stores in one screen, with a per-store income breakdown. SHORTFALLS (why partial, not yes): the same screenshot set shows the master-level sidebar is only Dashboard / Stores / Modules / Users (https://my.nexopos.com/storage/2026/04/create-store-nexopos-1024x493.jpg, 'Stores List' with columns Name, Status, Created At, Author) - there is NO Reports section above store level, so the ten per-store report pages stay inside a store; no labor and no item mix appear anywhere in the above-store view; no selectable set of locations (it is all stores or one store); no store-vs-store ranking and no variance flags. CAVEAT: the dashboard screenshot is captioned for the 4.x generation of the module (file name '...-4x-...'), while the shipped module is v6.2.1 (my.nexopos.com/api/nexoplatform/marketplace/items, item id 6, 2026-09-18); it is nonetheless the image the vendor publishes today on the item's live documentation tab. This supersedes the 328th hold's premise: the aggregate view is documented by the vendor, so the closed NsMultiStore source no longer has to be censused to reach partial. Retrieved 2026-09-18. https://my.nexopos.com/en/marketplace/item/multistore-for-nexopos/details · retrieved 2026-09-18 adversarially verified

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

CLAIM: gift cards issued at one location redeemable at any other, with outstanding-liability reporting and inter-store settlement. VERDICT: no. The Multistore documentation the old note could not open is now read and forecloses the cross-location limb, and no gift-card instrument exists. EVIDENCE: Multistore: "Each store benefits from nearly all the features available in single-store mode, while remaining fully isolated" ... "every store has its own components that include: | Products, | Products Categories | Customers, Customers Groups | Unit & Unit Groups | Providers, Procurements | Settings, | Orders" and "Every store is isolated and therefore isn't sharing the same resources (products, orders, customers, etc)". The nearest stored value (customer account credit, "Account History ... account funding", user-guide/customers/managing-customers) therefore lives in a per-store customer record another store cannot see. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "gift ?cards?" 0, "stored value" 0, "vouchers?" 1 (managing-payment-type: a store "may create payment types for Mobile Money, checks, vouchers" - a tender label, not an issued balance); core 6.2.2: "gift card" word-boundary 0 and no gift-card model among app/Models (prior note). Retrieved 2026-09-16. https://my.nexopos.com/en/marketplace/item/multistore-for-nexopos/details · retrieved 2026-09-16 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

The Multistore guide lists 'Customers, Customers Groups' among the components each store owns separately. Loyalty/rewards attach to customer records, so balances cannot be shared across stores. https://my.nexopos.com/en/marketplace/item/multistore-for-nexopos · retrieved 2026-09-17 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

CLAIM: one location/terminal operates 2+ brands with separate menus, receipts/branding and separately reportable revenue, on the same hardware and drawer. VERDICT: partial. EVIDENCE (vendor module doc, replacing "no public documentation"): Multistore "enables you to manage multiple stores within a single NexoPOS installation, all powered by one shared database"; "every store has its own components that include: | Products, | Products Categories | ... | Settings, | Orders | Expenses Category & Expenses"; "In order to access a store, you need to open the 'Stores' popup by clicking on the 'Stores' button on the top of every page ... When you access a sub store it looks like a single store"; optional per-store subdomains ("https://store-a.mypos.com"). So one device can run two brands as two stores with separate catalogues, settings (store logo/receipt settings are store settings) and orders. SHORTFALLS: (1) brands are switched between, not operated side by side - an order belongs to one isolated store and no shared drawer/register across stores is documented; (2) requires the paid Multistore module ($42); (3) nothing frames it as virtual or co-brands on one footprint, and no cross-brand consolidated P&L is documented (multi-location-consolidated-reporting stays unknown). WEAKER THAN IDEAL: a verifier may read "same drawer" as a hard conjunct and prefer no/unknown. Retrieved 2026-09-16. https://my.nexopos.com/en/marketplace/item/multistore-for-nexopos/details · retrieved 2026-09-16 adversarially verified

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

Core supports taxes, tax groups with multiple simultaneous rates, and inclusive vs exclusive VAT type selection. Per-location tax configuration and per-location exemptions are not documented. https://my.nexopos.com/en/documentation/user-guide/taxes-and-groups/creating-tax-and-tax-group · 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

Proposition: labor rules (overtime, breaks, predictive-scheduling compliance) configurable per location or location group and enforced at the terminal. There is no labor subsystem to configure. 'payroll', 'timecard', 'time clock', 'overtime' and 'attendance' are 0 files each across app, routes, database, config, resources/ts and the 3,412-key lang/en.json; none of the 26 permission definition files in database/permissions, the 40 CRUD classes in app/Crud, the 77 models in app/Models or the 27 API route files in routes/api defines an employee shift, timesheet or break entity, and the eleven reports enumerated in database/permissions/reports.php contain no labor report. Users exist only as authenticated operators with roles. Time-clocking in this ecosystem is a separate module, Blair2004/Clockin, whose own GitHub description is 'Simple clockin application for NexoPOS 4.x' - two major versions behind v6.2.2 - so even that floor does not reach the current product. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/permissions/reports.php · retrieved 2026-09-05 adversarially verified

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

Browser-based Laravel/Vue app served from the operator's own server; runs on any PC, tablet or phone with a browser, plus an optional Windows desktop build. The vendor sells no terminals. https://my.nexopos.com/en/documentation/self-hosted/getting-started/requirement · 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

Server requirements precisely published (PHP 8.2, MariaDB 10.11 / MySQL 8.4, Nginx or Apache, cron, Supervisor, Composer). Client OS versions, browser minimums and device specs are not stated. https://my.nexopos.com/en/documentation/self-hosted/getting-started/requirement · retrieved 2026-08-01

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

NexoPOS ships no device of any kind: it is a self-hosted PHP 8.2 / Laravel / Vue application the operator installs on their own server and reaches from a browser, and 'handheld' is word-boundary zero in code and across the 3,412-key UI string table. The claim's decisive element is an INTEGRATED CARD READER, and that is foreclosed architecturally, not merely unfound. The load-bearing fact is that NexoPOS accepts no cards. A payment type in this product is a bookkeeping label, not a rail: nexopos_payments_types has ten columns - label, identifier, priority, description, author_id, active, readonly, accounting_account_id, accounting_incoming_effect and timestamps - with no gateway, endpoint, credential, terminal or processor field, and emv, nfc, p2pe, pts, saq and pci are word-boundary zero across app/, routes/, database/, config/ and resources/ts. A device with an integrated reader therefore cannot exist for this product, and there is no drop or IP rating to publish for a device that is not sold. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_05_25_131104_create_nexopos_payments_types_table.php · retrieved 2026-09-05 adversarially verified

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

Foreclosed by its antecedent: there is no vendor handheld for a battery to be swapped in. NexoPOS is browser-delivered self-hosted software with no hardware line; 'handheld' and 'battery' are word-boundary zero in code and in the 3,412-key UI string table, and the product cannot ship a device with an integrated reader because it accepts no cards. The load-bearing fact is that NexoPOS accepts no cards. A payment type in this product is a bookkeeping label, not a rail: nexopos_payments_types has ten columns - label, identifier, priority, description, author_id, active, readonly, accounting_account_id, accounting_incoming_effect and timestamps - with no gateway, endpoint, credential, terminal or processor field, and emv, nfc, p2pe, pts, saq and pci are word-boundary zero across app/, routes/, database/, config/ and resources/ts. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. WEAKEST PART, stated plainly: the disjunct 'or the vendor publishes a rated battery life' is a publication fact, and the vendor's storefront is barred - I am resting on the antecedent being false rather than on having read the storefront. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_05_25_131104_create_nexopos_payments_types_table.php · retrieved 2026-09-05 adversarially verified

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

Two foreclosures. (a) There is no vendor handheld to carry a modem. (b) There is no failover to fall back to: NexoPOS has no offline mode at all - the record's hardware-offline-mode cell is already `no`, and I re-confirmed no service worker, no client-side store and no sync layer under resources/ts - so the app requires a live connection to the operator's own server and a connectivity fallback would have nothing to serve. lte, cellular, 4g, 5g and sim are word-boundary zero over app/, routes/, database/, config/ and resources/ts. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

Same evidence chain as above and the same defect. No client-side offline store, no service worker, no sync layer, and the vendor publishes no degradation matrix. Everything the Windows app does offline, it does because it IS the server. https://my.nexopos.com/en/marketplace/item/nexopos-for-windows · retrieved 2026-08-01 adversarially verified

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

Gastro ($45) is a first-party dedicated kitchen screen with touch input, multi-kitchen support and category routing. No bump-bar support and no course/fire timing. https://my.nexopos.com/en/marketplace/item/gastro-restaurant-extension-for-nexopos · 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

'kiosk' is word-boundary zero in app/, routes/, database/, config/, resources/ts AND across the 3,412 keys of lang/en.json - there is no self-order surface, no countertop or freestanding form factor, and no accessibility statement. The claim's integrated-payment element is additionally foreclosed: The load-bearing fact is that NexoPOS accepts no cards. A payment type in this product is a bookkeeping label, not a rail: nexopos_payments_types has ten columns - label, identifier, priority, description, author_id, active, readonly, accounting_account_id, accounting_incoming_effect and timestamps - with no gateway, endpoint, credential, terminal or processor field, and emv, nfc, p2pe, pts, saq and pci are word-boundary zero across app/, routes/, database/, config/ and resources/ts. I am also rewriting the migrated rationale, which said 'No kiosk SKU in the marketplace' - that is a statement about my.nexopos.com, a host this corpus may not read, and it is replaced by the core measurement above. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_05_25_131104_create_nexopos_payments_types_table.php · retrieved 2026-09-05 adversarially verified

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

drive thru, drive-thru, menu board, headset, speaker and order confirmation display are all word-boundary zero across app/, routes/, database/, config/, resources/ts and the 3,412-key lang/en.json UI string table, and there is no timer or speed-of-service measurement in ReportService or among the ten shipped report routes. NexoPOS's two order types are delivery and takeaway (App\Models\Order), with no drive-thru mode. Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

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

ESC/POS thermal printing via browser printing or the free Nexo Print Server Windows app plus the $15 NPS Adapter; operators report Epson and other brands. No published compatibility list, and printing is the most frequent bug theme in the tracker. https://my.nexopos.com/en/marketplace/item/nexo-print-server · 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

Barcode scanners (including a free Android scanner app and wireless-reader guide) and scales via weighted products plus scale-barcode ranges are supported. A customer-facing display module is an open roadmap issue; no published peripheral compatibility list; multi-drawer per terminal undocumented. https://my.nexopos.com/en/documentation/natives/barcode-utility/connecting-wireless-barcode-reader · 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

The strongest `no` in my set, and the migrated rationale was right. Card entry never occurs in NexoPOS. The load-bearing fact is that NexoPOS accepts no cards. A payment type in this product is a bookkeeping label, not a rail: nexopos_payments_types has ten columns - label, identifier, priority, description, author_id, active, readonly, accounting_account_id, accounting_incoming_effect and timestamps - with no gateway, endpoint, credential, terminal or processor field, and emv, nfc, p2pe, pts, saq and pci are word-boundary zero across app/, routes/, database/, config/ and resources/ts. A payment type merely records that money arrived and which accounting account it hit, so there is no PTS-listed device, no validated P2PE implementation, and no merchant SAQ type for the vendor to state - the product is never in the card data path at all, which is a different and stronger fact than 'the POS stays out of scope'. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_05_25_131104_create_nexopos_payments_types_table.php · retrieved 2026-09-05 adversarially verified

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

nfc, contactless, 'tap to pay' and 'tap on phone' are word-boundary zero across app/, routes/, database/, config/, resources/ts and the 3,412-key UI string table - I searched the vendor's spelling as well as mine. The capability is foreclosed upstream in any case: The load-bearing fact is that NexoPOS accepts no cards. A payment type in this product is a bookkeeping label, not a rail: nexopos_payments_types has ten columns - label, identifier, priority, description, author_id, active, readonly, accounting_account_id, accounting_incoming_effect and timestamps - with no gateway, endpoint, credential, terminal or processor field, and emv, nfc, p2pe, pts, saq and pci are word-boundary zero across app/, routes/, database/, config/ and resources/ts. NexoPOS does run on a commodity phone (it is a browser app), but what it does there is record a payment, never accept one. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_05_25_131104_create_nexopos_payments_types_table.php · retrieved 2026-09-05 adversarially verified

Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator

hardware-pricing-transparency

NexoPOS sells no hardware, so there are no SKU prices to publish. https://my.nexopos.com/en/marketplace · 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

No vendor hardware and therefore no lease or bundled rental; the operator buys and owns all devices outright from third parties. https://my.nexopos.com/en/marketplace · 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

CLAIM: vendor documentation confirms whether hardware PURCHASED FROM THE VENDOR stays usable after cancellation. VERDICT: unknown (refreshed; vacuous for this vendor). NEW: the full marketplace (32 items) is now censused and confirms there is no vendor hardware to lock. Nearest vendor statements, both grade C blog prose: "The restaurant decides how the environment is accessed and maintained instead of receiving a single locked hardware-and-software package" (self-hosted-restaurant-pos-solutions) and "lets a restaurant choose its hosting environment, compatible hardware, payment workflow, and extensions" (how-much-does-a-restaurant-pos-system-cost). They say the buyer's own hardware is not tied to NexoPOS, but the claim's subject (vendor-sold hardware) does not exist, and a differentiator yes needs A/B. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. Recommend a scope override for hardware-free vendors rather than a value. Retrieved 2026-09-16. || 330th: 330th, NEW SURFACE (still unknown, still vacuous): the marketplace is now held as a MACHINE-READABLE enumeration rather than as scraped HTML - the anonymous, unlinked API the core's own MarketplaceService.php calls (app/Services/MarketplaceService.php at v6.2.3 hard-codes 'https://my.nexopos.com' . '/api/nexoplatform/marketplace/items') returns a single page, meta.total = 24, one row per published product with an explicit `type` field. Every one of the 24 is software: 23 are type 'zip' (PHP modules: NsGastro, NsMultiStore, NsPrintAdapter, NsPinLogin, NsOxen, NsQrMenu, NsRentals, NsAppointments, NsSMS, NsWhatsAppNotification, NsRawMaterial, NsStockTransfers, NsBulkImporter, NsBulkEditor, NsCommissions, NsRacksManager, NsSocialite, NsEmail, NsOptionsExporter, NsImageOptimizer, NsAiThumbnail, GoogleAuthenticator, GoogleRecaptcha) and one is type 'electron' (NexoPOS Client for Windows). There is no hardware SKU, no `type` value denoting a device, and the vendor's second sales channel found this session - the hosted SaaS at nexopos.cloud ('Nexo SaaS', Stripe-billed installations, bundles Restaurant Essentials / Standard / Oxen Essential at $10-15/month) - sells hosting and modules only. The claim's subject (hardware purchased from the vendor) does not exist, so the cell is vacuous rather than answerable; recommend a scope override for hardware-free vendors. Retrieved 2026-09-18. adversarially verified

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

CLAIM: publishes a hardware warranty term and a replacement/advance-exchange SLA with stated turnaround. VERDICT: no. The robots bar the old note deferred to is gone, and nexopos.com is not a live vendor surface: Wayback CDX shows it answering 301 from 2024-01 to 2025-02 and 522 from 2025-08; it returned 522 again today. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. The vendor sells no hardware: all 32 marketplace items are software, and its own content positions devices as the buyer's choice ("lets a restaurant choose its hosting environment, compatible hardware, payment workflow, and extensions"; software figures "exclude hosting, POS hardware, installation", blog how-much-does-a-restaurant-pos-system-cost). The Terms of Use (sections 1-8.2) define Software as "NexoPOS, NexoPOS Cloud, NexoPOS for Windows, Nexo Print Server, modules, plugins, and downloadable applications" - no hardware. CONTROLS: "warrant(y|ies)" 0 (POISON: the raw substring "warrant" once = "you represent and warrant", Terms s.2), "RMA" 0, "replacement" 4 (a buyer cost list "replacement hardware", Oxen token replacement, a receipt-tag replacement). No warranty or RMA is published because no hardware is sold; a scope override for hardware-free vendors remains the structural fix. Retrieved 2026-09-16. https://my.nexopos.com/en/help/terms-of-use · retrieved 2026-09-16 adversarially verified

Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.

hardware-byod

Any staff phone with a browser reaches the LAN server, and the free Barcode Utility runs on staff Android phones. Security model is role/permission based with an optional PIN Login module; no MDM or device-trust model documented. https://my.nexopos.com/en/documentation/developers-guide/how-to/local-network-configuration · 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

There is no device entity in v6.2.2 to manage. The nearest surface, and the reason this needs saying rather than a bare zero, is App\Models\Register: a cash register with a status enum of opened, closed, disabled and in-use plus a used_by user id. That is a TILL SESSION bound to a cashier, not a device heartbeat - the four states are set by a human opening or cashing out a register, never by the terminal reporting in. Beyond it: no printer is registered anywhere (printing is browser window.print() via VueHtmlToPaper, imported at resources/ts/app-init.ts:15, with the printing gateway select in app/Settings/pos/printing.php offering exactly one core option, 'Default Printing (web)'), no KDS entity exists in core, 'reboot' is word-boundary zero over the tree, no software version is reported per client (the daily version check in routes/console.php polls GitHub for the SERVER's own NexoPOS version), and there is no staged-rollout mechanism. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/Register.php · retrieved 2026-09-05 adversarially verified

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

Careful with this one, because the word 'scale' is a trap here: it matches 29 files, and I opened them - every one is a WEIGHING scale, not a beverage flow device. NexoPOS supports weighed products through an ns_scale_barcode_enabled switch (the cited line), a ScaleRange model and a GenerateScaleBarcodeCommand that encodes weight or price into an embedded barcode. The claim's actual vocabulary is absent: pour, keg, tap, 'flow meter', flowmeter and 'self-pour' are word-boundary zero across app/, routes/, database/, config/ and resources/ts, and there is no open-tab-with-automatic-posting mechanism - the nearest thing is a held order, which a cashier posts by hand. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Settings/pos/features.php · retrieved 2026-09-05 adversarially verified

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

caller, 'caller id', callerid, telephony, CTI, SIP, Twilio and 'incoming call' are all word-boundary zero across app/, routes/, database/, config/ and resources/ts, and zero across the 3,412 keys of lang/en.json. Customers do have a phone field, but nothing consumes it as an inbound identifier: there is no call event among the 169 classes in app/Events, no screen-pop route among the 27 files in routes/api/, and no telephony driver in config/ (which holds app, auth, broadcasting, cache, cors, database, filesystems, hashing, logging, mail, medias, nexopos, queue, reverb, sanctum, services, session, telescope and view). Re-derived the census myself: GET https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 answers "truncated": false with 3,536 blobs and 208 trees (the brief's '3,744 blobs' is blobs+trees; the local checkout's git ls-files agrees at 3,536), so an absence measured over it is the publisher's own manifest, not a crawl floor. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://api.github.com/repos/Blair2004/NexoPOS/git/trees/v6.2.2?recursive=1 · retrieved 2026-09-05 adversarially verified

Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.

extensibility-public-api-docs

docs.api.nexopos.com is fully readable with no login, NDA or sales call, covering categories, customers, products, orders, medias, modules, notifications, fields/forms and a generic CRUD endpoint. https://docs.api.nexopos.com · 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

The API is part of the free GPL-3.0 core; no plan to upgrade to and no per-location fee. https://github.com/Blair2004/NexoPOS · 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

There is no vendor-hosted sandbox. demo.nexopos.com is a hard 404 (Laravel 'Not Found', 6,609 bytes, re-probed 2026-08-09) and no demo instance is referenced anywhere on my.nexopos.com any more, so that citation is withdrawn. What a developer can actually get for free, and the shortfall: the GPL-3.0 core ships FirstDemoSeeder.php in database/seeders, which calls RewardSystemSeeder, CustomerGroupSeeder, TransactionSeeder and FirstExampleProviderSeeder to populate a working instance with sample customers, transactions and providers; and the marketplace's NexoPOS For Windows listing offers a 'Free version: includes watermark on printed receipts' against a 'Premium version: removes watermark for production use' ($39). Neither is a hosted environment -- both oblige the evaluator to install and run their own PHP 8.2 + MySQL stack or desktop build. Seeded test data yes, zero-effort sandbox no. Partial. https://github.com/Blair2004/NexoPOS/blob/master/database/seeders/FirstDemoSeeder.php · retrieved 2026-08-09 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

Auth is Laravel Sanctum bearer tokens generated in the user profile, individually revocable but not scope-partitioned per third-party app, and non-expiring by default. Docs label this 'OAuth 2.0 or JWT'; true scoped operator-granted OAuth is not present. https://docs.api.nexopos.com · 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

Confirmed independently: I fetched docs.api.nexopos.com anonymously (no login wall) and the reference covers Authentication, Categories, Customers, Customer Groups, CRUD, Fields, Forms, Medias, Modules, Notifications, Products, Orders and User — no webhook, callback or subscription section, no rate-limit documentation, and it states tokens 'don't expire until manually revoked'. routes/ contains channels.php (Laravel broadcasting) but that is in-process/websocket, not outbound webhooks. Also upholds extensibility-public-api-docs, extensibility-published-rate-limits and extensibility-oauth-partn https://docs.api.nexopos.com · retrieved 2026-08-01 adversarially verified

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

I opened the single 'webhook' hit the brief flagged, and it is not an outbound webhook. It is one line in the CSRF middleware exempting a 'webhook/*' URI prefix - an affordance for a module that wants to RECEIVE a callback, and no route in the product registers under that prefix. Across the whole checkout, 'webhook' appears in only five files: this one, composer.lock, config/logging.php (Laravel's LOG_SLACK_WEBHOOK_URL), a module-authoring instructions file using 'mymodule_webhook_url' as an example option name, and rental.md - which is a 2,098-line SPEC for an unbuilt commercial Rental module, not shipped code. So there is no outbound dispatcher, no signing secret, no HMAC header, no retry queue and no delivery log, and the 121-heading API reference at docs.api.nexopos.com has no webhook, callback or subscription section. Signing, backoff and replay cannot be documented for a delivery mechanism that does not exist. What NexoPOS offers instead is IN-PROCESS extensibility, and it is genuinely deep: 169 event classes in app/Events, 58 listeners in app/Listeners, and 213 Hook::filter call sites over 69 distinct filter names (the Eventy library) - all consumable only by PHP modules running inside the same application. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Http/Middleware/VerifyCsrfToken.php · retrieved 2026-09-05 adversarially verified

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

The orders API supports creating orders with payments, refunds, instalments and delivery tracking; injected orders are first-class order records. https://docs.api.nexopos.com · retrieved 2026-08-01

Menu items, modifiers, and prices can be written and updated via API, not just read. differentiator

extensibility-menu-write-api

Products, units, procurements and categories all support full CRUD via the API, not read-only. https://docs.api.nexopos.com · 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

DoorDash, Grubhub, Deliverect, Chowly, Checkmate and ItsaCheckmate are word-boundary zero across the entire checkout. 'uber' and 'otter' are the only apparent non-zeros and I opened both: every match is a glyph id inside the bundled Line Awesome icon font (la-uber, la-otter) or the word 'lottery' in Laravel's session config - reader artefacts, not integrations. Positively, App\Models\Order declares exactly two order types, delivery and takeaway, both in-house, with no marketplace order source, no external order id, no commission field and no menu-publishing route among the 27 files in routes/api/. This is consistent with the record's already-settled extensibility-doordash-preferred cell, where DoorDash's own 2026 Preferred cohort is enumerated by name and NexoPOS is absent. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Models/Order.php · retrieved 2026-09-05 adversarially verified

The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).

extensibility-middleware-compatibility

Proposition: NexoPOS is a supported endpoint for at least two of Deliverect, Chowly, Otter, Checkmate and ItsaCheckmate. Measured on all four distinct companies' OWN publisher manifests rather than on a crawl, and every one answers zero. Deliverect's sitemap.xml (2,200,465 bytes, one flat urlset, 10,162 <loc>, 3,289 under /integrations/) contains no 'nexo' while /en/integrations/hippos and /en/integrations/toast are present and live and /en/integrations/nexopos 404s. Chowly's sitemap.xml (32,874 bytes, 167 <loc>) contains no 'nexo'; its POS partnership pages are /partnerships/toast/, /partnerships/spoton/ and /partnerships/square/. Otter's sitemap.xml is an index whose sitemap-integrations-en-us.xml holds 77 <loc> with no 'nexo' against a live slug convention (/integrations/4soft, /integrations/7shifts, /integrations/appfront); /integrations/nexopos returns 404. ItsaCheckmate's sitemap.xml is a flat urlset of 351 <loc> with no 'nexo'; /pos-integration/toast is present and /pos-integration/nexopos returns 404. Checkmate and ItsaCheckmate are the same company. All four hosts permit ClaudeBot. Corroborated from the NexoPOS side: Deliverect, Chowly, Otter, Checkmate and ItsaCheckmate are word-boundary zero across the entire v6.2.2 checkout. https://www.deliverect.com/sitemap.xml · retrieved 2026-09-05 adversarially verified

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

An internal accounting module exists (transaction accounts, cash-flow reporting) but there is no QuickBooks Online or other GL connector with mapped journal entries. https://my.nexopos.com/en/documentation/user-guide/accounting · 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

There are no labor hours in v6.2.2 to export to anyone. payroll, timecard, timesheet, punch, overtime and attendance are word-boundary zero across app/, routes/, database/, config/, resources/ts and the 3,412-key lang/en.json UI string table; Gusto, ADP, Paychex and Paylocity are word-boundary zero across the whole checkout. Labor appears in the product exactly once, as an accounting expense line: TransactionService seeds account 5102 'Salaries & Wages' under operating_expenses, a figure an operator types in. The export surface itself is enumerated by the vendor - the API reference's Available Components table under #export-entries lists what GET api/crud/{namespace}/export can emit (customers, customer groups, customer orders, product categories, procurements, procurement products, payment types, coupons, order-history CRUDs) and there is no timecard component in it. Scoped to the GPL core at v6.2.2: NexoPOS's entire commercial storefront is robots-barred to this corpus - my.nexopos.com and demo.nexopos.com are in data/robots-bars.json, and I re-read https://www.nexopos.com/robots.txt myself today (1,836 bytes), which carries 'User-agent: ClaudeBot' / 'Disallow: /'. A paid module may supply this; that question cannot be asked. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/TransactionService.php · retrieved 2026-09-05 adversarially verified

The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.

extensibility-app-marketplace

A public, no-login marketplace with in-dashboard install genuinely exists, so yes stands — but '30+ apps' is unverified and probably generous. The live index surfaces roughly 15 distinct items across Recommended / Recents / Most Downloaded, several of which are not POS extensions at all (Football Academy Laravel App, Website Explorer SaaS, BellSera marked 'Coming Soon'). Depth is thin: Gastro 2 downloads / 8 ratings, Raw Material Tracker 2 / 5, Multistore 8 / 2, Stock Transfers 0, NexoPOS For Windows 155. https://my.nexopos.com/en/marketplace · retrieved 2026-08-01 adversarially verified

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

Write-capable orders and products API plus full source access makes headless operation technically achievable, but the vendor documents no headless/embedded mode or reference pattern. https://docs.api.nexopos.com · 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

Self-hosted operators hold the entire MySQL/MariaDB database themselves; there is nothing to request and no exit event. CRUD exports and the REST API provide documented machine-readable access on top. The vendor API reference states the export mechanism verbatim at #export-entries (GET api/crud/{namespace}/export): "Use this endpoint to extract as a CSV document all the entries of a CRUD component." The same page's Available Components table enumerates the components that endpoint covers, and they are the business record set rather than a subset — Customers, Customers Group, Customer's Orders, Products Categories, Procurements, Procurements Products, Payment Types, Coupons and the order-history CRUDs, each named with its App\Models\*Crud class. The self-hosted database half is in the source tree: .env.example ships DB_CONNECTION=mysql with DB_HOST=127.0.0.1, so the datastore is the operator's own by default and there is no vendor-held copy to request on exit. RE-EVIDENCED 2026-08-30: the cell previously rested on https://my.nexopos.com/en/documentation/self-hosted/getting-started/requirement, which is quarantined behind a host-wide robots bar on my.nexopos.com ("claudebot / Disallow: /", re-measured 2026-08-16) and was NOT re-fetched. The barred page is not recovered; a different document on a permitted host was found to carry the same proposition, so the quarantine stamps come off and the grade is set from the new source rather than restored from grade_before_quarantine. docs.api.nexopos.com serves no robots.txt (404, 25 bytes, body "No input file specified." — a PHP error, classified not-robots by scripts/lib/robots.mjs, so unavailable under RFC 9309 rather than absent-and-silent); raw.githubusercontent.com and api.github.com likewise 404; github.com robots.txt was parsed whole and returns not-refused for the repo and blob paths. No verification.jsonl row was added: a re-citation is not an adversarial pass. https://docs.api.nexopos.com/ · retrieved 2026-08-30

Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.

reliability-offline-order-entry

Downgraded for consistency with the two cells above: there is no offline order entry. The genuine resilience story — a LAN-hosted server that survives an internet outage — is already scored correctly and separately at reliability-lan-degraded-multi-terminal (partial, upheld). Counting it twice inflates the offline picture. https://api.github.com/repos/Blair2004/NexoPOS/contents/public · retrieved 2026-08-01 adversarially verified

Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator

reliability-offline-card-auth

Proposition: card payments accepted while offline via store-and-forward, not just cash-only fallback. Two independent foreclosures. (1) No card authorization exists even online: OrdersService validates a payment only by checking its identifier against the active PaymentType label list, and composer.json's 31 requires name no processor SDK. (2) No offline path exists at all: the POS submits every order synchronously to /api/orders from pos-init.ts:1145, with no service worker, no IndexedDB and no replay queue; word-boundary 'offline' returns 0 files across the vendor's own source directories and matches only third-party transport bundles repo-wide. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

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

Proposition: the vendor publicly documents loss allocation for a store-and-forward decline after reconnect and states any per-transaction or cumulative offline cap. There is no store-and-forward feature, hence no policy: order submission is a single synchronous HTTP call to the authoritative Laravel server, there is no local queue, and no card is ever authorized. The documented API (121 headings, 27 of them Orders endpoints) contains no offline, replay, cap or failed-payment-report endpoint, and no offline setting exists among the eight files in app/Settings/pos (actions, features, layout, printing, registers, scale-barcode, shortcuts, vat). https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

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

The documented deployment pattern puts the server on the local network with all terminals reaching it by LAN IP, so terminals share one check state independently of the internet. The vendor frames this as a setup guide, never as offline resilience, and publishes no degradation behaviour. https://my.nexopos.com/en/documentation/developers-guide/how-to/local-network-configuration · 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

On-premise is the default and primary deployment: the operator runs the full Laravel transaction engine on their own server (or a Windows machine via the desktop build). Cloud is the optional variant. https://my.nexopos.com/en/documentation/self-hosted/getting-started/installation · retrieved 2026-08-01

Kitchen display and/or kitchen printer routing continues to function while offline.

reliability-offline-kds-printing

Nexo Print Server is a local Windows printing daemon and the Gastro kitchen screen talks to the same LAN server, so both survive an internet outage in a LAN deployment. Not documented as an offline guarantee, and printing reliability is the top complaint theme. https://my.nexopos.com/en/marketplace/item/nexo-print-server · 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 backup printer or fallback KDS routing. Issue history shows unhandled 'unsupported print gateway' and silent print failures. https://github.com/Blair2004/NexoPOS/issues?q=is%3Aissue · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

Proposition: the vendor documents conflict-resolution behaviour for edits made on two devices during a network partition. The architecture makes the partition case non-existent rather than merely undocumented: terminals are browser SPAs holding no durable local state, and every mutation is an immediate HTTP call to one authoritative MySQL-backed server (pos-init.ts:1145 for orders). Word-boundary searches over app, routes, config and resources/ts for conflict, 'last.write', replica, failover and cluster return no product-code hits — the only cluster matches are the Pusher and Redis connection settings in config/broadcasting.php:55 and config/database.php:125 plus a stray `import { Address } from "cluster"` in resources/ts/interfaces/order.ts. The uncited rationale is upheld with documents. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

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 document on my.nexopos.com enumerates which features are unavailable offline. https://my.nexopos.com/en/documentation · retrieved 2026-08-01

A public, per-component status page exists showing current and historical incident state without a login.

reliability-public-status-page

CLAIM: a public per-component status page with current and historical incidents. VERDICT: no. The gates the old note named are gone or dead: my.nexopos.com robots.txt is now "User-agent: * / Disallow: /cdn-cgi/", and nexopos.com is not a live vendor surface: Wayback CDX shows it answering 301 from 2024-01 to 2025-02 and 522 from 2025-08; it returned 522 again today. EVIDENCE: (1) the hosted service nexopos.cloud (a Nexo SaaS instance, "Hosted NexoPOS, managed for you") ships its Laravel Ziggy route table in the homepage HTML: 177 named routes including admin (74) and horizon (22), i.e. unfiltered; the public routes are home, pricing, legal.terms, legal.refunds plus auth - no status/incident/uptime route; its footer columns are Product (Home, Pricing), Account, Legal (Terms of Service, Refund Policy). (2) status.nexopos.cloud returns the same Nexo SaaS SPA shell as a nonsense subdomain (zzqq.nexopos.cloud 200, 57,386 B vs 57,396 B) - a wildcard catch-all, not a status page. (3) status.nexopos.com and status.my.nexopos.com do not resolve; nexopos.statuspage.io, nexopos.instatus.com and nexopos.betteruptime.com redirect to the providers' homepages; stats.uptimerobot.com/nexopos is 404. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "status page" 0, "statuspage" 0, "system status" 0, "outages?" 1 (Terms 8.1 "Third-party outages"), "incidents?" 2 (Terms 8.1; a Singapore PDPA blog). Terms 8.1: "While the Company aims to provide reliable hosting services, uptime is not guaranteed." Retrieved 2026-09-16. https://nexopos.cloud/ · retrieved 2026-09-16 adversarially verified

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 ticket-based plus WhatsApp/Telegram community channels. The FAQ further limits it: only the latest two major versions are supported, and no support is provided if the core has been edited. https://my.nexopos.com/en/faq · 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

Installation is entirely self-service via written guides; no first-party or dealer on-site go-live service is offered. https://my.nexopos.com/en/documentation · retrieved 2026-08-01

The vendor performs the initial menu build as part of onboarding rather than leaving it entirely to the operator. differentiator

reliability-menu-build-service

No menu-build or data-entry service; a Bulk Importer module exists for the operator to do it themselves. https://my.nexopos.com/en/marketplace · retrieved 2026-08-01

A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.

reliability-hardware-replacement-sla

Proposition: a hardware replacement or advance-exchange programme with a stated turnaround is included or purchasable. The vendor's own scoping sentence enumerates what the ecosystem consists of — free core, official modules, mobile companion applications, desktop utilities, developer tools, documentation and services — and hardware is not among them. Every named first-party product in README.md is software: Gastro, Raw Material Tracker, Multistore, Stock Transfers, Racks Manager, Bulk Importer, Sales Commissions, WhatsApp Notification, Barcode Utility, NexoPOS Authorizer and NexoPOS For Windows. Consistent with the record's existing commercial-hardware-purchase-outright: all hardware is third-party commodity equipment the operator buys. With no hardware sold there is nothing to advance-exchange. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/README.md · retrieved 2026-09-05 adversarially verified

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

CLAIM: vendor publishes a current PCI DSS v4.0/4.0.1 AoC or equivalent (P2PE listing). VERDICT: no. The hosts the old note could not read are now read: my.nexopos.com (robots now "User-agent: * / Disallow: /cdn-cgi/") in full, and nexopos.cloud; nexopos.com is not a live vendor surface: Wayback CDX shows it answering 301 from 2024-01 to 2025-02 and 522 from 2025-08; it returned 522 again today. EVIDENCE: the POS handles no card data - it records tenders only ("Creating a payment type does not automatically connect NexoPOS to an external payment provider", user-guide/orders/managing-payment-type) - and for the vendor's own billing the Privacy Policy says "Payments are processed securely through third-party payment processors including Stripe and PayPal. We do not store full credit card information on our servers." The hosted service publishes no legal documents at all: nexopos.cloud/legal/terms and /legal/refunds render page props {"unavailable":true,"document":null} with "terms_published":false. CORPUS: the whole of my.nexopos.com as the vendor publishes it - its robots.txt is now only "User-agent: * / Disallow: /cdn-cgi/" (the ClaudeBot bar earlier notes cite is gone). The sitemap index (/sitemap.xml -> 6 child maps: 19 blog, 3 bundles, 8 categories, 144 docs, 11 pages, 128 product URLs = 313) was fetched in full, all 313 HTTP 200; a nonsense path returns 404 (31,269 B), so no soft-200. Href fixpoint over every body: 19 /en/documentation/ hrefs are not in the sitemap - 10 are 301s onto sitemap pages, 5 are 404 retired slugs (base-api/hook-system, components/table-component, 3 under my-nexopos/), 4 are 200 and were added (cloud-hosting, developers-guide/fields, natives/nexopos-for-windows, user-guide/accounting); the marketplace category pages list one item slug absent from the sitemap (nexopos-client-for-windows), also added. 318 pages, zero 401/403: a census. The marketplace holds 32 items, every one a software module/app. Controls tokenised on non-alphanumeric boundaries, case-insensitive, over script/style/comment-stripped text. CONTROLS: "pci" 0 tokenised (POISON: the raw substring "pci" hits 7 files, e.g. "opciones" in a Spanish blog slug); "attestation" 0; "p2pe" 0. Core 6.2.2: "pci dss"/"p2pe" 0 (prior note). Retrieved 2026-09-16. https://my.nexopos.com/en/help/privacy · retrieved 2026-09-16 adversarially verified

Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.

reliability-mfa-role-based-access

Role-based permissions are granular and strong. No MFA implementation exists in the codebase for back-office or POS admin logins; the optional PIN Login module reduces rather than adds authentication strength. https://my.nexopos.com/en/documentation/developers-guide/roles-permissions/creating-roles · 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

A free public documentation library covers products, POS, taxes, procurement, customers and troubleshooting. No video/LMS curriculum and no terminal training mode; a demo instance serves as the practice environment. https://my.nexopos.com/en/documentation · 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

Proposition: any terminal can assume the master/server role automatically if the primary terminal or local server fails. Terminals are browser clients, not peers: they hold no durable state and every order goes over HTTP to the single Laravel/MySQL server (pos-init.ts:1145). Word-boundary failover, replica, 'high availab' and heartbeat return zero hits across app, routes, config and resources/ts; the only repo-wide 'failover' occurrence is a generic line in a bundled Laravel best-practices skill document (.agents/skills/laravel-best-practices/SKILL.md:60, 'Failover cache stores in production'), which is authoring guidance, not a product feature. The uncited rationale is upheld with documents. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/ts/pos-init.ts · retrieved 2026-09-05 adversarially verified

Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.

reliability-cellular-backup

Proposition: terminals support an automatic cellular/LTE failover for connectivity, first-party or documented. Two failures. (1) The vendor ships no terminals — its published ecosystem is core, modules, mobile companion apps, desktop utilities, developer tools, documentation and services, and its only first-party mobile apps are a barcode-scanner utility and a permission authorizer. (2) The core has no connectivity-management surface at all: word-boundary 'cellular' returns 0 files repo-wide and '\blte' matches only a minified third-party bundle, with no network-failover setting among the eight files in app/Settings/pos. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/README.md · retrieved 2026-09-05 adversarially verified

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

The core POS is GPL-3.0 and free with no subscription at all; there is no term to commit to. Cloud/subscription services are monthly or annual per Terms section 7. https://github.com/Blair2004/NexoPOS · 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 ETF or liquidated-damages clause appears in the published Terms, and the free core has nothing to terminate. But the Terms never affirmatively state 'no early termination fee', and the published document appears truncated after section 8.2. https://my.nexopos.com/en/help/terms-of-use · 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

Terms section 7 publicly discloses automatic recurring billing until cancellation, monthly or annual billing, and consequences of non-payment. It does not state a required cancellation notice window. https://my.nexopos.com/en/help/terms-of-use · 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

There is no in-house processing to lock to. Operators run any external terminal or gateway and record the result as a payment type. Positive evidence of absence, from two permitted primary sources rather than from not having found one. (1) The API reference makes payment methods an operator-managed record, not a vendor product: #get-supported-payments-method (GET api/orders/payments) — "This provide a list of payments that are available on the system" — and Payment Types appears in the Available Components table as App\Models\PaymentTypeCrud, i.e. a CRUD entity the operator creates and edits like customers or categories. (2) The dependency manifest names no payment processor at all: composer.json's require block is 30 entries (laravel/framework, laravel/sanctum, laravel/reverb, dompdf, phpspreadsheet, predis, pusher, guzzle, the PHP extensions) and contains no Stripe, Adyen, Square, PayPal or Braintree SDK, so there is no bundled processor in the shipped code to be locked to. NOTE ON A VENDOR SELF-CONTRADICTION found while reading it: composer.json declares "license": "MIT" while the repository's LICENSE file is GPL-3.0 (35,149 bytes, "GNU GENERAL PUBLIC LICENSE Version 3") and the GitHub API reports spdx_id GPL-3.0. The record's GPL-3.0 statement is the correct one; the manifest field is stale. This affects no claim value. RE-EVIDENCED 2026-08-30: the cell previously rested on https://my.nexopos.com/en/documentation/user-guide/orders/managing-payment-type, which is quarantined behind a host-wide robots bar on my.nexopos.com ("claudebot / Disallow: /", re-measured 2026-08-16) and was NOT re-fetched. The barred page is not recovered; a different document on a permitted host was found to carry the same proposition, so the quarantine stamps come off and the grade is set from the new source rather than restored from grade_before_quarantine. docs.api.nexopos.com serves no robots.txt (404, 25 bytes, body "No input file specified." — a PHP error, classified not-robots by scripts/lib/robots.mjs, so unavailable under RFC 9309 rather than absent-and-silent); raw.githubusercontent.com and api.github.com likewise 404; github.com robots.txt was parsed whole and returns not-refused for the repo and blob paths. No verification.jsonl row was added: a re-citation is not an adversarial pass. https://docs.api.nexopos.com/ · retrieved 2026-08-30

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

Proposition: the vendor publishes an interchange-plus option with the markup stated as a specific bps plus per-transaction figure. NexoPOS is not an acquirer: the only payment machinery in the core validates an operator-created identifier string and records an amount against an accounting account, with no authorization, capture, settlement or fee computation anywhere, and composer.json's 31 requires contain no processor SDK. With no processing product there is no rate structure of any kind — blended or cost-plus — to publish, which is why this is `no` and not merely unpublished. The record's existing grade-A commercial-processing-not-bundled reaches the same conclusion from the API reference. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/app/Services/OrdersService.php · retrieved 2026-09-05 adversarially verified

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

Proposition: the processing agreement caps or prohibits unilateral vendor-initiated rate increases, or grants penalty-free exit on any increase. There is no processing agreement because there is no processing: a NexoPOS 'payment type' is a row the operator creates in nexopos_payments_types (label, identifier, priority, description, author, active, readonly, accounting account, incoming-effect enum), and the merchant's card relationship, if any, is with a third party the vendor is not party to. The commercial documents that do exist are software-licence terms for paid modules, not card rates. Named gate: the Terms of Use on my.nexopos.com is robots-barred to this corpus, but a rate clause cannot exist in it for a service the vendor does not provide. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2021_05_25_131104_create_nexopos_payments_types_table.php · retrieved 2026-09-05 adversarially verified

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

Core software price is $0 under a published OSI license, and every paid module and bundle carries an exact public dollar figure with no sales contact. Caveat: NexoPOS Cloud hosting pricing is published nowhere and its docs category is empty. https://my.nexopos.com/en/marketplace · 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 is an independent one-time purchase — Gastro $45, Raw Material Tracker $20, Multistore $42, NPS Adapter $15 — installable and removable independently, with optional discount bundles. Nothing reprices a base subscription because there is none. https://my.nexopos.com/en/marketplace · 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 third-party commodity equipment bought outright by the operator; the vendor imposes no lease or rental. https://my.nexopos.com/en/documentation/self-hosted/getting-started/requirement · 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

Runs in any browser on standard PCs/tablets, prints to standard ESC/POS thermal printers via browser or the local print server, and reads standard barcode scanners including an Android phone as a scanner. https://my.nexopos.com/en/marketplace/item/nexo-print-server · 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

Direct database ownership under self-hosting, plus CRUD table exports and a public REST API covering orders, line items, payments and customers. No support ticket, no fee. https://docs.api.nexopos.com · 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

Customers, customer groups, rewards, coupons, coupon order history and account/wallet history are all first-class models with API and CRUD-export access. No gift-card liability exists to export. https://docs.api.nexopos.com · 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

For Cloud, Terms section 7 states that failure to pay may result in 'Data deletion' and 'Loss of hosted environments' with no retrieval window specified. For self-hosted the question does not arise. https://my.nexopos.com/en/help/terms-of-use · retrieved 2026-09-17

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

CLAIM: published terms state the merchant owns its transaction/customer data and constrain vendor use/resale beyond aggregated use. VERDICT: no. BOUND: the vendor's published legal set is two documents, both in every my.nexopos.com footer (href counts: /en/help/terms-of-use 312, /en/help/privacy 312; /en/help itself renders "null"): the Terms of Use, sections 1-8.2, whose scope covers "cloud hosting, downloadable software, APIs ... AI-powered features", and the Privacy Policy, sections 1-5. The hosted service nexopos.cloud publishes none: /legal/terms and /legal/refunds render {"unavailable":true,"document":null}, "terms_published":false. EVIDENCE of silence where the clause would sit: Terms 7 lists among consequences of non-payment "Data deletion; | Loss of hosted environments", and 8.2 makes "Data backups ... Data exports" the user's responsibility - no ownership statement; Privacy 2 lists uses of information about platform users ("Analyze usage trends", "Improve platform performance") and does not address merchants' POS transaction or customer data. CONTROLS over the raw HTML of both legal pages, tokenised: "own|owns|owned|ownership" 2 hits = "Copyright ownership or authorization" (Terms 5.1, an author duty) and "their own privacy and security standards" (Privacy 1.2, of Stripe/PayPal); "resell" 0; "de-identified|anonymi[sz]ed|aggregated?" 0; "customer data" 0; "your data" 1 = the Privacy page subtitle "Learn how we use your data". POISON: an untokenised "own" matches 25 times (shown, dropdown). Across all 318 my.nexopos.com pages "ownership" appears only in blog marketing ("NexoPOS's ownership model", "more ownership and flexibility") - grade C positioning, not terms. NOTE: self-hosted operators hold their own database, so the clause matters mainly for NexoPOS Cloud, but the claim scores published terms. Retrieved 2026-09-16. https://my.nexopos.com/en/help/terms-of-use · retrieved 2026-09-16 adversarially verified

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

Proposition: validated P2PE or hardware-encrypted card entry plus tokenization reducing merchant PCI scope to SAQ A or SAQ P2PE-HW, with the applicable SAQ named. No conjunct holds. Tokenization: the only token columns in the whole tree are Laravel Sanctum's personal_access_tokens.token (an API bearer token) and users.activation_token (email activation) — there is no payment vault or stored instrument among the 365 distinct migration column names. P2PE and encrypted entry: no card-data path exists at all, and word-boundary 'p2pe' returns 0 files repo-wide. SAQ guidance: no saq or 'pci dss' string appears anywhere in the tree. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/2019_12_14_000001_create_personal_access_tokens_table.php · retrieved 2026-09-05 adversarially verified

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

Proposition: the 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, plus payment-page script-integrity monitoring per Req 6.4.3/11.6.1. The MFA conjunct is provably false in the shipped core: authentication is Laravel Sanctum alone, and word-boundary searches over app/ and config/ for otp, google2fa, fortify, authenticator, 'one time password', mfa, 2fa, two-factor and totp return zero hits, with no mfa/otp/2fa column among the 365 distinct migration columns. This upholds the record's existing reliability-mfa-role-based-access finding. Req 6.4.3/11.6.1 is moot: there is no hosted payment page. Named gate: PCI documentation would live on the barred my.nexopos.com, but a conjunction with a false conjunct is false. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/composer.json · retrieved 2026-09-05 adversarially verified

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

Individual customer records can be located, exported and deleted in-app, and a public privacy policy exists. No purpose-built DSAR workflow and no executable DPA published. https://my.nexopos.com/en/documentation/user-guide/customers/managing-customers · 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

Proposition: the vendor publishes a VPAT/ACR claiming WCAG 2.1 AA for its SELF-ORDER KIOSK and CONSUMER WEB-ORDERING surfaces, including a tactile/audio non-visual kiosk mode. Both certifiable surfaces are absent from the product, so there is nothing for such a report to cover. The vendor's own shipped and translated root-page string tells the operator the product has no frontend; every other web route sits inside the `dashboard` prefix behind Authenticate middleware (routes/web-base.php:41) and every API group behind auth:sanctum (routes/api-base.php:18); and 'kiosk' is word-boundary zero across app, routes, database, config, resources/ts and the 3,412-key lang/en.json, re-run this session. 'wcag' matches exactly one file repo-wide, opened: a comment in the vendored line-awesome/Bootstrap sr-only-focusable SCSS mixin citing a W3C technique URL - a third-party artefact; 'vpat' is zero. Named gate, stated not glossed: my.nexopos.com and nexopos.com are both robots-barred, so a conformance report hosted there would be unreadable to this corpus - but it could not cover a kiosk and a consumer ordering flow the product does not have. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/resources/views/welcome.blade.php · retrieved 2026-09-05 adversarially verified

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

Proposition: card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, plus required receipt and menu-board disclosure. The debit/prepaid exclusion conjunct is architecturally impossible: NexoPOS never receives a card, so there is no BIN or product code to classify — no card, PAN, BIN or brand column exists among the 365 distinct migration column names. The nearest core feature, the three per-unit price tiers (sale / wholesale / custom), is a manual cashier toggle behind the ns_pos_allow_wholesale_price setting and a per-line action permission, unlinked to any tender and printing no second total. Word-boundary 'cash discount' and 'dual pric' return 0 files, and the only 'surcharge' occurrences are two comments describing a per-line room fee. https://raw.githubusercontent.com/Blair2004/NexoPOS/v6.2.2/database/migrations/create/2020_06_20_000000_create_products_unit_quantities.php · retrieved 2026-09-05 adversarially verified