NCR Voyix Aloha

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

Table Service floor plan with per-table definitions; sections and servers assignable. Multiple saved layouts per site not explicitly confirmed. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/table_definition · 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

Self-contradiction against the dossier's own identity section, which explicitly warns that Aloha Cloud 'is the SMB cloud product on a materially different codebase — its docs must not be read as classic Aloha.' The source here is exactly that: docs.ncrvoyix.com/restaurant/aloha-cloud/using/working_with_tables_and_tabs. Seat-level ordering in classic Aloha Table Service is plausible and probably real, but it is not evidenced by an Aloha Cloud page. https://docs.ncrvoyix.com/restaurant/aloha-cloud/using/working_with_tables_and_tabs · retrieved 2026-08-01 adversarially verified

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

Course Ordering module in Aloha Table Service delivers multi-course meals one course at a time with hold and fire control. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/course_ordering/implementing_course_ordering · 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

UPHELD partial 2026-08-10, but the shortfall shrinks from four items to one, because three of its four denials were wrong. Splitting by seat IS documented - POS Access Levels, 'Split seat (TS only) - Allows employees assigned this access level to split a guest check into separate checks by seat', with the TS Server Guide procedure 'Splitting checks by seating position'. Even N-way at check level IS documented - Jobcodes, 'Display equal payment on close screen ... split the check into equal amounts.' Merging IS documented in both forms the claim names: the TS Server Guide's 'Combining separate checks' ('Just as you can separate checks, you can also combine them for consolidation'), Store Settings' 'Auto-combine scanned checks', and for tables 'Pivot seating transfer merges seats - Merges seats with the same seat number when combining tables.' WHAT REMAINS UNMET, measured across the TS v19.11 Reference Guide, the TS Server and Manager Guides and the Split Checks QRG: no split by an arbitrary dollar or percentage amount AS A SPLIT METHOD - arbitrary amounts are tendered, not split - and nothing on recombining checks after a partial payment, where the documented flow tenders and closes each split separately. The only stated restriction runs the other way, 'Allow checks with comps, promotions and/or tax exempt items to be split.' https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/pos_access_levels · retrieved 2026-08-10 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

FLIPPED partial -> yes 2026-08-10. The prior note measured the Tenders page and concluded the fields do not exist; they are on the sibling Store Settings > Credit Card page. Group bar: Authorization carries 'Enable automatic pre-authorization - Automatically contacts the processor and performs a pre-authorization when the check total exceeds the specified amount', 'Initial pre-authorization amount - Specifies the amount the system uses for the first pre-authorization', and the incremental re-auth the claim names: 'Subsequent pre-authorization amount - Specifies the amount by which to increase the authorized amount when the guest check exceeds the pre-authorized amount. For example, if the initial pre-authorization amount is $50.00 and the subsequent pre-authorization amount is $25.00, the next amount sent to the processor for pre-authorization is $75.00.' A warning threshold turns the top of the FOH check window red as the total approaches the authorized amount, and eight pre-authorization amounts can be offered for selection at the POS. Stale tabs close automatically: Revenue Center > 'Close open checks at EOD to tender' closes 'all checks left open from this revenue center when the end-of-day runs' (v19.9), so it is scopable to the bar. Cards bind to tabs through the Saved Card feature, where the payment card 'names the tab and saves the credit card information'. Recorded because it qualifies the capability: NCR advises against using it - 'we recommend you turn this feature off, or, at the very least, turn off the subsequent authorization functionality, if applicable, as this functionality can cause multiple authorizations for the same check.' https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/store_settings_credit_card_group · retrieved 2026-08-10 adversarially verified

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

RE-SOURCED OFF AN ALOHA CLOUD PAGE 2026-08-09. The prior 92-char note ('audit log naming both employees not confirmed publicly') rested on /restaurant/aloha-cloud/using/working_with_tables_and_tabs, which product.yaml forbids reading as classic Aloha, and carried no product word. The classic answer is explicit: the Aloha Table Service Report Guide (p. 3-158) documents a Transfers report that 'provides a listing of all tables transferred between employees in the FOH', calls it 'commonly used as an audit tool for a single date', and gives columns Time, Type ('either accepting the table or transferring the table'), Table, From ('The name of the employee transferring the table') and To ('The name of the employee accepting the transfer'). Both employees are named, which is exactly what the hedge doubted. Two limits kept deliberately: the report is a Table Service artifact (Quick Service has no Transfers report), and transfer between DEVICES is not separately audited -- the log is server-to-server against a table. https://docs.ncrvoyix.com/downloads/aloha-pos/TS_ReportGuide.pdf · retrieved 2026-08-09

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

The Axium handheld is documented under the Aloha CLOUD hardware section. Nothing establishes Axium as a supported terminal for classic on-prem Aloha POS (Windows BOH/FOH), which is the product this dossier profiles. Native handheld for Aloha Cloud: yes. For Aloha POS: not documented. https://docs.ncrvoyix.com/restaurant/aloha-cloud/hardware/setting_up_axium_device · retrieved 2026-08-01 adversarially verified

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

On-prem BOH/FOH architecture plus EDC offline auth mode with maximum authorization amount. Full offline feature matrix not published. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-01

Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator

order-capture-qr-same-check

QR at-table item ordering is documented, but as a separate Digital Ordering order rather than an addition to the server's open check. 'The consumer scans the QR code at the table which opens a blank order in the Mobile Web app'; the table arrives only as free text - the feature matrix gives the 'Table Injection Method' for both variants as 'Special instructions through ATO order notes' - and the QR generator page states 'The tables are not associated with tables configured in the Aloha POS system.' In the base flow 'the consumer must enter their order, send it to the kitchen, and pay for it in the same session' and 'if the consumer decides to order additional items, they must start and close another order.' Two partial offsets: Digital Ordering release AO-14539 added an Open Check mode 'to allow dine-in consumers to place an order at the restaurant and keep the check open until the end of their meal', and AO-20779 lets additional guests at a table add to that same check; and the server can pull the mobile order into the POS ('The server selects the order and touches Modify. The system navigates to the Aloha POS system with the order displayed on the Order Entry screen'). Shortfall: nothing documents guest QR items landing on a check a server opened first, and the separate Aloha Mobile Pay QR is pay-only - its FAQ answers 'Can the guest order items from their phone?' with 'No, this functionality may make a comeback into Mobile Pay in the future, if the market demands it.' https://docs.ncrvoyix.com/restaurant/digital-ordering/implementing/contactless_dine_in/using_contactless_dine_in · retrieved 2026-08-09 adversarially verified

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

UPHELD partial 2026-08-10, grade D -> B, and the menu-parity denial was a READING gap against a document already cited elsewhere on this record. Both the Aloha QS and TS v19.11 Reference Guides state that the kiosk's screens come out of the POS database: 'you also use Configuration Center to build and activate the POS order entry screens that appear on the FOH terminal or self-service kiosk in a store. These order entry screens are also managed in the centralized database, and distributed to stores, as necessary.' So a separate menu build is ruled out, which the prior note said it was not. The kiosk is a first-party terminal function - 'Kiosk (QS only) - Indicates this terminal is an interface terminal used by NCR Kiosk and not the Aloha POS' - exposed by 'Uses Kiosk - Activates Consumer Self Ordering (Kiosks)', with an 'interface employee' that 'works behind the scenes to perform kiosk operations from this terminal', and POS order modes opted in individually via 'Display on kiosk'. THE ONE FAILING CONJUNCT, and it alone holds the cell short: no ADA, Section 508 or VPAT conformance statement is published for the kiosk on any surface. VPAT, Section 508 and WCAG appear in zero of the 150 first-party PDF guides, and NCR's published accessibility remediation belongs to Digital Ordering and Aloha Menu. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/terminals · retrieved 2026-08-10 adversarially verified

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

ORDERPOINT drive-thru product plus OrderPoint Outdoor Display board type configurable inside Aloha POS. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/display_boards · 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

The hedge said segment timers 'typically come from third-party timer hardware'. The cell's own cited report guide documents them natively: the Quick Service Speed of Service report 'Displays and prints information based on the order entry queue from which an order originates, allowing you to capture specific performance measures for terminals located at an inside counter verses a drive-thru terminal' [vendor's spelling], with segment columns Menu Average, Queue Average, Tender Average, Counter Average, Total Order Average, Production Average and Credit Average, live FOH threshold indicators, and BOH sorting by Revenue Center, Day Part, Order Mode, Video Display Unit or Store. The documented third-party dependency is for vehicle IMAGING and lane kiosks ('vehicle images taken when you integrate with a third party camera company'; Fingermark lane kiosks), not for the timers. HELD AT partial for a different reason than before: the segments are reported as averages by day part, revenue center or order mode, not as per-order timings. https://docs.ncrvoyix.com/downloads/aloha-pos/QS_ReportGuide.pdf · retrieved 2026-08-09

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

Neither half of the claim holds. There is no first-party voice agent: taken as a word, `voice` matches in only two of the 304 non-Japanese pages on www.ncrvoyix.com, both legal boilerplate about recordings, and every `voice` match in the product corpora is a different sense -- IVR voice authorisation for gift-card tenders, the 'NCR Customer Voice' survey partner, or screen-reader voice-out in accessibility release notes. Nor is there a partner program aimed at voice: NCR Voyix's own Above Store Marketplace enrollment page publishes the list of third-party vendors an operator can enroll against a classic Aloha site -- Bite, Checkmate, Chowly, DoorDash Delivery, DoorDash Drive, Ezcater, Grubbr, GrubHub, Marketman, Novadine, OLO, OpenTable, Paytronix, Shogo, Sunday App, Thanx, Tiphaus, Uber Eats -- and no voice ordering vendor appears on it. The page confirms the classic scope by requiring 'Configuration Center (CFC) Version 20 or Higher'. https://www.ncrvoyix.com/about/vendor-integration · retrieved 2026-09-10 adversarially verified

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

Both halves are documented. Aloha Takeout Order Scheduling and Capacity Tracking: 'Enable order capacity tracking to track the number of orders and items, per time segment, enforcing limitations you place on them', with a 'Default capacity time segment length' (recommended 15-20 minutes) and item/order capacity entered per order mode per day part -- the doc's worked example sets Call-in and Delivery item capacity to 90 and Delivery order capacity to 8 for a Friday lunch segment. Automatic quote-time extension comes from Aloha Kitchen's Quote Time Threshold Table: 'If the number of active items exceeds the item count, then the next highest quote time value is used. You can send the quote time to Aloha Takeout and feed up to Aloha Online.' ATO must have 'Use Kitchen quote times' selected for AK to drive it. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/order_scheduling_capacity_tracking/defining_start_day_day_parts_tracking_limits · retrieved 2026-08-08

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

Aloha Takeout handles future and scheduled orders with release and promise-time handling. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO201_ReferenceGuide-HKS1661.pdf · retrieved 2026-08-01

Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.

order-capture-catering

SHORTFALL REFUTED BY A FEATURE FOCUS GUIDE WITH THE ANSWER IN ITS TITLE, sitting unopened in the same corpus. The hedge said 'quotes, deposits and balance-due tracking not confirmed publicly'; all three are documented. Deposits: 'You can use the Deposits feature to collect partial or full payment from customers for a future order', refundable or surrendered 'to compensate your organization for labor and/or food costs'. Balance due: 'The system locates all deposits the customer paid, applies them to the check ... Tender any remaining balance', applying 'deposits, 2) credits, and 3) stored payment card' in order. Quotes: a configurable 'Catering Quote Increment in minutes to increment or decrement the catering quote time' on the Adjust Quote screen. Separate queue: catering 'uses a discrete, separate order mode' with 'A separate report ... for summarizing and analyzing your catering business'. Kept explicit: the deposit machinery is generic to future orders and only labelled catering in places. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO_FutureOrdersandDepositsFFG-HKS360.pdf · retrieved 2026-08-09

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

NCR Voyix states what a live marketplace integration does and it is two things, both inbound: an Active site is one where 'the partner can read menus and inject orders', and the guide adds only that the site is then live with that partner. No outbound order state is described in the self-serve onboarding guide, the Business Services Platform order documentation or anywhere else in the classic tier. The order-ready material that does exist in the developer portal is a Short Message Service notification sent to the guest, not to a marketplace, and every one of those pages is filed under the Aloha Cloud topic, which this record's scope rule excludes. NCR Voyix is also absent from DoorDash's 2026 Preferred Integration Partner cohort, whose published criteria include an order-ready signal. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/ssio · retrieved 2026-09-10 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

Security Roles gate functions per action; comps and voids carry reason codes and surface in audit and exception reporting. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/security_roles · 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

Vendor cites forced and nested modifiers; pizza modifier groups documented with topping levels and selection controls. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/basic_pizza/configuring_pizza_modifier_groups · 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

Topping price varies by pizza size and topping level as a matrix rather than by duplicating the modifier. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/advanced_pizza_qs/pricing_pizzas_with_fractional_toppings · retrieved 2026-08-01

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

menu-pricing-fractional-placement

Halves, thirds and quarters all confirmed, though NOT on the page the researcher cited for it. The 'using_pizzas_with_fractional_toppings' page shows only 1/2 and 1/4 in its worked examples and never mentions thirds; thirds are evidenced on the pricing page ('BYO LG with fractional third toppings'). Score stands, citation should be swapped. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/advanced_pizza_qs/pricing_pizzas_with_fractional_toppings · retrieved 2026-08-01 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

Verified independently against the cited vendor doc. All four methods appear verbatim: percentage pricing ('Prices each pizza fraction based on a percentage of the base topping price'), average pricing, higher fraction charged ('Charges the price of the higher priced pizza fraction only'), and whole price for topping ('Charges fully for each topping and gives no discount'). This is a real, operator-selectable four-mode engine and the single strongest cell in the dossier. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/advanced_pizza_qs/pricing_pizzas_with_fractional_toppings · retrieved 2026-08-01 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

FLIPPED partial -> yes 2026-08-10; refuted by the tree the cell already cited. The price tier lives on Maintenance > Menu > Modifier Codes, not in the pizza depletion matrix the note measured. 'Affects pricing' exposes 'Charge X percent' and 'Charge X percent if included', each 'from 0 to 9999 with 100% being the default', and NCR's own examples are the claim's own vocabulary - 'when a guest requests heavy mushrooms on a Pepperoni pizza' and 'when a guest requests extra pepperoni'. The Included Modifiers Feature Focus Guide (HKS482) states the intent and works the arithmetic: 'You can charge more for Extra and less for Light without affecting the defined base price of any given item', and 'The system charges the BLT as $3.00 + ($1.00 x 60%) = $3.60' for Heavy Bacon. Double is a separate multiplicative construct - Items > 'Apply price multiple' with 'Percent of base item price' or 'Multiplier of base item price' makes a Double modifier double the parent price. It is distinct from adding the modifier twice: the code is a prefix on a single modifier line, and its own Quantity field drives portion and PMix separately - 'if you configure the Heavy modifier code with a quantity of 3, all modifiers applied with the Heavy modifier code assume three times the portion sold.' https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/modifier_codes · retrieved 2026-08-10 adversarially verified

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

HEDGE UPHELD, BUT THE NOTE'S FIRST CLAUSE WAS WRONG AND IS WITHDRAWN. Classic Aloha item pricing methods are a closed list -- 'Item Price, Price Level, Quantity Price, and Ask for Price' -- with no grid and no per-cell override, so the two-axis size-by-preparation matrix the claim asks for is not documented. THE WITHDRAWAL: the thing Aloha calls a 'matrix' is INVENTORY DEPLETION, not pricing. 'Selecting this option enables the Pizza Topping Matrix tab. You need to configure this tab only if you are using pizza topping inventory depletion', whose cells relate pizza size to topping level to compute a depletion quantity. Per-size topping PRICING exists only as a grouping convenience via size-specific price levels, and Size Groups confirm the opposite of the claim -- 'You must add each item to the size group in order of smallest to largest size', i.e. each size remains a separate item record. Measured across the 150-document /downloads/ PDF corpus and the 1,941-document DevEx dump. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/items · retrieved 2026-08-09

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

FLIPPED partial -> yes 2026-08-10, and it was a READING gap: the substitution-credit half is the subject of a dedicated first-party guide nothing had opened, the Feature Focus Guide: Included Modifiers (HKS482), whose contents list reads 'Configuring substitution rules for included modifiers'. Items > Dynamic Modifiers carries a Substitution charge drop-down: 'Change Difference - Specifies this included modifier can be substituted for a non-included modifier from the same modifier group and charged the difference between the two modifiers. If the price of the included modifier is greater than the non-included modifier, the system prices the substitution at $0.00, instead of pricing a negative amount', alongside No Charge and None. Forbidding is configured from the other side: 'select Not eligible for substitution to specify this modifier ... cannot be substituted for an included modifier.' The guide enumerates all four outcomes the claim's third conjunct needs, including 'Not allow the substitution at all and count against the modifier group rules.' The allowance and its automatic overage are POS fields rather than a pizza special case: TS v19.11 Reference Guide, Modifier Groups > Modifier tab, 'Free - Specifies the number of items from the modifier group the customer can order at no charge. For example, if the value for Free is set to 1, then the Aloha POS system does not charge for the lower-priced item', and the Advanced Pizza guide applies the same mechanism ('a 3-topping pizza would have a minimum of three toppings and allow three free toppings'). https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_IncludedModifiersFFG-HKS482.pdf · retrieved 2026-08-10 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

Combo and promotion configuration documented in the Quick Service reference guide; auto-detection of eligible items is long-standing Aloha combo behavior. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS199_ReferenceGuide.pdf · 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

Digital Ordering has per-item upsell triggers: you build a Sales Item Group of upsell items, attach it to an Upsell Suggestion, then 'assign the items to trigger the prompt for upselling' -- 'When an assigned item appears on the check, and the consumer adds it to the cart, the associated upsell items appear.' Shortfalls: it is a single channel. The configuration lives in Digital Ordering / Aloha Online Ordering Web Admin only; no equivalent per-item suggestive-sell prompt configuration was found for the Aloha POS FOH or for kiosk, and no attach-rate or upsell-conversion report is documented (the Aloha Smart Manager sales report set is Sales Summary, Product Mix, Discounts, Payments, Refunds, Voids, Taxes, Transactions, Revenue Centers, P&L, POS Event Log). Digital Ordering also overrides the configured prompt text with a fixed 'PEOPLE ALSO ORDERED.' https://docs.ncrvoyix.com/restaurant/digital-ordering/implementing/configuring_upselling · retrieved 2026-08-08

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

Item Availability is genuinely cross-product: 'The Item Availability feature is available for configuration and use in Aloha POS (Table Service or Quick Service), Aloha Kitchen, and Aloha Takeout', and setting an item unavailable in Aloha Kitchen 'communicates to the Aloha POS and you can not enter an order for that item.' Aloha Online Ordering picks it up: 'You can configure Aloha Online Ordering to receive item availability updates through Aloha Takeout (ATO) ... any item that is fully depleted or marked as unavailable in the POS does not appear for selection in the online menu.' SHORTFALL SOFTENED 2026-08-09: the old sentence 'no propagation to kiosk or to connected third-party marketplaces is documented' was measured on the POS/ATO/AOO chain and is now too strong. The Aloha Menu User Guide (HKS1744, v2.24) shows the availability signal reaching the very tool that publishes to third-party partners: 'If an item is out of stock and unavailable by the Item Availability service, it appears grayed out.' Stated precisely, because the distinction is the whole point: that sentence describes the PREVIEW screen inside the authoring tool, not the published partner catalog. So the honest shortfall is that the signal demonstrably reaches the menu-publishing layer, while whether and how fast it reaches a partner's live catalog is undocumented -- latency occurs zero times in the guide -- and kiosk propagation remains undocumented. The other shortfalls stand: the online leg is not automatic, requiring ATO integrated with the Business Services Platform, ATO v17.1 or later, and an Enterprise Unit ID entered per site in Web Admin. https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/configuring_online_order_features/supporting_item_availability_updates · retrieved 2026-08-08

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

UPHELD partial 2026-08-10, now measured on all four surfaces that carry the feature: the POS web tree, the Item Availability Feature Focus Guide (HKS368) that the web page only referenced, and both v19.11 Reference Guides. Per-item countdown with automatic 86 at zero is documented: 'you can specify there are 10 slices of pecan pie available to sell and when a slice is sold, the count decrements by one. When the slices are depleted, the system sets the item as unavailable and you can not enter an order for that item.' Depletion behaviour is specified in detail - once for Extra and Light modifier codes, not at all for the default NO code, at order time for held items, as a full topping for pizza fractions - and a returning void adds the count back. THE FAILING CONJUNCT IS SCHEDULED AUTO-RESTORE, and it is absent: restore is manual, 'To reset the item as available, touch No Limit', and the flag survives a void that puts stock back - 'when you void an item that has become unavailable, and the item is now in stock, the system still considers the item unavailable. You must access Item Availability to set the item as available.' Neither reference guide exposes an Event Schedule event for item availability; the only scheduled behaviour is the EOD wipe of ending quantities to zero, or its opposite via 'Category excluded from Item Availability reset'. Aloha Kitchen can toggle availability but holds no quantity. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/item_availability/feature_interaction_with_item_availability · retrieved 2026-08-10 adversarially verified

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

Re-cited 2026-08-09 off a one-sentence 2026-08-01 note ('Price Changes support scheduled activation by day and time; day parts are a core Aloha construct') onto documentation that shows the construct at four levels of the menu hierarchy -- menu, submenu, sales item and quick combo. Aloha Menu User Guide (HKS1744, v2.24): 'Day availability buttons -- Specifies the days of the week for which the menu is available to the consumer', 'All day -- Indicates the menu is available for all days (24 hours) of the week. When disabled, the starting and ending times for the days of the week appear', and the product summary 'Enable differentiated pricing and menu availability by days or times per week.' Value unchanged at yes; the grade and value were already right, but the evidence behind them was a single asserted sentence. https://docs.ncrvoyix.com/restaurant/aloha-menu/about/overview · retrieved 2026-08-09

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

RE-EVIDENCED 2026-08-09; the old note understated the product. It read 'Price levels and price changes vary price by order mode and revenue center' -- a mechanism read off Aloha POS. There is a dedicated module: 'Use the Price Schemes module to create different price schemes for your menu. Price schemes allow pricing customization among solution partners, order fulfillment types, order channels, menus, site groups, and sites' (Aloha Menu User Guide HKS1744, v2.24). Distinct per-channel price books are therefore first-class and explicit, not inferred from Price Levels. The claim nonetheless requires percentage-markup rules applied to a base price rather than manual per-item entry, AND THAT CLAUSE ALONE IS WHAT KEEPS THIS PARTIAL: 'You do not set prices in Aloha Menu', a scheme resolves price by pointing at a POS revenue center ('The system uses the revenue center designated for exporting to the BSL Catalog service in Aloha POS'), and markup and percentage occur zero times in the guide. Recorded explicitly so the channel half is not re-litigated: it is settled, and only the markup half is open. delivery-menu-push is held partial on this identical fact. https://docs.ncrvoyix.com/restaurant/aloha-menu/about/overview · retrieved 2026-08-09

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

Aloha POS v19.12+ has a native cash-discount pricing model for Quick Service and Table Service, and the claim's base-price requirement is met explicitly: 'It is the responsibility of the merchant to ensure the standard (non-discounted) price appears to the consumer at all times. This includes all public displays at the door and counter, printed guest checks, printed and digital menus, and the base items entered in to the Aloha POS system' -- i.e. the card price is the base price. Shortfalls: it is not item-level. It is implemented as a single check-level percentage comp ('Select Fixed percent from the Method drop-down list. This is the only method supported for cash discounting') auto-applied by the Cash tender, so no second price is stored per item; it is documented only for the Aloha POS FOH, with no kiosk or online-ordering leg; and it requires Connected Payments with NCR Voyix Payment Processing plus CFC v21.23 and the 2025 product stack. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/cash_discounts/implementing_cash_discounts_pos1912 · retrieved 2026-08-08

Menu changes can be staged as an effective-dated version, previewed before publish, and rolled back to a prior version after publish. differentiator

menu-pricing-versioning-effective-dates

Re-scored 2026-08-09 against TWO surfaces, because the old 149-character note asserted a CFC mechanism from an Aloha Takeout page and then doubted the whole claim. EFFECTIVE DATING IS DOCUMENTED, twice over, in CFC: 'It also enables you to distribute database changes for a future date, to intended stores. The changes remain in the local, store database until the specified effective date', and 'Versions with start and end dates use Scheduled versioning' -- though scoped to a named function list, Event Schedules, Modifier Groups, Panel Editor, Price Changes, Promos, Tax Groups and Tax Types. ITEMS ARE NOT IN THAT LIST and take dateless Standard versioning, which 'overrides its primary record indefinitely, as there are no start and end dates used with Standard versioning'. PREVIEW IS DOCUMENTED, but on the OTHER surface: the Aloha Menu User Guide (HKS1744, v2.24) has draft status ('Indicates a menu that is not yet published. Consumers will not yet see this newly created menu'), 'Preview the menu to help identify any errors and make last minute changes, as needed', and scheduled publish ('Select Publish on date from the Schedule drop-down list'). The CFC chapter is silent on preview -- the word occurs zero times. PARTIAL NOW RESTS ON ROLLBACK ALONE, and both surfaces agree: rollback, version and history occur zero times in the Aloha Menu guide, and CFC's only documented reversal is deletion, 'If you no longer want a version available at a store, you delete the version, and the primary record will be in effect at the store' -- there is no retained history to roll back TO. Naming each surface deliberately: preview belongs to Aloha Menu, effective dating to CFC, and neither documents post-publish rollback. Aloha Configuration Center as documented for CLASSIC on-premise Aloha (Table Service v19.11 Reference Guide, HKS1780, Chapter 1 "About CFC"). This does NOT describe Aloha Smart Manager, Aloha Cloud or NCR Console. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09

Supports a central corporate menu template pushed to locations with field-level governance controlling which attributes a location may override. differentiator

menu-pricing-franchise-hierarchy

Re-scored 2026-08-09 off a 133-character 2026-08-01 note that cited an Aloha Takeout page carrying none of this. Central push is documented: 'the corporate office can easily manage daily POS data changes using the hosted, centralized database. The corporate office accesses the client-side application to add or update menu items, prices, promotions, and more.' The franchise tier is explicit rather than inferred: CFC 'enables you to manage database records at the store level, as well as at the corporate and franchisee levels, through the use of owners and record hierarchy levels', so that 'the corporate office controls the records for the stores they own, while allowing each franchisee to have control of certain records, as necessary.' SHORTFALL RESTATED AS A POSITIVE FACT RATHER THAN AN ABSENCE, which is what the old wording got wrong: governance granularity is the RECORD and its OWNER, not the field -- 'Record-level security ... enables you to control who can view and edit data in Aloha Configuration Center, based on the owner assigned to each record in the system', and 'Records owned at this level are editable only by a corporate- or global-level employee, who is within the same record hierarchy.' The claim asks for field-level governance over which attributes a location may override; no per-attribute lock surface appears in the chapter. Aloha Configuration Center as documented for CLASSIC on-premise Aloha (Table Service v19.11 Reference Guide, HKS1780, Chapter 1 "About CFC"). This does NOT describe Aloha Smart Manager, Aloha Cloud or NCR Console. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09

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

Calculated Nutrition Feature Focus Guide (HKS340, NCR Voyix Back Office, last updated 2024-06-17), found via the Aloha POS documentation catalogue and not previously read. Derivation from recipe components is fully documented: 'The Calculated Nutrition function in NCR Voyix Back Office automatically calculates menu item nutritional information based upon the values entered for each raw ingredient in your recipes', it 'can easily account for the amount of nutritional value lost during the cooking process', it rolls up through nested prep recipes ('it reports the nutritional information for any prep recipe listed as an ingredient in another prep recipe or a menu item recipe'), and raw-item values can be pulled from the USDA National Nutrient Database for Standard Reference. Which components are tracked is operator-defined in Nutritional Component Maintenance, benchmarked against the FDA Nutrition Facts minimum. Allergens are stored as item ATTRIBUTES on ingredients and roll up with the recipe: the Recipe Ingredient List Report and the Nutrition Facts Sheet - US report each list 'any allergens identified in the attributes for the ingredients'. SHORTFALLS: the only documented outputs are back-office reports and a printed FDA-format Nutrition Facts label - no publishing path carries allergen or nutrition values to online ordering or to third-party menus, and Aloha Digital Ordering exposes only a single company-level 'Nutritional Information URL' field in its company settings (release notes v22.x), not per-item data; the feature lives in NCR Voyix Back Office rather than the POS or Aloha Smart Manager, and NCR gates setup ('To use Calculated Nutrition in NCR Voyix Back Office, contact your NCR Voyix representative for information and assistance with setup and configuration'); and NCR recommends running the reports 'only for one site and for the current business date'. https://docs.ncrvoyix.com/downloads/aloha-pos/NBO_CalculatedNutritionFFG-HKS340.pdf · retrieved 2026-08-09

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

Aloha Smart Manager maps sales items to recipes for theoretical cost; pizza topping inventory depletion is separately configurable. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/advanced_pizza_ts/configuring_pizza_topping_inventory_depletion · retrieved 2026-08-01

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

UPHELD partial 2026-08-10, shortfall re-scoped from a 4-page tree to three surfaces - and reading the new surface STRENGTHENS the shortfall rather than closing it. Conjunct one is met: NCR's own authoring tool names the marketplace as a menu consumer, per the Aloha Menu User Guide (HKS1744, the aloha-menu edition, 'Last Updated: September 11, 2025') - 'Solution partners - Specifies the solution partner to consume the menu. Click Edit and select All solution partners, or select individual solution partners from the list that appears, and click Save. The choices are Doordash and others.' Selecting None was added later, per release note EAS-23819. EDITION CORRECTED AND THE REASON RECORDED, because the prior note dated this guide 24 March 2025 and that is a DIFFERENT LIVE DOCUMENT UNDER THE SAME NUMBER: /downloads/aloha-menu/AM_AlohaMenuUserGuide-HKS1744.pdf is 2,524,543 bytes and last updated September 11 2025 'per the v2.23 and v2.24 releases', while /downloads/aloha-order-direct/AM_AlohaMenuUserGuide-HKS1744.pdf is 2,503,185 bytes and last updated March 24 2025 with no v2.x mention (both probed live, fabricated product 404s at 215 bytes). This quote is in both; the 'None' selection and the day-availability wording are in the September edition only. WHAT HOLDS THIS AT PARTIAL is that the documented architecture has NO RETURN CHANNEL. The DevEx Menu service is read-only and aggregator-pull: 'The Menu API enables customers to: Relay Menu information to API consumers such as third-party aggregators', role MENU_VIEWER to 'Perform read operations', verbs GET /menus and GET /menu-details/{menuId}. Its publish notification carries one field - 'The menu you have subscribed to has been updated, please update for the latest change. MenuId' - and its published error table lists only 400/401/403/404 faults returned to the API caller, not partner verdicts on items. Measured on Aloha Menu (guide and docs tree), the DevEx Menu service and the DevEx Item Availability service: no per-item sync status and no partner rejection error is documented on any of them, and 'rejected' and 'doordash' each return zero of the 3,122 API-Explorer operations against a passing control. https://docs.ncrvoyix.com/restaurant/aloha-menu/about/overview · retrieved 2026-08-10 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

Maintenance > Pricing > Price Changes plus the Event Schedule give rule-based automatic price variation by time: 'You must create an event in Maintenance > System Settings > Event Schedule to control when a price change takes effect and for how long. Use the Set Price Change event type to activate a price change ... You can also use the Disable Price Change event to stop a price change before EOD occurs, such as when you need happy hour items to return to regular pricing for the current day.' A single change can move individual items, price levels and promotions at once, and expiring changes hand off to the next scheduled event. SHORTFALL RE-SCOPED 2026-08-09, AND THE OLD ONE WAS WRONG: it read 'variation is by schedule only -- nothing in the function keys price off demand or channel'. That was measured on Aloha POS Price Changes and published as a fact about the vendor; it is false of Aloha Menu, whose Price Schemes 'allow pricing customization among solution partners, order fulfillment types, order channels, menus, site groups, and sites' (Aloha Menu User Guide HKS1744 v2.24). Price DOES vary by channel. What remains unevidenced, and what holds this at partial, is demand-driven variation and floor/ceiling guardrails: the only limits documented anywhere are count caps ('Maximum number of item price changes in thousands'), and percentage and markup occur zero times in the Aloha Menu guide. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/price_changes · retrieved 2026-08-08

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

FLIPPED partial -> yes 2026-08-10. The hedge existed only because the cited PDF would not render; it renders now, at 372,477 characters. Aloha EDC 'provides authorization and settlement capabilities for payment card transactions, using one or more processors of your choice. Depending on your merchant agreement, each processor will debit your merchant account for processing fees.' Appendix A: Processor matrix is the documented list the claim asks for, and it states its own completeness - 'While the processor type list box offers many processors, Aloha EDC currently supports only those provided in this matrix' - naming AMEX, BA Merchant Services (settlement only), Chase Paymentech, Comdata, Elavon, First Data Buypass, First Data CES, First Data Nabanco, Heartland, Moneris, TSYS, Vantiv host capture, Vantiv terminal capture and Worldpay, each with credit/debit/gift/EBT and dial-up/TCP-IP/SSL columns, followed by a 'Processors no longer supported' list. Per-processor Feature Focus Guides exist for EMV Elavon, EMV Moneris, Elavon Fusebox/Simplify, Global Payments and EBT via payment gateway. NCR Payment Solutions is one option among them, not a requirement. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-10 adversarially verified

Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator

payments-published-rates

No card-processing rate is published anywhere on ncrvoyix.com; the payments page routes to a contact form. https://www.ncrvoyix.com/platform/restaurant-applications/payments · retrieved 2026-08-01

Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator

payments-dual-pricing

UPHELD partial 2026-08-10, and the hedge was right on the two conjuncts it named. A native cash-discount mode exists from Aloha POS v19.12+, and it does print on both receipts: 'The cash discount prints on the receipt', and on a card payment 'the message, You could have saved x.x% by paying with cash prints on the receipt, where x.x is the cash discount percentage.' The claim additionally asks the system to store TWO PRICES PER ITEM and print both cash and card totals, and NCR instructs the opposite on three surfaces (the POS web tree, both editions of the Supporting Cash Discounts QRG HKS1742, and the DevEx Knowledge Hub): it is 'the responsibility of the merchant to ensure the standard (non-discounted) price appears to the consumer at all times. This includes all public displays at the door and counter, printed guest checks, printed and digital menus, and the base items entered in to the Aloha POS system.' One total prints, chosen by the tender used; the discount is a single Fixed percent comp auto-applied by the Cash tender off the check subtotal, 'You must apply a cash payment first before applying a non-cash payment' or it is not applied at all, and Equal Pay in Table Service is unsupported. The feature also requires Connected Payments and NCR Voyix Payment Processing. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/cash_discounts/using_cash_discounts_pos1912 · retrieved 2026-08-10 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

UPHELD partial 2026-08-10, and the shortfall is now structural rather than merely undocumented. Card surcharging exists in classic Aloha, but the object the credit tender points at is an ALCOHOL EXCISE-TAX RECAPTURE RECORD, not a card-surcharging engine. The EDC v19.9 User Guide's credit-card tender setup says 'Select the surcharge to pass along to the guest to help recoup extra charges, such as the credit card processing fee, from the Apply a surcharge to this tender drop-down list', and both the QS and TS v19.11 Reference Guides carry the same field pointing at the same place: 'You define surcharges in Maintenance > Taxes > Surcharge.' Per-location enable/disable is present and store-scoped via Store Settings > Financials > 'Enable Surcharges'. The other two conjuncts fail because the record has nothing to read: 'A surcharge is an additional charge applied to a check when specific items are sold ... a surcharge can be based on the quantity of the item sold ... such as in Florida where each alcoholic drink you sell has its own surcharge assessed ... a state might have a surcharge of $13.50 per gallon on liquor', and its entire field set is Name, Description, Method (Amount or Percent), Amount, Percentage and Tax surcharge. It reads no BIN or card product code, so debit and prepaid exclusion is achievable only by not attaching a surcharge to those tender records, and it enforces no network cap, the percentage being free-typed. NCR pushes compliance onto the operator ('The merchant must adhere to network operating guidelines'), and its own v19.11-and-earlier Cash Discounts QRG goes further: 'While cash discounting is fully available with Aloha POS, credit card surcharges are only available in Aloha Cloud' - a sentence dropped from the v19.12+ edition of the same guide. Recorded so a later pass can revisit: that vendor statement is an argument for no. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-10 adversarially verified

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

payments-emv-nfc

Verbatim from the live Aloha POS platform page: 'Integrated EMV, tap-to-pay, and digital wallet. Supports EMV chip, magstripe, and NFC/contactless payments, including Apple Pay and Google Wallet, with point-to-point encryption for security.' The page is Aloha-branded ('with Aloha as the industry-leading POS solution at its core'). Vendor feature copy rather than documentation, hence grade D. https://www.ncrvoyix.com/platform/restaurant-applications/ordering-fulfillment/point-of-sale · retrieved 2026-08-08 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

Every contactless acceptance path NCR Voyix documents requires a reader. The payment-devices page is the vendor's own complete catalogue and each entry is a separate device -- Verifone Engage P400 and M400 pinpads, the Equinox Luxe 8500i and 6200m, and the Ingenico Moby 5500, whose mobility option is physical rather than software: 'Available with cradle for desktop use and a clip-on extension to snap the device onto any smartphone for mobility'. `Tap to Pay on iPhone`, `SoftPOS`, `soft POS` and `tap to phone` occur zero times across all corpora. The four bare `Tap to Pay` matches in the developer portal are front-of-house button instructions of the form 'Tap to pay the dine in order as a takeout order' and are not the Apple or Google product. https://www.ncrvoyix.com/hardware/payment-devices · retrieved 2026-09-10 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

Aloha Pay-at-Table (announced May 2024, powered by sunday) and Aloha OrderPay take EMV/NFC tableside with tip and split. https://investor.ncrvoyix.com/news-releases/news-release-details/ncr-voyix-unveils-aloha-pay-table-powered-sunday-simplify · retrieved 2026-08-01

Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator

payments-qr-guest-pay

The scan-and-pay half is documented in detail: 'the server prints the guest check, as normal. Toward the bottom of the guest check, the system prints a unique QR code and six-digit code'; the guest scans with the native iPhone or Android 9+ camera, or enters the code at NCRPay.com, or follows a Text to Pay link, and can 'View their itemized check. Add a tip. Submit payment.' Shortfall on the second half of the claim: the payment does not close the check automatically. 'The next time a server logs in to a terminal, a popup notification appears to let you know the consumer paid. You can close the check at this time' - the FOH notification screen is a Dismiss/View All message list, not an auto-close. The Contactless Dine-In flow states the same limitation: 'Even though the consumer pays for the check up front, the check remains open on the Pick Up screen until the server closes the check.' The Mobile Pay FAQ adds that a payment fails outright while the server has the check open on the terminal, 'because the server may be making a modification to it at that moment.' https://docs.ncrvoyix.com/restaurant/aloha-mobile-pay/using/how_it_works · retrieved 2026-08-09 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

Aloha EDC supports pre-auth then tip adjust with batch settlement, plus on-device tip prompt on payment terminals. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-01

Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator

payments-tip-pooling

Aloha Table Service Tip-Share Distribution Feature Focus Guide (last updated June 20, 2024) documents a configurable engine. Contribution is a percentage of tippable sales per job code or job group, with rules for tax, discounts and excluded categories ('The system calculates the tip-share contribution as the default tip-share percent multiplied by the discounted subtotal of the guest check: 2% x $14.48 = $0.29'); pools are created by job code or job group, each taking a defined percentage of the pool, and a Set Tipshare event can change the percentage by day part. Distribution by hours worked is the documented method: 'Multiply the total tip-share pool amount by the percentage received by each job code, and then take the amount calculated for each job code and divide it by the total hours worked by all employees clocked in under that job code' ('$10.00 x 25% going to bussers = $2.50; $2.50 divided by 10 total hours worked by all bussers = $0.25 per hour worked by a busser'). Per-employee allocation is produced by the BOH Tip-share Distribution Detail and Summary reports - recipient employee number, recipient name, tip-share amount received, signature line, total distributed and total undistributed - generated over a date range and viewed, printed or exported. On payroll, the guide states the manager can 'interface with a payroll software and have the amounts reflect on each recipient's paycheck', and the Aloha Table Service v19.11 Reference Guide's Exports > Electronic payroll group bar defines named per-employee export files for ADP, PayUSA, Paychex and RealWorld, the Paychex layout carrying Employee Number, Job Code, Regular/Overtime Hours, Pay Rate, Credit Card Tips, Declared Cash Tips and Gross Wages. Scored on classic on-premise Aloha Table Service v19.11, not the Aloha Smart Manager cloud back office. https://docs.ncrvoyix.com/downloads/aloha-pos/TS_TipShareDistributionFFG-HKS384.pdf · retrieved 2026-08-09

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

Same vendor field-definitions evidence as offline card auth: configurable offline authorization with a floor limit, spooling, and automatic replay on restoration. Genuinely native and architectural, not a patch. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/store_settings_credit_card_group · retrieved 2026-08-01 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

HEDGE UPHELD ON LIABILITY, but the note previously gave the product no credit for the reporting it does publish. The EDC and Store and Forward guides speak of risk without ever allocating loss -- 'You can minimize the risk involved in not receiving approval while the guest is still in your restaurant by establishing a maximum amount allowed for mock authorization' and configuring offline gift-card authorization is 'a risk you want to consider carefully' -- and no document we hold says who bears it. What IS documented: a per-transaction cap, a 'Floor for transaction amount' above which the system declines rather than stores, a 'Maximum number of offline transactions' per processor, the Store and Forward Transaction List of everything currently stored, a '~' marker and an 'O = Offline transaction' key on EDC batch reports, and an Edit Rejected Transactions function to recall and re-add a transaction rejected at settlement. Scope kept honest: liability would live in a merchant processing agreement, not a product guide, so this absence is about published documentation. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-09

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

Aloha Stored Value sells and redeems gift cards, integrated to online ordering and shared across the enterprise. https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/configuring_online_order_features/working_with_gift_cards · retrieved 2026-08-01

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

payments-house-accounts

HEDGE HALF-WRONG, VALUE UNCHANGED. Statements ARE documented, on ATO's own doc set: 'Select Reports > Aloha Point-of-Sale > House Accounts and the House Account function tab appears, where you can run periodic reports for house accounts. Typically, you will print and send these reports (statements) to the house account contact for reimbursement at the end of a billing cycle. Once you have sent a statement, click Balance to reset each account for the next billing cycle', which rolls ending balance into previous balance and clears transaction detail. ASM corroborates on a second surface (CBO-272, 'create and maintain house accounts, including creating statements and managing credits and debits'). CREDIT LIMITS genuinely survive as the gap: the House Accounts maintenance definition lists only Account name, first/last name, Telephone, Inactive and an address block, and 'credit limit', 'account limit' and 'maximum balance' return zero classic-Aloha hits across all four corpora. Trap avoided and worth recording: DevEx DOES carry 'Maximum Balance' and 'Last Statement' fields -- in house-accounts-report-aloha-cloud, topic Aloha Cloud, which product.yaml forbids reading as classic Aloha. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO201_ImplementationGuide-HKS326.pdf · retrieved 2026-08-09

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

FLIPPED partial -> yes 2026-08-10. All four split axes and the cap are documented, and the cap is what settles the claim's 'no hard cap below eight ways': the TS Manager Guide states 'When split, you can have up to 32 checks for each table or tab.' By seat - POS Access Levels, 'Split seat (TS only) - Allows employees assigned this access level to split a guest check into separate checks by seat without manager approval', with the TS Server Guide procedure 'Splitting checks by seating position'. By item - Split Item, 'Enter the number by which to divide the cost of the item.' By even shares at CHECK level and not only per item - Jobcodes, 'Display equal payment on close screen (TS only) - Allows an employee clocked in under this job code to split the check into equal amounts', surfacing an Equal Payments button on the FOH Close screen. By arbitrary amount - the tender screen accepts a typed figure: 'Enter the amount of the credit card purchase, or accept the balance of the check.' Multi-tender settlement was already evidenced: 'Continue to apply payments until the balance of the guest check is zero and close the check.' https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/pos_access_levels · retrieved 2026-08-10 adversarially verified

Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.

payments-refund-void-controls

Security Roles gate voids, comps, discounts and refunds by role, with approver attribution in exception reporting. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/security_roles · 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

The NCR merchant reporting portal lists a chargeback feature: 'Self-Service Chargebacks -- Emailed chargeback notifications, upload responses to the portal, online tracking at your fingertips in the merchant portal.' Shortfalls: the vendor's own readiness column marks that row 'COMING 2023' (the guide is dated 11/18/2022) while Landing Page Dashboard, Search by Card Type, Data Filtering and Virtual Terminal are marked LIVE, and no later page on the docs host records it shipping. The operative process documented elsewhere is manual and out-of-product: 'You will be notified by NCR Payment Solutions' Dispute Processing department ... You will receive a debit advice ... It is important to be as detailed as possible when filing a rebuttal', with a Chargeback Customer Service phone number. Nothing documents evidence being assembled from the POS transaction record. https://docs.ncrvoyix.com/payments/merchant-portal-reference-guide · retrieved 2026-08-08

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

PARTLY OVERSTATED, VALUE UNCHANGED. Online and phone are BOTH documented; only the single-token-across-all-three element is not. Online: 'You can store up to five payment cards when processing with Connected Payments. Note: If the site is also processing with EDC, you can only store one card.' Phone and delivery: the ATO FOH quick reference has 'Touch Use credit card on file ... to charge the order to a stored payment card', and the Future Orders guide adds 'select Use credit card on file, if the card is already present in the system. (Note: If the card is not present, touch `Save card info to customer's profile' to store and encrypt the customer's credit card information in the customer profile.)' In-store is genuinely different: the POS Saved Card feature 'retains the card information during the transaction for use at time of payment, and then expunges all information.' No NCR document we hold states that a Digital Ordering stored card and an ATO customer-profile card are the same token. Weakest point recorded: token reuse may be an implementation fact NCR simply never writes down, so this absence is weaker than the others. https://docs.ncrvoyix.com/restaurant/digital-ordering/implementing/company_settings/checkout_and_payments_tab · retrieved 2026-08-09

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

payments-payout-timing

The deposit schedule is published: 'How soon will I get my deposits? It will take 48 hours, or Next Day Funded (except on banking holidays) if your account qualifies after you settle/batch your POS for your funds to post to your bank account. To apply for Next Day Funding, please submit your request to: assist.payments@ncr.com.' The same FAQ covers batching ('NCR Payment Solutions recommends that you batch your transactions every day. We are happy to set you up on auto batch'). Shortfalls: next-day funding is conditional on qualification and a written application rather than a standard option, there is no same-day or instant funding product documented, and the page sits in NCR's merchant-services (NCR Payment Solutions) FAQ set rather than on an Aloha-specific page, so the schedule is not explicitly scoped to the Connected Payments / NCR Voyix Payment Processing stack Aloha uses. https://docs.ncrvoyix.com/payments/general-payments-faq · retrieved 2026-08-08

A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator

payments-multi-entity-routing

NEW SURFACE, AND IT IS A CENSUS: support.alohaenterprise.com Aloha Insight Online Help is bounded by the publisher's own WWHelp manifest -- /wwapp/en_US/wwhdata/common/files.js enumerates exactly 292 topic files (/wwhdata/js/toc.js, 296 TOC nodes), and all 292 are on disk (2.2 MB), so this is 100% of the publisher's manifest, live and anonymous 2026-09-18. It holds the per-location funds-destination construct that the POS and payments docs do not. VERDICT moved unknown -> partial (B). EVIDENCE: 'You associate the merchant account number provided by Worldpay to specific restaurant(s) in Aloha Insight. This number designates the bank account used for deposits and withdrawals for the Stored Value transactions for the store. You can use the same merchant account number for multiple stores, if all the stores use the same bank account' and, explicitly per-entity, 'If all stores using the Merchant Account number and Terminal ID need to use a different bank account, contact Worldpay to update the Merchant Account number with the correct bank account number' / 'If only one store needs to use a different bank account, contact Worldpay for an updated Merchant Account number and Terminal ID combination. Access Site Setup on Aloha Insight and update the store with the new Merchant Account number' (helpdata/AlohaMarketing/ACH_TroubleshootACHTransactions.html). The construct is governed from ONE corporate account with a documented approval workflow -- 'The Merchant Account Authorization module enables the financial authorizer for your company to accept or reject the merchant account numbers entered for your stores in Site Setup ... before the transactions for the store are included in the ACH transaction file' (ACH_Auth_MerchAcct.html) -- and is reported on centrally across stores: the Stored Value ACH Transaction Status report 'shows activity by merchant account number', plus a Merchant Account Number Audit report and an ACH Financial Authorizer Email Notification report, i.e. unified reporting over the per-entity destinations. WHY PARTIAL AND NOT YES: the documented funds flow is Aloha Stored Value ACH (gift-card sales/redemption liability settled daily to your ACH processor), not card-processing settlement; on the card side the platform documents multiple MIDs per processor (EDC 'Index'/'Store Index', separate credit and gift merchant-ID fields) but no document binds a card MID to a destination bank account or a legal entity, and 'split settlement' 0, 'sub-merchant' 0, 'legal entity' 0 across the whole 34.0 MB classic corpus (150-PDF library census + 1,238 doc-tree pages + this 292/292 help census + classic DevEx), with 'bank account' 57 hits of which every multi-account passage is Stored Value ACH. So part of the claim itself is satisfied for one funds flow under unified reporting; whole-of-settlement per-entity routing remains set in the unpublished merchant agreement. Retrieved 2026-09-18. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/ACH_TroubleshootACHTransactions.html · retrieved 2026-09-18 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

HEDGE OVERSTATED IN ONE DIRECTION AND UNDERSTATED IN THE OTHER, VALUE UNCHANGED. An AoC is not merely 'not located' -- it is offered on request. The Mobile Pay Operator Guide states 'www.ncrpay.com is a PCI-DSS validated consumer-facing web site and NCR Mobile Pay does not store payment information on a device. Contact your NCR representative for a record of compliance', and explains the AoC mechanism before pointing at NCR's validated-products list behind an INTERNAL SharePoint URL, i.e. the list exists but is not merchant-reachable. Against that, the P2PE feature guide disclaims validation twice: 'Keep in mind, this is not a PCI P2PE validated solution; however, the merchant's PCI QSA or the acquirer shall determine the PCI scope reduction.' No PCI DSS 4.x version is named on any surface we hold. Scope kept tight: the AoC language sits in a Mobile Pay guide and evidences an AoC for ncrpay.com, NOT for the Aloha POS P2PE path. https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_PointtoPointEncryptionFFG-HKS374.pdf · retrieved 2026-08-09

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

Aloha Kitchen Routing Rulebook and item routing configure station targets by item, category and workflow, per site. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/configuring_item_routing · 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

Expo stations are first-class in the routing rulebook and sit at the start or the end of a workflow. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/field_definitions/routing_rulebook · 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

Course Ordering in Table Service holds and fires courses; Aloha Kitchen consumes the course state. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/course_ordering/implementing_course_ordering · retrieved 2026-08-01

Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator

kitchen-prep-time-pacing

Per-item cook times drive item timing and staged progression to prepared state within Aloha Kitchen automation. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/automating_aloha_kitchen · retrieved 2026-08-01

Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator

kitchen-order-throttling

Aloha Kitchen's Quote Time function is exactly a load-triggered automatic extension of quoted prep time. Maintenance > Kitchen Configuration > Quote Time carries a Thresholds Table: 'Use the Quote Time Threshold Table to determine when to change the quote time. If the number of active items exceeds the item count, then the next highest quote time value is used. You can send the quote time to Aloha Takeout and feed up to Aloha Online.' Each row pairs 'Number of items' with 'Quote time in minutes' (minutes to add for that item count). The integration page confirms the runtime effect: 'when the kitchen is cooking 10 items, the quote time is 10 minutes; however, when the kitchen is cooking 50 items, the quote time is 25 minutes', enabled by selecting 'Use Kitchen quote times' in ATO Takeout Settings. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/field_definitions/quote_time · retrieved 2026-08-08

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

Availability does propagate automatically out of the POS, but only to the vendor's own channel. Aloha Online Ordering can be configured to receive item availability updates through Aloha Takeout once Takeout is integrated with the Business Services Platform, and the effect is described plainly: 'any item that is fully depleted or marked as unavailable in the POS does not appear for selection in the online menu. When the item is marked as available, it reappears in the online menu.' Nothing equivalent is documented toward third-party marketplaces. The vendor's own account of what an active marketplace integration does is narrower -- in the Marketplace self-serve onboarding guide, an Active site is one where 'the partner can read menus and inject orders' -- and no marketplace pause exists anywhere: store pause and pause the store occur zero times across every corpus, and the three snooze matches were read and are a fuel cashier deferring a price-change popup on FuelPOS. https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/configuring_online_order_features/supporting_item_availability_updates · retrieved 2026-09-10 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

Aloha Kitchen documents bumping thoroughly and documents no outbound event from it. The only order-ready notification NCR Voyix ships on a bump is a guest text message, and it belongs to the other lineage -- the page describing it says 'If using KDS, once the entire ticket is bumped, a text message is automatically sent to the customer, informing them the order is ready for pickup', under the Aloha Cloud topic, which this record's scope rule excludes. For the classic tier, the vendor's own description of a live marketplace integration is inbound only -- an Active site is one where 'the partner can read menus and inject orders'. No courier dispatch event, marketplace status callback or webhook fired from a KDS bump is documented anywhere. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/ssio · retrieved 2026-09-10 adversarially verified

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

kitchen-bump-bar-hardware

Bumpbar Layout objects with per-station port assignment; typical deployments run separate expo and production layouts. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/field_definitions/bumpbar_layout · 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

HELD AT partial DELIBERATELY, AGAINST A RECOMMENDATION TO FLIP, BECAUSE TWO SEPARATE FEATURES WERE BEING WELDED INTO ONE ANSWER. Both facts are real and now sourced. An all-day view exists: 'All Day -- Toggles between displaying and exiting the All Day screen on the video screen to allow you to view the current list of active orders', with a touch-screen equivalent, 'All Day Summary -- Adds the All Day command at the bottom of the kitchen screen to allow you to view all active orders'. Quantity aggregation also exists: 'Enable on-screen item consolidation -- Consolidates all like items on the video screen' on Expo and Production views, and 'Consolidate items in this category in production screens ... For example, if the consumer orders three sides of guacamole, (3) Guacamole appears on the screen.' But the claim requires the ALL-DAY VIEW to aggregate outstanding quantities per item and modifier, and Aloha Kitchen describes the All Day screen only as showing 'the current list of active orders' -- the counted consolidation is a property of the production/expo screens, not of All Day. No document we hold joins them. https://docs.ncrvoyix.com/downloads/aloha-kitchen/AK19138_ReferenceGuide-HKS1720.pdf · retrieved 2026-08-09

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

Item and order cook times drive timing states used for visual escalation on kitchen screens. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/automating_aloha_kitchen · 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

The hedge tested ALERTING, which this claim does not ask for. Failover itself is a first-class configuration pair in the Aloha POS reference guides: 'Backup printer -- Identifies a backup printer to use in the event of hardware failure ... If the originally designated printer fails for longer than the time interval specified in `Reroute timeout seconds' ... the system reroutes output to the backup printer', with 'Reroute timeout seconds' specifying 'the amount of time, in seconds, the system waits before rerouting the print job from the defined printer to the backup printer' (0-65535). Aloha Kitchen carries the screen-side equivalent, a 'Backup station' under kitchen redundancy; as of AK v17.2 an undefined backup station disables kitchen redundancy rather than defaulting to the lowest-ID station. Kept explicit: the system reroutes the print job, but no guide states no-ticket-loss as a guarantee, and no alert-on-failover field exists in the Printers or Options group bars. https://docs.ncrvoyix.com/downloads/aloha-pos/QS1911_ReferenceGuide-HKS1779.pdf · retrieved 2026-08-09

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

kitchen-offline-operation

Aloha Kitchen runs on the store LAN against the on-prem POS, so tickets continue during a WAN outage. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/manually_configuring_aloha_kitchen_hardware · retrieved 2026-08-01

Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator

kitchen-item-build-screens

Production Assembly Line feature guide documents item-level build and assembly station screens. https://docs.ncrvoyix.com/downloads/aloha-kitchen/AK_ProductionAssemblyLineFFG-HKS1548.pdf · 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

HEDGE UPHELD, and now measured rather than assumed. Across all 150 documents of the /downloads/ PDF corpus 'fraction' occurs 597 times in 17 documents, NONE of them Aloha Kitchen -- 343 hits in the QS Advanced Pizza FFG, 139 in the TS Advanced Pizza FFG, 6 in the Basic Pizza FFG, the rest in POS reference and report guides. The Aloha Kitchen v19.13.8 Reference Guide contains the word 'pizza' zero times. What the pizza guides document is order-object structure, not rendering: 'select Fraction to indicate this item is a pizza fraction item' with options 1/2, 1/3, 1/4, and Basic Pizza uses text separator items ('Left Half'/'Right Half') recommended to 'display differently from menu items so they stand out on the FOH'. No guide describes graphical section rendering on a make-line screen or chit. One limit: the pizza guides are figure-heavy and a text extraction cannot read a rendered chit image. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/advanced_pizza_qs/using_pizzas_with_fractional_toppings · retrieved 2026-08-09

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

kitchen-recall-refire

The bumpbar command set includes recall and unbump operations on kitchen screens. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/field_definitions/bumpbar_layout · 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

Aloha Kitchen Kitchen Settings carries the option verbatim: 'Display indicator on changed items -- Displays a delta (triangle) indicator on the kitchen screen next to the item that you added, changed, cleared, or voided.' Two documented caveats: it requires 'One behind' selected in the 'Routing method' drop-down list, and the doc notes the indicator does not appear when the changed item is the last item on the display. Related: 'Print only modified items -- Automatically prints a kitchen chit only when you modify an item.' https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/field_definitions/kitchen_settings · retrieved 2026-08-08

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

Bump-triggered guest SMS is documented and configurable: 'At the time you fully bump (serve) the order in Aloha Kitchen, the system sends a text message to the guest', and Kitchen Settings > 'Paging method' selects which bump fires it - 'Page on any bump', 'Page on course prepared', 'Page on course served', 'Page on order served'. The default message is 'Order 10 is ready for pick up.' The guest mobile number comes from the Name Order button in Quick Service, a tab in Table Service, or from the Aloha Takeout customer record. Shortfall: this is not free of a separate purchase. The feature page says 'Separate License Required? No' but also 'You must contact a JTECH representative (800-321-6221) to set up an account and place the order for the transmitter, which makes wireless paging possible... getting started requires a one-time setup fee, per site, for the transmitter.' Aloha Kitchen itself is a separately licensed product from Aloha POS, and the parallel HME Wireless Text Paging tree is a second third-party vendor. No first-party, purchase-free order-status board or app push was found in the 2,311-URL docs.ncrvoyix.com sitemap. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/wireless_text_paging/implementing_wireless_text_paging · retrieved 2026-08-09 adversarially verified

Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.

kitchen-waste-logging

Quick Count Feature Focus Guide (HKS316) documents a real waste log with stock effect, but not at the KDS and not with reason codes. On the FOH, 'Touch Waste Counts. The Enter Waste Counts screen appears'; the guide defines waste as 'items thrown away or unused, for reasons such as over-production or spoilage', and a tracking item appears there only if 'Display item on the Waste count screen' is selected. The entry moves the tracked-item balance - Quick Count reconciles Opening, Add, Usage, Waste and Closing counts into an adjusted on-hand, with 'Auto depletion and replenishment' handling sales/voids/refunds automatically while 'You must manually enter Waste Counts'. Optional 'Print waste chits' records 'The name of the person entering the waste, the time and date of the entry, the wasted item(s), and the quantity wasted'. SHORTFALLS: (1) that screen is an Aloha POS FOH panel, not the KDS - the guide's own KDS section, 'Interfacing quick count with video display systems', only puts tracking-item quantities into the video summary cell; (2) no reason code is captured anywhere. The chit records who, when, what and how much and nothing else, and the earlier statement that waste and spoilage reason codes exist in the Aloha Smart Manager inventory module is WITHDRAWN: it quoted the module's opening blurb. The full ASM with Aloha Essentials Inventory User Guide (November 17 2025) reprints that blurb verbatim on its 'About inventory management' page and then enumerates the module's actual screens - units of measure, raw items, vendors, vendor items, invoices, the 'Invoice history' report, counting inventory and managing locations, the 'Cost of goods sold' report, recipes, sales items and modifier groups - with no waste-entry screen and no reason-code maintenance screen among them, and the inventory count workflow's only non-count actions are 'Out of stock' and 'Skip'; (3) remakes are not logged at all - Aloha Kitchen's nearest command is Refire, which reprints to the line with no reason and no stock effect; and (4) the one genuinely KDS-side waste action, assigning forecast-bin quantity to waste from the bump bar plus 'Shelf life in seconds' auto-moving cooked items into the bin's Waste section, is forecast variance only and does not touch inventory. https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_QuickCountFFG-HKS316.pdf · retrieved 2026-08-09 adversarially verified

Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.

kitchen-speed-of-service-reporting

Quick Service Report Guide documents a Speed of Service report including bump-time breakdown. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS_ReportGuide.pdf · retrieved 2026-08-01

Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.

kitchen-prep-forecasting

Aloha Kitchen Forecast Bins produce predicted prep quantities from sales history and surface them at the production station: 'The quantity that appears in a forecast bin is based on up to four prior weeks of historical sales data, which allows you to take a more proactive approach to bins.' A forecast bin lets you 'Populate a bin quantity based on historical sales data, instead of the current sales from the FOH', 'Define the text to appear on the label of each cooking stage of the bin', 'Display a forecast report to gauge an upcoming bin quantity and analyze waste data, by variance', and 'Establish a minimum bin quantity for occasions when the projected total might fall below the amount necessary to run the bin'. The Forecasting function sets those minimums per bin per time interval for each day of the week, and kitchen staff can adjust a bin quantity on demand from the bump bar. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/forecast_bins/implementing_forecast_bins · retrieved 2026-08-08

Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).

delivery-driver-roster

Score upheld but the note overstates. Clock-in state and idle-time tracking are confirmed on the cited page; driver LICENCE and INSURANCE status and run history are NOT mentioned anywhere on it. Those details appear to have been imported from elsewhere or assumed — strike them from the note. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/configuring_ato_for_delivery · retrieved 2026-08-01 adversarially verified

Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).

delivery-dispatch-board

Verified: the ATO delivery configuration page documents 'Open drivers on clock in' and 'Restrict dispatch to longest in driver', defined as the driver with the greatest idle time since clocking in, plus minimum time between runs. A real first-party dispatch board, not a partner product. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/configuring_ato_for_delivery · retrieved 2026-08-01 adversarially verified

Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator

delivery-route-map

SHORTFALL REFUTED BY THE SAME PRODUCT'S OTHER GUIDE. The hedge said 'system-generated multi-stop route sequencing is not documented'; the ATO Reference Guide states 'With the addition of a mapping license, ATO interfaces with a mapping application to provide multi-stop routes and maps. Selecting a driver with assigned orders allows you to view and print the map and directions ... Turn-by-turn route information also prints on driver itineraries.' The Takeout Settings field definition adds 'Enable mapping -- Enables a map retrieval program, for establishing the maximum efficient routes for each delivery run', and the Implementation Guide sells it as 'optimizing delivery routes for drivers'. Kept explicit: routing requires a separately licensed Takeout Delivery Mapping option plus a third-party mapping application, and the optimisation is attributed to that program rather than to ATO itself. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO201_ReferenceGuide-HKS1661.pdf · retrieved 2026-08-09

Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator

delivery-driver-tracking

Aloha Takeout's Delivery Area Feature Focus Guide is the vendor's dedicated delivery-management document and its contents enumerate the whole dispatch surface: assigning delivery orders, rearranging the order of a delivery run, viewing and printing a driver route, printing a driver itinerary manually, reassigning a delivery order, recalling a driver, returning a driver, and features specific to the Map screen. Every one of those is a dispatcher action on a fixed screen. There is no driver-facing mobile application and no captured driver position: `GPS`, `driver tracking`, `driver location`, `real-time location` and `live location` occur zero times across the 17.9 MB PDF corpus, the 1,238 docs.ncrvoyix.com pages and the 292-page Insight help. The guide states of its own route estimate that 'estimated time is not a real-time estimate based on traffic or road construction.' The only `GPS` string anywhere in the NCR corpora is a hardware spec line for the Axium handheld, and the only `geo-fence` is the delivery-area polygon border. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO_DeliveryAreaFFG-HKS351.pdf · retrieved 2026-09-10 adversarially verified

Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator

delivery-zones-polygon

Aloha Takeout Delivery Area is map-drawn, not radius or postcode based: 'A delivery area is typically unique to each site and usually looks like an odd-shaped polygon radiating out from a site, with a geo-fence border ... You can easily define a delivery area and delivery zones, if necessary, using Map Pack and a paint-brush style configuration tool.' The doc names drive-time limits as a design input ('Some things that affect the delivery area for a site include franchise rights, geographic boundaries, and drive time limits'). The resulting DeliveryArea.xml is a hierarchy of delivery area > zone > neighborhood > street with lower/upper street-number ranges and even/odd side-of-street, so the boundary can follow arbitrary geography down to one side of one block. It requires an Aloha Takeout and Delivery Mapping licence and a regional Geobase Map Pack. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/delivery_area/implementing_delivery_area · retrieved 2026-08-08

Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.

delivery-zone-pricing

Per-zone fees are explicit. The Delivery Areas field definitions expose 'Delivery fee -- Stipulates the delivery fee for the selected delivery area type' on each node of the area/zone/neighborhood/street tree, and the Takeout Settings Delivery Fees tab has a Delivery zone method: 'Enables the system to calculate the delivery based on the delivery fee defined in the zone', with a 'Delivery zone default fee' for addresses that fall in a qualified zone. Assignment is automatic from the validated address -- type-ahead address lookup resolves the address into the area, and 'Restrict delivery orders to delivery area' blocks addresses outside it. Shortfalls: no per-zone order minimum exists (the Delivery Fees tab's minimum/maximum settings cap the fee, not the check), and no per-zone promise time exists -- quote times are held per order mode on the ATO info bar or driven globally by Aloha Kitchen, and capacity limits are per order mode per day part, never per zone. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/field_definitions/fielddefinitions_delivery_areas · retrieved 2026-08-08

Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.

delivery-address-validation

Confirmed: the system 'checks an address when you begin a delivery order', supports 'Restrict delivery orders to delivery area', and offers type-ahead address lookup. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/configuring_ato_for_delivery · retrieved 2026-08-01 adversarially verified

Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator

delivery-driver-comp

UPHELD partial 2026-08-10, but the prior shortfall sentence - 'mileage is not a compensation input ... no per-run mileage is captured against the driver' - was false, and refuted by the ATO Implementation Guide the record already cites. That guide enumerates the whole scheme: 'Drivers receive compensation for deliveries in several ways: Hourly rate ... Tips - Cash or credit tips, which are deducted from the net cash owed by the driver on the driver checkout report. Driver fees - A per delivery amount or check percentage ... Mileage - A per day mileage fee that is calculated by the payroll company and received on their paycheck.' Driver Commission Groups attach to a job code and pay per run by Flat amount, Check percentage, Charge percentage or Delivery zone, bounded by minimum and maximum and optionally varied by day part; tips are captured via 'Prompt for driver tips on return'; and mileage IS captured - POS Jobcodes has 'Prompt for mileage - Enables a delivery driver to track mileage for reimbursement', and ATO instructs you to 'Type the Driver fee per mile to prompt for the starting mileage at clock in and ending mileage at clock out. The net mileage appears on the labor report for payroll to calculate driver reimbursement based on an agreed mileage rate.' THE FIRST-PARTY CONTRADICTION THIS NOTE PREVIOUSLY LEFT VISIBLE IS NOW RESOLVED, AND IT WAS NEVER A CONTRADICTION - IT IS ONE FIELD NAME OVER TWO MECHANISMS. The POS Employees > Delivery tab defines 'Driver fee per mile - Defines the dollar per mile reimbursement the driver receives for each delivery. This option is for use with `Delivery/Frequent Buyer.' No equivalent functionality exists in Aloha Takeout.' - that is AUTOMATIC DOLLAR-PER-MILE REIMBURSEMENT, scoped by its own sentence to the legacy POS Delivery/Frequent Buyer module. What ATO does with the same field is only to TRIGGER a mileage prompt at clock in and clock out; the rate is applied downstream, 'by the payroll company'. A third quote settles it in the vendor's favour: ATO's own POS-field mapping table marks the Delivery tab entry 'Driver fee per mile N/A' while marking 'Driver fee amount per order' and 'Driver fee percent' Optional. So both sentences are true, and the resolution SHARPENS the shortfall rather than removing it. WHAT REMAINS: mileage is per SHIFT, not per run - ATO calls it 'a per day mileage fee' and directs sites using it away from the ATO driver checkout entirely - ATO computes no per-mile amount at all, and the reimbursement-versus-wage split exists only inside the ATO Driver Checkout report, with no documented payroll export carrying distinct reimbursement and wage lines. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/creating_pos_jobcodes_access_levels_employees · retrieved 2026-08-10 adversarially verified

Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.

delivery-cash-reconcile

Confirmed verbatim: 'Auto cash to store on driver checkout' and 'Must authorize cash to store/driver' requiring manager authorization. Driver cash settle-up is genuinely native — this is a real differentiator versus cloud POS competitors. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/configuring_ato_for_delivery · retrieved 2026-08-01 adversarially verified

Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.

delivery-daas-dispatch

NCR announced logistics partnerships with DoorDash and Grubhub; native courier quote and status return into the order record not documented. https://www.fastcasual.com/news/doordash-and-grubhub-partner-with-ncr-to-streamline-logistics/ · retrieved 2026-08-01

Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator

delivery-daas-fallback

UPHELD no 2026-08-10, but the ENTIRE PRIOR RATIONALE was wrong and is replaced. It asserted 'there is no courier-marketplace or third-party-fleet option' and that 'the sitemap contains no DaaS or courier-handoff page in any classic Aloha tree'. A DaaS substrate exists: Aloha Takeout's BSL service list includes 'Delivery - Used by Aloha Takeout to connect third-party and in-store delivery services', Digital Ordering advertises 'Last mile delivery integration' as a shipped feature and its release notes send consumer apartment numbers to 'Last-Mile Delivery partners', and the DevEx Delivery API offers multi-partner availability, quotes, create and cancel (POST /deliveries/availability, POST /quotes, POST /deliveries). WHY no STILL HOLDS, and this is the real finding: the choice between fleets is EXCLUSIVE AND STATIC, not a rule. The Digital Ordering Implementation Guide defines 'Delivery Type - Identifies the type of delivery used by the company. Select from Fleet or External for a third-party delivery', and per site 'Delivery Mode ... Fleet - Indicates delivery is provided at the store. External - Indicates the site uses an external delivery service.' Where DaaS is used the routing decision belongs to the consumer picking a quote, not to a threshold. Every ATO dispatch rule targets in-house drivers only, and the documented out-of-zone behaviour is to block rather than overflow: 'Restrict delivery orders to delivery area - Prevents new and existing customers from starting delivery orders if a customer address is not within the defined delivery area.' No trigger the claim names - no driver available, out of zone, past a wait threshold - appears on any surface, and 'overflow' returns zero across the DevEx API Explorer's 379 ProductHowTo and 3,122 SwaggerOperation rows with the control passing. Also recorded: the prior note's premise that the ATO Options tab is 'the complete configurable surface of Aloha Takeout' is false - the Panel Options tab holds the online-order-acceptance controls. https://docs.ncrvoyix.com/downloads/aloha-digital-ordering/DO_ImplementationGuide-HKS1518.pdf · retrieved 2026-08-10 adversarially verified

Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator

delivery-3p-direct-integration

UPHELD partial 2026-08-10, grade D -> B, AND THE PRIOR NOTE MATERIALLY UNDERSTATED THE PRODUCT: its claim that 'nothing on docs.ncrvoyix.com names any marketplace' and that 'middleware remains the ordinary route' was measured on the wrong surfaces. NCR operates the plumbing itself. The BSL 'Order' service is 'Used by Aloha Takeout to receive orders from the third-party marketplace and send new order information and order status updates as the order progresses through the fulfilment process in the restaurant', the 'Delivery' service is 'Used by Aloha Takeout to connect third-party and in-store delivery services', and the wiring is concrete: 'You must share the POS order mode ID with the third-party delivery service for them to use. When the delivery service submits an order with that order mode ID, Aloha Takeout recognizes that the order is from that service.' NCR also sells the onboarding console: Self-Serve Integration Onboarding 'is a feature in the NCR Voyix Marketplace that allows IT and admin users to independently enable and manage integrations with third-party partners (such as DoorDash) for their restaurant sites', where 'Active status means the partner can read menus and inject orders.' SHORTFALL against the claim as worded: DoorDash is the only marketplace named in an integration context. Uber Eats appears once and illustratively ('Partners such as DoorDash or UberEats that exist within BSL'), and Grubhub only in a gig-economy glossary ('the rise of on-demand services (e.g., DoorDash, GrubHub, Uber)'). No ATO or Digital Ordering guide names any marketplace at all, so certified per-partner integrations for all three are not published. https://docs.ncrvoyix.com/restaurant/aloha-takeout/integrating/integrating_ato_and_bsl/integrating_ato_and_bsl · retrieved 2026-08-10 adversarially verified

Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.

delivery-3p-injection

A 'yes' on a weighted integration cell resting entirely on a vendor marketing page ('orders flow directly into the POS without tablet re-keying') is exactly the failure mode to correct. No product documentation for a first-party marketplace connector was located; the dossier's own evidence points the other way — Deliverect and Chowly publish the Aloha connectors, and NCR Voyix is absent from DoorDash's 2026 preferred roster. Middleware is the documented path. https://www.ncrvoyix.com/platform/restaurant-applications/ordering-fulfillment/point-of-sale · retrieved 2026-08-01 adversarially verified

Menu, pricing, modifiers, and photos publish from the POS master menu out to connected third-party marketplaces, including channel-specific price markups, without maintaining a separate menu in each portal.

delivery-menu-push

UPHELD partial 2026-08-10; every quote in the prior note verified verbatim against HKS1744 after whitespace-collapse and de-hyphenation, and the shortfall is now measured on three surfaces rather than one. Menu, pricing, modifiers, photos and the no-separate-portal conjunct are met: Aloha Menu is 'an easy-to-use web-based authoring tool that allows you to create a full menu to be consumed by other products and services for publishing', sales items must already exist in the POS database, images attach to every menu element, and solution partners consume the menu directly. THE FAILING CONJUNCT IS CHANNEL-SPECIFIC PRICE MARKUPS. Aloha Menu computes nothing - 'Price schemes allow pricing customization among solution partners, order fulfillment types, order channels, menus, site groups, and sites. You do not set prices in Aloha Menu ... The system uses the revenue center designated for exporting to the BSL Catalog service in Aloha POS' - and markup, mark-up and percentage occur zero times in that guide. In the classic POS the Price Changes function assigns 'the new price to assign to the item' and to the price level, the sole percentage form being confined to promotions: 'Depending on the type of promotion, you can define the price change as a percentage rather than a specific amount.' The platform engine behind the price schemes confirms the channel half and refutes the markup half: DevEx Catalog v3's Prices Service resolves price 'using multiple parameters such as fulfillment type, order channel, solution partner, and time windows', but every override is absolute ('Global price: $10, Region override: $9, Store override: $8.50'), and markup returns zero of 3,122 API-Explorer operations against a passing control. Channel-VARYING price is documented; a markup rule over a base price is not. Held consistent with menu-pricing-channel-price-books deliberately: one fact must not yield two answers. Source correction: HKS1744 is dated 24 March 2025; 'v2.24, September 2025' was the PRODUCT release, not the guide. https://docs.ncrvoyix.com/restaurant/aloha-menu/about/overview · retrieved 2026-08-10 adversarially verified

Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).

delivery-86-sync

Item-level 86 propagation off the POS is real and bidirectional, but the documented destination is NCR's own ordering channel, not a marketplace. Aloha Online Ordering: 'You can configure Aloha Online Ordering to receive item availability updates through Aloha Takeout (ATO). To do this, you must integrate Aloha Takeout with the Business Services Platform (BSP). You must be on Aloha Takeout v17.1, or later ... Once configured, any item that is fully depleted or marked as unavailable in the POS does not appear for selection in the online menu. When the item is marked as available, it reappears in the online menu' - so restore-on-availability is explicit. The transport is a platform service, not a point integration: the Aloha POS Items field definitions carry a Catalog group bar exporting each item, and each item within a modifier group, 'to the Business Services Layer (BSL) Catalog service', Modifier Groups carry the same 'Available for online' flag, and the Aloha Digital Ordering v22.x release notes name a 'BSL Item Availability service'. SHORTFALLS: no document states that availability reaches DoorDash, Uber Eats or Grubhub - NCR Voyix Marketplace's Self-Serve Integration Onboarding describes a DoorDash partner as able to 'read menus and inject orders' and lists 'maintaining menu accuracy' as the operator's job, with no availability push named; modifier-level 86 is documented outbound only as a menu-export flag, and its runtime effect is an inbound rejection rule ('Reject items with failed modifiers') rather than an out-of-stock message; and near-real-time latency is nowhere characterised. https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/configuring_online_order_features/supporting_item_availability_updates · retrieved 2026-08-09

Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.

delivery-store-pause

UPHELD partial 2026-08-10, and BOTH prior shortfalls were false - the pause is not portal-only and it does auto-reactivate. Aloha Takeout's Takeout Settings > Panel Options > Info Bar tab carries 'Enable Stop accepting online orders - Controls whether a store can stop accepting online orders temporarily until EOD, or semi-permanently until specifically started again by the manager', which puts a Stop Accepting Online Orders button on the ATO front-of-house Dashboard, and as of ATO v20.1 adds per-order-mode toggles for Catering, Curbside, Delivery, Drive-thru and Pickup, each with a reset-at-end-of-day pair. Timed reactivation exists in that EOD form: 'The store begins accepting online orders after the end of day occurs.' Digital Ordering's Emergency Closed switch is the above-store equivalent, synchronous with Web Admin. THE CONJUNCT THAT ACTUALLY FAILS: what stops is the store's ACCEPTANCE of orders arriving from the BSP service, not the store's listing on each connected marketplace - no page on the Aloha Takeout or Digital Ordering trees documents pushing a paused or closed status OUT to a third-party marketplace - and reactivation is tied to end-of-day rather than an operator-set timer. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/field_definitions/takeout_settings/takeoutsettings_panel_options_tab · retrieved 2026-08-10 adversarially verified

Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator

delivery-3p-reconciliation

Enumerated the vendor's own complete report catalogues rather than searching. The Aloha Quick Service and Table Service Report Guides (469KB and 493KB of extracted text, each a full chapter-by-chapter enumeration of every BOH and FOH report) return ZERO occurrences of 'commission', 'payout', 'royalty', 'DoorDash', 'Uber Eats', 'Grubhub' or 'marketplace'. The Aloha Takeout Report Guide (HKS1719) is the delivery-specific catalogue and its only 'commission' is driver pay - 'The total amount of delivery commissions earned by the driver' on the driver Pre-Checkout and Employee Checkout reports, which 'may be a negative amount, which is a commission owed to the driver'. In Aloha Smart Manager third-party sales appear only as a tender line: the Payments sales report field table reads 'Payment name - The name of payment through which the amount is paid. For example, Credit card, DoorDash, OLO etc.', and the ASM Essentials user guide's report set (Invoice history, Cost of goods sold, Sales summary, Product mix, Profit and loss, Revenue centers, Voids, Discounts, Payments, Transactions, POS event log) contains no commission, marketing-fee, payout or adjustment column. NCR Voyix Data Sharing publishes its full data-set catalogue - Check summary, Comp summary, Item discount, Item sales, Item voids, Labor, Promotion summary, Sales totals, Taxes, Tenders - with no marketplace settlement fields, and the NCR Payment Solutions settlement guide (HKS508) reconciles card batches to NCR's own deposits only. No report in the published catalogue matches marketplace deposits to POS-recorded 3P sales or identifies missing or unpaid orders. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO_ReportGuide-HKS1719.pdf · retrieved 2026-08-09

Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator

delivery-injection-error-visibility

UPHELD partial 2026-08-10, and the note's own caveat is discharged. It ended 'this cell cites an API-Explorer spec page absent from the DevEx dump, so a per-channel status field could exist there'. That page is Order Monitor (productId 1270) and it is now read in full. IT IS SITE HEALTH, NOT PER-CHANNEL. Order Monitor 'offers customers and partners the ability to know the status of their sites and whether they're able to process orders': a Passive Monitor whose latency fields 'retrospectively check for any created order within a maximum allowable timeframe' (maxCreatedLatency, maxUpdatedLatency, maxAcknowledgedLatency, executionPeriod default 60 seconds), and an Active Monitor that 'sends synthetic orders to a site and waits for the downstream system to respond', escalating over VALIDATION_FLOW, ACKNOWLEDGEMENT_FLOW or CUSTOM_FLOW. THE ALERTING CONJUNCT IS MET AND IS THE STRONGEST EVIDENCE THIS CELL HAS EVER HAD: subscribers receive ORDER_MONITOR_SITE_HEALTH messages carrying '"type":"SITE_HEALTH_CHANGE" ... "previousStatus":"WARNING","currentStatus":"OFFLINE"', filterable via 'messageAttributePatterns', across Online, Offline, Warning, Extended Offline and Unmonitored, with GET /order-monitor/sites/health for an instant snapshot. THE PER-CHANNEL CONJUNCT STILL FAILS, AND NOW ON EVIDENCE RATHER THAN SILENCE: every Order Monitor object is keyed to an enterpriseUnitId and the service carries no channel or partner dimension, and an individual failed injection is never surfaced -- the monitor INFERS a whole site is down from the absence of order traffic. Stated so this is not later read as a corpus-wide absence: a channel dimension does exist one service over, as 'channel' and 'channel-label' attributes on Order's ORDER_CHANGE notifications, but those describe an order's origin, not a connection's health. The vendor's own caution is worth keeping against silent failure: 'If messages aren't sent to a subscriber successfully, there is a possiblity that messages will send out of order due to the retry behavior.' [vendor's spelling] https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/1270 · retrieved 2026-08-10

Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.

delivery-tracking-page

PARTLY OVERSTATED, VALUE UNCHANGED. The guest-facing driver-tracking half survives -- no live driver map on the restaurant's own domain appears on any surface we hold, and ATO's mapping is a STAFF dispatch tool ('Selecting a driver with assigned orders allows you to view and print the map and directions'). But the cell missed a real capability: the Aloha Solution v19.9 Enhancement Release Guide records under ATO-3422 that 'Aloha Takeout now passes the order status to the cloud through Aloha Pulse to provide customers and their consumers accurate real time updates in the order fulfillment process.' So consumer-facing real-time ORDER STATUS is documented; branded live DRIVER LOCATION is not. Sourcing note kept deliberately: the transport is named 'Aloha Pulse', and the pulse documentation tree was scoped 2026-08-09 as Aloha Cloud / SMB lineage -- this cell cites the classic Aloha Solution v19.9 ERG and must not reach into that tree. https://docs.ncrvoyix.com/restaurant/digital-ordering/implementing/configuring_site_settings · retrieved 2026-08-09

Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator

delivery-promise-time

RE-POINTED off an Aloha Kitchen bumpbar_layout field page, which had nothing to do with promise-time computation. The hedge ('dynamic adjustment is not documented') is refuted: Aloha Kitchen 'Displays dynamic quote times based on several real-time productivity metrics', and the ATO/AK Integration Guide gives the mechanism -- 'you can allow AK to override the quote times in ATO based on the production in the kitchen ... The adjustment is based on the number of items currently cooking in the kitchen', with the guide stating the negative case precisely: without the integration 'the default quote time values in ATO remain static and do not automatically update based on production from the kitchen.' Drive time is a system-calculated per-order element a manager can override. HELD AT partial for a narrower reason than before: driver availability is documented only as an order-capacity gate ('You can limit each order mode by the number of orders, number of items, or labor resources available'), not as an input that adjusts the quoted promise time. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO_ATOandAKIntegrationGuide-HKS327.pdf · retrieved 2026-08-09

Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.

delivery-offline-behavior

UPHELD partial 2026-08-10, but the prior premise - that the only documented scenario is loss of the in-store BOH file server rather than an internet outage - was false across the estate. Three surfaces document degraded operation. Aloha Takeout covers the server case: 'Enable offline support - Permits entry of takeout or delivery orders, when the ATO service host is unavailable, or is not running', with explicit degradation - 'caller ID and database search capabilities are compromised ... you must enter all customers as new, these new records are not added to the database when connectivity is restored.' For a genuine WAN outage the payment path is documented on the POS: Store and Forward (HKS381) means 'the system approves the transaction amount, if it is within the defined limits, stores the transaction, and attempts to authorize it again at a later time', while 'all debit cards processed as true debit cards, not as credit cards, automatically decline while the processor is in the store and forward state' and 'Store and Forward does not support EBT cards.' The QS v19.11 Reference Guide's Business continuity section adds that if 'the store cannot connect to the host database, store employees can work in offline mode'. THE SHORTFALL, and it is what keeps this partial: across the ATO, POS and CFC surfaces no page states what happens to driver assignment, dispatch, driver settlement or cash accountability during an outage of any kind, nor to cash delivery orders specifically. https://docs.ncrvoyix.com/restaurant/aloha-takeout/implementing/enabling_redundancy · retrieved 2026-08-10 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

Aloha Digital Ordering / Aloha Online Ordering is a first-party branded ordering channel linked to Aloha Enterprise. https://docs.ncrvoyix.com/restaurant/digital-ordering/integrating/digital_ordering_and_asval/link_aoo_to_ae · 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

SHORTFALL RE-SCOPED 2026-08-09. The old note read 'Digital Ordering integrates to the Aloha Enterprise menu, but maintains its own site and company settings layer' -- a fact about Digital Ordering used to characterise the vendor's single-source story generally. The Aloha Menu User Guide (HKS1744, v2.24) shows one shared authoring layer serving every digital channel at once, sourced from POS records: 'Aloha Menu is an easy-to-use web-based authoring tool that allows you to create a full menu to be consumed by other products and services for publishing', 'Manage menus for all channels, from owned online ordering to third-party delivery', and the POS remains the master -- 'You cannot add new sales items in Aloha Menu. You must use a sales item already defined in the POS database.' That is one build for all digital channels rather than one per channel, which is a real improvement in the evidence. The answer does not change, and the reason is precise: the claim requires the digital menu be generated from the same POS record WITHOUT a separate digital menu build, and Aloha Menu is exactly such a build step, layering its own consumer-facing names, descriptions, images, tags, external IDs and availability windows over the POS item ('Name -- Displays the name of the sales item that appears to the consumer ... POS Name -- ... You cannot change this name in Aloha Menu'). https://docs.ncrvoyix.com/restaurant/digital-ordering/integrating/digital_ordering_and_asval/configure_ae_for_do_integration · retrieved 2026-08-01

Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator

digital-native-app

CITATION-BY-INFERENCE REPLACED WITH DIRECT SOURCING, VALUE UNCHANGED. The old note asserted Engage Mobile was 'the branded mobile app product referenced throughout Digital Ordering docs' without a source for the product itself. Two now exist. The engage-mobile product overview states Aloha Engage Mobile 'enables restaurant brands to create their own branded mobile app for ordering, payment, loyalty, and stored value redemption', iOS and Android, Related products: Aloha POS -- but it is a vendor feature list (grade C) on a tree carrying 'WE HAVE MOVED! THIS SITE IS NO LONGER UPDATED' whose newest release note is v22.2, October 2022, so it evidences existence, not current sale. Stronger and current: the Digital Ordering Contactless Dine-In guide requires 'Mobile App Deep Link' and 'App ID' fields 'for consumers who use the Engage Mobile App for ordering' -- a deep link plus an App ID only makes sense for an installed native app. HELD AT partial on the publication model: App Store, Play Store and Google Play across all corpora surface only NCR-branded apps, and Engage Mobile's stated installation method is 'Remote installation', so publication under the restaurant's own brand is undocumented. https://docs.ncrvoyix.com/restaurant/digital-ordering/integrating/digital_ordering_and_cm/integrating_do_em_and_consumer_marketing · retrieved 2026-08-09

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

HELD AT partial, AGAINST A RECOMMENDATION TO FLIP, BECAUSE ONE OF THE CLAIM'S THREE CONJUNCTS IS GENUINELY UNMET. Two are now documented rather than hedged. Tokenized saved cards: 'Click Save Card for Future Use to save the payment card information ... The system saves the stored card under the `Default Payment Information' section of the My Profile screen', the CVV is not stored, and 'You can store up to five payment cards when processing with Connected Payments. Note: If the site is also processing with EDC, you can only store one card.' One-tap reorder: 'Re-Order Recent/Favorite Order -- Allows consumers to place an order saved as a favorite or a previous order without navigating through the menu.' A SAVED ADDRESS BOOK is not documented in the 7 Digital Ordering PDFs held locally, nor in the Aloha Engage Mobile feature list, and the claim names saved addresses explicitly. Aloha Engage Mobile's overview advertises the same two capabilities on a second classic surface, but it is a vendor product-overview feature list (grade C) on a tree frozen at v22.2 in October 2022, so it corroborates and does not carry this cell. https://docs.ncrvoyix.com/downloads/aloha-digital-ordering/DO_DOandCPIntegrationGuide-HKS1536.pdf · retrieved 2026-08-09

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

Digital Ordering has a rules-based upsell engine: Web Admin > Designs > Upsell Configuration builds a Sales Item Group, an Upsell Suggestion, and an Upsell Suggestion Assignment naming the trigger items, so 'when an assigned item appears on the check, and the consumer adds it to the cart, the associated upsell items appear.' Aloha Online Ordering runs the same configuration as a checkout-time popup. Shortfalls: the suggestion is trigger-item rules only - Digital Ordering overrides the operator's suggestion text with a fixed 'PEOPLE ALSO ORDERED' label and there is no personalization from order history; and no attach-rate or upsell-conversion reporting on those suggestions appears in the Digital Ordering portal, the AOO company/site dashboards, or the Consumer Marketing report catalog. https://docs.ncrvoyix.com/restaurant/digital-ordering/implementing/configuring_upselling · retrieved 2026-08-08

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

Aloha Online Ordering calls this capacity management: Designs > Capacity Management > Capacity Configurations takes an interval in minutes, an item count and an order count, the days of week, and a start/end time - 'if you set the interval for 30 minutes and the order count to 4, the system only allows 4 online orders every 30 minutes' - and 'once your online ordering site reaches the maximum number of orders or items for a store location, the site restricts the specific time frame from the promise time selection page,' i.e. the slot closes to the guest. Per-item Count Multipliers weight prep-heavy items. Operators can instead delegate to Aloha Takeout (UseATOCapacity=True), where order-scheduling day parts (Breakfast, Lunch, ...) each carry maximum items and orders, and ATO counts in-store as well as online orders. Future/scheduled orders are supported (ATO 'Enable future day orders'). https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/company_and_site_settings/control_the_number_of_online_orders_you_can_receive · retrieved 2026-08-08

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

One Digital Ordering configuration surface enables all four modes as company-level toggles: 'Display Dine-In', 'Display Delivery', 'Display Curbside', 'Display Pickup', each with a matching site and menu assignment. Mode-specific prep timing is on the same tab - 'Menu Lead Time' (days), 'Pickup Lead Time' and 'Pickup Time Granularity', 'Delivery Lead Time', 'Delivery Time Granularity' and 'Delivery Time As Range' - and it can defer to the POS promise engine via 'Use ATO Capacity... when providing the consumer with a promise time.' Mode-specific fees are there too: 'Minimum Delivery Order Total Amount', 'Site Level Delivery Fees - Uses delivery fees configured in Aloha POS and Aloha Takeout', 'Apply Tax to Delivery Fee', and release AO-16902 'The service charge fee for an order mode (curbside, pickup, or dine-in) is now visible to the consumer.' Curbside arrival check-in is documented in Aloha Takeout Takeout Settings > Options > Check In, whose 'Check in alert behavior' options range from 'No alert' to 'Display notification on list of terminals' and exist to notify staff 'a check-in action occurred and the consumer is near or at the premises'. Dine-in is the Contactless Dine-In QR flow. Delivery Type selects 'Fleet or External for a third-party delivery.' https://docs.ncrvoyix.com/restaurant/digital-ordering/implementing/company_settings/ordering_settings_tab · retrieved 2026-08-09 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

Both QR surfaces exist. Scan-to-pay attaches to the existing POS check: Aloha Mobile Pay prints 'a unique QR code and six-digit code' on the guest check and the guest can 'View their itemized check. Add a tip. Submit payment.', with preset tip percentages configurable at ncrpay.com/dash. Scan-to-order exists separately as Digital Ordering Contactless Dine-In, where the QR 'opens a blank order in the Mobile Web app'. Shortfalls: (1) splitting is not a guest-side function - the Mobile Pay FAQ answers 'How does a consumer split a guest check?' with 'Guests who want to split payment or split items on a check can work with their servers to split the check-and then can still pay through the NCR Mobile Pay', so the server must split first; (2) the scan-to-order path does not attach to the server's existing check, it opens a new Digital Ordering order whose table is carried only as an ATO order note; (3) the guest payment does not close the check - the server closes it after a FOH popup. https://docs.ncrvoyix.com/restaurant/aloha-mobile-pay/using/frequently_asked_questions · retrieved 2026-08-09 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

UPHELD partial 2026-08-10, grade D -> B: the citation moves off a press release onto both flagship reference guides. One of the claim's three tests is met and two are not. Menu parity is documented: 'you also use Configuration Center to build and activate the POS order entry screens that appear on the FOH terminal or self-service kiosk in a store. These order entry screens are also managed in the centralized database, and distributed to stores, as necessary' (Aloha QS and TS v19.11 Reference Guides, Ch. 1). The kiosk is a named first-party terminal function - 'Kiosk (QS only) - Indicates this terminal is an interface terminal used by NCR Kiosk and not the Aloha POS' - enabled by 'Uses Kiosk - Activates Consumer Self Ordering (Kiosks)', with POS order modes opted in individually via 'Display on kiosk (QS only)'. UNMET: no unattended or CNP-attended EMV statement exists anywhere - 'unattended' appears in the 150-guide PDF corpus only as a bump-bar setting and as a warning not to leave payment devices with a guest - and no accessibility conformance statement exists for the kiosk on any surface, with VPAT, Section 508 and WCAG appearing in zero of the 150 first-party PDFs. NCR's published ADA and WCAG remediation belongs to Digital Ordering and Aloha Menu, not the kiosk. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/terminals · retrieved 2026-08-10 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

Aloha Online Ordering ships Group Order By Invitation, enabled by adding GroupByInvitation to the AvailableOrderTypes company setting. A logged-in Event Organizer picks the store, a target time and a response deadline, sends email invitations, each invitee follows their link and submits their own items, and the organizer clicks Build Order (which locks invitee editing) then checks out - 'as one order with a single payment.' A reusable Group Order Address Book lives on the customer profile. Shortfalls named by the claim and absent from the doc: no per-person or total spend cap on what invitees may add, and no split payment - the organizer alone pays. Invitations go out as emailed links to named addresses rather than as an open shareable link. https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/configuring_online_order_features/supporting_group_ordering · retrieved 2026-08-08

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

Aloha Takeout lists catering among its operational types ('Use for pick-up orders or expand to delivery, curbside, catering, and other operational types') and carries the pieces a catering flow needs: Future Orders 'book orders up to five years in advance and automatically release them based on promise and prep times,' saved payment information for 'regular or business customers,' and POS House Account integration imported against ATO customer profiles. A Deposits feature (Takeout Settings > Deposits: deposit tender, deposit order mode, deposit revenue item) prepays and authorizes an online order before release. Shortfalls: no distinct catering ordering portal is documented - no separate catering menu or order minimums, no lead-time rule specific to catering, and no quote/proposal or invoice/ACH payment-terms workflow anywhere in the ATO, Digital Ordering or Aloha Online Ordering trees. https://docs.ncrvoyix.com/restaurant/aloha-takeout/overview · retrieved 2026-08-08

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

The vendor's own ordering-and-fulfillment page enumerates the channels it serves -- 'Meet guests wherever they want to order: at the counter, table, kiosk, mobile, drive-thru or delivery' -- and inbound phone is not among them. No AI phone-answering product is offered first-party or named as a certified partner anywhere: taken as a word, `voice` appears in only two of 304 marketing pages, both legal, and `IVR` in the product corpora means voice authorisation for a gift-card tender. The closest the site comes is a blog telling readers to 'explore innovations such as predictive prep, voice-enabled ordering, kitchen operation' as industry trends, which is advice about the market rather than a product claim. https://www.ncrvoyix.com/platform/restaurant-applications/ordering-fulfillment · retrieved 2026-09-10 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

Drive-thru is a documented Aloha channel -- `drive-thru` matches 362 times in the product PDFs and 21 times on the marketing site -- and in every one of those the lane is operated by a person on a headset or an order point. No AI ordering, speech recognition or escalation-to-human handoff is documented for the lane: `voice AI`, `AI voice` and `speech recognition` occur zero times across all corpora, and the January 2026 next-generation portfolio announcement, which does name conversational AI for analytics, names nothing for the drive-thru. https://www.ncrvoyix.com/platform/restaurant-applications/ordering-fulfillment · retrieved 2026-09-10 adversarially verified

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

digital-sms-ordering

The one documented SMS-to-transaction rail is Text to Pay, and it pays an existing check rather than opening an order: 'Guests may pay their guest check using a text message you send to their mobile phone. The check code is embedded into the text message. The guest touches the URL and follows the prompts to complete the payment process.' The operator must first recall an open check on the POS and press a Text to Pay button, so the order already exists. Consumer Marketing sends outbound SMS and MMS marketing with shortened links, but its documented objects are campaigns, coupons and segments, never an order. No conversational SMS or chat ordering exists in any corpus. https://docs.ncrvoyix.com/restaurant/aloha-mobile-pay/using/using_text_to_pay · retrieved 2026-09-10 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

NCR Voyix's published position on the Google listing is that the operator maintains it by hand. Its own guide to the subject tells the reader that 'Google Business Profile has a functionality that lets business owners add their own structured menu and showcase it directly on their Google business listing. It can be done in the dashboard with the rest of your business's information', then walks through claiming the listing and entering the menu. No provisioning from the POS or from the ordering platform is offered, and the phrase Order with Google occurs zero times across the 150 product PDFs, 2,320 developer-portal docs, 1,238 docs.ncrvoyix.com pages and all 304 non-Japanese marketing pages. The vendor does ship a Google integration and it is listing-side rather than ordering-side: the NCR Voyix Marketplace application declares a product whose display name is Google Business Profile Integration and whose endpoints are account management, business information, site mapping and location verification, with no place-action or ordering-link provisioning. Graded C because the Marketplace product catalogue answers 401 to an anonymous reader, so its scope is read from the application NCR Voyix serves publicly. https://www.ncrvoyix.com/resources/blog/how-to-edit-your-restaurants-menu-in-google-business-profile · retrieved 2026-09-10 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

`Apple Business Connect` occurs zero times across every NCR Voyix corpus read for this record, and there is no Apple Maps surface of any kind. The comparison is what makes the absence legible: NCR Voyix built and ships a Google Business Profile integration in its Marketplace application, so it does treat map-listing provisioning as a product area, and it has built no Apple equivalent. No 'Order Food' custom action, no Apple Maps place card and no Apple listing management appears in the marketing site, the developer portal, the product PDFs or the doc trees. https://www.ncrvoyix.com/partners/marketplace · retrieved 2026-09-10 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

Aloha Loyalty and Consumer Marketing integrate into Digital Ordering and Engage Mobile via the Business Services Platform. https://docs.ncrvoyix.com/restaurant/digital-ordering/integrating/digital_ordering_and_cm/integrating_do_em_and_consumer_marketing · retrieved 2026-08-01

Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.

digital-subscriptions

The word membership does appear in NCR Voyix Loyalty, and it means an earned segment rather than a paid tier. The promotion engine grants and revokes it on spend: the worked example is a customer who spends '$100 on Nescafe products' and is 'granted a' Nescafe Gold 'membership as a reward', with the tier 'revoked and are granted a' Platinum one once 'cumulative spending on Nescafe products exceeds the threshold say $200'. No money moves from the guest. Across every corpus the terms recurring billing, subscription program, paid membership, membership fee and subscription tier match four times in total and each was read: a payments-glossary definition of a 'Recurring Billing Transaction', a charges page listing 'membership fee' among non-sales revenue items, and a VIP membership-fee discount whose own page says 'This feature is currently offered to a limited audience and is not generally available' -- the last two both filed under the Aloha Cloud topic, which this record's scope rule excludes, and the one page in the doc trees actually titled Subscriptions is Mobile Pay's administrator email alerts -- 'Subscriptions are email alerts a user receives based on actions performed in Mobile Pay Dashboard.' https://docs.ncrvoyix.com/retail/ncr-voyix-loyalty/userguide/Rewards/grant_revoke_membership · retrieved 2026-09-10 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

Promotions and discounts defined in Aloha Enterprise flow to Digital Ordering; channel eligibility controls are not fully documented. https://docs.ncrvoyix.com/restaurant/digital-ordering/integrating/digital_ordering_and_asval/configure_ae_for_do_integration · retrieved 2026-08-01

Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator

digital-guest-data-ownership

UPHELD partial 2026-08-10, now measured on two independent guest-data surfaces rather than one. Consumer Marketing documents self-serve bulk export (Segmentation > Actions > Export Segment, downloaded from the Notifications Center as a .CSV); Aloha Insight adds an older second path, where 'The Loyalty Card Lookup offers you two ways to export your query' and writes profile_export.csv, auto-downloading when a query exceeds the member list box. Both are operator-run with no fee and no support ticket. The claim then fails on the same three points in BOTH places, which is what makes the shortfall safe to publish. Ownership: no NCR document states the operator owns the guest records - the Sales Orders Terms and Conditions define 'Customer Content' without assigning title to either party, and reserve NCR's right to use system information 'after it has been aggregated, for analytics, commercial, and benchmarking purposes'. The only 'Data Owner - The customer producing the data to be shared' language belongs to Data Sharing, whose enumerated data sets (Check Summary, Tenders, Taxes, Comp Summary, Item Discount, Item Voids, Promotion Summary, Sales Totals, Item Sales) contain no guest record at all. Consented marketing status appears in neither export. Order history appears in neither: Insight's column list ends at 'Last Visit Date'. Recorded as a scoping trap: marketing copy promising 'you own the guest relationship ... including order history' is Aloha Order Direct, a cloud product this record excludes. https://docs.ncrvoyix.com/restaurant/consumer-marketing/using/working_with_segments/exporting_a_segment · retrieved 2026-08-10 adversarially verified

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

Re-cited after the old /restaurant/security URL was retired. The live payments page carries the same proposition verbatim: 'secure hosted pay page or API options for online ordering to help limit PCI scope', plus 'Point-to-point encryption and enterprise-wide tokenization remove cardholder data from the POS' and 'Tier 1 and 2 PCI-certified redundant data centers'. Shortfall: no PCI DSS 4.0 statement at all, nothing on the client-side script-integrity requirements effective March 2025, and no 3DS support statement. https://www.ncrvoyix.com/platform/restaurant-applications/payments · retrieved 2026-08-08 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

UPHELD partial 2026-08-10, and the parity gap turns out to be at the POS rather than at the digital tier. The digital channel does share the POS fee construct: an AOO service charge is implemented as a POS order-mode charge ('Apply service charge', fixed $0.00) that Aloha Takeout overwrites with the calculated amount, with UseSiteLevelDeliveryFees driving site-level rates. Past service and delivery fees the parity ends, and the Supporting Cash Discounts QRG (HKS1742) says why: 'While cash discounting is fully available with Aloha POS, credit card surcharges are only available in Aloha Cloud' - a documented refusal for classic, so there is no card surcharge for the digital tier to mirror. Classic dual pricing is a POS comp an employee applies at cash tender and 'applies to checks that are fully paid in cash and is invalid if the check has a partial payment by a credit/debit card', which cannot exist in a self-service channel. Disclosure and card-network compliance are assigned to the operator: it is 'the responsibility of the merchant to ensure the standard (non-discounted) price appears to the consumer at all times ... printed and digital menus', and 'Cash discounting cannot be used with other fee programs defined by the card networks, such as surcharging, convenience fees, and service fees.' No jurisdiction logic exists on any surface; the Digital Ordering CHECKOUT AND PAYMENTS tab offers only Tip Entry and Hide Tax. Recorded as a trap: the POS Store page's 'Enable Surcharges' is an ITEM-LEVEL levy, not a card surcharge. https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/company_and_site_settings/configure_a_service_charge_fee · retrieved 2026-08-10 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

Held at partial; the classic surface confirms the shortfall from a second direction and names the actual join key. ALOHA LOYALTY IDENTITY IS THE CARD, NOT THE PERSON: a mandatory 14-digit card number, with existing programmes forced through a support-built transform ("A card transform uses the existing number and transposes it to a unique 14 digit number... Aloha Insight develops an algorithm that runs behind the scenes"). Alternate lookups (phone, email, driver's licence, name) resolve TO a card. MemberLink is the guest-facing profile — "enables you to augment your Loyalty system by allowing cardholders to access Web pages where they can register/update their profile information and view their current Stored Value/Loyalty balances" — and it too authenticates on card number plus ePin or a security question. NO DEDUP OR MERGE BEHAVIOUR IS DOCUMENTED ANYWHERE IN THE 292 PAGES, matching the Consumer Marketing finding. https://docs.ncrvoyix.com/restaurant/digital-ordering/integrating/digital_ordering_and_cm/integrating_do_em_and_consumer_marketing · retrieved 2026-08-09

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

Read the whole Aloha Takeout Virtual Kitchen FFG (HKS1718, https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO_VirtualKitchenFFG-HKS1718.pdf), which is Aloha's documented marketplace path: an aggregator order 'is submitted to Business Services Layer (BSL), and then injected into Aloha Takeout (ATO), and then to Aloha Kitchen (AK)'. Its configuration list is complete and enumerable - create Concepts, create a revenue center per concept/aggregator combination, add Concept and Aggregator columns to the ATO Pickup and All Orders panels, add the Aggregator element to a header/footer layout, to a bag label and to a production or order-taker chit, refresh POS data - and not one step maps the inbound order to an ATO customer profile or a Consumer Marketing member; the guide's identifying elements are all print and display. Separately, ATO does maintain customer profiles (Takeout Customer Organizer, Caller ID 'New Guest' creation, the Takeout Data Importer's GenericCustomer import, POS house-account association, documented in the ATO v20.1 Reference and Implementation Guides), and Consumer Marketing member assignment is documented as a manual front-of-house action. Unresolved: the Virtual Kitchen FFG is a configuration guide, not a field-level statement of what the BSL Order Service payload carries, and that schema is in the gated API Explorer on developer.ncrvoyix.com. || 329th: NEW THIS PASS. (1) ATO's own 'External Order Interface' -- the only inbound-order construct in Aloha Takeout's settings -- is documented as NOT IN PRODUCTION: 'Enable external order interface -- Enables the C1200 display or Web ordering interface to integrate with ATO. This feature is not currently supported in production versions of ATO. Recommended Configuration: Cleared' (Takeout Settings > Options tab, ATO v20.1/v20.1.3 Reference and Implementation Guides), and the Implementation Guide repeats 'the external order interface functionality is reserved for future versions of Aloha Takeout'. So the marketplace path really is the BSL -> ATO -> AK injection of the Virtual Kitchen FFG, and ATO's own documented customer-creation surfaces are all manual: Caller-ID 'New Guest', order-taker 'create or locate existing customers', type-ahead address lookup, 'Check for duplicates ... compares the exact first and last name of the new customer to existing customers'. No page in the 262-page aloha-takeout tree or the 30 ATO PDFs maps an injected/aggregator order onto a customer record. (2) BOUND ON THE GATED SCHEMA, measured: the developer.ncrvoyix.com portal (Angular, 4 bundles, main.c6e270e7a4a42263.js 508 KB, no lazy-chunk table) builds every call from apiUrlBase + /product/<id>, /product/<id>/howtos, /search, /product/<id>/proxies/<n>/contract; anonymously /api/product, /api/product/1936, /api/product/1936/howtos and /api/documentation all return 400 and /api/search 405 (GET), so the request schemas are not public. What IS public is the portal's own search index (5,442 entries: 3,122 SwaggerOperation, 1,941 HelpCenter, 379 ProductHowTo) and it carries only {productId, method, path, operationId, summary} -- no models. The classic-facing injection product is 'InStore Order API' 1936 (POST /AlohaAccess/{handlerId}/Order 'Inject an Order'); its customer block is therefore still unbounded, and Order 374's operations expose no customer sub-resource (Selling Cart Service 848 /carts/{cartId}/customer belongs to the Emerald/retail stack, not Aloha). (3) Controls over the 34.0 MB classic corpus: 'guest profile' 11, all ATO/Consumer-Marketing native profiles; the 18 DoorDash hits are partner onboarding, receipt order-source printing and a Gig-economy glossary entry; BSL's DoorDash/UberEats passage is about partner ACCESS TO DATA ('may request and be approved for access to data for Midtown Burgers'), not identity attach. Retrieved 2026-09-18. 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

Held at yes; the value was right and the product attribution was wrong. Classic Aloha Loyalty enumerates EIGHT plan types in its own FAQ, not the three previously recorded from Consumer Marketing: "Be My Guest-based, Currency-based, Employee Comp-based, Frequency-based, Items-based, Lottery-based, Points-based, Smart Rewards-based." Accrual granularity is configurable ("one point for every dollar they spend, or... three points for every three items"), plans can be linked ("you can link multiple Points-based plans together"), discounted items can be included or excluded from earn "before or after applying the promotion or comp", and there are four reward types: Corporate-issued, Stored Value Add Value, Real-time Discount and Reward Voucher. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/bonus_plan_faq.html · retrieved 2026-08-09 adversarially verified

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

guest-loyalty-tiers

Neither of NCR's two loyalty products for Aloha ships a status-tier object, but both ship enough scheduling machinery for an operator to approximate one, which is why this is partial rather than absent. CLASSIC ALOHA (Aloha Loyalty, in the Aloha Insight suite): bonus plans have reward levels, not member status - 'You can create different tiers or levels of rewards for your bonus plans so that a member has a lower threshold on one reward and then stagger to a higher threshold on a larger reward' - and the Reset Options tab supplies the rolling-window half: 'Reset merit after ___ days of non-usage' ('the merit resets to zero after 30 days of non-usage'), 'Reset merit when merit ___ ___ and ___ days of non-usage' with Equal To / Greater Than / Greater Than or Equal To qualifiers, 'Reset plan every ___ days after member sign-up date', 'Reset plan every ___ days after plan start date', and resets at the start of a Day, Week, Company Week, Month, Fiscal Period, Pay Period, Visit or Year. Plan types are Currency-based, Points-based, Items-based, Frequency-based, Lottery-based, Be My Guest-based and Employee comp-based. CLOUD (Consumer Marketing): program shapes are Bankable Rewards, Currency Based, Items Based, Visits Based and Points Based; periodical campaign rules 'run solely based on a unit of time passing', schedule Daily, Weekly, Monthly or Day of Month, and are 'ideal for scheduling recurring rules like a birthday reward ... or a win-back offer targeting customers who have not shopped in the last 30 days', with status carried in demographic customer-model fields (the worked example is 'Free Shipping Earned' set on spend and cleared by an annual rule). SHORTFALLS: no tier entity and no membership level on the member record on either surface - grepping all 292 Aloha Insight pages finds no status or tier field on a member - so promotion and demotion are assembled by the operator from reward thresholds and scheduled resets; Consumer Marketing caps this at 'The total number of allowable periodical rules per brand is 20 rules' with soft-cap, hard-cap and monthly firing ceilings; and NCR Voyix Loyalty, which does have a Tier construct, is a separate retail product whose tiers are promotion reward levels ('Tier 1: Spend $50, get 10% off'), not membership status. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/Reward_levels_bp.html · retrieved 2026-08-09 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

One connectivity outcome is documented, and it is blocked-with-an-error rather than queue-and-reconcile; the rest of the claim is still unevidenced. Aloha Loyalty's own FOH troubleshooting topic is the only place the vendor states what happens: "If you encounter a message stating, 'The Loyalty application is not running...,' upon startup of the FOH, the Loyalty program is off-line or disconnected. Contact your Loyalty support for assistance in resolving the error." That is the entire treatment - the 292-page Aloha Insight help system (support.alohaenterprise.com, the Aloha Loyalty and Stored Value help) returns no other hit for offline, timeout, retry, queue or unavailable, and describes Aloha Loyalty as "a Web-based back-office application that tracks the buying habits of your customers in real-time via an Internet connection". Two things bound how much this can carry. It covers FOH startup only: nothing states what an already-running terminal does to a lookup, an accrual or a redemption when the host drops mid-shift, and the POS-side configuration offers only 'Number of milliseconds to wait for host connection' with no stated consequence when the wait expires, plus 'Default Comp Id' and 'Default Promo Id' which apply when the host returns no ID rather than when it is unreachable (Maintenance > Guest Experience > Loyalty Providers, TS and QS v19.11 Reference Guides; the Generic Loyalty Using BSL FFG HKS528 returns zero hits for the same terms). And it is a contrast case rather than an oversight: sibling Aloha Stored Value ships an explicit disconnected design - a 'semi-connected' store that 'queries the in-store database for gift card approvals' with configurable auto-approve thresholds, versus a 'virtual' store that queries the central database in real time - so NCR documents this pattern where it exists and does not document it for loyalty. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/TroubleShoot_FOH.html · retrieved 2026-08-09

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

guest-loyalty-offer-stacking-rules

Held at yes on the POS Promotions citation, which stays. What was missing is that THE LOYALTY LAYER HAS ITS OWN STACKING MODEL on top of it, and that is where an Aloha Loyalty operator actually configures this. Bonus events stack multiplicatively and independently: "a check qualifies for an event that awards double credit on beer items, and a second event that awards triple credit on beer items during happy hour... The member receives a total of 20 points credit for the bonus plan and events." Rewards are ordered by an explicit priority field ("Reward Priority — Indicates the order in which the member receives the reward when more than one reward is earned on a check"), capped per day, and losers are queued: "You can configure Loyalty to 'queue' or save the rejected real-time rewards for future visits." Loyalty discounts are also a segregated promo/comp class — "Any Aloha POS promotion or comp in which you select 'Loyalty Real Time' is strictly for use when applying a Loyalty discount to a FOH check. You cannot place it on the FOH Promo or Comp Lookup screens." https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/promotions · retrieved 2026-08-09

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

Held at yes. Classic Aloha delivers audience-targeted offers and the worked example is the canonical win-back: "A Smart Rewards-based plan enables you to use historical data to determine the members who will be eligible to receive a one-time reward upon their next visit... offer all cardholders who have not used their card within the last 30 days a $5.00 discount on their next visit." Geographic targeting is native ("Select from All Stores, Areas, Regions, Replication Groups, Stores, and Store Groups"), as is behavioural narrowing by category, revenue center, day part, hours and order mode. THE LIMIT TO NAME: delivery is in-store — a real-time discount or a printed voucher — not an outbound message. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/Smart_Bonus_Plan.html · retrieved 2026-08-09

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

Held at yes. Classic Aloha has RFM in substance without the vocabulary — the 292 pages return zero hits for RFM, recency and churn. Smart Rewards bonus plans are built on exactly those metrics: "There are different metrics upon which you can base the reward: Card first used, Card not used, Dollars spent, Items purchased, Number of visits", and the Member Profile module adds nine query filters over the same axes including Card Last Used and Card Not Used. DIFFERENCE WORTH RECORDING versus Consumer Marketing: on classic Aloha this is a TARGETING INPUT TO A REWARD RULE, not a reporting classification — there is no Active/At Risk/Churned state model on the member. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/smartreward_settings.html · retrieved 2026-08-09

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

Held at yes, with the product attribution corrected: birthday/anniversary/win-back automation is not new with Consumer Marketing, classic Aloha Loyalty had it. Bonus events fire "on a special occasion for the member. The drop-down list includes Anniversary, Birthday, and Sign-Up Date", with the operator choosing "the specific date only, during the week of the occasion, or the month of the occasion", and the FAQ adds the guard "if the member did not supply you with the date of his or her birthday, the system cannot detect when they have a birthday." Smart Reward issuance schedules are Daily / Weekly / Monthly / Sign-Up Date / Birthday / Anniversary with recurrence intervals. THE LIMIT TO NAME: these are always-on earn rules that fire at the terminal on the member's next visit, not outbound triggered messages — nothing is sent to the guest between visits. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/Bonus_Events_sched_BP.html · retrieved 2026-08-09 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

Held at yes ON CONSUMER MARKETING, with a scoping correction: this must not be read as something an Aloha loyalty operator has always had. THE 292-PAGE ALOHA INSIGHT HELP SYSTEM DOCUMENTS NO SENDING ENGINE AT ALL — zero hits for unsubscribe, opt-in and opt-out; "campaign" appears once, as "Campaign # — Reserved for future use"; and the only SMS hits are Pulse EMPLOYEE alerts ("Contains the mobile number Pulse uses to send alerts"). The documented outbound path on classic Aloha is manual and external: "you can import it into Excel for analysis and generate a mailing or email list... export the data into Word as a mail merge, or even export the data into Outlook to send an email list." Classic Aloha Loyalty collects an email address and hands you a CSV. https://docs.ncrvoyix.com/restaurant/consumer-marketing/using/creating_a_scheduled_multichannel_message · retrieved 2026-08-09 adversarially verified

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

Held at partial, with the shortfall strengthened by a second, cleaner instance. The 292-page Aloha Insight help system has NO CONSENT OBJECT WHATSOEVER — no subscription list, no opt-out link, no consent timestamp, no source-of-consent field. The Member Profile tab lists every collectable member field (Anniversary Date, Birth Date, Card Number, Card Type, City, Company, Country, Email Address, First Name, Last Name, Other Phone #, Phone #, Postal Code, State) plus up to 30 company-defined fields, and none of them is a permission flag. The only privacy affordance is a link: "Indicates you are displaying a link to your privacy statement next to the email address on the Gift Card Registration and Edit Profile pages." https://docs.ncrvoyix.com/restaurant/consumer-marketing/using/working_with_emails/creating_email_lists · retrieved 2026-08-09

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

guest-loyalty-10dlc-registration

Held at unknown. Zero hits for 10DLC, A2P and short code across the 292-page Aloha Insight help system — consistent with the existing rationale and adding nothing, since Insight has no messaging rail at all. SUPERSEDED 2026-09-10: NCR Consumer Marketing is the classic-tier messaging rail and it does document carrier compliance -- its FAQ answers the alcohol/cannabis question by reference to the CTIA, whose 'Short Code Handbook' it says 'outlines the types of messages that cannot be delivered using a short code for both legal and ethical reasons.' The rail is therefore short-code based. A2P 10DLC brand and campaign registration is documented nowhere: `10DLC`, `A2P`, `TCPA`, `campaign registration`, `brand registration` and `carrier registration` each occur zero times across every NCR Voyix corpus read for this record -- 17.9 MB of 150 product PDFs, 2,320 developer-portal docs, 1,238 docs.ncrvoyix.com pages, the 292-page Aloha Insight help and all 304 non-Japanese www.ncrvoyix.com pages. Control `Aloha` matches in all of them. https://docs.ncrvoyix.com/restaurant/consumer-marketing/faq/frequently_asked_questions · retrieved 2026-09-10 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

Held at yes, and an absence sentence must NOT be written here: this is unknowable from the Insight corpus rather than absent from it. The Aloha Loyalty getting-started page says only "Aloha Loyalty comes standard with detailed reports... Select Aloha Loyalty in the Category drop-down list to view a list of available Aloha Loyalty reports" — THE REPORT CATALOGUE IS RENDERED AT RUNTIME AND IS NOT IN THE HELP SYSTEM, so the Loyalty report list cannot be enumerated from it. What IS documented: rejected real-time rewards surface in Loyalty reports, Stored Value has a drilldown dataset (Redemption Count/Dollars, Add Value Count/Dollars by Area/Store/Series/Card Number), and loyalty discounts map one-to-one, one-to-some or one-to-many onto POS promo/comp IDs so they roll up separately in Aloha reporting. https://docs.ncrvoyix.com/restaurant/consumer-marketing/reporting/communication_attribution_report · retrieved 2026-08-09

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

Held at partial. A second self-serve export surface with the SAME shortfall, which strengthens the verdict rather than moving it. Classic Aloha Loyalty exports the member query to CSV with a fully enumerated 32-column layout including every PII field (name, address, phone, email, birth date, anniversary, plus company-defined fields 1-30); "the exported file contains only the information the Loyalty member supplied." TWO LIMITS: it is MEMBERS ONLY, NO TRANSACTION HISTORY (history is view-and-print-per-card in Card Lookup), and the interactive list box caps at 3,000 members before forcing the download path. Unlike Consumer Marketing there is no documented PII-suppression toggle — access is governed by Security Class Setup instead. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/Export_Loyalty_Query.html · retrieved 2026-08-09

Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator

guest-loyalty-cdp-event-api

Held at partial. The 292-page Aloha Insight help system has zero hits for webhook, SOAP, REST-as-a-word and event stream; its three "API" matches and one "web service" match are unrelated (the latter means the hosted product: "After signing up for the Aloha Insight Web service"). The only documented bulk-data motions are operator-driven CSV export and a SUPPORT-MEDIATED member import — "Contact Aloha Insight support for more information on importing existing members into Aloha Loyalty. Aloha Insight support facilitates this process." That is a data-entry channel, not an API, and it does not disturb the BSP-based verdict. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/1563/how-to?howToId=888 · retrieved 2026-08-09

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

Held at partial. The 292-page Aloha Insight help system has zero hits for survey, NPS, Yelp or review-site. Its Alerts / Alerts Viewer subsystem (13 + 6 pages) monitors STORE BUSINESS EXCEPTIONS routed to users by email, cell phone or pager — it is not a guest-feedback rail and does not touch the routing half of this claim in either direction. https://docs.ncrvoyix.com/restaurant/consumer-marketing/using/post_purchase_surveys/understanding_post_purchase_surveys · retrieved 2026-08-09 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

Held at partial. Zero hits for "referral" and "refer a friend" across all 292 pages of the Aloha Insight help system — the 537 "refer" matches are the help system's own "Refer to..." cross-references, which is the kind of substring count that manufactures a false positive. Aloha Loyalty's guest-facing surface is MemberLink, whose documented sections are profile registration/update and balance viewing; it has no referral section, unlike Consumer Marketing's Member Portal. https://docs.ncrvoyix.com/restaurant/consumer-marketing/faq/frequently_asked_questions · retrieved 2026-08-09

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

Held at unknown, with the null usefully narrowed. Zero hits for wallet and passbook across the 292-page Aloha Insight help system. MemberLink, the nearest analogue, is a CSS-skinned browser page the operator links from their own website ("a service hosted on the Hosted Solutions Group servers") that shows balances on request rather than pushing updates — not a wallet pass. This narrows the null but does not settle the claim. SUPERSEDED 2026-09-10: Reopened from unknown: the vendor does have a wallet integration and it runs the wrong direction. The Google Wallet Feature Focus Guide describes the POS reading credentials the consumer has already loaded onto their own phone, and it places the provisioning burden explicitly on the guest -- 'Consumers must download the Google Wallet application onto a supported smartphone and load their payment card information onto the NFC chip in their phone. If a consumer wishes to participate in a loyalty program, this requires additional configuration, as they also need to load their loyalty member number and configure the phone to receive wireless rewards and discounts from the loyalty program.' The POS setting is correspondingly a read setting, specifying 'whether you support payment-only or full Google Wallet integration'. Nothing issues a pass: `Apple Wallet` and `wallet pass` occur zero times across every corpus, and no push-updatable balance is documented. https://docs.ncrvoyix.com/downloads/aloha-pos/QS_GoogleWalletFFG-HKS365.pdf · retrieved 2026-09-10 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

Held at partial, with real new evidence of an ADMIN control — exactly what this cell said was missing. Aloha Loyalty has a data-privacy configuration tab: "Use the controls on this tab to manage any sensitive data collected with the Aloha Loyalty system based on your business needs or regulatory requirements. The 'Delete member account data after X days of inactivity' option when engaged will delete any and all member profile data stored in Aloha Loyalty once a member has reached the defined threshold of inactivity... Their account will still be active to accept future assignments, but all of their sensitive data will be deleted. Additionally, if they have a MemberLink account, this account will also be deleted." That is operator-configured retention with cascade to the member portal. IT STAYS PARTIAL BECAUSE IT IS RETENTION AUTOMATION, NOT RIGHTS FULFILMENT: there is no per-guest access or erasure action, and the 292-page Aloha Insight help system returns zero hits for GDPR, "data subject" and "right to be forgotten" (the single CCPA match is the string "ACCPAC GL" in a report-builder page). Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/Config_dataPrivacy.html · retrieved 2026-08-09

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

CORRECTION: the previous note closed with "no redemption velocity or frequency limit is configurable". That is false for classic Aloha, and the contradicting control is a first-class configuration field. Aloha Loyalty Advanced Settings: "Members can be assigned to a check X times per day unless approved by a manager — Indicates the number of times you can assign the same Aloha Loyalty member to different checks on a single business day before prompting for manager approval. You can type a number from 0 to 100." The FAQ names the threat model: "This is a great way to keep employees from using a card over and over to earn rewards." Three further preventive controls sit alongside it — "Require Loyalty member card to be swiped and disallow manual entry unless approved by a manager" ("this can help prevent employees from entering the card number of a friend or their own card number and fraudulently getting a reward"), a per-check earn cap ("the maximum amount of credit (points, items, dollars, or visits) that a member can earn on a guest check"), and a per-day reward cap. So the corrected picture is preventive, manager-gated velocity controls on classic Aloha Loyalty PLUS detective fraud monitoring on Consumer Marketing — the opposite halves of what this cell previously said existed. Aloha Loyalty is a licensed module inside Aloha Insight. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/adv_bonus_plan_options.html · retrieved 2026-08-09

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

Two shipped, documented features, both with operational detail rather than roadmap language. AI Channel Optimization 'uses intelligent logic to automatically choose the best channel to send each message to your customers,' evaluating per-customer email opens/clicks and mobile clicks (weighted equally), checking subscription eligibility, and delivering email or SMS accordingly; it is a toggle on scheduled multichannel messages and on campaign notifications. Send Time Optimization sends each recipient's email at their own optimal time, 'calculated using the median of their previous open and click times,' dispatched in 10-minute intervals, and 'for users without a determined time, such as new users or those with no engagement data, the solution automatically recommends a time that has previously had high engagement based on the day of the week.' Scope note: these target channel and send timing; offer content and audience are not machine-generated. https://docs.ncrvoyix.com/restaurant/consumer-marketing/using/using_ai_channel_optimization · retrieved 2026-08-08

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

Held at yes, re-cited off an Aloha Online Ordering gift-card page onto the product's own documentation. "Aloha Gift Card is the next generation of web-based back-office applications for selling and redeeming gift cards", requiring "an Internet connection, Aloha v5.0 or greater, and Aloha Insight". It enumerates reload ("Allow value to be added to card after the original purchase"), expiry (Expires On / Expires In), remaining-balance policy (adjust / cash back / forfeit), dormancy service charges limited by store group "because service charges may not be appropriate in all states", and cross-site scope via replication groups. It also confirms the combined-card design: "you can create one card that a user can use as a Stored Value card and receive credit towards one of your bonus programs." Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/SV_FAQ.html · retrieved 2026-08-09

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

Held at yes. The ASM Labor settings page this cell cites has now been read in full and it places the punch at the terminal from the configuration side: a job carries "Show job on the POS system to make the job available for selection when logging in to the Front-of-House", the employee profile carries a Local device login group bar used "to enter the code to login to the POS", and the workday start time is what is used to "align punches to the business day". ASM’s own Working with punches screen is an after-the-fact editor - add a shift, adjust clock-in, clock-out and punch reason - which is only coherent if capture happens at the POS. The earlier Insight corroboration is unchanged. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/implementing/working_with_labor_settings · retrieved 2026-08-09

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

THE no SURVIVES A SIXTH SURFACE. photo, camera, facial, biometric and fingerprint occur zero times across all 75 pages of the Aloha Smart Manager web documentation, including Working with punches, which is the ASM punch surface and describes adding and adjusting a punch by date, employee, job, clock-in and clock-out time, break period, declared tips and an adjustment reason, with no capture verification of any kind. As with Insight, ASM is downstream of the POS and edits punches rather than taking them, so this corroborates rather than independently proves. The load-bearing evidence remains the Aloha POS Employees field definitions page, where fingerprint is the only biometric offered. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/employees · retrieved 2026-08-09

Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.

labor-geofenced-mobile-punch

CLAIM: mobile clock-in restricted by geofence or location validation. VERDICT: no (B). The prior passes' stated blocker -- 'no punch-CAPTURE document exists, only punch editors' -- is retired: the capture surface IS documented, and it is the fixed POS terminal. EVIDENCE: (1) the Jobcode 'Group bar: Time and Attendance' enumeration in the Aloha Table Service v19.11 and Quick Service v19.11 Reference Guides (Chapter 4: Maintenance Menu Field Definitions, the vendor's complete configuration field reference, 2.08 MB and 2.0 MB) lists the clock-in configuration in full -- 'Shift required to clock in/out -- Requires an employee clocked in under this job code to clock in and clock out at the beginning and end of each shift', 'Exclude from Labor Scheduling', 'Automatically clock in/out when ringing an order' -- and contains no location, device-location, geofence or validation option of any kind. (2) The three dedicated labor feature guides read this pass have the same shape and the same zeros: QSTS_ClockinMovieFFG-HKS344 ('you configure the Point-of-Sale (POS) system to require your kitchen staff to watch an instructional movie when they clock in'), QSTS_EmployeeBreaksFFG-HKS315 (282 KB: 'the break types you allow employees to take by the job code an employee uses when they clock in to the Aloha FOH'), QSTS_EmployeeReconciliationFFG-HKS307 -- offline 0, GPS 0, mobile 0, geo* 1 (an index artefact) in each. (3) NEW SURFACES READ THIS PASS: the two ASM116 guides that the 321st downloaded and never opened -- ASM116_StarterUserGuide.pdf (8.1 MB, 274,219 chars, 'Last Updated: April 17, 2025') and ASM116_GettingStartedGuide.pdf ('Last Updated: April 21, 2025') -- confirm capture is elsewhere: 'Others -- Miscellaneous reason for which the SYSTEM-RECORDED punch was modified', i.e. ASM edits punches the POS records. geofence 0, GPS 0, mobile punch 0 in both. BOUND: the census is (a) the docs.ncrvoyix.com Aloha PDF download library, 150 of 152 enumerated paths fetched, 17.6 MB, including both complete Reference Guides; (b) the six in-scope docs.ncrvoyix.com product trees, 1,238 pages (aloha-pos 650, aloha-takeout 262, aloha-kitchen 114, digital-ordering 114, consumer-marketing 81, data-sharing 13); (c) support.alohaenterprise.com Aloha Insight Online Help, and this pass established it is a CENSUS: the publisher's own WWHelp manifest /wwapp/en_US/wwhdata/common/files.js enumerates exactly 292 files and /wwhdata/js/toc.js 296 TOC entries, and the corpus on disk holds all 292 (2.2 MB, live and anonymous today, the host's 1,231-byte session shell is what returns for absent paths); (d) all four ASM guides and the ASM web help corpus; (e) the classic DevEx doc dump (6.7 MB). CONTROLS over all of it (34.0 MB, tokenised, word-boundary, case-insensitive): 'clock in' 1,966 and 'punch*' 1,177 (positive controls fire), against geofence/geo-fence/geofencing 3, GPS 0, 'location validation' 0, 'mobile punch|mobile clock' 0, 'web clock' 0, 'clock in remotely / from a phone' 0. POISON NAMED: all 3 geofence hits are ONE Aloha Takeout delivery-area page reproduced in three corpora ('a delivery area ... usually looks like an odd-shaped polygon radiating out from a site, with a geo-fence border') -- geofencing exists in Aloha's vocabulary for DELIVERY AREAS and never for labour; 'geolocat*' 6 = the ASM invoice-history report's 'Geo location (GL)' GENERAL-LEDGER category (4) plus BSL site coordinates (2); 'latitude' 26 = BSL/WebAdmin site geocoding. SCOPE: classic Aloha POS / Aloha Essentials plus its above-store apps (Insight, ASM); the Aloha Cloud / Silver Essentials trees are excluded by this record's scope rule and were not read onto it. Retrieved 2026-09-18. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · 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

CLAIM: punches recorded offline and reconciled on reconnect without loss/duplicates, documented. VERDICT: held unknown. NEW: (1) NEW SURFACE: Aloha Smart Manager User Guide PDF, https://docs.ncrvoyix.com/downloads/aloha-smart-manager/ASM_UserGuide.pdf (13.8 MB, "DRAFT Last Updated: October 21, 2025", "Updated the document to include Core functionalities"), unlinked from the current docs.ncrvoyix.com sitemap (2,311 URLs, identical to the 2026-08 copy) and found via Wayback CDX of docs.ncrvoyix.com/downloads/* (169 distinct paths, 17 not in the prior corpus). Its Labor chapter is again a manager editor: "Use the Punch summary screen to add a new punch ... adjust a punch for any modifications to the clock-in, clock-out, and to the punch reason", reasons incl. "Forgot to clock in/out". "offline" occurs 0 times in it. (2) TS v19.9 Reference Guide PDF (docs.ncrvoyix.com/downloads/aloha-pos/TS199_ReferenceGuide.pdf, 5.9 MB, not previously in corpus) repeats the same outage architecture as v19.11 and nothing more: glossary "Redundancy architecture is designed to retain maximum system functionality in the event of common hardware failures. There are three types of failures: BOH file server down, master terminal down, and complete network failure (hub failure). Redundancy provides a system of fault tolerance that allows the restaurant to continue functioning regardless of the type of failure experienced." and Store Settings > Redundancy options; no sentence names clock-in/punch capture in redundancy or punch reconciliation on file-server recovery, so this is adjacent architecture, not part of the claim. (3) crt.sh (2026-09-17) on ncrvoyix.com, alohaenterprise.com, ncrplatform.com: 1,459 distinct names; 60 non-dev/stg/qa candidates probed for /, /swagger, /swagger/index.html, /swagger/v1/swagger.json, /api-docs, /v3/api-docs, /openapi.json, /docs, /robots.txt (probe1.tsv). Production labor back-end hosts exist by name (asm-labor-service.internal.ncrvoyix.com, cbo-labor-rules-service.internal.ncrvoyix.com, cbo-employee-configuration.internal.ncrvoyix.com) but all time out from the public internet; te/secure/mgmt/memberlink/loyaltyapi/chef.alohaenterprise.com are Aloha Enterprise login portals (404/403 on every doc path, /help/ 403); alohasitereporting.commerce.ncrvoyix.com /swagger redirects to /login, /api-docs 401. The only anonymous Swagger found (jpa2-rlsg.paymentslab.ncrvoyix.com, "OnlineOrdering") is a payments LAB host and holds nothing on labor. crt.sh on ncr.com returned 502. Retrieved 2026-09-17. || 329th: NEW THIS PASS (held unknown; the shape of the absence is now measured rather than asserted). (1) INVARIANCE ACROSS THE WHOLE CLASSIC CORPUS: over 34.0 MB -- the 150-of-152 docs.ncrvoyix.com Aloha PDF download library, the 1,238-page in-scope product trees, the Aloha Insight help at 292/292 of its own WWHelp manifest (files.js), all four ASM guides, the classic DevEx dump -- 'offline' occurs 403 times and 'clock in' 1,966 / 'punch*' 1,177, yet a punch/clock token and an 'offline' token NEVER co-occur within 300 characters: 0 hits in either direction, in every corpus. 'Store and forward' (131 hits) is documented exclusively for card authorisation ('Allow authorization when EDC is offline', .spl spooling, fake authorisations, EDC v19.9 User Guide), and the 112 'redundan*' hits are file-server/master-terminal failover, the Alert engine, kitchen station backup and EDC dial-out. (2) NCR DOES document data-class-specific offline reconciliation semantics WHEN THEY EXIST, which sharpens the silence: Aloha Takeout's own field definition is explicit both ways -- 'Enable offline support -- Permits entry of takeout or delivery orders, when the ATO service host is unavailable ... When the file server becomes available again, the terminal functioning in place of the takeout service automatically updates new orders to the server ... Although you must enter all customers as new, THESE NEW RECORDS ARE NOT ADDED TO THE DATABASE WHEN CONNECTIVITY IS RESTORED' (Takeout Settings > Options tab > Redundancy group bar, ATO v20.1.3 Implementation/Reference Guides). Orders sync, offline-created customer records are lost, and punches are not addressed at all. (3) The ONLY NCR document that states the claimed behaviour is Aloha Cloud / Silver Essentials -- 'You can clock in/out even if the POS device is offline. The system stores the time clock activities and sends them to the host when the POS device is online' (developer.ncrvoyix.com .../starting-and-ending-a-shift-silver-essentials, topic 'Silver Essentials') and 'employees are warned of any duplicate and unpaired punches on the device even if the POS is offline' (configuring-pos-device-settings-silver-essentials) -- which is the SMB cloud codebase this record's scope rule excludes; recorded here so a later pass does not mistake it for classic Aloha. (4) The ASM116 guides the 321st downloaded and never read (Starter 274,219 chars; Getting Started) contain 'offline' 0 and are punch editors over 'the system-recorded punch'. WHY STILL UNKNOWN: the claim's first conjunct is a capability, and a documentation census cannot show that FOH-captured punches are lost during a file-server outage; the third conjunct ('with the behavior documented') is what is demonstrably unmet. Retrieved 2026-09-18. 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

Security Roles grant discrete function access across POS, EDC, Aloha Kitchen, Aloha Takeout and ORDERPOINT. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/security_roles · 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

UPHELD yes 2026-08-10, and the note it replaces was 92 characters asserting the verdict rather than evidencing it. THE ATTRIBUTION CONJUNCT IS NOW QUOTED RATHER THAN INFERRED, from the Employee Breaks Feature Focus Guide's worked sample of the BOH Audit report, where every entry names the acting manager by employee number AND name, names the affected employee, and carries the before-and-after values: 'BREAK OUT | Break Out Mgr 6965 MATT ended the break for Emp 7651 MELISSA'; 'BREAK ADJ | Mgr 130 JILLIAN deleted the break for Emp 130 JILLIAN / From In Time: 08:37 To In Time: 08:37 / From Out Time: 08:38 to Out Time: 08:38 / From UnPaid Break To Paid Break'; 'OTHER WAGES | 100 SMITH changed Unpaid Mandatory for Emp 300 Johnson / From 2:00 hrs to 1:00 hrs'; 'BREAK RULE VIOLATION | Manager JANE SMITH verified CLOCK OUT for employee ROGER SMITH'; 'MGR CLOCK OUT | Clock Out Emp: 300 ABBEY ... Emp 100 APRIL / Reason: Employee did not waive break.' Each cites the governing rule by number ('Break Rule 11, California Minor Unpaid Break'). The pattern is not confined to breaks -- the v19.6 Enhancement Release Guide describes the Loyalty Mgr Override audit entry the same way: 'The entry includes the time, check ID, member name, and the manager who approved the override.' THE QUERYABLE-AFTER-THE-FACT CONJUNCT IS ALSO DOCUMENTED AS A PROCEDURE, not just a report name: 'Select Reports > Aloha Point-of-Sale > Audits', pick a date, and a 'Select Transactions to Audit' dialog filters by transaction type before View, Print or Export. Above store, Labor Data Management 2 exposes the same trail as an API -- 'POST /reports/shifts/audits: Get shift history audit trails', per business day, gated on LABOR_DATA_MANAGEMENT_PAY_RATE_VIEWER to see pay rates -- with an employee-side dispute loop ('the Acknowledgements service will send an Edit Acknowledgement notification for the employee. Then the employee can accept or dispute this edit') and an anti-overwrite guard ('after either shift edit, break edit, or shift delete is performed by above-store user, shift reset is no longer permitted for given businessDay and employee'). THE IMMUTABILITY CAVEAT SURVIVES AND IS NOW MEASURED RATHER THAN ASSERTED: across the 17.9MB /downloads/ guide corpus and the seven local docs.ncrvoyix.com product trees, 'immutable' occurs ZERO times, 'read-only log' and 'unalterable' zero, and all eight 'tamper' hits are PCI hardware language about pin pads and fibre. Nothing states the audit trail cannot itself be edited or purged. Held at yes because the claim's operative conjuncts -- individual attribution and after-the-fact queryability -- are both first-party documented, and the third is unstated rather than contradicted. https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_EmployeeBreaksFFG-HKS315.pdf · retrieved 2026-08-10

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

The ASM page this cell cites has now been read in full rather than by title, and it carries more than the verdict needs: a calendar-based week view with per-employee weekly totals, Add Shift with job selection, 15-minute start and end intervals and paid or unpaid break periods of 15, 30 or 60 minutes, filtering by job or by employee, Publish as an explicit draft-to-published gate that can be republished after edits, Copy schedule to the current and all future weeks, and a 150-character announcement broadcast. Overtime is surfaced in the grid itself ("if the employee’s scheduled hours are approaching or exceeding overtime limits, the corresponding hours are highlighted in red") alongside Historic sales average, Scheduled hours and Scheduled labor cost % for the past six weeks. Yes stands, on a fully read source. The earlier corroboration is unchanged: classic Aloha Manager ships Basic Labor Scheduler, and Insight names a third product, Aloha Employee Scheduling. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/labor/working_with_schedules · retrieved 2026-08-09

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

UPHELD partial 2026-08-10, with the limit now measured on three surfaces. Insight publishes the generate-from-forecast action outright: 'This is useful for companies using Aloha Labor Scheduler, which generates schedules based on sales trends and labor rules. Set Labor Scheduler to generate unassigned shifts, which enables management to assign employees of their choice to the shifts.' The demand input is an engine rather than a typed number - a weighted moving average over up to ten prior weeks, each weighted and summing to 100%, selectable from Same Week Last Year, Last Week, Two through Eight Weeks Ago or Budget Sales, set company-wide and overridable per store - and the output joins back through Scheduled Labor and Scheduled Hours. WHAT KEEPS IT PARTIAL: Aloha Smart Manager publishes the demand signal BY DAYPART but recommends nothing. Its Interval sales and labor report gives 'Average sales per labor hour by day part' and a 'Forecasted sales amount' column, while its Schedule screen has a manager create each shift ('A manager creates shifts and specifies the employees to work for the shift'), showing only 'Historic sales average, Scheduled hours, and Scheduled labor cost %' as reference, with copying last week as its only generator. And the current v19.11 Reference Guides describe the same add-on without sales at all: it 'enables you to create employee work schedules based on shift requirements for each work day', and its menu 'only appears when you log in from the file server at a store, and if you are using Aloha Labor Scheduler'. The sales-driven generation therefore rests on one incidental Insight sentence about a separately licensed add-on whose user guide is in no corpus we hold. https://support.alohaenterprise.com/wwapp/en_US/helpdata/CompSetup/CompanySetup_SalesCalculationsTab.html · retrieved 2026-08-10 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

Documented on the POS terminal itself, twice over, for the current day. The Aloha Table Service Report Guide's Flash report Entire Day Summary view publishes a 'Labor %' column defined as 'The labor percentage by each time interval, based on the following calculation: (labor dollars / net sales) x 100,' and the FOH Sales & Labor Statistics report - a v12.3 consolidation whose stated purpose is that 'Monitoring hourly sales and labor versus budget or projection is a critical part of running your daily business' - publishes a 'Lbr%' column, 'Labor percentage for the interval based on the following formula: labor dollars / net sales,' beside sales, transactions, labor hours and sales per man hour. Both are FOH reports and 'The FOH reports include data for the current day only.' The interval is configurable: 'POS Flash report time interval in minutes' offers 5, 10, 15, 20, 30 and 60, 'FOH Labor report interval minutes - Denotes the time interval (in minutes) used for calculating the FOH Labor Report,' and 'Automatic 15 minute interval report' prints the Flash report every 15 minutes unattended. Access is gated per role by the 'Manager Flash' and 'Restaurant sales and labor statistics' POS access-level options, and with Print Intercepter configured the report displays on screen rather than only printing. Labor is attributed through Labor Groups, which exist to 'view labor costs for each labor group, as a percentage comparison to specific sales/general categories.' https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/TS_ReportGuide.pdf · retrieved 2026-08-09 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

Native, configurable and pre-emptive. The Aloha POS Alerts feature (Maintenance > System Settings > Alerts) has Overtime as one of its four alert types: 'Overtime alerts help managers monitor the hours worked by multiple employees throughout a shift to reduce overtime exposure... managers no longer rely on reports to determine employees that may be approaching overtime.' The threshold is a field - 'Hours to alert before overtime begins - Specifies the number of hours and minutes prior to an employee reaching overtime to send an alert' - with 'Alert only for weekly overtime' switching the basis from daily to weekly hours, and the implementation article works the example: 'you may want the manager to receive an alert 45 minutes prior to the employee going into overtime; however, if your state uses weekly hours to calculate overtime, you may want to send the manager an alert eight or more hours prior.' Delivery is to the POS: 'an overtime alert appears with the employee ID and name, and the time at which the employee begins to earn overtime pay,' shown on the FOH floating logo and login screens and viewable from the Alerts button, generated by the master terminal via the Alert Engine service. Two more surfaces reinforce it forward-looking: Aloha Smart Manager's 'Approaching overtime threshold' report 'calculates the total hours worked for the week so far, combined with any remaining scheduled hours... take action if an employee has exceeded their scheduled hours and is on track to incur overtime' (ASM-3540 / CBO-4834), and NCR Console's schedule option 'Display Schedule Warnings - Overtime: Allows a warning to appear to the right of any employee that is scheduled for overtime.' The one thing Aloha does not do is hard-block the punch: the alert warns, it does not refuse the clock-in, and it is addressed to the manager rather than fired at the employee's clock-in moment. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09 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

Maintenance > Labor > Break Rules is a full compliance engine and the Reference Guide frames it as one: 'Break rule alerts help you maintain compliance in states that mandate employee breaks.' Rule sets are qualified rather than global - each break rule carries age qualifiers ('Only applies to Minors', 'Employee age range type' Under/Above with from-to ages), shift start and shift end time ranges, a 'Break calculation method' switchable between hours into a shift and a set time of day because 'Some labor laws require employees to start their breaks within a specific time frame', and up to five break occurrences; Aloha Smart Manager's Labor rules add a state- and county-scoped layer with effective dates. Attestation is explicit: 'Eligible to be waived' enables waive break messages, 'Display break waive message at' selects Clock in or Clock out, 'Display break reminder at clockin - Activates a break reminder to appear at clock in for a scheduled employee' with a named Break Reminder Message record, and store settings force both to appear at clock in even when no schedule is used. Missed breaks carry premium pay: 'Apply penalty if break is missed - Enables you to configure the system to compensate any employee who misses an earned break', 'Hours to pay if break is missed', 'Penalty pay rate... Choose Regular pay rate or Minimum wage rate', and 'Manager must approve clock out when Penalty Pay is earned... Penalty pay is used in certain jurisdictions that allow monetary compensation to an employee in lieu of not taking their required break.' Enforcement rounds it out with 'Enforce minimum break minutes', 'Enforce break start time', a manager approval gate on any violated clock out, and New York-style 'Spread of Hours Premium' and split-shift premium wage records generated at end of day. The one honest limit: the per-jurisdiction rule sets are operator-configured against local law, not shipped preloaded state by state. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09 adversarially verified

Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.

labor-fair-workweek-support

COUNT CORRECTED: the ASM limit is FIVE named jurisdictions, not four. Release note CBO-1342 appears twice in the 0.x notes - "Added fair workweek capabilities to wage calculation and schedule validation services for Philadelphia, New York City, Chicago, and Oregon" and, separately, "To support penalty and additional pay, you can now support missed break penalty payments, split shift premiums, and Los Angeles Fair Work Week measures for wage calculations and schedule validation services." Both halves of the claim are therefore touched - schedule validation is the advance-notice side, wage calculation the predictability-pay side - but only inside an enumerated jurisdiction list, and the ASM Labor rules configuration screen exposes no fair-workweek tab (Overtime and Tips & Wages only), so an operator outside those five cannot configure one. The 22-page ASM Labor module adds nothing: Working with schedules names the ordinance only as motivation ("in certain jurisdictions, the organization must schedule shifts up to 14 days in advance") and its Publish action is a plain draft-to-published state change ("Publish exposes the shift to the employees for the first time"), with no advance-notice deadline tracked and no change penalty computed on republish. Partial stands. TWO TRAPS RECORDED SO A LATER PASS DOES NOT INFLATE THIS CELL. First, the one recorded earlier: the Aloha POS "Approaching workweek hours threshold" alert is Affordable Care Act reporting, not Fair Workweek. Second, new: "predictab" matches three times in the ASM corpus and none of them is predictive scheduling - all three are the same marketing blurb for the Copy schedule feature ("Consistency: Maintains consistency in scheduling, ensuring employees have predictable work patterns"), repeated across the core, starter and combined 1.x release notes. A term grep alone would score this cell wrong. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/about/release_notes/version_0x · retrieved 2026-08-09

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

labor-minor-labor-rules

SHORTFALL CORRECTED AGAINST THE ASM WEB CORPUS, VALUE UNCHANGED. The sentence above claiming "no clock-in or scheduling check refuses a minor a shift on those grounds" overstated the null on the scheduling side: ASM 0.x release note CBO-1370 records "Added overtime warnings and minor law violation capabilities to the schedule validation service", so a minor-law check does run at schedule authoring. What the corpus still does not do is name WHICH minor rules that service evaluates - no age-based maximum hours, prohibited time-of-day window, school-day or school-night limit appears anywhere in the 75 ASM web pages, whose Labor rules configuration screen exposes only Overtime and Tips & Wages tabs - and nothing extends the check to clock-in. The claim requires enforcement at both scheduling and clock-in across those three named rule classes, so partial stands, now on a narrower and accurate shortfall. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09 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

Fully published, in the Aloha Tip-Share Distribution Feature Focus Guide (HKS384, last updated June 20 2024) and Maintenance > Labor > Tip-share Pools. The contribution rule is percentage of sales and it fires automatically: 'When the employees who contribute to the tip-share pool check out, they contribute a portion of their tips into the pool based on a percentage of their sales.' The distribution rule is by role: 'The tip-share pool determines which job codes receive the tip-share amount based on a defined percentage. For example, if the restaurant determines that bartenders should receive a larger percentage from a tip-share pool that consists of bussers, dishwashers, and bartenders, you can configure bartenders to receive 50% of the tip-share, while bussers and dishwashers receive 25% each,' with a 'Share of pool percent' column on the pool's Jobcodes tab whose 'total must equal 100 percent.' Job codes are switched in with 'Contributes to tip-share pool' and 'Receives from tip-share pool'; a Categories tab excludes or weights sales categories ('Exclude from tipshare'); the percentage can be varied by job group and day part through the Set Tip Share and Set Tip Share Pool For Category events, contributed to multiple pools at once; a server may contribute above the default; and 'Only collect tip share for a Jobcode / JobGroup with eligible recipients' handles the case where a recipient role is not clocked in, worked through arithmetically in the guide. Reporting is per shift. The residual manual step is distribution, not calculation: a manager releases the calculated pool, daily or weekly, and the system records who did it. https://developer.ncrvoyix.com/api/media/3925/content · retrieved 2026-08-09 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

The Aloha Tip-Share Distribution Feature Focus Guide (HKS384, updated June 20 2024) enumerates the record. 'The Aloha POS system reports tip-share contributions on a per shift basis only', and with NCR Back Office the raw contributions are readable per shift and day part in GndTpShr.dbf, typed as recipient or contributor. The BOH Tip-share Distribution Detail report provides 'Total tip-share pool amount, Contribution date, Distribution date and time, Name of the manager who distributed the tip share, Recipient employee number, Name of the recipient employee, Tip-share amount received, Includes a signature line for the recipient employee to sign, indicating that they have received their alloted share, Total distributed, Total undistributed.' Corrections are tracked too: 'If a punch edit occurs after tipshare distribution, and tipshare redistribution happens automatically or manually, the Tipshare Distribution Detail and Summary reports provide the amount returned to a contributor.' The Summary report 'is designed for reporting to the corporate office or to provide legal documentation, if desired', and both are generated from Reports > Aloha Point-of-Sale > Employee > Tip-share Distribution over a date range with 'View, Print, or Export'. Access to run them is gated by a POS Access Levels option. Contributed, distributed and undistributed are all on the same page, per shift, per employee, exportable. https://developer.ncrvoyix.com/api/media/3925/content · retrieved 2026-08-09 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

PRECISION ON THE ASM HALF, WHICH THE NOTE ABOVE COULD BE MISREAD AS OVERSTATING: ASM does hold the cash-versus-charged split, it simply does not put it in the export. The ASM Employee tip report breaks out Charge sales, Charge tips, Charge tip% of sales, Non-charge sales, Non-charge tips, Non-charge tips%, Total declared tips and Total auto-gratuity, and tiles the IRS allocation threshold directly as "Employees with tips under 8%". The Generic payroll export column list is still the closed nine already recorded, with Declared tips as its only tip column. So the cloud-path gap is the export, not the underlying data - and it remains a gap. No Treasury tipped-occupation code, W-2 Box 12 code TP or Box 14b handling appears in any of the 75 ASM web pages. Partial stands. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09 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

UPHELD partial 2026-08-10, and the export boundary now holds on four surfaces instead of one. Aloha Insight states it in its own words: 'Aloha Insight enables you to save time and resources by generating an export file containing time and attendance information that you import into your payroll processing information system', and its FAQ is blunt about the limit - 'Are California overtime laws supported? No ... Aloha Insight provides the raw time and attendance data, check with your payroll processing company on their requirements.' Insight also says 'The payroll and general ledger configuration requires the use of a supported third party payroll or general ledger systems', naming ADP PC/Payroll for Windows, ADP Canada, Millennium for Windows and a Generic export. The POS BOH offers 'Use ADP - Specifies ADP as the active third-party payroll processor' alongside Use PayUSA, Use Paychex, Use Real World payroll and a PDI export file. Aloha Smart Manager, the modern surface and previously unmeasured, is the same: 'Use the Generic payroll export to upload payroll information to a payroll processor or to simply analyze in a spreadsheet.' NCR DOES sell payroll, which the prior note asserted without sourcing and is now sourced: DevEx lists 'Payroll & HR Solutions' from the December 2018 JetPay acquisition with 'Payroll processing', onboarding, time and labor and 401K services and its own support line. But it is a Payments/HCM business line with no tax filing and no direct deposit named anywhere, and no documented Aloha integration. https://support.alohaenterprise.com/wwapp/en_US/helpdata/CompSetup/Payroll_About.html · retrieved 2026-08-10 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

Held at yes on the current-product PDF, now over-supported. The previous caveat needs a third term: Aloha Insight publishes an above-store, multi-store-consolidated export naming SEVEN processors — "ADP PC/Payroll for Windows, ADP Canada, Generic Payroll, Heartland, Millennium for Windows, Paychex, Paychex Export with Premium Overtime" — with Ceridian and DHR added in the FAQ and ADP Payforce as an eighth variant, each with a documented field-by-field mapping table. ADP: "(5) Regular Hours — The total hours less overtime hours worked by the employee... (17) Temp Dept — ADP mandates that the 'Temp Dept' field must contain either three or six digits." Millennium: "Field 1 (Employee ID) — The Social Security number for the employee as entered in Aloha Table Service and Quick Service." Paychex is fixed-length with explicit positions: "(1) Employee Number / 1-6 / The Aloha POS system export ID... (9) Hours /... Regular hours, overtime hours, and other wage hours are reflected in separate records within the file." Reports Viewer exposes them as schedulable, emailable report categories scoped to "stores, regions, areas, or store groups". Citation stays on the current-product PDF because Insight is legacy; Insight is the above-store corroboration. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09 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

UPHELD partial 2026-08-10 on four surfaces, and the failing conjunct is real rather than an artefact of the hedge. NCR Console remains the only surface carrying the workflow, and it carries both halves the claim's first two conjuncts need: an employee clicks 'Request to cover shift', 'the first person to accept your request is what will be sent to the manager for approval', and 'the manager must approve the change before the schedule will reflect any changes.' THE ELIGIBILITY CONJUNCT FAILS ON THAT SAME PRODUCT. The candidate list is unfiltered by job code - 'select the employee you would like to request coverage from' - and the manager approves from a bare 'Pending Approval status link to approve or reject the request'. Console's only overtime awareness is a display preference, 'allows a warning to appear to the right of any employee that is scheduled for overtime', on the manager's schedule-build screen rather than as a gate on the swap. Beyond Console there is nothing: 'swap' in the labor sense occurs zero times across the 650-page classic POS tree, the TS and QS v19.11 Reference Guides, ASM's 75 pages and Aloha Insight's 292, and the DevEx Labor Data Management API's only employee-facing primitive 'captures an employee response for the specified acknowledgement reference.' https://www.manula.com/manuals/cimplebox/ncr-console-for-aloha/1/en/topic/shift-swap-request-employee · retrieved 2026-09-17 adversarially verified

Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.

labor-digital-onboarding-i9

UPHELD partial 2026-08-10 across six surfaces. Digital onboarding is real and self-service: ASM creates the user in NCR Identity, 'an email is sent to the provided email address with a link for the employee to enter their personal information and emergency contact details', and release note CBO-2172 adds certifications carrying a certificate number and expiry date. The eligibility paperwork the claim names is absent everywhere we hold. I-9, W-4 and E-Verify occur zero times across the 75-page ASM tree, the ASM mirror on the DevEx Knowledge Hub, the 150 first-party Aloha PDFs, the 650-page classic POS tree, Aloha Insight's 292 pages and NCR Console's 164 topics - the single apparent e-verify hit is the de-hyphenating normaliser catching 're-verify buttons or panels' in a Screen Designer guide - and they score zero in the DevEx API Explorer against a passing control. The classic POS Employee function collects 'the employee birth date, social security number, employment status, and hire date' with an optional SSN validation check, and nothing further; NCR Console offers only generic document upload. NCR's documented answer is to keep the paperwork elsewhere: the Users and Employees HR Integration API 'synchronizes labor user and employee profile data from an external HR system into Labor service' under the ASM_HR_INTEGRATOR role. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/labor/onboarding_new_employee · retrieved 2026-08-10 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

Aloha report guides include per-employee sales performance reporting used for server scorecards. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS_ReportGuide.pdf · 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

ASM 'Managing recipes' (Inventory Core only): 'A recipe is a list of inventory ingredients that make up both prep items and sales items. It contains a detailed list of ingredients, required quantity, and cost incurred to create the recipe.' Ingredients are selected from 'All, Raw items, or Prep items', where a prep item is itself a recipe ('You can create a recipe that is a prep item used as an ingredient in any other recipes. For example, Ketchup'), each ingredient row showing Unit price and Total cost and rolling into a Recipe costing panel of Recipe Cost ($), Goal Price ($) and Goal Price (%). Depth and propagation are stated in the ASM Inventory Core release notes v1.22 (October 21, 2025): 'Supports nesting of recipes up to 5 levels with safeguards against circular references'; 'Each modification automatically logs an audit trail and recalculates food cost and inventory data to ensure accurate reporting'; 'Prompts admins with a confirmation before recalculations, offering options to apply changes retroactively or from the edit date. Updates automatically reflect in parent recipes and inventory reports.' The recipe screen offers the same choice on a yield-unit change ('Recalculate food costs - The costing of recipe is recalculated from the start date when the recipe is available' versus 'Keep old food costs'). Requires the ASM Inventory Core package; the identical release notes are published under Advanced Inventory. Classic on-premise Aloha v19.11 has no costing BOM - its 'recipes' are staff-facing text, bitmap and .avi display attached to a menu item. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/inventory/managing_recipes · retrieved 2026-08-09

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

ASM units of measure carry explicit conversion factors: a custom unit is defined as starting unit, class and quantity converted to a target unit - 'To sell a case that contains water bottles with 10 units of one liter each, here is how you set it up: Starting Unit = Case, Class = Volume, Quantity = 10, and Conversion unit = Liter (L)' - in volume, weight or count classes, Imperial, Metric or Neither. 'Units of measure are used in the definition and maintenance of raw items, vendor items, menu items, batch items, and modifier items', specifically 'Raw Items - Purchasing, Invoicing, Transferring, Wasting, Inventorying and Reporting' and 'Menu Items - Recipes, Waste and Reporting'. Each vendor item stores Container, Pack, Size, Purchase unit ('the industry standard measurement of product inside a pack, such as 16 pounds'), Receive unit and a Catch weight true/false flag, and each recipe stores a Yield amount and Yield unit. Shortfall: the recipe Yield is the expected output quantity of the recipe ('if the recipe is Tea and the Recipe makes value is 2, then two cups of tea is expected'), not a yield or waste percentage applied to a raw-to-usable conversion; no yield-percent or shrink/waste-percent field appears on raw items, vendor items or recipe ingredients anywhere in the ASM inventory tree, where waste is instead recorded as a separate transaction against configured waste and spoilage reasons. The classic v19.11 reference guides add nothing here - 'yield' returns zero hits in either guide. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/inventory/managing_units_of_measure · retrieved 2026-08-09

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

COGS report computes actual usage from opening inventory, purchases and closing counts; NCR positions actual-to-theoretical variance analysis. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/reporting/inventory/cost_of_goods_sold_report · retrieved 2026-08-01

Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator

inventory-realtime-depletion

THE TEXTBOOK ONE-SURFACE DEFECT: scored off a single pizza-topping page, then published as 'general near-real-time depletion across the menu is not confirmed'. Aloha Quick Count 'automatically depletes and replenishes items defined as tracking items when you sell, void, or refund a menu item (composite item)', configured by 'Auto depletion and replenishment -- Adjusts the selected item sale and void counts automatically, based on sale, void, and refund quantities of the associated menu items'. Modifier-driven depletion is explicit -- tracking items attach to modifiers, not only parents ('Add only the modifiers for the menu item you want to track') -- up to 1,500 tracking items. Item Availability holds the live count and 86s at zero: 'when a slice is sold, the count decrements by one. When the slices are depleted, the system sets the item as unavailable'. Two limits kept: Quick Count is separately licensed, Add/Waste/Usage counts are still entered by hand, and the guides state depletion happens on sale without stating the latency with which the FOH screen reflects it. https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_QuickCountFFG-HKS316.pdf · retrieved 2026-08-09

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

UPHELD partial 2026-08-10; THE PRIOR NOTE CONTAINED A FALSE SENTENCE, that 'docs.ncrvoyix.com carries no DoorDash/Uber Eats/Grubhub integration pages at all'. It carries a twelve-page first-party integration tree for exactly this, and that tree settles the propagation question far better than an absence argument. Aloha POS Item Availability holds a per-menu-item quantity that decrements automatically as the item is ordered from any terminal; at zero the item cannot be ordered, the universal no symbol appears on the button, and the state propagates to Aloha Kitchen and Aloha Takeout, where 'any item that is fully depleted or marked as unavailable in the POS does not appear for selection in the online menu.' SHORTFALL ONE: propagation stops short of marketplaces by NCR's own scoping - 'Item Availability - Used by Aloha Takeout to publish changes made to item availability in the Aloha POS to Aloha Online Ordering, eliminating the possibility of a guest adding an item that is temporarily not available to their online order', while the sibling Order and Delivery services are the ones that touch third-party marketplaces. SHORTFALL TWO: the trigger is a count a manager sets per menu item or modifier, not a component ingredient's on-hand level. Quick Count, the classic ingredient module, never mentions Item Availability and has no par level, reorder point or threshold; ASM Core Inventory's out-of-stock marker is a stocktake annotation - 'The Out of stock indication appears if the count is 0' - not a POS 86. https://docs.ncrvoyix.com/restaurant/aloha-takeout/integrating/integrating_ato_and_bsl/integrating_ato_and_bsl · retrieved 2026-08-10 adversarially verified

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

ASM 'Counting inventory and managing locations' (Inventory Core only) defines inventory lists by count frequency - 'Shift', 'Daily', 'Weekly', 'Fiscal Period' and 'Unassigned' - each with its own selected item set ('Select or clear the items to update the counting of the inventory item. The selected items are counted as per the scheduled frequency'), so a recurring cycle count of a chosen subset and a full fiscal-period physical are separate scheduled objects; administrators assign raw items to one or more lists and to storage locations (walk-in, dry storage, bar station) and set a shelf-to-sheet count order. Ad-hoc counting is documented: 'In the case the manager wants to count the items during a shift, the manager can record the count by specifying the exact date and time of the shift. Additionally, a manager can record the count of unassigned items', with per-item Out (out of stock) and Skip. Counts are retained as discrete history rather than overwritten: the count screen shows the previous entry ('Previous count was 0 on 04/09'), the Submitted tab lists every posted count with Period, Locations, Counted on, Counted by, Approved by, Counted value, Posted on, Effective on and Skipped items under In review / Finalized / Unfinalized status with Finalize and Unfinalize actions, and the Cost of goods sold report reports 'the cost and usage of raw items between two inventory counts'. Requires the ASM Inventory Core package. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/inventory/counting_inventory_and_managing_locations · retrieved 2026-08-09

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

UPHELD partial 2026-08-10, and the shortfall is now measured on two surfaces. Mobile counting is real on ASM: the ASM with Aloha Essentials Inventory User Guide states 'The counted values can be recorded using a smartphone', and ASM v1.29 adds prep-item counts 'by location and list using desktop or mobile devices, with support for both count and catch weight items'. The other three conjuncts fail. Barcode, QR, offline and sync-on-reconnect occur zero times across the 75-page ASM tree, both Aloha Essentials PDF guides, all three ASM release-note sets and the ASM mirror on the DevEx Knowledge Hub, normalised for whitespace and de-hyphenation; the only documented resume mechanism is Save and exit inside the app, and 'scan' appears only as invoice OCR and flat-file import. The classic POS's own count module is terminal-bound and has no mobile, barcode or offline vocabulary at all: Quick Count counts are entered by touching a panel button, selecting the item, and 'Enter the quantity using the keyboard.' Barcode hardware IS documented on this stack but never for inventory - bar code scanners 'are used to recall a check' in Aloha Takeout, and Barcode Messages prints a QR code on guest checks. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/inventory/counting_inventory_and_managing_locations · retrieved 2026-08-10 adversarially verified

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

WITHDRAWN: the 'SFTP Settings' group bar, the 'For Sysco file format' note and the Email-or-EDI purchase-order delivery choice. All three come from 'Aloha Smart Manager with Aloha Cloud: Core + Advanced', the Aloha Cloud pairing this record may not cite; SFTP, Sysco and the string 'purchase order' each return zero hits in both Essentials guides (ASM with Aloha Essentials: Starter + Core Inventory, 262,274 characters, and the Starter guide, 186,487). What the Essentials surface does document is a generic file push: ASM Inventory Core release notes v1.26 (February 23, 2026), 'Sending purchase orders using FTP: Restaurant managers can now send purchase orders using file transfer protocol (FTP) and allow for faster and automated order processing (ASM-9109).' Shortfall, and it is the substance of the claim: no distributor is named anywhere on this product's surface, and there is no pre-built vendor catalog feed at all. The vendor record is enumerated in full twice - in the Essentials Inventory user guide and on the live 'Working with vendors' page - as vendor name, A/P code, country, street address, apartment/suite, city, state, postal code, contact name, title, phone, email, customer account number and comments, with a 15-column vendors_data_import.CSV bulk import carrying exactly those columns and no transport, credential or file-format field of any kind. The catalog itself is built on the vendor Catalog tab item by item (vendor item code, name, container, packs per case, size, unit from a closed 15-value list, 'Verify Catch weight item is not selected as it is currently not supported', unit price, raw item, informational GL account) or by .CSV bulk import. The only vendor-schedule construct is Order & delivery, a manual order-day/delivery-day pairing per vendor. Inbound invoices are classified only by entry type 'manual, scan flat file import, electronic transfer by vendor, or API', naming no distributor and describing no feed. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/about/release_notes/inventory_core_release_notes/version_1x · retrieved 2026-08-09

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

'ASM is built with OCR (Optical Character Recognition) functionality that reads the uploaded invoices and feeds data into the system.' A manager uploads an invoice from desktop or mobile as a digital image (JPG, JPEG, IMG, PNG) or as a PDF whose pages are converted to image files, then works a four-step wizard: Step 1 invoice header mapping (invoice ID, vendor), Step 2 page column mapping with editable anchor points, Step 3 'Review row information' where item rows already in the catalog auto-populate and 'you can edit only the quantity, price, and tax of the item', Step 4 invoice totals and Create invoice. The invoice posts into the inventory ledger through the Draft/Accepted/Finalized approval flow without manual line entry. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/inventory/uploading_an_invoice · retrieved 2026-08-08

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

UPHELD partial 2026-08-10, measured on three surfaces rather than one. ASM Inventory states you can 'set up specific raw items with associated prices, and then monitor the price fluctuation using Back Office reports'; each vendor catalog row carries a single 'unit price of the vendor item container' that the Edit flow overwrites, invoices capture the received unit price per row, and the Cost of goods sold report exposes item price and usage between counts - but there is no dated purchase-price series, no contracted price and no variance threshold. The Invoice history report is dollar-total only (GL sub-category, Invoice count, Subtotal, Sales tax, Total). Neither alert engine carries the event: ASM's documented notification examples are a missed clock-in and stock 'running low or is at zero', and the classic Aloha POS Alerts engine supports exactly four types - break rule, overtime, custom, and 'Approaching workweek hours threshold' - all labor, with 'The Aloha POS system is currently the only product available as a subscriber.' Recorded as a near-miss so a later pass does not flip on it: the POS Price Changes function DOES compute variance ('Action - Calculates the variance between the price in Compare and the value you enter in the Price column'), but that is the menu SELL price, not a vendor's received price. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/inventory/about_inventory_management · retrieved 2026-08-10 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

WITHDRAWN: the 'Add item > Add suggested items ... based on historical sales and forecasted demand methodology' quotation, which is from the Aloha Cloud Core + Advanced guide and cannot evidence this record - the Essentials guides contain no purchase-order function at all ('purchase order' returns zero hits in both). The forecast-driven half nevertheless stands on the Essentials-side documentation: ASM Inventory Core release notes v1.26 (February 23, 2026), 'Enhancing purchase order generation: Managers can now generate purchase orders with recommended quantities for vendor items based on past sales and demand forecasts (ASM-8989)', alongside the 'Low stock levels report', which combines 'current on-hand quantities, upcoming deliveries, and forecasted usage, by vendor' to identify raw items 'expected to run short before the next scheduled delivery, based on historical usage patterns and recipe or usage per settings, with quantities shown in the vendor's defined order units. Only items with a positive shortage value appear', and the 'Perpetual inventory on-hand report', which updates stock 'based on purchases, sales, recipe usage, transfers, and adjustments'. Shortfall: a static par level per item per location is not documented. 'Par level' and 'reorder' return zero hits in the 262,274-character Essentials Inventory guide and the 186,487-character Starter guide alike; the enumerated vendor-item field list (vendor item code, name, container, packs per case, size, unit, catch weight - 'currently not supported', unit price, raw item, GL account) has no reorder point; the only vendor replenishment construct in the guide is Order & delivery, a manual order-day/delivery-day pairing that helps 'forecast deliveries, avoid stock-outs' but stores no quantity; and ASM inventory 'locations' are storage areas within one store (freezer, walk-in, dry storage, bar) carrying count frequencies and item lists, not par quantities. Note also that the suggested-order feature is so far attested only by release note, not by any shipped user guide - the Essentials guide is dated November 17, 2025 and predates v1.26. Packaging: the inventory feature set is a paid sub-package above the base. The Starter release notes state 'ASM v1.25 delivers feature and enhancement updates for the Inventory Core package. The Starter package remains unchanged', and the same at v1.22 and v1.21.1 - the releases that carried counting, recipes and the COGS report. NCR Console, the older Aloha back office, lists 'suggested reorders, par levels and inventory transfer status notifications' among its dashboard alert types, but its inventory module required a separate Console Inventory subscription and its newest release note is v4.9.0 (April 2019), so it cannot evidence par levels in the shipping product. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/about/release_notes/inventory_core_release_notes/version_1x · retrieved 2026-08-09

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

inventory-waste-logging

Aloha Quick Count (Feature Focus Guide HKS316, last updated June 14 2024) provides Waste Counts as one of its five FOH count types - 'items thrown away or unused, for reasons such as over-production or spoilage' - entered per tracking item, folded into the count math that produces the closing count, reportable as its own Waste column on the Quick Count report, and optionally printing a waste chit carrying 'the name of the person entering the waste, the time and date of the entry, the wasted item(s), and the quantity wasted'. The previous second leg - that ASM Inventory lets you 'define and maintain the allowable reasons for recording and tracking waste and spoilage' - is WITHDRAWN as evidence of a reason-code facility. That sentence is the module's opening blurb, and the full ASM with Aloha Essentials Inventory User Guide (November 17 2025) reprints it verbatim on 'About inventory management' while listing the module's actual areas as managing units of measure, working with raw items, working with vendors, working with vendor items, working with invoices, the 'Invoice history' report, counting inventory and managing locations, the 'Cost of goods sold' report, managing recipes, viewing and mapping sales items, and viewing modifier groups. No waste-entry screen and no waste-reason maintenance screen appears in the guide; the inventory count workflow's only non-count actions are 'Out of stock' and 'Skip', and a posted count moves through In review, Finalized and Unfinalized. The reporting half of the claim is positively evidenced absent as well: the ASM 'Cost of goods sold' report columns are raw item name, GL account, reporting unit, start count, total purchases, end count, item price, ending inventory, days on hand and actual usage in units, dollars and percent - there is no waste line - and the Inventory Core release notes postdating the guide add only a Perpetual inventory on-hand report. SHORTFALL: waste is captured only as a bare Aloha POS FOH quantity with no reason-code selection, and no report isolates waste cost from usage variance. https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_QuickCountFFG-HKS316.pdf · retrieved 2026-08-09 adversarially verified

Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.

inventory-transfers

UPHELD partial 2026-08-10; the hedge was right, and the shortfall is now scoped rather than absolute. Inter-location transfer exists only in NCR Voyix Back Office Central Kitchen, hub-and-spoke, two-sided, with an in-transit state. The two other inventory surfaces we hold are negative, which is what makes the shortfall safe to publish: Quick Count, the classic POS ingredient module, uses the word 'transfer' exactly once and only to mean pushing configuration to terminals ('and All Installed Products to transfer the new information to the FOH terminals'), and the ASM Core Inventory User Guide names transfers only as a consumer of units of measure ('Raw Items: Purchasing, Invoicing, Transferring, Wasting, Inventorying and Reporting'), with no transfer screen or procedure anywhere and 'locations' meaning storage areas inside one store. A sweep for inter-site inventory movement across all seven docs.ncrvoyix.com trees, the ASM web tree and the Aloha Insight corpus returned nothing on point; the only 'transfer between accounts' hits are Aloha Stored Value ACH gift-card funds. https://docs.ncrvoyix.com/downloads/aloha-pos/NBO_CentralKitchenFFG-HKS343.pdf · retrieved 2026-08-10 adversarially verified

Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.

inventory-commissary

NCR publishes a dedicated commissary feature guide that the previous pass had not located: Central Kitchen (HKS343), a Feature Focus Guide for NCR Voyix Back Office, listed in the Aloha POS documentation catalogue and requiring no separate license. It is precisely the claimed model: 'The Back Office Central Kitchen (CK) functionality allows you to configure one site that acts as a main distribution site. This CK site orders and prepares prep items and distributes product and requisitioned items to outlying sites referred to as served sites. Typically, these outlying sites are smaller locations that sell ready-to-serve menu items, but may not have the capacity to produce or store products.' Production is real prep work at the CK site - it runs a 'Central Kitchen Prep List by Station and Day Part' report and its production team decides which site orders and forecasts to prepare. Issuing to other sites is costed rather than free: the CK site is registered as a vendor, publishes an item catalog of raw and prep items via Catalog Setup, and on delivery Back Office 'automatically distributes the product as delivered and converts the delivered order or orders to an invoice at each served site', while 'the system adds those delivered prep and raw items to the CK site Sales - Sales Mix report' - so the receiving site is invoiced and the producing site books the movement as sales-mix volume. Demand can be forecast-driven as well as manual: 'The Back Office forecasting engine automatically calculates the forecasted CK prep items needed based upon menu item forecasted for the served site.' Scope note: this is NCR Voyix Back Office, not Aloha Smart Manager, and the CK must be a separate site record. https://docs.ncrvoyix.com/downloads/aloha-pos/NBO_CentralKitchenFFG-HKS343.pdf · retrieved 2026-08-09

Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.

inventory-lot-traceability

Re-grounded on the Essentials guides after the previous note enumerated the Aloha Cloud pairing's receiving surface, which this record may not cite. 'Aloha Smart Manager with Aloha Essentials: Starter + Core Inventory' (262,274 characters extracted, marked DRAFT, last updated November 17, 2025) enumerates the entire receiving path as numbered field lists: vendor creation (active flag, name, A/P code, country, street address, apartment/suite, city, state, postal code, contact name, title, phone, email, customer account number, comments), the 15-column vendors_data_import.CSV bulk import carrying those same columns, vendor-item creation (vendor item code up to 50 characters, name, container from a 10-value list, packs per case 1-999, size 1-999 to two decimals, unit from a closed 15-value list, 'Verify Catch weight item is not selected as it is currently not supported', unit price, raw item, informational GL account), the Order & delivery day pairing, invoice entry by type 'manual, scan flat file import, electronic transfer by vendor, or API' through the Draft/Accepted/Finalized approval flow, and the OCR invoice-upload appendix whose review step states 'For items that are recognized in the catalog, you can edit only the quantity, price and tax of the item.' No lot, batch, expiry or supplier-reference field appears at any step: grepping for lot, batch, expir, traceab and recall returns zero hits for lot, expir, traceab and recall, and the only 'batch' hits are ASM's term for prep recipes ('Batch Items: Recipes, Waste, Transfers, Forecasting Suggested Prep, and Reporting'). The 186,487-character Starter guide returns zero for all five terms. The same field lists are published on the live ASM tree (Working with vendors, Working with vendor items, Working with invoices), so this is the shipping surface, not a stale draft. NCR's Back Office feature-focus guides for Central Kitchen (HKS343) and Calculated Nutrition, the deepest inventory features NCR publishes for classic Aloha, likewise return zero hits for lot, batch number, traceability and recall. With no lot captured at receiving there is nothing to link forward, and no recall trace exists. https://docs.ncrvoyix.com/downloads/aloha-smart-manager/ASM_ASMwithAlohaEssentialsInventoryUserGuide.pdf · retrieved 2026-08-09

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

Aloha Smart Manager is the inventory module sold with Aloha Essentials and its user guide enumerates the module's whole scope in its contents: units of measure, raw items, vendors, vendor items, invoices, an invoice-history report, counting inventory and managing locations, a cost-of-goods-sold report, recipes, sales-item mapping and modifier groups. Dating is not among them, and `shelf life`, `expiration`, `expiry` and `use-by` occur zero times in either the Core or the Starter guide. Counting is scheduled by frequency -- shift, daily, weekly, fiscal period -- which is a cadence, not a date on a lot. No expiring-soon report or alert is documented. https://docs.ncrvoyix.com/downloads/aloha-smart-manager/ASM_ASMwithAlohaEssentialsInventoryUserGuide.pdf · retrieved 2026-09-10 adversarially verified

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

inventory-bar-partial-bottle

The unit-of-measure model supports fractional liquid quantities, which is why this is not a `no`. A unit of measure is 'the unit in which you count and track stock items, such as by case, package, six-pack, single can, two-liter bottle, and more', and conversions are defined with a volume class -- the guide's worked example sets 'Starting Unit = Case, Class = Volume, Quantity = 10, and Conversion unit = Liter (L)' -- so an open bottle can be counted in litres rather than as a whole unit. Counting is location-aware and the guide names bar stations among the storage areas. What is missing, and what keeps this off `yes`, is any purpose-built bar mechanism: no scale or weight integration and no bottle-fraction entry is documented, and `scale` never appears in an inventory sense in either guide. https://docs.ncrvoyix.com/downloads/aloha-smart-manager/ASM_ASMwithAlohaEssentialsInventoryUserGuide.pdf · retrieved 2026-09-10 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

The ASM Cost of goods sold report is run per site and date range and is both filtered and reported by general ledger account - 'Select the General Ledger (GL) account' among the run parameters, and a per-row 'GL account - The general ledger account number' beside Raw item name, Reporting unit, Start count, Total purchases qty, End count, Item price, Ending inventory, Days on hand and Usage in units/dollars/percent, with Net sales and Total cost of goods headline tiles. Accounts-payable detail sits alongside it: the Invoice history report opens on a 'GL categories' tab totalling invoice count, subtotal, sales tax and total by GL sub-category, and every raw item is assigned one of ASM's predetermined category IDs (5110 Meat, 5140 Produce, 5310 Liquor, 5710 Paper and so on) from which a vendor item's 'GL account is populated based on the configuration of the raw item and is informational only'. Shortfall: no export in a named accounting system's import format is documented - QuickBooks, Sage Intacct, NetSuite and Great Plains appear nowhere in the ASM tree, nor in the classic Aloha v19.11 TS/QS reference guides, whose only named third-party export targets are payroll processors (ADP, PayUSA, Paychex, RealWorld) plus the PDI, Coconut Code and Clarifye grind-process export files; and the GL account is described as informational rather than as a configurable per-category mapping. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/reporting/inventory/cost_of_goods_sold_report · retrieved 2026-08-09

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 and recipe costing ship natively inside Aloha Smart Manager rather than requiring a contracted third-party product. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/using/inventory/about_inventory_management · 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

UPHELD partial 2026-08-10, BUT THE PRIOR SHORTFALL WAS MEASURED ON ASM AND WAS FALSE OF THE PRODUCT. It said nothing renders contribution margin per menu item against the actual sales mix. The classic POS's own BOH Product Mix report does exactly that: alongside Rank, Item Num, Item Name, Num Sold, Price Sold, Amount and % Sales it carries 'Cost - The cost of the item value, based on the following calculation: (item cost) x (num sold)', 'Profit - The profit of the item, based on the following calculation: amount - cost' and 'Food Cost % - The calculated value, based on the following calculation: cost / amount', daily or weekly and filterable by category or terminal (TS and QS Report Guides, Ch. 3). Aloha Insight repeats it above store: the Menu Mix data set carries Item Cost and 'Item Cost Percent of Sales - The item cost divided by item sales', grouped by Category and Item down to check detail. The cost is a maintained standard rather than ASM's recipe cost pushed down - 'Cost - Specifies the dollar amount required to produce the item ... the standard cost of the menu item, based on the specific ingredient purchase costs', moved to Maintenance > Menu > Item Cost in CFC v17.5. WHAT IS ACTUALLY MISSING is the threshold flag: no engine evaluates margin per item. Insight's Alerts Setup accepts any line item with a Greater Than / Less Than threshold but is scoped by Stores Monitored and publishes no item-cost line item; its Audit Exception thresholds are employee-behaviour types; ASM's notification events are the clock-in miss and stock low or zero; and the POS alerts engine has its four labor-only types. https://docs.ncrvoyix.com/downloads/aloha-pos/TS_ReportGuide.pdf · retrieved 2026-08-10 adversarially verified

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

A browser above-store view and a mobile app both exist for classic Aloha; what is missing is any published intraday latency. Aloha Insight - the classic-Aloha above-store product, separate from the POS - ships Current Day Polling, which 'provides you with an extremely convenient way to view the most current net sales data for all the stores within your company', lets you 'Select any store within Current Day Polling to view the detailed data for that store in Drilldown Viewer', and is switched on by the 'Current Day Polling' option on Company Setup > Polling and System Admin ('Indicates data for the current day of business is available in Drilldown Viewer reports, and Current Day Polling'). Its freshness is a batch poll, not a stream: 'Your company determines how often the data gets updated. Polling your stores frequently provides you with the latest information' and 'Click Contact Us on the Current Day Polling screen to submit a request for Aloha Technologies to configure the polling frequency for your stores'. NCR publishes no interval anywhere, and the report date-range definitions repeatedly warn that a range 'does not return data if data for the current date of business has not been polled'. Correction to an earlier reading of this cell: Pulse is not scoped away from classic Aloha - Aloha Insight Company Setup carries a Pulse Settings tab that assigns 'the employees that have access to Pulse' from an Unassigned/Assigned list and sets a 'Short Store Name' per store because 'Mobile devices are limited to the number of characters that can appear on the screen'. On the cloud back office, Aloha Smart Manager's dashboard remains day-grain ('Each time you sign in, the data from the previous day appears by default'; Yesterday / Last 7 / 14 / 90 days), and NCR Console's Executive View Summary 'defaults to the prior day'. Shortfall: within-minutes reflection of a sale is not documented on any surface, and the one live consolidated view - the FOH Sales and Labor Statistics report - runs on the terminal, not off-premise. https://support.alohaenterprise.com/wwapp/en_US/helpdata/Polling/CDP_About.html · retrieved 2026-08-09

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

End-of-Day processing and daily reconciliation are core to the Aloha BOH; drawer reconciliation is separately documented. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/drawer_reconciliation/entering_cash_and_bills · retrieved 2026-08-01

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

Aloha report guides include product mix reporting at item and modifier level with daypart filtering. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS_ReportGuide.pdf · retrieved 2026-08-01

Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.

reporting-comps-voids-audit

Re-cited off an Aloha POS security-roles field list, which was a weak evidentiary match for an audit report. Aloha Insight's Audit Exception Settings enumerates ~22 monitored types with per-store thresholds: "Comp Amount — Monitors when any employee meets or exceeds the dollar threshold amount for all comps applied to a check by either an employee or manager", plus Comp Count, Promo Count, Void Amount, Void Count, Cleared Items, Refund Amount/Count, No Sale Count, Reopen Check by Mgr Count, Edit Punches by Mgr Count, and "Deleted Check Out by Mgr Count... This audit type reports the manager who deleted the checkout, rather than the employee whose checkout was deleted." The approver half is corroborated in the Drilldown glossary: "Manager — Displays the manager who approved the void", alongside the reason-code name and check open/close timestamps. The POS-side equivalent lives in the QS/TS Report Guides; this is the above-store version. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AuditExc/AuditException.04.3.html · retrieved 2026-08-09

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

Drawer reconciliation captures counted cash against expected, producing over/short by drawer, shift and employee. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/drawer_reconciliation/entering_cash_and_bills · retrieved 2026-08-01

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

Held at yes on the ASM citation, with Insight as strong above-store corroboration. Insight publishes an explicit productivity metric list with group-by levels: "Sales per Labor Hour"; "Sales per Hour Worked — Net sales divided by the total labor hours from the selected period"; "Sales per Labor Dollar"; "Guest per Labor Hour — The average number of guests per labor hour. (Guest Count / Labor Hours.)"; "Labor % — [(Labor Dollars / Net Sales) * 100]"; "Overtime Labor %"; "Scheduled versus Actual Labor Dollars — The variance between the scheduled and the actual labor dollars"; "Budgeted versus Actual Labor Dollars" — each rolled up by Area, Region, Store Group, Store, Date, Day Part, Hours, Employee Job Code, Job Code, Revenue Center and Employee Name. Wage-bearing elements are separately gated: "Using the security rights provided for each of the data sets, you can provide access to sensitive wage information to only the people who need it." Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/reporting/labor/interval_sales_and_labor_report · retrieved 2026-08-09

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

Per-employee sales reporting is standard in the Aloha report guides; named-category attachment rate is not confirmed. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS_ReportGuide.pdf · retrieved 2026-08-01

Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator

reporting-channel-profitability

The margin half is better supported than previously recorded, and the previous note was wrong to say it does not exist. Insight's Dynamic Drilldown Menu Mix data set carries Item Cost ("The cost of the items, as defined in Aloha Manager") and Item Cost Percent of Sales ("The item cost divided by item sales"), and both list Order Mode among their group-by levels: "Region, Area, Store Group, Store, Category, Sales Item, Revenue Center, Date of Business, Day Part, Order Hour, Order Mode, Check, Check Detail". That is food-cost margin by fulfilment channel. THE LIMIT THAT KEEPS THIS PARTIAL: order modes are operator-defined POS constructs, not named marketplaces, and nothing in the 292-page Aloha Insight help system nets marketplace commission — commission, DoorDash, Uber, Grubhub, third-party delivery and marketplace all return zero relevant hits (the only "third party" references are payroll/GL processors and corporate-issued loyalty rewards). Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/d3v/Menu_Mix_dataset.html · retrieved 2026-08-09

Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator

reporting-multiloc-drilldown

Aloha Insight documents the whole path in one worked example. Drilldown Viewer: 'As a regional manager, you can use Drilldown Viewer to determine how the sales are going for a new special ... Select the region, the beginning and ending dates, and the Menu report option ... Select the category for the item, to narrow the item choices, or click the link for the item. Drilldown Viewer displays the total sales by date for the item, as well as the sales by the hour for the item. You can click a specific hour to see the store(s) in which the item was sold. Then click a particular store to get down to check level detail.' Group total, to one location, to the transaction. Side-by-side comparison and ranking are explicit at the top level - you 'select a store, region, or area' and 'to determine the store with the highest sales, click the Net Sales column heading' - and Dynamic Drilldown Viewer builds saved multi-site pages grouped 'by: Area, Date, Day Part, Employee Job Code, Employee Name, Job Code, Region, Revenue Center, Store, or Store Group', sortable on any column header with a breadcrumb trail back up the chain. The transaction level is also reachable on its own: Check Detail Viewer 'enables you to view historical check level detail from your Aloha Insight Web site', searched by store, date of business, time range and check number, filtered by Clears / Comps / Open / Promos / Refunds / Reopened checks / Voids, returning items ordered, subtotal, tax, tender type and tip, up to 90 days back. NCR Console corroborates the group-to-store half independently: Executive View 'allows a user with multiple sites to see aggregated data for all sites within his/her network ... measure one store's performance over another', with store-by-store Breakdown views. Scope note: this is Aloha Insight, the separately licensed above-store product for classic Aloha, not the POS and not Aloha Smart Manager, whose only multi-site constructs remain the Above Store Manager role, a standardized Site filter and an organization switcher. https://support.alohaenterprise.com/wwapp/en_US/helpdata/Drilldown/Drilldown_About.html · retrieved 2026-08-09

Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator

reporting-custom-report-builder

Aloha Insight ships a wizard-driven above-store report builder for non-developers. Reports Builder 'enables you to create custom reports containing polled POS data for any single store or all of your stores combined ... You determine the format, the headings, and the line items on the report', and a report is three parts: Report Settings (name, description, style, category), Report Groups ('user-defined groupings ... you can break your report into Voids and Comps') and Line Items ('Data elements from within your Aloha Insight data warehouse ... a system-supplied line item provided by Aloha Insight, or ... a custom line item using the Custom Line Item wizard', e.g. 'Void Count by Day Part by Revenue Center'). Measures beyond the supplied set are built without code: the Custom Line Item wizard composes 'System line items, Custom line items, Numbers, Mathematical operators' with multiplication, division, addition, subtraction and parentheses, a Test button, and a Number/Currency/decimal display format. Filters and dimensions: the Advanced Options tab sets a per-line-item date range overriding the report's own ('Line items can report on specific dates or time periods'), and running the report 'invokes the Reports Viewer application where you can define the stores included in the report, as well as the date range', with area, region, store and store-group selection. The result is saved, named, access-controlled ('Select the security classes that can access the report'), re-runnable and schedulable - Reports Viewer generates it Daily, Weekly, Monthly, 'End of Every' or 'Once as Soon as Possible' and delivers it by email or to the Portal in a chosen file type, including comma-separated values. Roughly 35 predefined report styles cover comparative, weekday, stores-on-top and GL-export layouts. Scope: this is Aloha Insight, a separately licensed above-store product, not the POS; the terminal-side Custom FOH Reports remain the POS's own limited equivalent, and Aloha Smart Manager's ad-hoc builder is Advanced Analytics only. https://support.alohaenterprise.com/wwapp/en_US/helpdata/Reports/RB_About.html · retrieved 2026-08-09

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

Aloha Insight Reports Viewer schedules any report for recurring automatic delivery: "Use the Report Schedule tab to specify the frequency and dates a report generates, and the report delivery schedule... When you schedule a report, it generates and is sent to you via email as an attachment, or it is sent to the Portal." Cadence is Daily (every 1-365 days), Weekly with weekday checkboxes, Monthly by nth day or nth weekday, "End of Every" Company Week / Fiscal Period / Fiscal Year / Month / Pay Period, and "Once as Soon as Possible", each with a run time, time zone and start date. The recipient list is explicit ("Send Report to Other Users... you must select the subscriber group that receives the report", scoped by "Base Stores Reported on the Subscribers' Security"), and the format is per report: CSV, tab-separated, PDF, Excel, RTF or Crystal. The payroll export is separately schedulable ("Schedule the export file and automatically email it to any Aloha Insight user"). SCOPE, and it is why this was previously partial: the CLOUD surfaces still do not do this — Data Sharing is a fixed daily feed and ASM reports are on-demand only. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/Reportsviewer/RptViewer_Rpt_Sched_Tab.html · retrieved 2026-08-09

Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator

reporting-raw-warehouse-export

Insight adds a real automated recurring delimited export, but to the wrong destination, so the named limit survives on both the modern and the legacy surface. Reports Viewer exports Active Reports as "Delimited File (.csv or .txt)" with a configurable delimiter, quotation-mark policy (All Fields / Text / None) and extension type — ".txt or .iif" for tab, and "QuickBooks uses the .iif format" — while Crystal reports export as CSV, character-separated, tab-separated and Excel. The payroll feed is genuinely automated: "Consolidate time and attendance information from all of your stores, or a group of stores, into a single export file... Schedule the export file and automatically email it to any Aloha Insight user." THE DESTINATION IS EMAIL OR THE IN-PRODUCT PORTAL IN EVERY CASE. The 292-page Insight help system documents no FTP/SFTP, no S3, no customer-owned endpoint and no API of any kind. So the shortfall — destination is NCR-side, not customer-controlled — now holds of both Data Sharing (signed URLs, 7-day TTL) and Insight. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://docs.ncrvoyix.com/restaurant/data-sharing/using/introducing_data_sharing · retrieved 2026-08-09

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

HEDGE UPHELD ON CREDENTIALS AND NOW QUOTED RATHER THAN INFERRED; COVERAGE HALF UNDERSTATED. On the gate: 'NCR teams are actively working to enable more self-service capabilities for customers. However, at this time, the initial cloud enablement of customer systems still requires reaching out to your NCR Account Representative. Once you've been approved, you will receive an invitation to one of our customer portals', with the same sentence published for third parties. Self-registration exists but yields only a trial -- 'Begin Test Drive to download a Postman collection with credentials that will remain active for 90 days ... Test Drive is a trial feature.' On coverage: the note listed Menu, Catalog, Site, Order and InStore Order and omitted labor and payments, both of which Data Sharing publishes as documented datasets alongside taxes and check summary. Tension worth seeing: Data Sharing's own overview advertises 'Self service access: Easily manage access to your data yourself without having to go through a support or enablement team' -- a bullet about managing feeds once enabled, which does not contradict the account-rep onboarding gate. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer · retrieved 2026-08-09

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

RETRIEVED 2026-08-10; no longer scoped to the help-center dump, and the signature conjunct now fails on evidence rather than for want of a corpus. Order lifecycle webhooks exist: 'You can subscribe to order change notifications by creating a subscription with the Order Service', POST /order/v3/orders/subscriptions registering a customer-supplied destinationUrl on the ORDER_CHANGE topic, with statuses FOR_FULFILLMENT, IN_FULFILLMENT, IN_TRANSIT, ABANDONED, EXPIRED, VALIDATED, READY_FOR_VALIDATION and ORDER_UPDATED (Order, productId 374, whose overview points at Aloha Takeout). Payment-bearing transactions ride Transaction Document Management, which 'is responsible for publishing processed TLOGs via webhook to URL subscriptions' - though TDM's documented providers are emerald and StoreLine, not established as Aloha-fed. RETRY IS ACKNOWLEDGED, NOT SPECIFIED: subscriptions carry a retryQueue field, Labor Data Management 2 exposes PUT /messaging/subscriptions/{id}/retry-queue, and Order Monitor's only statement is that 'If messages aren't sent to a subscriber successfully, there is a possiblity that messages will send out of order due to the retry behavior' [sic]. No attempt count, interval or backoff is published for webhook delivery anywhere in the tier. SIGNATURE VERIFICATION IS ABSENT BY DESIGN: the platform authenticates the CALLBACK with credentials the subscriber supplies, and Site documents the field as 'authenticationType | Indicates the type of credentials required | Enum with allowed values BASIC', with NONE and PLATFORM the only other observed values. Zero hits for signature, signing, HMAC, verification or redelivery in any outbound-event document across both tiers with the control passing; the sole HMAC is inbound request auth on the Data Sharing API. Partial on the signature conjunct. Correction to the prior note: 'Alerts and Messaging' is NOT an Aloha lead - every path is /fis/{fiId}/, it is Digital Banking. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/374 · retrieved 2026-08-10 adversarially verified

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

The DevEx Knowledge Hub, now readable, settles the access question and leaves the price question open - so the claim as worded fails on its second half. Raw data access is real, documented and self-service once entitled: NCR Voyix Data Sharing publishes a fixed data-set catalogue (Check summary, Comp summary, Item discount, Item sales, Item voids, Labor, Promotion summary, Sales totals, Taxes, Tenders) with per-transaction field schemas, delivered daily as Parquet to cloud storage with an API, and lists 'Self service access: Easily manage access to your data yourself without having to go through a support or enablement team to configure things for you'; the platform itself documents an API gateway, OpenAPI contracts and a BSL security/provisioning model. SHORTFALLS, which are why this is not a yes: access is entitlement-gated per organization rather than included by default. Marketplace Self-Serve Integration Onboarding lists among its prerequisites 'Sign up for Menu and Ordering platform capabilities with NCR Voyix', the Marketplace portal itself is eligibility-checked ('Check in with your NCR Voyix Account Representative to see if you are eligible to access NCR Voyix Marketplace'), Data Sharing is a separately provisioned product with a remote installation, and Virtual Kitchen likewise instructs sites not already on BSL to 'contact your NCR Voyix representative and initiate the BSL provisioning process'. Whether those entitlements carry an incremental per-location fee or revenue share is published nowhere - NCR is quote-only and www.ncrvoyix.com/restaurants/aloha-pos shows no price, plan tier or API fee. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/ssio · retrieved 2026-08-09

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

Insight's existence is not neutral on this claim — it is affirmative evidence of a paywall, and the licensing is per store, not per company: "Store Name — Contains the stores licensed for Aloha Insight that do not already have store specific thresholds"; "If you are licensed for Aloha Insight and the store gets polled, the guest check displays as an active hyperlink"; "When you first sign-up with Aloha Insight...". On classic Aloha the multi-location comparison this claim names by name is delivered by Drilldown Viewer, Dynamic Drilldown Viewer, Reports Builder and Reports Viewer, and all of those are Aloha Insight applications sold as a separately licensed above-store product on top of the POS. That is a second, older, independent instance of the gate the ASM release notes show (COGS and Advanced Analytics above base), and it sharpens the shortfall from "which package is entry-level is unpublishable" to "the multi-store comparison capability is a separate per-store licence on classic Aloha". Value held at partial because single-store labor-vs-sales, PMIX and comps/voids remain in the base BOH report set. Citation kept on the ASM release notes because they carry the packaging evidence for what is sold TODAY; the Insight evidence is legacy. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/about/release_notes/core_release_notes/version_1x · retrieved 2026-08-09

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

The bar is at least 24 months of transaction-level detail queryable in the reporting UI, and the only NCR surface that states a retention window states one an order of magnitude short of it. Aloha Insight's above-store Check Detail Viewer: "Date of Business — Specifies the date of business for which the system returns guest checks. The system can only return data up to 90 days in the past." Nothing else in the 292-page Aloha Insight help system sets a warehouse retention window; the other purge rules are gift-card and alert housekeeping (alerts purge from Alerts Viewer after a user-set number of days, default 30). Bound to four corpora: the 292-page Insight help system, the 150-document /downloads/ PDF library (17.9MB), the 1,941-document DevEx dump and the 82-topic NCR Console manual — none documents 24 months, and the one that documents anything documents 90 days. JUDGEMENT CALL, recorded deliberately: this is `no` rather than `partial` because the claim is a threshold claim and a documented 90-day cap defeats it; a reader who scored it partial with "the limit is 90 days" would not be unreasonable. The 90 days is Insight's above-store viewer — the on-premise BOH's own local retention remains undocumented in every corpus we hold. Aloha Insight is a separately licensed above-store product for classic Aloha, not the POS itself; its help is visibly legacy (worked examples dated 2002-2009, Crystal Reports), so grade B, not A, and it does not establish what a new buyer is sold today. https://support.alohaenterprise.com/wwapp/en_US/helpdata/ChkDetailViewer/Check_Detail_Viewer.html · retrieved 2026-08-09

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

Held at yes, and corroborated by a far better-matched surface than the AlertEngine.xml citation. Insight Alerts Setup: "Alerts provide proactive information to management when specific criteria is met... Notification is accomplished through the use of email, pagers, cell phones, or the Insight Alerts Viewer window", with operator-set severity levels and thresholds against any Insight line item ("Between" takes two threshold values), qualified by revenue center, order mode, category or job code. The FAQ gives the examples this claim names: "employees approaching overtime... store sales that are over/under a predefined threshold, or even the sales for new menu items which have exceeded their defined threshold." Intraday cadence exists — "You select either minutes or hours... If you select 'Minutes,' you select from 1 to 59 minutes" — but is polling-bound: "If the data has not been polled, Aloha Insight is unable to use the data to create the alert." The deviation-from-pattern half is documented via Relative Audit Exceptions, though peer-relative rather than historical. COMPLICATION WORTH RECORDING: the richest alerting sits on the separately licensed Insight, not the base POS. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/alerts/implementing_alerts · retrieved 2026-08-09

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

NCR Voyix announced conversational analytics on 7 January 2026 as part of the next-generation portfolio: 'Voyix Insight with conversational AI: An AI-powered analytics application with conversational search that provides real-time insights, recommended actions, alerts and automated targeting for forecasting, labor and shrink.' That is the claim's subject, which is why this is not a `no`. It is not a `yes` because it is a launch announcement for the microservices suite on the Voyix Commerce Platform, shown at NRF '26, not a documented feature of Aloha POS or Aloha Essentials; classic Aloha Insight's 292-page help contains no natural-language or conversational query at all, and `natural language` occurs zero times across every product corpus. The platform FAQ describes the platform's AI more modestly, as 'predictive analytics and AI-powered insights'. https://www.ncrvoyix.com/newsroom/ncr-voyix-unveils-ai-accelerated-suite-of-applications-on-the-voyix-commerce-platform · retrieved 2026-09-10 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

NCR Voyix Consumer Marketing ships guest-level cohort reporting in its Report Catalog. The Life Cycle report classifies identified guests as Active, At Risk or Churned and shows the percentage in each state, the average lifetime spend of each cohort, the counts that moved between states in the period (At Risk to Active, Churned to Active, At Risk to Churned), the average timeframe before a guest becomes At Risk for the brand, and a Guest Movement line graph of migration between cohorts over time. The Guest Sales report ranks individual card numbers by Total Transactions, Total Net Sales, Average Order Value, Basket Size (average items per transaction), Total Discount and Lifetime Value, with each card number opening that customer's profile; Segment Comparison compares customer count, percent enrolled and sales metrics between segments. All are keyed to identified loyalty card records and filterable by Location, Segment, Order Mode and Revenue Center. https://docs.ncrvoyix.com/restaurant/consumer-marketing/reporting/life_cycle_report · retrieved 2026-08-08

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

Held at yes and corroborated on a second, above-store surface, which matters because the cloud back office offers only a six-week rolling average. Insight ships a weighted projection engine at company and store level: "Number of weeks used in sales projections... zero to ten weeks"; "Use Week — Establishes the prior week(s) to base sales projection amounts" from Same Week Last Year / Last Week / Two through Eight Weeks Ago / Budget Sales; "Weight — Applies a weight to the week selected... from 5 percent to 100 percent. The total for all weeks must equal 100%"; plus Zero/Null handling to exclude unpolled days, with per-store overrides. CAVEAT: this is day/week grain from polled history, so the SUB-HOURLY half of the claim still rests solely on the POS Quick Count projection reports (5/15/30/60-minute intervals) in the v19.11 Reference Guide. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09 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

Aloha report guides cover declared and charged tips per employee; a jurisdiction-level tax liability summary is not confirmed. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS_ReportGuide.pdf · retrieved 2026-08-01

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

RE-CITED AND RE-SCORED 2026-08-09. The old 125-character note from 2026-08-01 asserted store groups and stores from an Aloha Takeout field-definitions page on which "store group" occurs ZERO times -- a `yes` resting on one unsupported sentence, which is the more dangerous error because nothing about it invites re-examination. The value is UPHELD, now on the document that actually carries the mechanism. CFC models the organisation on TWO orthogonal axes and documents both. (1) OWNERSHIP: "Aloha Configuration Center enables you to create a hierarchy structure to successfully manage database records for your multi-store environment. To do this, Aloha Configuration Center employs two concepts known as `Owners' and `Record Hierarchy Levels.'" An owner is "a restaurant organization, franchisee, or individual store", and "There are three record hierarchy levels built in to Configuration Center: Global, Corporate, and Store." The levels are load-bearing, not cosmetic -- they control "Record visibility", "Record maintainability" and "Record distribution -- Filters the database records that are sent to each store, based on who owns the records." Sibling isolation is explicit: "records owned by AlohaBurger Corporate are not visible to AlohaBurger TX ... their records fall under separate hierarchy branches." The franchise tier is named outright, not inferred: "the corporate office controls the records for the stores they own, while allowing each franchisee to have control of certain records, as necessary." (2) STORE GROUPING, which is a SEPARATE and multi-dimensional structure: "Configuration Center provides a store group hierarchy feature that enables you to define several hierarchies, or classifications, by which you can group your stores. A hierarchy is any classification you find helpful when organizing your stores, such as region, tax jurisdiction, store size, or pricing tier, to name a few. You can use as many hierarchies as you need." The guide works a store simultaneously in a `States' hierarchy and a `Region' hierarchy. Records are scoped to those groups, and the employee record carries an owner that determines what they see on login. TWO CONSTRAINTS RECORDED SO A LATER PASS DOES NOT OVER-READ THIS, and neither defeats the claim: a store belongs to exactly one group per hierarchy ("You can assign a store to only one store group, within a given hierarchy"), and the structure is append-only -- "once you add a hierarchy and store group, you cannot delete them from the system." Aloha Configuration Center as documented for CLASSIC on-premise Aloha (Table Service v19.11 Reference Guide, HKS1780, Chapter 1 "About CFC"); Aloha Menu as documented in the Aloha Menu User Guide (HKS1744, v2.24, Sept 2025). This does NOT describe Aloha Smart Manager, Aloha Cloud or NCR Console. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09

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

RE-CITED AND RE-SCORED 2026-08-09, VALUE UPHELD, AND THE OLD SHORTFALL CLAUSE IS NOW MEASURED RATHER THAN GUESSED. The 125-character note from 2026-08-01 cited an Aloha Takeout field-definitions page whose only CFC sentence is scoped to Takeout Settings, and hedged with "full publish and version history detail is not documented" -- a hedge nobody had tested. CENTRAL AUTHORING AND DISTRIBUTION, on the CFC surface: "the corporate office can easily manage daily POS data changes using the hosted, centralized database. The corporate office accesses the client-side application to add or update menu items, prices, promotions, and more. The POS database changes are saved in the centralized database, and then distributed to stores using the Data Distribution and Export processes." Targeting is by ownership, not broadcast: "A Data Distribution service runs at the data center, to distribute database records from the centralized database, to the local SQL Express database at your store. Only those database records applicable to your store are sent to your store." Propagation is documented on both a batch and an immediate path -- the store Refresh/Update ("the system connects to the centralized database at the data center, to obtain the most recent database records"), normally automatic at End-of-Day, and a Real-Time Update feature that "enables you to send certain record changes to the FOH terminals, without the need to bring down the terminals through the normal refresh process", triggered for a named function list that includes Items and Price Changes. THE LITERAL PUBLISH ACTION BELONGS TO THE OTHER SURFACE, AND NAMING WHICH IS THE POINT: the word "publish" occurs ZERO times in the CFC chapter -- its vocabulary is distribution and refresh -- while the Aloha Menu User Guide ships an explicit one. There, a menu is assigned "to a site or site group" before publishing, previewed, then "click Publish now", with a Schedule drop-down offering "Publish Immediately" or "Publish on date ... select a specific date and time", and per-menu status badges including "changes have been made to the menu and they are not yet published". So central menu publish is real on both surfaces, by two different mechanisms. THE SHORTFALL, NOW TESTED ON BOTH AND ON THE WHOLE GUIDE: there is NO PUBLISH OR CONFIGURATION HISTORY -- no record of who pushed what, when. In the Aloha Menu guide, version, audit and history occur zero times. In the CFC chapter, publish, audit, history, timestamp, revision and rollback all occur zero times. Across the full 1.59-million-character Table Service v19.11 Reference Guide, "version history" and "who changed" occur zero times and all 41 "audit" hits are coupon audit counts, bartender audit chits, the transactional BOH Audit report, the debout.log transaction trail, and a "Months to retain audit data" retention field -- none is a configuration change log. AND CFC'S "VERSIONING" IS NOT THAT EITHER, WHICH IS THE TRAP ON THIS CELL: "A `version' is a copy of a record, which has the same record number as the original, primary record; however, there might be one or more settings that are different ... and is applicable to only specific stores." That is variant management across stores, not versions over time. The `yes` therefore rests on central authoring, group targeting and scheduled distribution -- all documented -- and deliberately does NOT claim an auditable publish trail. Aloha Configuration Center as documented for CLASSIC on-premise Aloha (Table Service v19.11 Reference Guide, HKS1780, Chapter 1 "About CFC"); Aloha Menu as documented in the Aloha Menu User Guide (HKS1744, v2.24, Sept 2025). This does NOT describe Aloha Smart Manager, Aloha Cloud or NCR Console. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09

Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator

multi-location-local-override-policy

Re-scored 2026-08-09 off a 128-character 2026-08-01 note. The override mechanism is a record version: 'A version is essentially a composite copy of the primary record, except for the few changes made to the record that one or more stores may need. The version is not a standalone record, it shares the record number of the primary record, but overrides the primary record at designated stores.' Precedence is documented -- 'Configuration Center uses a priority rule, in combination with start and end dates, to determine which version is in effect at a store. The more specific the version assignment, the higher the priority' -- ordered Store, Store Group, Corporate, Global. Corporate lock is real: 'Store is the lowest, and most restrictive record hierarchy level.' And delegation is documented outright, which the old note missed: Table Service 'uses a combination of pricing methods, pricing hierarchy rules, and pricing features to help the corporate office manage pricing for all its stores; yet, delegate pricing control to one or more stores, when necessary.' TWO SHORTFALLS, THE SECOND NEWLY FOUND AND THE MORE DECISIVE: there is no per-field lock/unlock surface, and the LOCATION DOES NOT PERFORM THE OVERRIDE AT ALL -- 'You must be logged in as a corporate-level employee to create a version of a primary record.' Corporate authors the version and assigns it to the store. Deliberately NOT taken to no: delegated local pricing control and a corporate-vs-store lock are the substance of the claim, and downgrading on one chapter's granularity would be this record's recurring over-generalisation running in the opposite direction. Aloha Configuration Center as documented for CLASSIC on-premise Aloha (Table Service v19.11 Reference Guide, HKS1780, Chapter 1 "About CFC"). This does NOT describe Aloha Smart Manager, Aloha Cloud or NCR Console. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09

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

RE-SCORED 2026-08-09, AND THE OLD SHORTFALL WAS FLATLY WRONG. It read 'a formal price-zone object is not documented'; the store group hierarchy IS that object, and the guide names the use case itself: a hierarchy is 'any classification you find helpful when organizing your stores, such as region, tax jurisdiction, store size, or pricing tier, to name a few.' One item record carries different prices per location group without duplication: 'A version is a copy of a record, which has the same record number as the original, primary record; however, there might be one or more settings that are different ... Record versions allow you to have different settings in a primary record at a store, without creating a separate, unique record for each store', and the guide's own worked example is exactly this claim -- 'you determine there does need to be a version of the corporate-owned hamburger record because your California stores require a different price ... The store group to which the store belongs, which in this example is California, becomes the store group assignment.' Daypart pricing is documented too: 'Use the Price Change pricing method to activate one or more price changes at a specific time ... for happy hour or other periods of the business day.' THE CLAIM IS A THREE-WAY CONJUNCTION AND PARTIAL NOW RESTS ON THE ONE LEG THAT REALLY IS ABSENT: per-order-channel pricing. The pricing-method list is Item, Price Level, Price Change, Button, Fixed Item (TS only), Quantity and Ask for Price, with no channel dimension anywhere in Chapters 1-3. Aloha Configuration Center as documented for CLASSIC on-premise Aloha (Table Service v19.11 Reference Guide, HKS1780, Chapter 1 "About CFC"). This does NOT describe Aloha Smart Manager, Aloha Cloud or NCR Console. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09

Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator

multi-location-scheduled-publish

HELD AT partial, BUT THE ROLLBACK HALF IS NOW DOCUMENTED RATHER THAN DOUBTED. From the Aloha Configuration Center chapter of TS1911: CFC 'enables you to distribute database changes for a future date, to intended stores. The changes remain in the local, store database until the specified effective date. This ensures database changes take effect on the POS as scheduled, even if the file server cannot connect to the host database.' Post-activation rollback has two documented mechanisms -- scheduled versions auto-revert ('After End-of-Day processes on May 31, 2008, Store 105 will revert back to using the primary food tax record') and deleting a version restores the primary ('you delete the version, and the primary record will be in effect at the store') -- and scheduled versioning explicitly covers Price Changes and Promos. WHAT STILL BLOCKS A yes, stated as the inference it is: the claim requires activation 'interpreted in each target location's own timezone', and no document we hold says so. Activation is evaluated per store against that store's own date-of-business, and each store carries its own Time zone setting materialised as a per-server TimeZone.ini -- which implies local interpretation but never states it. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/price_changes · retrieved 2026-08-09

A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator

multi-location-new-store-template

A documented clone flow exists, but it clones the above-store record rather than the POS build, and no opening timeline is published. Aloha Insight Site Setup: 'Use the Copy function to copy attributes of an existing store to a new store. This is helpful when adding several stores that are similar in configuration' - select the store, click Copy, type the new ID and name, then 'Make the changes that are specific to the store, such as store address.' Security classes copy the same way ('Copying settings to a new security class enables you to start with pre-configured settings'), and a new store inherits company-level behaviour through Site Setup's region/area/store-group assignment and Company Setup's sales-calculation, polling and reporting-module settings. What that copy carries is the Insight site record - polling and dial-up configuration, projected sales, store groups, ACH merchant settings - not menus, taxes, printers, modifiers or tenders. Those live in Aloha Configuration Center, where the documented mechanism is inheritance rather than templating: Store Groups 'associate different store locations based on the type of data they need to receive from Aloha Configuration Center', a store can belong to several groups, and assigning a database record to a group pushes it to every store in it (the worked example is 20 of 200 stores), with store-level versions overriding corporate records where needed ('you accomplish any store-specific need to override an item cost by creating a store version of the primary Item Cost record'). Shortfall: no documented one-step copy of a complete POS configuration to a new site, and NCR publishes no expected time-to-open on docs.ncrvoyix.com, www.ncrvoyix.com or the Aloha Insight help system. https://support.alohaenterprise.com/wwapp/en_US/helpdata/SiteSetup/SiteSetup_CopyStore.html · retrieved 2026-08-09

The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator

multi-location-corp-vs-franchisee-roles

UPHELD partial 2026-08-10, with the shortfall upgraded from an inference to CFC's own visibility matrix. NCR documents the franchisee case by name, but as scoping inside one corporate hierarchy rather than as a tenant boundary. Aloha Insight Site Setup lets you 'create a store group for each franchisee that includes only their stores, thus limiting the sales data they can view', with Security Class Setup binding a class to Home Store, Home Region, Home Store Group or explicit sets; Stored Value Replication Groups 'divide your stores into logical groups by geographical areas or by franchisee owner'; and gift-card settlement is partly separated, each store supplying its own merchant account number and terminal ID which the company's financial authorizer must approve. Configuration Center adds owners and record hierarchy levels so the corporate office controls the records for the stores it owns 'while allowing each franchisee to have control of certain records'. THE SHORTFALL IS NOW STATED BY CFC ITSELF: the isolation is lateral only. 'Records that belong to one owner are not visible to other owners at the same level. For example, records owned by AlohaBurger Corporate are not visible to AlohaBurger TX' - but 'some system records, such as employee and hardware records, need to be assigned to a specific store', and store-owned records are 'visible to AlohaBurger Corporate, as well as AlohaBurger Global' and editable 'by a store 101 employee, or a corporate- or global-level employee'. Franchisee labour and employee data therefore poll into the corporate warehouse, and company-wide switches such as 'Do Not Import Employee SSN' are set once for everyone. Banking remains the one genuinely separated element. https://support.alohaenterprise.com/wwapp/en_US/helpdata/SiteSetup/SiteSetup_Add_StoreGroups.html · retrieved 2026-08-10 adversarially verified

Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator

multi-location-royalty-calculation

The three mechanical halves of the claim exist as generic above-store tooling in Aloha Insight; the franchise constructs do not exist at all. Calculation: the Custom Line Item wizard builds new measures from 'System line items, Custom line items, Numbers, Mathematical operators' - multiplication, division, addition, subtraction and parentheses, with a Test button and a Currency display format - so net sales multiplied by a percentage is a supported, documented configuration, and the result can be placed on a custom report in Reports Builder or on an alert threshold. Schedule and distribution: Reports Viewer runs a saved report Daily, Weekly, Monthly, 'End of Every' or once, at a set time and time zone with start and end dates, scoped to selected stores, store groups, areas or regions, and delivers it to a defined subscriber list by email or to their Portal in a chosen file type. Basis: Company Setup > Sales Calculations moves individual comps and promos between 'Comps that are included in Net' and 'Comps that are excluded from Net' (and the same for promos), and selects Gross, Net or Straight for check average and per-person average - a configurable definition of net sales, albeit one set once for the whole company's reporting. Shortfall, and it is the entire difference between this and a franchise system: there is no royalty, ad-fund or marketing-fee object anywhere. Grepping the Aloha Table Service and Quick Service v19.11 Reference Guides (the complete Maintenance field enumeration) and the QS/TS/ATO Report Guides for 'royalt' returns zero occurrences, and the 292-page Aloha Insight help system has no fee schedule, no per-franchisee rate, no royalty basis distinct from the company reporting basis, no accrual or liability posting, and no franchisee statement or invoice. Every 'franchise' hit in the POS field set is record ownership rather than money. What an operator has is a general formula-and-scheduled-report facility they must define themselves, not a fee engine. https://support.alohaenterprise.com/wwapp/en_US/helpdata/LineItems/CLW_About.html · retrieved 2026-08-09

Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.

multi-location-royalty-collection

Aloha Insight is the above-store product for multi-unit and franchise operators and it documents ACH in depth -- 264 matches across the 292-page help, all of them stored-value and marketing ACH reconciliation against a merchant account. Royalty collection is absent: `royalt` occurs once in the developer portal, in a payments glossary explaining that a card issuer 'often pays the organization a royalty to market that card to their membership base', and once on the marketing site in a blog. Neither is a franchise royalty. No document describes calculating royalties or fees, sweeping them from franchisee accounts, or presenting a franchisee-visible statement of what was charged. https://support.alohaenterprise.com/wwapp/en_US/helpdata/Reports/RB_CustomRptSettings.html · retrieved 2026-09-10 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

Aloha Insight - the above-store product for classic Aloha, whose 292-page help system at support.alohaenterprise.com was retrieved live on 2026-08-09 - documents every element of this claim, which neither NCR Console nor Aloha Smart Manager did. AGGREGATION OVER A SELECTED SET: Reports Viewer lets you 'Select the stores to include in the report' and 'Decide whether the stores list separately or all together', and 'If you do not select either List Stores Separately or List Dates Separately, the report summarizes the data for all stores and dates included on the report'; Reports Builder styles include 'Comparative - All Stores (Date Range to Last Yr Date Range)' and 'Groups On Top with Region, Area, and Store (with group subtotal)', and reports export to Crystal, Excel, CSV or character/tab-separated text and can be scheduled to e-mail or the Portal. COVERAGE: Drilldown Viewer, entered by store, region or area, offers Category Sales, Hourly Sales, Menu (PMIX), Labor, Schedule (scheduled versus actual hours), Comps, Promos, Voids, Payments, Deposits, Revenue Centers and Order Modes - so sales, labor, discounts, voids and item mix are all present - and 'Void Dollars by Selected Void Type' is a system line item available to Reports Builder. STORE-VS-STORE RANKING: in Drilldown Viewer 'Sort columns alphabetically or in ascending order, depending upon the column data. For example, to determine the store with the highest sales, click the Net Sales column heading. The numeric data sorts ... with the highest sales displaying first.' VARIANCE FLAGS: the Alerts Setup wizard monitors any Insight line item against a threshold (Between, Equal To, Greater Than, Less Than, Greater/Less Than or Equal To) over Home, Selected or All Stores, as either 'a single alert for all stores' or a separate alert per store, with Warning and Critical severity and delivery to Alerts Viewer, e-mail, pager or cell phone; its stated benefits are 'The ability to manage by exception' and 'The ability to monitor all stores or a specific store', and messages embed %AlertThreshold%, %AllStores% and drilldown links including Voids. Two qualifications, neither fatal: Aloha Insight is a separately licensed above-store product rather than something the POS ships on its own, and freshness is bounded by polling ('Only data in the data warehouse can be used for alerts'). https://support.alohaenterprise.com/wwapp/en_US/helpdata/Drilldown/Drilldown_Working.html · retrieved 2026-08-09 adversarially verified

Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator

multi-location-normalized-item-rollup

Item-level sales do roll up across sites, and the classic-Aloha above-store product states the identity rule explicitly rather than leaving it unsaid. Aloha Insight Company Setup carries a Master Store setting: 'Aloha Insight reports and Drilldown Viewer use the item IDs, names, and sales categories from the master store. You can add new category and item data for individual stores, but master store data overrides categories and items specified by other stores if the IDs are the same. If a category or item exists in a store that is not in the master store, the system adds the item or category from the non-master store to your data warehouse.' So an item a store has renamed locally still reports under the corporate name, because the master store's name wins on a matching ID; PMIX item naming style (long name, short name or chit name) is a company-level setting; and reporting categories can be taken away from the stores entirely with 'All Categories Specified Through Category Wizard', where 'store category data will not affect Insight reports'. On the cloud side the ASM Product mix report accepts 'one or multiple sites' or Select all Sites, and Aloha Configuration Center holds one primary item record from which stores receive versions rather than separate items. SHORTFALL: the rollup key is the POS item number, not a corporate item ID with a per-store cross-reference, and NCR documents the collision case rather than solving it - 'Separate PMIX by Store' exists because 'stores do not have standard menu item numbers across locations. For example, the Bedford store uses the item number 3000 for meatloaf; while the Denver store uses item number 3000 for a chef salad', and once it is on, 'The PMIX report does not display combined item sales for all stores.' Local pricing rolls up as quantity and dollars with no documented price reconciliation. https://support.alohaenterprise.com/wwapp/en_US/helpdata/CompSetup/CompanySetup_data_mgmntTab.html · retrieved 2026-08-09 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

Aloha Stored Value operates at the Aloha Enterprise level, redeemable across sites and online. https://docs.ncrvoyix.com/restaurant/aloha-online-ordering/implementing/configuring/configuring_online_order_features/working_with_gift_cards · retrieved 2026-08-01

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

Aloha Loyalty and Consumer Marketing are configured at the enterprise level and shared across sites and digital channels. https://docs.ncrvoyix.com/restaurant/digital-ordering/integrating/digital_ordering_and_asval/link_aoo_to_ae · retrieved 2026-08-01

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

UPHELD partial 2026-08-10, BUT THE PRIOR SHORTFALL SENTENCE WAS FALSE and is withdrawn. It said 'separately branded receipts per concept on a shared terminal are not documented - guest check content is configured through Print Designer and Guest Check Message at store level.' Two TS v19.11 Reference Guide entries contradict that. Aloha POS has a first-class multi-brand construct: concepts 'represent different brands under the same company. For a virtual kitchen solution, add a concept for the host restaurant and each virtual kitchen in use. You then associate each concept with a revenue center', and the Concept function covers 'separate store types operating from the same database' while providing 'top-level reporting capabilities per store in the Sales report and PMix report.' Because concepts attach to revenue centers, per-brand output on shared hardware IS documented: 'Set Guest Check Footer Message By Revenue Center' overrides 'the current message that prints in the footer of a guest check for orders that originate from a specific revenue center', and 'Print Revenue Center - Prints the revenue center on the guest check.' The Virtual Kitchen Feature Focus Guide (HKS1718) goes further, printing the concept on the kitchen chit and the bag label, giving each brand its own ordering website, and writing the concept 'to Trans.log as a check attribute' reporting into Gnd.dbf, GndSale.dbf, GndItem.dbf and GndRev.dbf. WHAT ACTUALLY REMAINS UNMET is a per-brand receipt LAYOUT: the guest-check layout is switched by the time-scheduled 'Activate Layout Override' event with no revenue-center scope, so only one header and logo can be live at a store at a time. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/concepts · retrieved 2026-08-10 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

FLIPPED partial -> yes 2026-08-10, and it was a READING gap in the tree the cell already cited: the note said no tax field-definitions page was produced, and there are four (tax_type, tax_group, tax_locale, flex_tax_rule). Maintenance > Taxes > Tax Type documents five tax types, 'up to 999 taxes', exclusive and inclusive methods, and tax tables with breakpoints: 'The Aloha system can meet the needs of virtually any taxing jurisdiction.' Conditional taxation is explicit - 'it is possible to not charge tax on a soft drink when it is ordered individually, but charge tax when the soft drink is ordered with food' - and Flex Tax Rules extend it by category, quantity and check subtotal. Simultaneous rates: 'Secondary Tax represents a jurisdictional tax that works in conjunction with the primary tax. Some establishments must apply two taxes to a sale, such as a state and a city tax.' Per-location is stated twice: Tax Locale says 'taxes typically calculate based on the location of the store' and provides for destination-based rates, and the TS v19.11 Reference Guide's About taxes chapter says a multi-store organization can 'manage different tax rates for each of your restaurants, based on their individual location and tax jurisdiction', with store groups built per state to organise tax jurisdictions. The thinnest conjunct is per-location exemption, met through per-store Store Settings records rather than a dedicated exemption list: Financials carries 'Subtract inclusive taxes when Tax Exempt' and Security carries 'Disable Tax Exempt (TS only)'. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/tax_type · retrieved 2026-08-10 adversarially verified

Supports locations operating in different currencies and languages within one enterprise account, with consolidated reporting converted to a reporting currency.

multi-location-multi-currency-locale

Locations in different currencies within one account are documented on the reporting side: the Consumer Marketing Life Cycle report offers a 'Currency Selector filter to select a currency in which to view metrics if your brand utilizes multiple currencies', and Guest Sales and Segment Comparison filter 'based on the currency type of the location where the transaction occurred. USD is the default unless your brand does not have any USD locations' - so one brand account demonstrably spans multi-currency locations. Language is handled per site (Aloha Takeout localization with a language-culture table, Aloha Kitchen 'Configuring other languages'). Shortfall: consolidation is by filtering, not conversion - the reports show metrics in one selected currency at a time rather than converting all locations into a single reporting currency - and the Aloha POS Foreign Currencies function is per-store tender acceptance with a manually maintained exchange rate, not enterprise reporting-currency conversion. https://docs.ncrvoyix.com/restaurant/consumer-marketing/reporting/life_cycle_report · retrieved 2026-08-08

Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator

multi-location-config-audit-log

A TRAP RECORDED BEFORE A LATER PASS INFLATES THIS CELL. The citation on this claim is ASM’s Activity Log page and the note above never engaged with it, which invites exactly the over-read. Read in full, the ASM Activity Log is genuinely a who-did-what-where-when trail: filterable by Sites, Priority, start and end date, Origin (the module impacted), User, Event Type ("Create, Update, Delete, Login, and Logout") and Entity, with a per-entry detail panel carrying an "Audit logging ID", a "Pub Sub Message ID" and the actual "Payload", and it is organisation-wide, so corporate can query it. BUT IT IS NOT THIS CLAIM. It logs "the usage of the ASM application across your organization", and ASM configures labor and inventory, not price, tax, permission or discount; no export is documented and no immutability is asserted. The ASM log therefore narrows what is missing - a POS configuration change history - rather than supplying it. Partial stands, and what would settle it is still an Aloha Configuration Center or Aloha Manager administration guide, which no corpus we hold contains. CORRECTION 2026-08-09, WRITTEN BECAUSE ONE FACT MUST NOT YIELD TWO ANSWERS: the sentence above says what would settle this "is still an Aloha Configuration Center or Aloha Manager administration guide, which no corpus we hold contains." THAT IS WRONG -- we hold TS1911, the Table Service v19.11 Reference Guide, already cited eight times, whose Chapter 1 is "About CFC". It was read in full while re-scoring the CFC cluster and it does NOT supply a configuration change history: across 1,591,242 characters, "version history" and "who changed" occur zero times, rollback zero, and every one of the 41 "audit" hits is transactional or operational (coupon audit counts, bartender audit chits, the BOH Audit report, the debout.log trail, a "Months to retain audit data" retention field). CFC's "versioning" is variant management across stores, not versions over time. So the corpus gap is CLOSED and the answer came back negative: the classic-Aloha configuration surface documents no config-change trail, and ASM's Activity Log remains the only real who-did-what-when log on this vendor, scoped to labor and inventory. Partial is unchanged and now rests on a read rather than on an unread document. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/reporting/viewing_activity_log · retrieved 2026-08-09

Supports SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. differentiator

multi-location-enterprise-sso

NCR Voyix does document single sign-on for above-store users, but of a different kind than the claim describes: Consumer Marketing's SSO is 'an authentication method that allows users to log in to multiple applications and websites with one set of credentials', combining NCR application logins into one, layered with two-step authentication via the Google Authenticator app or hardware authenticators (Apple Touch ID, Windows Hello, YubiKey USB keys). The Aloha Smart Manager package list states the scope outright: the Base package capability, included with any Aloha Traditional or Aloha Cloud subscription, is 'Platform single Sign-on and User Management' - one sign-on across NCR's own hosted applications. SHORTFALL: this is NCR-side SSO, not federation to the customer's identity provider, and there is no automated deprovisioning. That absence is positively evidenced on two independent surfaces. (1) The ASM with Aloha Essentials User Guides (November 17 2025) enumerate the entire configuration surface - 'The following options are available to you in the Settings function for configuring your business ... Organization settings -- The options available under `Organization settings' are `Sites' and `Fiscal calendar.' Site settings -- The options available under `Site settings' are `Site settings,' `Payroll calendar,' and `Day parts.'' - with no identity-provider, SAML, OIDC or SCIM configuration among them, and the Site Settings screen itself is 'view-only'; users are instead created one at a time in NCR Identity ('select Identity from the list of applications ... Click Users > Create new users'), with a per-application role, location access and a POS device-login PIN, from a fixed predefined role list. (2) The classic above-store product tells the same story: the 292-page Aloha Insight help system at support.alohaenterprise.com returns zero hits for SAML, OIDC, SCIM, LDAP and Active Directory, and its User Account Setup screen enumerates the whole user record - first name, last name, login name, password, security class, language, Crystal and Active Report file types and initial view - with security governed by hand-built Security Classes and no federation, directory sync or automated deprovisioning anywhere in the wizard. https://docs.ncrvoyix.com/restaurant/consumer-marketing/using/single_signon_two_factor_authentication/about_single_signon_two_factor_authentication · retrieved 2026-08-09 adversarially verified

Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator

multi-location-enterprise-api

NCR Voyix Data Sharing is exactly what this claim describes, and it sat unread in two corpora the record already held. It is 'a modern, secure method of sharing NCR Voyix solution data to data warehousing, reporting, or other 3rd party solutions', API-enabled, Parquet-formatted, with 'Versions supported: Aloha POS v19.6, Configuration Center v21.x and above' -- classic Aloha explicitly in scope. Transaction level: 'The Check Summary data set provides a record with key metrics for each check or transaction generated on the POS for the given store and date of business', with StoreId and StoreName columns. Multi-location under one credential: a feed names a site list with an option to auto-include sites added to the organization, reads against a single DevEx account, and is retrieved through Dataset Status and Export Dataset endpoints under HMAC auth -- no per-location credentials. Kept explicit: this is a daily Parquet feed with a seven-day availability window, not a live single call; the claim's own '(or data warehouse/BI export)' is what it satisfies. The Data Sharing UI guide PDF is watermarked DRAFT, so the load-bearing quotes are taken from the DevEx pages instead. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/overview-data-sharing · retrieved 2026-08-09

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

THE PRIOR SHORTFALL WAS FALSE AND THE ASM WEB DOCS REFUTE IT DIRECTLY. The old note ended "no break rule, overtime rule or scheduling rule is authored in Insight and pushed down" - true of Insight, and wrongly generalised to the product. Aloha Smart Manager, whose overview scopes it to "Versions supported: Aloha POS v6.13 and later" with Aloha Cloud POS listed only as a Related product, authors exactly those rules above store. Settings > Labor settings > Labor rules opens on an Overtime tab carrying "Weekly overtime, Daily overtime, Workday definition, and 7th consecutive day overtime", is selected by state and then by county ("If you also need to view the overtime rules for a county, select the Other tab, click the arrow next to the applicable state, and select the county from the list"), and every edit is scoped to a site set and effective-dated: "Verify the affected and excluded sites receiving the change are correct", then "Select the date on which to start the labor rule", after which "The Sites in this jurisdiction table under the labor rule type is updated with the level of enforcement in Configuration, the effective date the law begins, the effective date the law ends, and the reason for the change." A Tips & Wages tab does the same for minimum wage and tip credit, and deactivating or editing a rule requires a digitally signed acknowledgment. The 0.x release notes name the services the rules feed: "To support certain labor rules, you can now add default rule, by location" (CBO-1313), "Added overtime warnings and minor law violation capabilities to the schedule validation service" (CBO-1370), weekly, daily, consecutive-day and "Nevada’s 24-hour overtime" capabilities added to wage calculations (CBO-1558/1560/1561), and missed break penalty payments and split shift premiums (CBO-1342). TERMINAL ENFORCEMENT IS THE CLASSIC ENGINE ALREADY ESTABLISHED ON THIS RECORD: Aloha break rules fire a reminder at clock in, gate the clock out behind manager approval when penalty pay is earned, and enforce minimum break minutes and break start time, while the Alerts feature warns at the POS before overtime begins. TWO LIMITS KEPT IN VIEW, NEITHER OF WHICH DEFEATS THE CLAIM: ASM states its own disclaimer, "Aloha Smart Manager provides the tools to abide by the labor rules; however, it is your responsibility to follow and enforce them", and no document shows an ASM jurisdiction rule pushed down into terminal configuration - the ASM rules drive cloud wage-calculation and schedule-validation services while the terminal gate is configured per store in classic Aloha. Grade B, not A: ASM is a separately licensed, US-only cloud back office, and Every page of the ASM web documentation now carries "WE HAVE MOVED! THIS SITE IS NO LONGER UPDATED. ALL PRODUCT DOCUMENTATION IS NOW IN THE DEVEX KNOWLEDGE HUB", so this is superseded vendor documentation and is cited as such. https://docs.ncrvoyix.com/restaurant/aloha-smart-manager/implementing/working_with_labor_settings · retrieved 2026-08-09 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

Aloha POS is PC software, so commodity hardware is architecturally possible: the docs give 'Operating systems supported: Windows 10, Windows Server' and describe the deployment as 'one order entry terminal per license and one computer functioning as a file server for the network', with extra nodes and remote Aloha Configuration Center PCs permitted outside the licence count. Shortfall: the configuration surface still steers to certified devices. The Terminals function's 'Model' field 'Contains a list of the typical terminals encountered in an Aloha system environment. If the type of terminal you are using does not appear in the list, contact Technical Support for help with selecting an appropriate terminal type from the list' - a closed picklist with a support call as the escape hatch, not free choice. There is no published device specification an operator could buy against: the only hardware-and-software-requirements page in the Aloha tree defers to a non-public guide ('refer to NCR Mobile Pay Hardware and Software Requirements - HKS531'). No iPad or Android tablet is named as an Aloha POS client anywhere in the corpus; the Axium handheld pages belong to Aloha Cloud, a different product family. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/terminals · retrieved 2026-08-09 adversarially verified

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

The client OS is named with a floor version - the Aloha POS documentation card states 'Operating systems supported: Windows 10, Windows Server' - and that is genuine documentation, a structured product-record field rather than marketing copy. Two shortfalls against the claim. First, no device specs are published: the only hardware-and-software-requirements page in the Aloha trees defers to a guide this host does not carry ('refer to NCR Mobile Pay Hardware and Software Requirements - HKS531'), and the Terminals field definitions give a 'Model' picklist without CPU, RAM, display or storage minimums. Second, no other client OS is documented for Aloha POS - there is no iOS, Android, Linux or web client named anywhere in the aloha-pos tree, and the Android handheld pages a reader might cite (Axium setup, Axium modifier panel) sit under aloha-cloud, a different product family on a different codebase. Related products are OS-scoped separately: Aloha Smart Manager is browser-only (Chrome, Edge, Safari, Firefox) and Consumer Marketing lists iOS and Windows. https://docs.ncrvoyix.com/restaurant/aloha-pos/about/overview · retrieved 2026-08-09 adversarially verified

Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.

hardware-handheld-purpose-built

Same Aloha Cloud sourcing problem. The six-inch Axium with integrated EMV/contactless and drop rating is real, but is documented as Aloha Cloud hardware, not as classic Aloha POS hardware. https://docs.ncrvoyix.com/restaurant/aloha-cloud/hardware/setting_up_axium_device · retrieved 2026-08-01 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

Doubly weak: the cited page is Aloha Cloud, and the evidence offered (eight-plus hours per charge, rapid recharge on a base) is battery LIFE, while the sub-feature asks about battery swap — which the note itself admits 'is not claimed'. Long runtime without hot-swap is a partial at best. https://docs.ncrvoyix.com/restaurant/aloha-cloud/hardware/setting_up_axium_device · retrieved 2026-08-01 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

NCR Voyix's own mobile-POS handheld is documented as cellular-capable: 'With the ability to run off Wi-Fi or 4G cellular, the handheld can operate anytime and anywhere. The handheld can support cellular connectivity using a cellular network provider SIM card to process transactions online in real time.' Its key-feature list reads 'Payment anywhere and anytime (4G, 3G, GPRS, Bluetooth, Wi-Fi)'. Partial rather than yes for one reason: that page is filed under the Aloha Cloud topic, and this record's scope rule forbids reading Aloha Cloud documentation as classic Aloha. The same device, the Axium EX8000, is listed under Mobile POS on the company-wide hardware page, but that page names only screen size, battery life and 'tap, dip, and swipe to pay capabilities' and never mentions cellular. No classic Aloha POS document states cellular connectivity or a Wi-Fi failover for a handheld. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/setting-up-axium-device · retrieved 2026-09-10 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

On-prem architecture keeps ordering, kitchen routing and cash going; EDC offline auth covers card capture with a configurable cap. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-01

Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.

hardware-kds

Aloha Kitchen is a first-party KDS with kitchen stations, screens, bump bars and printers configured per site. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/manually_configuring_aloha_kitchen_hardware · 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

UPHELD partial 2026-08-10, grade E -> B, and the prior note's claim that 'all first-party kiosk citations are gone' was false. Kiosk is a configured first-party POS product in three field-definition pages plus both v19.11 Reference Guides. Installed Products carries 'Uses Kiosk - Activates Consumer Self Ordering (Kiosks) so that the user interface displays the applicable menus and options'; Terminals exposes 'Kiosk (QS only) - Indicates this terminal is an interface terminal used by NCR Kiosk and not the Aloha POS' driven by an 'interface employee' that 'works behind the scenes to perform kiosk operations from this terminal'; Order Mode has 'Display on kiosk (QS only)'. The menu-parity test is met: the QS v19.11 Reference Guide says you use Configuration Center to 'build and activate the POS order entry screens that appear on the FOH terminal or self-service kiosk in a store', managed centrally and distributed to stores. SHORTFALLS, measured on the classic POS tree, the DevEx Knowledge Hub and the DevEx API Explorer: no first-party page names the kiosk HARDWARE - 'Aloha Kiosk' and GRUBBRR appear nowhere - so countertop and freestanding form factors rest only on trade press; no integrated-payment statement exists, and CSO2 'injects orders using Aloha Transaction Gateway' rather than tendering in the POS; and the only ADA and WCAG work documented is for the Digital Ordering web cart, not the kiosk. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/installed_products · retrieved 2026-08-10 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

ORDERPOINT plus an OrderPoint Outdoor Display board type; speed of service measured via the Speed of Service report. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/display_boards · retrieved 2026-08-01

Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.

hardware-printer-compatibility

The hedge said no published multi-vendor matrix was found; there are two. The Aloha Solution Enhancement Release Guide carries a table headed 'Printer Name | QR Code Character Limit | Supported Driver' listing Bixolon (Radiant) SRP-S300, SRP-S300 PlusIII and SRP-350 Plus, Epson TM-T88V and TM-T88VI, and Posiflex 8802U+S, with per-vendor driver download links. The DevEx Printers field definitions add the Aloha Takeout label printers -- 'we support the Bixolon SLPD420, the Datamax E4203 (supported for legacy installs only), the Epson TM-L90, and the Zebra LP2044' -- plus a Model drop-down of 'typical printers that work with Aloha' (Epson TM-80, Radiant SRP350, OPOS) and Ethernet support via 'Use native network interface'. Five manufacturers, generic OPOS and Windows drivers, and LAN printing. Two limits kept: the QR table is scoped to QR-code character limits rather than general certification, and Star Micronics -- the claim's own example -- returns zero hits across the 150-document /downloads/ PDF corpus. Aloha Kitchen Ethernet printing is Epson-only. https://docs.ncrvoyix.com/downloads/aloha-pos/AS199_EnhancementReleaseGuide-HKS1713.pdf · retrieved 2026-08-09

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

Cash drawers, customer displays and scales for by-weight quantity pricing are documented; a consolidated compatibility list is not published. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/scales/configuring_item_to_use_quantity_pricing · 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

HEDGE UPHELD ON THE LETTER, WRONG ON THE REASON. 'SAQ' occurs zero times across the 150-document /downloads/ PDF corpus and the Insight, ASM and CFC corpora, and its only DevEx occurrences are a generic card-brand bulletin about PCI SSC's SAQ formats naming no NCR merchant SAQ -- so 'the merchant SAQ type is not named' survives. But this is not a documentation gap: the vendor has affirmatively closed the door, stating in the P2PE feature guide that 'this is not a PCI P2PE validated solution' at both the TSYS and First Data flows. Hardware capture is fully satisfied -- 'Once you implement P2PE functionality, guests and employees can only process credit, debit, and EBT payment cards with the PIN pad device' (Ingenico iPP350 / VeriFone VX820), and 'Cardholder data is never in clear text in the Aloha environment.' Recorded as a judgement call: a stricter reading supports 'no', since two of the claim's three elements are affirmatively disclaimed rather than merely unevidenced; partial is kept because the PTS-device-capture element is fully met. https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_PointtoPointEncryptionFFG-HKS374.pdf · retrieved 2026-08-09

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

NCR Voyix's contactless story is reader-based throughout. The company-wide hardware catalogue describes its Android tablet as having 'Integrated EMV and contactless payments' and its Windows tablets as having 'Built-in NFC for contactless tags and non-payment cards' -- vendor devices with payment hardware in them, not commodity phones. The Ingenico Moby 5500 is offered explicitly as the phone accessory: a clip-on extension 'to snap the device onto any smartphone for mobility'. No commodity-device acceptance is documented: `Tap to Pay on iPhone`, `Tap to Pay on Android`, `SoftPOS` and `tap to phone` occur zero times in the 150 product PDFs, 2,320 developer docs, 1,238 doc pages and 304 marketing pages. https://www.ncrvoyix.com/hardware/payment-devices · retrieved 2026-09-10 adversarially verified

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

hardware-pricing-transparency

Re-cited after /restaurant/hardware collapsed into the /hardware category index. The POS hardware page does now name SKUs - CX5 POS, CX7ii POS, AX5 POS, VX40 and VX80 Modular POS, Axium EX8000 mobile, plus scanner and peripheral models - and publishes no dollar figure against any of them. The page closes with 'Our experts can help you select the right POS hardware... and ensure everything is configured for performance from day one' and a 'Get in touch' button. An enumerated catalogue with zero prices is positive evidence that hardware is quote-only. https://www.ncrvoyix.com/hardware/point-of-sale · retrieved 2026-08-08 adversarially verified

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

NCR Voyix Sales Order Terms and Conditions state that equipment is sold rather than compulsorily leased: "All equipment purchased under this Agreement will be supplied and fulfilled by NCR Voyix or Supplier", and where NCR Voyix acts as sales agent "title and risk of loss to equipment will pass to you from Supplier upon delivery". Rental is a separate, distinct billing category in the same clause ("NCR Voyix will invoice you for equipment, software and supplies on delivery; in advance for recurring services and rental"), and NCR Voyix retains only a purchase money security interest "in each Product until you pay for it". https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

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

The published sales terms settle ownership and are silent on lock-in. Equipment is sold outright, not leased: where NCR Voyix acts as sales agent, 'title and risk of loss to equipment will pass to you from Supplier upon delivery'. The software licence is what ends -- 'On termination, you will immediately stop using the software and either return or destroy all copies' for licensed software, and for subscription services 'Upon termination, you will immediately disable all access to the services and return or destroy all copies of NCR Voyix-provided software used in conjunction with the services.' There is no obligation to return hardware and no reserved right to disable a device. What is missing, and what keeps this off `yes`, is any affirmative statement that the purchased device runs third-party software after cancellation. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-09-10 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

A warranty term is published but no exchange turnaround is. Sales Order Terms and Conditions, section 5: "NCR Voyix warrants on behalf of Supplier that equipment will materially conform to its published documentation and that equipment will be free from material defects in workmanship upon delivery and continue for 90 days (Equipment Warranty Period)"; equipment "may include used or refurbished components, which are warranted to function equivalent to new". SHORTFALL: no replacement or advance-exchange SLA with a stated turnaround is published. The remedy is discretionary - NCR Voyix "will at its discretion correct, repair or replace the non-conformity" within a "reasonable time" - and the closest published turnaround figure anywhere is a per-request "Estimated CE ETA" column in the Operations 360 Field Service Request list, not a committed next-business-day or depot-swap window. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

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

hardware-byod

The vendor's mobile story is a vendor device. The POS hardware page offers 'integrated terminals, handheld devices, or modular systems' and its Mobile POS section lists the Axium EX8000, Windows tablets and a rugged Android tablet -- all NCR Voyix hardware. `BYOD`, `personal device`, `personal phone` and `own device` occur zero times across the 150 product PDFs, the 2,320 developer-portal docs, the 1,238 docs.ncrvoyix.com pages, the 292-page Insight help and all 304 non-Japanese marketing pages. No permission or security model for staff-owned phones is documented, which is what the claim asks for. https://www.ncrvoyix.com/hardware/point-of-sale · retrieved 2026-09-10 adversarially verified

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

Operations 360 Event Management is the estate console. Its Estate Summary Dashboard reports "device performance for devices with a DCS (Digital Connected Services) agent installed", with a Device Connectivity widget (SCO, POS Connectivity), an asset view per store, an HW Inventory view listing "asset name, type, serial number, model, asset, asset manufacturer, address, location", and an SW Inventory view of "Software packages and patches" with OS Inventory and Software Inventory summaries. SHORTFALL: no remote reboot action and no staged or phased update rollout is documented on any Operations 360 page (key-components, standard-views, release notes and the FAQ set cover dashboards and ticketing only); coverage is stated for devices carrying a DCS agent, a separately sold connected service rather than part of the Aloha licence; and printers and KDS units are not named among the asset types. https://docs.ncrvoyix.com/digital-connected-services/o360/faqs/connected-systems · retrieved 2026-08-08

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

Aloha POS carries a first-class Drink Dispensers hardware record (Maintenance > Hardware > Drink Dispensers). The docs state "Drink dispensers make it possible to more accurately account for every liquor drink poured. This eliminates the potential for employees to over pour or forget to ring up a drink", and that "any drink dispenser ID (or PLU, as some companies may call them) must match an Item ID in the Aloha system", failing which the POS raises "Item #### not found in database. Notify Manager" - that is, the pour drives an item ring on the check. The supported-device table names the Berg Liquor System and the EasyBar Liquor System with their serial parameters (baud, parity, data bits, stop bits, cable), each bound to a named Terminal and Port. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/drink_dispensers · retrieved 2026-08-08

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

Aloha Takeout supports caller ID lookup that surfaces the customer record and order history on an inbound call. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO201_ReferenceGuide-HKS1661.pdf · retrieved 2026-08-01

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

extensibility-public-api-docs

UPHELD yes 2026-08-10, and now measured rather than impressionistic. The 2026-08-01 note said the API Explorer is 'a JS SPA and poorly crawlable' -- true of the HTML, false of the site. POST /api/search is anonymous, needs no key or cookie, and enumerates the whole corpus: HelpCenter 1,941, ProductHowTo 379, SwaggerOperation 3,122, ProxyHowTo 0, total 5,442 documents spanning 64 API products and 3,122 operation rows, which resolve to 3,101 distinct product+method+path operations (2,739 distinct method+path, since paths repeat across products). What is published per product is not a teaser but a reference: operation summaries with methods and paths, required-role tables (for example Order Monitor's ten ORDER_MONITOR_* roles), error-code tables, and worked request/response examples. No NDA, partner agreement or sales call gates any of it, and robots.txt for developer.ncrvoyix.com, read whole and cached at .cache/ncr-dev_robots.txt, disallows nothing under /api/ or /portals/. DISTINGUISH THIS FROM CREDENTIALS, WHICH ARE GATED AND ARE SCORED SEPARATELY AT reporting-public-api: reading the reference is open; obtaining production keys 'still requires reaching out to your NCR Account Representative'. The claim is about documentation, and the documentation is open. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer · retrieved 2026-08-10

API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator

extensibility-api-access-cost

UPHELD partial 2026-08-10, and the single-surface flag is CLEARED: the licence asymmetry is stated in identical words on three surfaces - the Aloha QS v19.11 and TS v19.11 Reference Guides (Ch. 4, Terminals, Function drop-down) and the DevEx Knowledge Hub field definitions. Enabling the interface costs nothing: 'In POS v12.3, or later, Aloha Connect is automatically enabled', and 'Enable FOH COM Interface' is a plain configuration checkbox. Using it from a third party consumes a licensed seat at each site: 'Interface terminal - Designates the defined terminal as an interface terminal. The interface terminal enables applications to communicate through Aloha Connect. The license agreement for the restaurant must include a specific number of order-entry terminals.' The exempt siblings are the asymmetry: 'Radiant interface terminal - ... does not require a terminal license, as it does not increase the count of interface or order entry terminals at the store, and it must be initialized through an Aloha application', and 'Interface server ... the terminal performs FOH functions without the need for an order entry terminal license.' Named shortfall: third-party API access is metered against the restaurant's per-location terminal licence while first-party NCR devices are exempt, and cloud production access additionally requires Marketplace eligibility through an NCR account representative plus a separate 'Sign up for Menu and Ordering platform capabilities' entitlement. No fee amount is published on any host, so the finding is the per-location licence requirement, not a quantified surcharge. https://docs.ncrvoyix.com/downloads/aloha-pos/QS1911_ReferenceGuide-HKS1779.pdf · retrieved 2026-08-10 adversarially verified

The vendor publishes its partner/marketplace commercial terms (referral fee, revenue share percentage, or per-location partner fee) in public documentation.

extensibility-partner-revshare

NCR Voyix publishes its partner program in some detail -- two named tracks, technology partners and reseller partners, with reseller benefits enumerated as 'Deal registration and partner validation', 'Marketing development funds', 'Sales, pre-sales and service enablement' and 'Tiered recognition' -- and publishes none of its commercial terms. `revenue share`, `rev share`, `referral fee`, `per-location fee` and `partner fee` occur zero times across all 304 non-Japanese www.ncrvoyix.com pages, the 2,320 developer-portal docs and the 150 product PDFs. The seven `commission` matches on the marketing site were each read: five are the vendor arguing that first-party ordering avoids third-party marketplace commissions and two are SEC boilerplate. The reseller application page is a form with no rate card. https://www.ncrvoyix.com/about/become-a-partner · retrieved 2026-09-10 adversarially verified

A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator

extensibility-free-sandbox

The hedge ('whether it is free without a paid production account is not stated') is answered on the DevEx surface the cell already cited. 'Getting Started with NCR APIs' documents an API Test Drive: 'Begin Test Drive to download a Postman collection with credentials that will remain active for 90 days', gated only by 'You must be signed in to Developer Experience and have confirmed your email address'. The environment is seeded -- the BSL Sandbox collection ships Order, TDM, Catalog, Sites and CDM folders and a Create Site call that populates the BSL Environment -- and 'Basic Authentication can be used for sandbox environments.' No contract, purchase or production account is named as a prerequisite. Two qualifiers kept: NCR never uses the word 'free', and Test Drive is described as 'a trial feature' whose credentials expire after 90 days, though they may be regenerated. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/getting-started-with-ncr-apis · retrieved 2026-08-09

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

VERDICT UPHELD AND STRENGTHENED. The NCR platform 'currently supports three types of authentication schemes/methods: HTTP Basic ... Access Key ... Access Token', with Basic flagged as one that 'should NOT be used for production' and access key authentication 'preferred' for system-to-system. The only oauth2 endpoint in the entire 1,941-document DevEx dump is shared-key client credentials, not a user grant: partners 'must authenticate at /access-key-authentication/oauth2/token using shared key as `client_id' and secret key as `client_secret' to receive a longer-lived token.' The other OAuth mentions are outbound -- Facebook login redirects, and the operator authenticating TO DoorDash -- which is the reverse direction from this claim. Two corrections in both directions: keys ARE individually revocable ('Access key pairs can also be deactivated by selecting the trashcan icon'), but generating a new pair does not invalidate the old ('Whenever a new pair of keys are generated, any previous keys for the user will still be valid'). One limit: the key-generation and revocation screens are documented on a Digital Banking customer-admin page, so that UI may not be the restaurant path. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/hmac-authentication · retrieved 2026-08-09

The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.

extensibility-webhooks-push

UPHELD partial 2026-08-10, AND THE PRIOR NOTE'S OWN INSTRUCTION IS DISCHARGED: it said 'Do not harden this into a negative until that tier is fetched', and the tier is fetched. THE ABSENCE IT WORRIED ABOUT WAS WRONG IN BOTH HALVES -- a named order-lifecycle catalogue exists, and classic Aloha has a real-time feed. ON THE BOX: events stream over Kafka from the back office -- 'Kafka server address : Refers to BOH IP address', 'Kafka port no. : 9092', 'Topic name : RESTAURANTEVENTS', consumed under the role 'IS_RESTAURANTEVENTS_CONSUMER', with 'Kafka Tester is a verification tool that runs locally at the site to verify that events triggered from Aloha POS are received by the consumer.' ABOVE STORE: Order (374) publishes a true HTTP webhook -- POST /order/v3/orders/subscriptions taking a 'destinationUrl', delivering ORDER_CHANGE messages whose attributes include from-status, to-status, enterprise-unit-id, channel and fulfillment-type, and whose payload carries 'currentOrder' and 'updatedOrder' full order objects. THE CATALOGUE, QUOTED IN FULL BECAUSE THE CLAIM NAMES SPECIFIC EVENTS: 'Full list of Order statuses to filter messages on: ORDER_PLACED, READY_FOR_PICKUP, FINISHED, CANCELED, ERROR, IN_PROGRESS, RECEIVED_FOR_FULFILLMENT, REJECTED_FOR_FULFILLMENT, IN_FULFILLMENT, IN_TRANSIT, ABANDONED, EXPIRED, VALIDATED, READY_FOR_VALIDATION, ORDER_UPDATED.' The InStore Order API adds an ORDERCHANGE topic with 'IS_ORDERCHANGE_CONSUMER' and 'NOTIFICATION_SUBSCRIBER -- Allows subscribing to web-socket to get real-time notifications', and Menu subscriptions deliver 'to a menu topic for an endpoint defined as an arbitrary URL'. WHAT STILL FAILS: created and modified are covered (ORDER_PLACED, ORDER_UPDATED) and cancellation is covered, but PAID, VOIDED and REFUNDED appear nowhere as event types in the 15-status list. Push is real and polling is not required; the catalogue is fulfillment-shaped, not financial. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/374 · retrieved 2026-08-10

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

RESOLVED unknown -> no 2026-08-10 against the API Explorer tier, which the prior note correctly identified as the place the event contract would sit and which is now readable through POST /api/search. THE DELIVERY CONTRACT IS DOCUMENTED AND IT IS UNSIGNED. Every subscription model in the tier authenticates the callback with credentials the subscriber supplies, never a signature over the payload: Site publishes the field as 'authenticationType | Indicates the type of credentials required | Enum with allowed values BASIC', and NONE and PLATFORM are the only other values observed across Order, TDM, Fulfillment Time, CDM and Digital Receipts. Zero hits for signature, signing, HMAC, verification and redelivery in any outbound-event document across 379 ProductHowTo and 3,122 SwaggerOperation rows with the control passing; the sole HMAC is INBOUND request auth on the Data Sharing API, the reverse direction, exactly as the prior rationale predicted. Retry is a knob without a policy - a retryQueue field on the subscription payload and PUT /messaging/subscriptions/{id}/retry-queue in Labor Data Management 2 - and no backoff is published for webhook delivery; the tier's two backoff mentions are HR-API client guidance and Order Monitor's synthetic-order site-health probing, which must not be read as redelivery backoff. Recovery exists by RECONCILIATION rather than replay: GET /orders/find-unacknowledged with POST /orders/{id}/acks, and for in-store events a Kafka consumer can reset to the earliest offset. Unsigned, so no. Recorded because it corrects a related belief: the classic-Aloha real-time feed is not a webhook at all - InStore Events Subscription (1855, requiring 'Aloha Point of Sale (POS) | 19.9.5 or above') publishes Kafka topic RESTAURANTEVENTS on the BOH at port 9092, corroborated in a first-party classic PDF: 'Now with the integration of Kafka into ATG, consumers can receive events by connecting to the Kafka Broker.' https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/645 · retrieved 2026-08-10 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

RESOLVED partial -> yes 2026-08-10, AND BOTH GROUNDS OF THE 2026-08-01 NOTE WERE FALSE. It said API Explorer detail pages 'return only the title ... to any fetch' -- the tier reads anonymously through POST /api/search, and its 379 ProductHowTo bodies are now dumped locally by workflows/ncr-devex-search-dump.mjs --dump-howtos. It also said 'nothing establishes that they inject orders into a classic on-prem Aloha POS store'; measured, the opposite holds -- across the InStore Order API's five how-tos 'Aloha' occurs 26 times and 'Aloha Cloud' ZERO, the same both-sides discriminator that reclassified aloha-order-direct. THE ENDPOINT IS 'POST: /AlohaAccess/{handlerId}/Order -- This endpoint can be utilized to inject an order into POS via various ordermodes. The response will return the details of order placed', with 'POST: /AlohaAccess/{handlerId}/Order/{alohaCheckId}/OrderLine -- This endpoint can be utilized to add an orderline to an open check' and a DELETE twin. It is on-prem classic by construction: services are discovered by UDP multicast carrying the 'Server address (BOH IP address)', verified with ATGConnectTester found in 'Bootdrv> ATG> Tools', and the key is 'the actual Aloha check id'. FIRST-CLASS TICKET IS DOCUMENTED, NOT INFERRED: HealthCheck verifies 'Master Interface terminal, Interface terminal, Prepaid tender, Interface employee' plus an 'Interface job code' carrying OrderEntryChecked, InterfaceChecked, BartenderChecked, CashierChecked and OrdertakerChecked -- a real Aloha order-entry terminal -- and the POS itself signs off, 'Validated | The order has been successfully validated by the POS at the site.' Printers are in-tier (PrintCheck, PrintXMLStream). TWO CONJUNCTS RESTING ON WEAKER EVIDENCE, RECORDED AS SUCH RATHER THAN GLOSSED: reporting is documented only obliquely, by the classic guides making Aloha Connect activity reportable BY DEFAULT since suppression needs an explicit flag -- 'Do Not Report -- Indicates this void reason does not appear on the BOH Audit report'; and KDS has no in-tier statement, the nearest being 'Aloha Kitchen uses Aloha Connect to establish communication between the Aloha POS system and Aloha Kitchen.' https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/1936 · retrieved 2026-08-10 adversarially verified

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

extensibility-menu-write-api

UPHELD partial 2026-08-10 -- the verdict is unchanged and its entire basis is replaced. The 2026-08-01 note rested on 'the cited API Explorer URL is a JavaScript SPA returning no fetchable content', which is false; the tier reads through POST /api/search. Measured there, THE ALOHA-SCOPED MENU API IS READ-ONLY. Menu (productId 1750) publishes exactly five operations and none writes menu content: GET /v2/menus, GET /v2/menu-details/{menuId}, and POST/GET/DELETE on /v2/subscriptions. Its own overview says so -- it 'exposes a set of public APIs that allow consumer and associated touch points to access menus for a site', supporting 'Retrieving a list of menus per site / organization' and 'Retrieving a detailed menu per site / organization' -- and it is the Aloha-facing one, naming 'Menu Maker / Aloha Menu Manager' and 'Aloha Online'. Menu v1 (1773) is GET-only as well. WRITES DO EXIST ONE LAYER DOWN, in Catalog (productId 453), and they cover exactly the claim's three objects: PUT /items and PUT /items/{itemCode}, PUT /item-prices and PUT /item-prices/{itemCode}/{priceCode}, PUT /item-custom-modifiers, plus PUT /link-groups and PUT /category-nodes. WHAT KEEPS THIS OFF yes IS SCOPE, NOT CAPABILITY, and it is stated as a measured gap rather than a denial: Catalog names Aloha zero times and describes itself as 'a cloud-based repository through which customers and upstream integrating systems can store product data' usable 'across multiple industries'. Nothing in the tier establishes that a classic Aloha site's menu is authored through it. Classic menu authoring is documented instead in Aloha Menu and Configuration Center -- see multi-location-central-menu-publish -- which is a UI, not an API. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/1750 · retrieved 2026-08-10 adversarially verified

Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator

extensibility-data-symmetry

RETRIEVED 2026-08-10; the scope caveat is discharged and partial now stands on inventory alone rather than on an unread surface. The API Explorer reads through POST /api/search (request field 'searchString'), and it holds 379 ProductHowTo plus 3,122 SwaggerOperation documents that the 1,941-document help-center dump never contained - Labor Data Management 2, Order, Item Availability and the HR Integration APIs appear in that dump zero times, so the prior note's 'structurally excludes this surface' premise was exactly right. THE EMPLOYEES HALF IS SETTLED AND IT IS A WRITE API. Labor Data Management 2 (productId 751) is documented 'compatible with Aloha and Silver', its operations read 'Creates a new employee shift. In Aloha this is represented by ClockIn clock punch', and it exposes PUT /configuration for 'Employee Configuration Data: Employee definitions, including roles and wage rates' beside POST, PUT and DELETE on shifts, breaks, other wages and schedules, under roles LABOR_DATA_MANAGEMENT_SHIFT_WRITER, _SCHEDULE_WRITER and _ABOVE_STORE_WRITER. The Users and Employees HR Integration API adds POST /users and POST /users/bulk. INVENTORY DOES NOT FOLLOW, and it fails on positive evidence rather than silence: zero hits across both tiers, control passing, for stock-on-hand, onhand, theoretical, ingredient, depletion and inventories, and Item Availability (443) is 86'ing - PUT /item-availability/{itemCode} flags an item unsellable, not a quantity. Real inventory is Aloha Smart Manager Advanced Inventory, an application with release notes through v1.31 and no published API. Orders, menu and customers all have writes. CORPUS LIMIT, stated because it decides what a negative means: this tier is searchable, not bulk-readable, so a negative is 'no hit for these single-word terms across 379 ProductHowTo and 3,122 SwaggerOperation rows with the order control passing'. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/751 · retrieved 2026-08-10 adversarially verified

API rate limits are published as specific numeric quotas with documented throttling behavior and headers.

extensibility-published-rate-limits

RESOLVED unknown -> partial 2026-08-10, because the surface the prior note named as unreachable is now readable. It said the per-API reference that would publish quotas and 429 headers 'is the API Explorer on developer.ncrvoyix.com, which serves a universal 61,078-byte Angular shell'. Reading it through POST /api/search finds exactly one numeric quota: 'Rate limiting: The published endpoint family must preserve the same quota posture as the internal HR integration baseline: 6000 requests per minute at organization scope' (Users and Employees HR Integration API, productId 2040). The same product documents throttling behaviour: '429: The organization has exceeded the allowed request rate', and 'Retry with backoff for transient conditions, including 429 Too Many Requests. Do not immediately replay high-volume requests; apply exponential backoff and controlled concurrency.' TWO THINGS KEEP IT OFF yes. Headers are absent - no endpoint in the tier publishes a rate-limit response header, and the apparent X-RateLimit and Retry-After counts are an artefact of the search splitting hyphens and OR-ing the parts: no returned snippet contains either string. And that quota belongs to a product whose own overview reads 'Visibility: NCR (internal review) Initial rollout: dev, staging', with examples against gateway-dev-x.ncrcloud.com. It is not a contract for the 3,101 operations across 64 products, none of which carries a quota; throttle, throttling, quotas and ratelimit return zero across both tiers with the order control passing. Elsewhere 429 is only a status-table row (Digital Coupons '429 | Rate limit reached', Banking Activity API '429 | Too many requests'). https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/2040 · retrieved 2026-08-10 adversarially verified

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

The claim requires all three marketplaces without a paid middleware layer; only DoorDash is evidenced. NCR's release: 'announced an agreement with DoorDash ... for the planned integration of the DoorDash marketplace to the NCR Aloha Platform-of-Sale (POS)', with DoorDash leveraging 'NCR's API ecosystem'. So the connector is written by the marketplace against Aloha's partner API, not published by NCR as a certified first-party connector, and Uber Eats and Grubhub have no equivalent first-party statement at all. No docs.ncrvoyix.com page in the 2,311-URL sitemap names any delivery marketplace. Deliverect ('NCR Voyix Aloha (BSL): Integration Overview') and Chowly both sell paid Aloha connectors for the full marketplace set. Prior citation withdrawn: hard 404 on 2026-08-09. https://investor.ncrvoyix.com/news-releases/news-release-details/ncr-and-doordash-join-forces-simplify-end-end-dining-experience · retrieved 2026-08-09 adversarially verified

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

extensibility-middleware-compatibility

Three aggregation platforms document classic Aloha as a supported endpoint. Otter publishes an integration guide for 'Aloha BSL POS' - 'A POS integration is when you connect your online channels and delivery platforms with your Aloha BSL POS, via Otter' - including menu synchronisation from the POS to the delivery channels. Chowly's NCR integration page states it 'transmits online delivery orders from third-party marketplaces... and injects them directly into your NCR Aloha POS System'. Checkmate's support site carries live-order troubleshooting for Aloha BSP order IDs, which presupposes a production Aloha connector. Note the Deliverect citation this replaces now covers Aloha Cloud only, a different codebase from the product this record scores. A FOURTH platform, and the strongest of the four because it is first-party middleware documentation naming a CLASSIC-ONLY module: Deliverect publishes a four-article NCR Voyix Aloha (BSL) collection dated 29 April 2026 — "Deliverect has partnered with NCR Voyix Aloha to provide a reliable two-way integration" — and it scopes itself to classic explicitly: "The integration supports NCR Voyix's Advanced Pizza features... Add recipe items and toppings / Use modifier codes for items / Configure half pizzas." Advanced Pizza is a classic Aloha POS module, not an Aloha Cloud one. See https://help.deliverect.com/en/articles/14107848-ncr-voyix-aloha-bsl-integration-overview. The Otter URL is retained as the citation and was re-verified live on 2026-08-09 (200, 108,091 bytes, correct title) against a fabricated control — an earlier retrieval note claiming Otter 403s us is not true today. https://helpdesk.tryotter.com/hc/en-us/articles/32868613493139-Otter-NCR-Aloha-BSL-Integration-Guide · retrieved 2026-08-09 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

Aloha Insight ships vendor-built general-ledger export layouts, offered in the custom report settings list alongside its ordinary report layouts: 'Lawson GL Export', 'Mas 90', 'Peachtree GL' and 'QuickBooks GL'. The same page documents the delivery format -- a delimited file whose extension the operator chooses, noting that 'QuickBooks(R) uses the .iif format.' That is four accounting systems with vendor-maintained mappings, which is why this is not a `no`. It is not a `yes` because these are file exports rather than live connectors, .iif is a QuickBooks Desktop format and QuickBooks Online is never named; the only QuickBooks Online path NCR documents is Shogo, a third party, whose page is filed under Aloha Cloud. Shogo does appear on the classic-tier Above Store Marketplace enrollment list, which requires 'Configuration Center (CFC) Version 20 or Higher'. https://support.alohaenterprise.com/wwapp/en_US/helpdata/Reports/RB_CustomRptSettings.html · retrieved 2026-09-10 adversarially verified

Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.

extensibility-payroll-export

Aloha POS ships native electronic payroll exports to named third-party processors, configured under Maintenance > Store Settings, 'Group bar: Exports > Electronic payroll' in the Aloha Table Service v19.11 Reference Guide: 'Use ADP -- Specifies ADP as the active third-party payroll processor' with ADP Company #, ADP Store #, ADP Version #, 'Output cash tips' and 'Include SSN in ADP export'; 'Use Paychex -- Specifies Paychex as the active third-party payroll processor', whose export 'lists each job an employee works in a specified pay period... The export file displays as a comma-delimited text file', with Paychex branch #, client # and site code; plus 'Use PayUSA' and 'Use Real World payroll'. Job code settings feed these files directly ('Do not print or export' suppresses an employee from 'ADP export file, Coconut Code export file, Real World Payroll export file'), and the employee record carries an 'Export ID -- Specifies the employee identification number that is recognized by third-party software for electronic payroll processing. For example, enter the employee ADP number for an ADP interface.' Four named providers, no re-keying. Aloha Smart Manager separately offers only a provider-agnostic 'Generic payroll export' CSV. https://docs.ncrvoyix.com/downloads/aloha-pos/TS1911_ReferenceGuide-HKS1780.pdf · retrieved 2026-08-09 adversarially verified

Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator

extensibility-bi-data-warehouse

NCR Voyix Data Sharing is a scheduled machine-readable feed rather than a reporting UI: "Daily Data Delivery", "Cloud Storage Access", Parquet file format, generation triggered by a site end-of-day, and an accompanying API so integrators can "automate the process of retrieving and loading data into your data warehouse". Granularity is transaction level - the Check Summary data set "provides a record with key metrics for each check or transaction generated on the POS for the given store and date of business", with TransactionNumber, EmployeeId, CheckCloseTime, RevenueCenter and NetSales columns. Customers self-configure feeds (sites, data sets, consuming DevEx service account) in the Data Sharing web app. THREE FIGURES IN THE PRIOR SHORTFALL WERE STALE, AND THE VENDOR'S OWN RELEASE NOTES ARE WHAT SUPERSEDE THEM - the concept page introducing_data_sharing has not been updated to match, so the two first-party pages disagree and THE RELEASE NOTES ARE THE LATER DOCUMENT. Retention is no longer seven days: 'Increasing data set storage period: The Data Sharing exports are now stored for 30 days instead of seven days. (DATA-478)', Version 1.18, January 12 2026, with a v1.19 shipped after it on March 24 2026; the concept page still reads 'Data is maintained in cloud storage for seven days from time of generation'. The catalogue is no longer nine data sets: v1.15 adds Tax Summary (DATA-342) and v1.17 adds a Labor Shift data set (DATA-449), neither named on the concept page. And a push channel now exists for FEED EVENTS: 'Customers can now subscribe to a webhook to receive notifications for events related to their data feeds. (DATA-440)', v1.15. SHORTFALL, RESTATED ON CURRENT FACTS: DATA delivery is still pull-only from NCR-hosted cloud storage via signed URLs with a one-hour TTL - the DATA-440 webhook notifies about a feed, it does not carry the payload - and there is still no push to a customer-controlled S3 bucket, SFTP endpoint or Snowflake share, and the data sets remain a fixed vendor-defined catalogue of summarised and item-level extracts rather than the raw transaction log. SCOPING NOTE so the Labor Shift addition is not over-read for classic: DATA-449 scopes it 'For organizations using both Aloha Cloud and Aloha Smart Manager'. https://docs.ncrvoyix.com/restaurant/data-sharing/using/introducing_data_sharing · retrieved 2026-08-10

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

extensibility-app-marketplace

NCR Voyix operates a public marketplace at www.ncrvoyix.com/partners/marketplace - "Extend your capabilities with integrations designed to work seamlessly with our platform" - listing 42 named partners browsable by integration type (Online Delivery, HR, Inventory, Loyalty, Menu Design, Labor Mgt, Accounting, Analytics, Social Media, Payments, Scheduling, Reservations, Online Ordering), among them Crunchtime, Tillster, OpenTable, 7shifts, Chowly, Deliverect, Thanx, DoorDash, Acrelec, Fingermark, WAND Digital and Sparkfly. SHORTFALL: it is a directory, not a self-install channel - every listing terminates in a "Visit website" link out to the partner with no in-product install, enable or provisioning flow - and the corresponding in-POS plumbing (Maintenance > System Settings > Integrations) is an implementer-configured connection profile requiring a nominated interface server terminal and interface terminal. https://www.ncrvoyix.com/partners/marketplace · retrieved 2026-08-08

Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.

extensibility-custom-fields-scripting

Classic Aloha exposes operator-configurable code hooks that require no vendor engineering engagement, but not the ones this claim describes. Store > Store Settings tab > System group, End Of Day group bar, documents 'Name of batch file to run following EOD -- Contains the name of a custom batch file to launch following the EOD process. Custom batch files allow you to automate certain routines originating outside the Aloha POS system that address Aloha data files, such as compressing or zipping data files, and copying them to another drive', and 'FOHHOOK.BAT timeout in seconds -- Instructs the master terminal how long to wait (in seconds) after executing FOHHook.bat so the batch has time to complete before the terminals reboot ... Set this option to zero (0) to disable FOHHook.bat.' The Store Settings Delivery group adds 'Allow user to launch external application -- Enables the Aloha system to launch a third-party program, such as opening an external accounting program.' SHORTFALL: these are local Windows batch files, running on the store's own file server, fired once at end of day against exported Aloha data files -- they are not vendor-hosted, not event-driven, and do not operate on POS objects. No operator-defined custom field on an item, check or employee exists anywhere in the aloha-pos field-definitions set, the customization topics (custom FOH reports, Checkout.cfg, screen and print designers) restructure presentation over a fixed schema, and the one extension point that does touch POS objects, the Integrations record's 'Additional POS Parameters', is documented as 'Work with your Client Services Manager to define any additional parameters' -- explicitly a vendor engagement. Whether the DevEx platform offers a hosted functions runtime could not be checked: that content is behind login. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/store_settings_system_group · retrieved 2026-08-09

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

RESOLVED partial -> yes 2026-08-10. The whole prior note was one sentence -- 'BSP order and menu services underpin kiosk and digital ordering, implying an embeddable engine, but no documented headless mode' -- written when the API Explorer was believed unfetchable. It is readable through POST /api/search, and the InStore Order API (productId 1936) IS that mode for classic Aloha: an external client drives a real terminal end to end. 'POST: /AlohaAccess/{handlerId}/Login -- Use this to login an employee into the terminal', 'POST: /AlohaAccess/{handlerId}/ClockIn -- Use this to Clockin an employee', 'POST: /AlohaAccess/{handlerId}/Order' to inject the order, 'POST: /AlohaAccess/{handlerId}/Order/{alohaCheckId}/OrderLine' and its DELETE twin to edit an open check, 'POST: /AlohaAccess/{handlerId}/PrintCheck', QueryObject and QueryCollection for state, 'GET: /AlohaAccess/{handlerId}/StoreInfo', and Logout. THAT THIS IS A THIRD-PARTY SURFACE IS PUBLISHED AS ITS OWN ROW, not inferred: 'For Client, to inject orders via ATG InStore API | IS_ORDER_EDITOR | Allows to access InStore API Endpoints to Create/Edit Order'. Scoping measured both ways: 26 'Aloha' and ZERO 'Aloha Cloud' across its how-tos, with discovery against the 'Server address (BOH IP address)'. LIMIT RECORDED SO THIS IS NOT LATER OVERREAD: there is no tender or payment operation in this API -- the client builds and prints the check, and classic Aloha tenders it ('touch Apply Payment to use Aloha Connect to tender the order'). The claim asks for a third-party UI driving the transaction engine, which is met; it does not ask for payment capture. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/1936 · retrieved 2026-08-10

The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.

extensibility-api-versioning-deprecation

RESOLVED unknown -> partial 2026-08-10, AND THE PRIOR RATIONALE'S SHORTFALL WAS MEASURED ON A TIER THAT STRUCTURALLY EXCLUDED THE ANSWER. It said 'there is no API changelog anywhere in the 1,429 classic-topic articles' -- true of the HelpCenter tier, which is the only tier it could read. The ProductHowTo tier (379 docs) now dumps whole, and TWELVE of its products publish a per-product release-notes document: Order, Fulfillment Time, Transaction Document Management, Delivery, Order History, Digital Receipts, Digital Coupons, Tax Categories, Consumer Data Management, Schedule Definition, Promotion Execution, Order Monitor. THE CHANGELOG CONJUNCT IS MET. Order Service publishes 'Order Release Notes' as dated, semantically versioned entries running from 'August 31, 2022 | Here's what's new in Version 3.21.0' to 'September 19, 2024 | Here's what's new in Version 3.34.0', each naming the specific field or behaviour added -- e.g. 3.34.0 'New field added to define the item or items total after any promotional discounts are applied. The new field is called totalAfterPromotion in the promotions object', 3.29.0 adding Rejected/InFulfillment/InFulfillmentQueue/ValidatingFulfillment fulfillment results plus an Employee ID 'to identify the employee making updates to each item on the order'. Breaking changes are called out by name and given their own document: 'NOTE: The behavior of patch has changed in Order Service 3.0. See Potential Breaking Changes in Order Service 3.0'. Menu (1750) documents a version migration in the same voice -- 'customFields in V1 are to be replaced by tags in V2. Please note that the data type changed from key value pair to a string' -- selected by a nep-service-version header. Deprecation is also marked at the operation level in the OpenAPI summaries: 41 of the 3,122 published operations carry it, in the actionable form 'This endpoint is about to be deprecated, please use the new endpoint in selling-receipt-formatting of /emerald/selling-service/receipt-formatting/v1/receipt-settings/endorsement'. WHAT STILL BLOCKS A yes IS THE SECOND CONJUNCT, AND THE REASON IS SCOPE, NOT ABSENCE. The portal does publish a stated notice period -- 'Deprecation policy: If a new major version of API is published the previous versions will be supported on new versions of POS for the next 12 months. After that period of time the API version will not be supported anymore and is subject to removal' -- but it belongs to Aloha Cloud - In-Store API (productId 2021), which this record must not read as classic Aloha, and the document says so itself in its own vocabulary: 'Device: Physical point of sale terminal or handheld running Aloha Cloud POS application on site', 'ACBO: Aloha Cloud Back Office', 'introduced in Aloha Cloud In-Store API v6.16.0.X'. Measured both ways, that product is 22 'Aloha Cloud' against 10 bare Aloha. No classic-facing product -- InStore Order API (26 Aloha / 0 Aloha Cloud), InStore Events Subscription (15/0), Site (15/0), Menu (5/0), Order (1/0) -- states any notice period, advance-warning commitment or support window for a breaking change. A dated changelog without a notice policy is exactly partial. https://developer.ncrvoyix.com/portals/dev-portal/api-explorer/details/374 · retrieved 2026-08-10

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

A machine-readable export path exists but is not an exit artefact. Data Sharing delivers transaction-level data sets in Parquet on a daily end-of-day trigger to a customer-nominated DevEx service account, covering check summary, item sales, item discounts, item voids, comp summary, promotion summary, sales totals, taxes and tenders, with Tax Summary (DATA-342) and a Labor Shift data set (DATA-449, scoped to 'organizations using both Aloha Cloud and Aloha Smart Manager') added since. SHORTFALL, AND THE RETENTION FIGURE IS CORRECTED RATHER THAN DROPPED BECAUSE IT WAS QUOTED FROM A PAGE THE VENDOR HAS SUPERSEDED WITHOUT EDITING: it is a rolling feed rather than a historical dump. The concept page introducing_data_sharing still reads 'Data is maintained in cloud storage for seven days from time of generation', but the Data Sharing release notes v1.18 (January 12, 2026) state 'The Data Sharing exports are now stored for 30 days instead of seven days. (DATA-478)'. THE VERDICT IS UNAFFECTED AND THAT IS THE POINT OF RECORDING IT - a rolling 30-day window is still a rolling window, access is still by signed URL with a one-hour TTL, so it still cannot produce complete history on demand, and the data sets are summarised rather than a full order, customer, menu and payment-metadata dump. The NCR Voyix Sales Order Terms and Conditions termination clause imposes obligations only on the customer ("you will immediately disable all access to the services and return or destroy all copies of NCR Voyix-provided software") and gives NCR Voyix no obligation to provide a data export at contract end. https://docs.ncrvoyix.com/restaurant/data-sharing/using/introducing_data_sharing · retrieved 2026-08-10

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

reliability-offline-order-entry

Classic Aloha is a LAN system, so order entry never depends on a WAN link, and the vendor documents fault tolerance one level deeper than that. Store Settings > System > 'Group bar: Redundancy' defines 'Terminal automatically becomes fileserver in redundancy -- Designates the selected terminal will take over as the file server in situations where the file server goes down unexpectedly. This process of redundancy helps to keep a restaurant functioning even when the BOH file server goes down', with 'Show redundant mode indicator -- Displays a red outline on the FOH Log in screen'. The Table Service v19.11 Reference Guide glossary: 'Redundancy architecture is designed to retain maximum system functionality in the event of common hardware failures. There are three types of failures: BOH file server down, master terminal down, and complete network failure (hub failure). Redundancy provides a system of fault tolerance that allows the restaurant to continue functioning regardless of the type of failure experienced.' Card authorisation degrades separately - the guide describes 'mock' authorisations queued in the terminal's local \EDC directory until the EDC file server returns. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/store_settings_system_group · retrieved 2026-08-09 adversarially verified

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

reliability-offline-card-auth

Upheld, and on a better source than the researcher used (the cited EDC PDF is a 1.8MB binary that does not render). The Aloha POS store-settings field definitions page documents 'Allow authorizations when EDC is offline' and 'Maximum authorization amount' — 'the ceiling limit to authorize when credit card server is down' — with the transaction spooled to an .spl file on the master terminal and replayed on reconnect. Important qualification the dossier soft-pedals: the doc calls these 'mock authorizations', i.e. no issuer decision is obtained, which makes the decline-liability partial score cor https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/store_settings_credit_card_group · retrieved 2026-08-01 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

HEDGE UPHELD, first clause understated. The Store and Forward FFG -- a second surface this cell never read -- documents TWO caps, not one: 'Type the dollar amount above which the system will not `store and forward' the transaction, in `Floor for transaction amount.' If EDC does not receive an authorization before the allotted time frame for a transaction greater than this amount, the system declines the transaction', and 'Type the highest number of transactions, per processor, to allow EDC to `store and forward' in `Maximum number of offline transactions.'' On loss allocation, searches for liability, bears-the-loss, assumes-the-risk and chargeback across the 150-document PDF corpus, the 1,941-document DevEx dump, the 292-page Insight help and the 75-page ASM dump return only EMV liability-shift warnings and chargeback-dispute glossary -- nothing allocates the loss on a stored transaction that declines after the processor reconnects, even in the Attempt Recovery section that describes recovery in detail. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-09

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

FOH terminals share check and table state through the on-site BOH file server over the store LAN, independent of the internet. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS199_ReferenceGuide.pdf · retrieved 2026-08-01

The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator

reliability-local-transaction-engine

The Terminals field definitions describe the shipped topology as 'one order entry terminal per license and one computer functioning as a file server for the network, which you normally locate in an area of the restaurant that is accessible only by management personnel', and the v19.11 Reference Guide glossary defines Refresh as copying configuration 'from the \NewData subdirectory of \Aloha to the \Data subdirectory of \Aloha... The changes do not take effect on the FOH until a refresh occurs (FOH reads the files in the \Data directory)'. Configuration and transaction data live on an in-store Windows BOH file server and on the terminals themselves, not behind a cloud request/response path; the Aloha Communication Layer (ACL) carries traffic 'across the Aloha network', and a designated terminal can assume the file server role in redundancy. Note this describes classic Aloha POS - Aloha Cloud is a different codebase and 'Aloha Next' is a cloud rewrite in named-account rollout. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/terminals · retrieved 2026-08-09 adversarially verified

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

reliability-offline-kds-printing

Aloha Kitchen stations and kitchen printers are LAN-attached to the on-prem POS and keep receiving tickets during a WAN outage. https://docs.ncrvoyix.com/restaurant/aloha-kitchen/implementing/manually_configuring_aloha_kitchen_hardware · 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

PARTLY OVERSTATED, VALUE UNCHANGED. The AUTOMATIC half is now sourced properly: 'Backup printer -- Identifies a backup printer to use in the event of hardware failure ... If the originally designated printer fails for longer than the time interval specified in `Reroute timeout seconds' ... the system reroutes output to the backup printer', with the interval configurable from 0 to 65535 seconds, and the QS Manager Guide confirming 'Printers are configured to automatically reroute to a backup printer; however, you may need to manually override the destination.' The ALERTING half survives but is weaker than 'not stated': the QS Manager Guide's 'Checking for error messages' procedure has 'Touch the floating logo on each FOH terminal to display the login screen. If a problem occurs, a message appears. Fix any error, such as a printer is out of paper.' That is a staff-visible printer error, but it is a passive login-screen indicator found by a manual daily check, not a push alert on failover, and no alerting field exists in the Printers or Options group bars. https://proddocsitesa.blob.core.windows.net/downloads/aloha-pos/QS199_ReferenceGuide.pdf · retrieved 2026-08-09

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

Aloha Configuration Center's offline mode is the documented partition case, and the guide states the resolution rule verbatim. Chapter 1: when CFC cannot reach the hosted database at login it converts to 'offline' mode, an Offline message asks whether to proceed, a ***Offline*** label appears on the header bar, and 'the changes you make while in offline mode are saved to the in-store database until Aloha Configuration Center resumes a connection with the host.' On reconnect: 'the system also checks to see if changes were made concurrently, to the same record. If changes were made to a record and saved to the hosted database, while you were making changes to the same record while working in offline mode, Configuration Center accepts the first set of changes, and your changes are not allowed. In this situation, a Save Failed message appears, informing you that the record has been updated or deleted by another user.' That is first-write-wins with an explicit operator prompt. Transmission is also atomic: 'The changes you make while in offline mode are serialized, and if one cannot transmit successfully to the host, then none of the changes are transmitted to the host.' For the separate import case the same chapter documents divergence being preserved rather than overwritten -- a store record that does not match the corporate-owned record 'is converted into a version of the primary, corporate-owned record, and automatically assigned to the imported store.' Scope note: this is back-office configuration data between an offline store client and the hosted database; on the order-entry side classic Aloha avoids two writers by design, with a terminal taking over as file server under Store Settings > System group > Redundancy. https://docs.ncrvoyix.com/downloads/aloha-pos/QS1911_ReferenceGuide-HKS1779.pdf · retrieved 2026-08-09

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

HEDGE UPHELD -- no consolidated matrix exists on any surface we hold -- but the note should not imply nothing is published. Offline behaviour is documented feature by feature: 'All debit cards processed as true debit cards, not as credit cards, automatically decline while the processor is in the `store and forward' state'; 'Store and Forward does not support EBT cards'; gift cards decline on a shared processor unless it supports offline gift cards; BOH EDC functions (authorize, adjust, force, refund, void, settle batch) error out for a processor in the SAF state; PMS carries 'Allow offline posting'; campus cards carry 'Maximum amount while processing offline'. What is absent is any single list of what is unavailable offline, measured across the 150-document /downloads/ PDF corpus, the 1,941-document DevEx help-center dump and the 292-page Insight help. Recorded as a judgement call: 'no' is arguable for a claim that asks for an explicit published list; partial is kept because the per-feature coverage is unusually thorough. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-09

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

reliability-public-status-page

status.ncrvoyix.com gives per-component status (including Restaurant Reporting / Aloha Insight by region) and maintenance windows, login-free. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/subscribing-to-status-page-alerts · retrieved 2026-08-01

A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator

reliability-contractual-uptime-sla

NCR Voyix publishes the "NCR VOYIX Hosted Software Availability Service Level Agreement" (as of July 2020) with a Hospitality SLA table keyed by name to Aloha Essentials. Stated thresholds and remedies: at an availability rate "Less than 99.9% but greater than or equal to 99.0%" the Aloha Essentials service level credit is 5% (software only and individually invoiced hosted solutions) or 1% (software plus hardware bundle); "Less than 99%" yields 10% or 3% respectively. The same table covers Other Cloud Services including Command Center, Mobile Pay, Aloha Loyalty, Aloha Stored Value, Online Ordering, Configuration Center, Pulse Real Time and Insight. The page carries the credit-request form itself, conditioned on the outage being documented at status.ncrvoyix.com and on the customer contract including an SLA commitment. The Sales Order Terms and Conditions add that "NCR Voyix uses commercially reasonable efforts to maintain service availability 24 hours a day, seven days a week". https://www.ncrvoyix.com/support/aloha-sla-form · retrieved 2026-08-08

The vendor publishes written post-incident reports or root-cause summaries for major outages.

reliability-incident-postmortems

THE ENUMERATION IS NOW COMPLETE AND IT TERMINATES, which is the whole reason this cell was withdrawn: the previous `no` rested on "the complete published incident set - 50 incidents", and that was page one of a paged API. Walking the PERMITTED /history.json to exhaustion (page 4 returns zero incidents) yields 279 published incidents back to Dec 2025 - 209 maintenance, 38 minor, 26 none, 5 critical, 1 major - and all 279 /incidents/<code> pages were read, each discriminated against a fabricated control (HTTP 302, 94 bytes) and a known-good one (HTTP 200, ~150KB). No page failed to read. THE SIX CRITICAL AND MAJOR INCIDENTS - the ones this claim is actually about - CONTAIN NO ROOT-CAUSE LANGUAGE AT ALL. Their entire published text runs 441 to 1,631 characters. "Voyix Connect (f.k.a. Connected Payments) Major Outage", a six-and-a-half-hour payments outage, says at its Identified stage "We have identified the cause and are making the necessary changes to resolve the issue" and never states what the cause was, then closes with "we are seeing normal functionality within the environment"; "Command Center for NAMER is unavailable" is 498 characters and contains no cause or identification language whatsoever. WHERE THE VOCABULARY DOES APPEAR IT IS NOT A POSTMORTEM, and this is the substance of the verdict rather than a silence argument: 26 of the 279 pages use root-cause or corrective-action wording, and each does one of three things instead of disclosing. It asserts a cause was found without naming it ("our technical teams promptly investigated the issue, identified the root cause, and implemented the necessary corrective actions"); it attributes to a third party ("ServiceNow team has identified issues with one of their servers"); or IT PROMISES AN RCA THAT NEVER ARRIVES - the 5 Dec 2025 multi-application outage closes "We are working closely with our third-party vendor on a root cause analysis to prevent this from happening again. We will share additional details as soon as they become available", and no further update was ever posted to that incident. Across all 279 pages the phrase "incident report is available" matches zero times and no page links out to a postmortem document. Median published incident text is 1,210 characters; the longest of all 279 is 5,418 and it is a minor reporting degradation, not an outage report. GRADE B, NOT A: a Statuspage instance is vendor-published operational reporting, not primary technical documentation, an API reference or a regulatory filing - the same grade the sibling cell reliability-public-status-page already carries for this host. TWO RECORDED FACTS THAT SHOULD NOT BE RE-DERIVED. The /api/ citation this cell once carried stays quarantined and must not be re-fetched (robots.txt, 48 bytes read whole, disallows /api/ and /embed/ only). And the atom feed is deliberately switched off rather than broken - RE-PROBED THIS SESSION AND THE MECHANISM IS NOT WHAT THE RECORD SAID: https://status.ncrvoyix.com/history.atom does not return a 404 directly, it returns a 302 REDIRECT to /inactive.atom, which then 404s with a 669-byte Atom document titled "NCR Voyix Status - Inactive Incident Feed". A fabricated .atom control 404s at zero bytes, so the named inactive feed is a deliberate deactivation and not a soft-404 - the prior conclusion was right and its stated mechanism was not. https://status.ncrvoyix.com/incidents/5b37w3l7q4qn · retrieved 2026-08-09 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

The standard contract states the support window, and it is not 24/7. NCR Voyix Sales Order Terms and Conditions, software maintenance section: "NCR Voyix will accept a request for services through the NCR Voyix support web site, by e-mail, or by telephone, as instructed by NCR Voyix, during Monday to Friday 8am to 5pm US Eastern Time, excluding federally observed holidays", with anything beyond that scope available "either on a pre-paid or time and material basis at your request". The same terms make the customer responsible for first-line triage: "you are responsible for providing a help desk to receive calls from your end users ... and will serve as the initial point of contact for service requests". www.ncrvoyix.com/support does advertise access "24 hours a day, seven days a week", but expressly "through our global support site: NCR Voyix @ Your Service" - a web portal, not live phone - and www.ncrvoyix.com/support/contact-restaurant lists regional Aloha phone numbers (West 844-263-0298, North 844-263-0147, Southeast 844-249-9602) with no hours attached. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

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

On-site deployment exists but as a separately-scoped professional-services engagement, not something the POS subscription documents. The deployment-services page says NCR Voyix executes rollouts 'across corporate and franchise locations with on site and remote services' and covers 'power and data cabling to NCR Voyix and non NCR Voyix hardware' — first-party but a sell page (grade C), quote-only, with no scope, response time or go-live definition, and no service description document reachable. Named shortfall: no product or technical documentation describing a first-party install/go-live visit for Aloha POS could be located — the Aloha POS docs overview's own 'Installation method' field is empty ('installation'), and the sibling Aloha Cloud SMB line documents 'Installation method: Self-service and remote installations' with only 'Concierge onboarding assistance' (https://docs.ncrvoyix.com/restaurant/aloha-cloud/about/overview). Classic Aloha's dealer channel plainly does install on site, but that is dealer-by-dealer and not a documented vendor commitment. https://www.ncrvoyix.com/services/deployment-services · retrieved 2026-08-02 adversarially verified

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

reliability-menu-build-service

NCR Voyix publishes two service lines and neither includes menu configuration. Deployment Services is scoped to the physical rollout -- 'site readiness, infrastructure, cabling, hardware, and timelines', 'From power and data cabling to NCR Voyix and non NCR Voyix hardware, we deliver complete, store ready builds', and standardized rollout 'ensuring consistent configuration, readiness, and performance at every site' -- while Managed Services is scoped to the service desk, multi-vendor hardware maintenance and depot repair. `menu build`, `we build your menu` and `menu configuration service` occur zero times across the whole corpus, and the Aloha menu documentation is written throughout for the operator to perform, using an installable Menu Configurator tool. The one line that points the other way was found and is a single ambiguous aside in an Aloha Online Ordering graphics page -- 'Contact your menu builder to locate these numbers' -- which names no party and commits the vendor to nothing. Graded C because 'consistent configuration' is marketing copy rather than a delimited statement of work. https://www.ncrvoyix.com/services/deployment-services · retrieved 2026-09-10 adversarially verified

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

reliability-hardware-replacement-sla

A purchasable field-maintenance programme is documented. Operations 360 exposes Field Service Request management with open-by-type, open-by-severity, count-by-age and top-location views, and a request list carrying SR Number, Customer Reference, SR Type, Severity, Create Date Time, Last Update, Status, "Estimated CE ETA" and Asset Model, plus an Area of Failure view toggled between "SLM (Second Line Maintenance)" and "FLM (First Line Maintenance)" with repair breakdowns. The Sales Order Terms and Conditions confirm equipment maintenance services are separately contracted under a statement of work, and that once a unit has been in service more than five years NCR Voyix may require a "customer-chargeable overhaul" or terminate service on that unit on 90 days written notice. SHORTFALL: no turnaround time is stated anywhere - "Estimated CE ETA" is a per-ticket estimate, not a committed window - and no advance-exchange or depot-swap offer with a named turnaround is published; the warranty remedy in the standard terms is discretionary repair or replacement within a "reasonable time". https://docs.ncrvoyix.com/digital-connected-services/o360/faqs/field-service-request-management · retrieved 2026-08-08

Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.

reliability-backup-restore

FLIPPED partial -> yes 2026-08-10. The claim is a DISJUNCTION - operator-triggered backup and restore, OR published RPO/RTO figures - and the first disjunct is fully documented for both databases an on-premise Aloha site owns. Two of the three prior shortfalls were false. 'The scope is the Aloha Takeout SQL Express database only, not the POS estate' is refuted by the POS's own field definitions: Store > Aloha Manager/Aloha Configuration Center carries 'Number of database backups to retain - Specifies the number of backups to retain on the server. This function provides you the ability to restore your system to a specific backup, if necessary', alongside 'Location for database backup files'. 'It is a DBA procedure in SQL Server Management Studio rather than a self-serve control' is refuted by the guide the cell already cites: 'With Aloha Takeout v13.1, the system enables you to schedule an automatic backup of your database without the need for additional batch files', configured at Maintenance > Takeout Configuration > Takeout Settings > Options with a time, a retention day count and a path, and retrieval is explicit - 'Save the backup somewhere other than the local drive, such as network storage, jump drive, or CD-ROM.' The disjunct's other half remains unmet and is recorded rather than dropped: for the hosted CFC tier the QS v19.11 Reference Guide promises only 'close to 24/7 uptime on data center core services' and to 'recover your data set quickly', and RPO, RTO, recovery point objective and recovery time objective return zero across all 150 PDFs, every web tree, ASM, Aloha Enterprise and the DevEx Knowledge Hub. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/store · retrieved 2026-08-10 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

The current release guide states a PCI SSC validation for the shipping product: 'Aloha Solution 2026 is validated against PCI Software Security Framework (SSF) standards. PCI SSF is a collection of standards and programs for the secure design and development of payment software.' The same statement appears in the 2025 and v19.9 release guides, so it is maintained rather than a one-off. That is a real, published, current PCI SSC validation, which is why this is not `no`. It is not `yes` because SSF validates payment software, not the DSS: no PCI DSS v4.0/4.0.1 Attestation of Compliance is published, `Attestation of Compliance` and `AOC` occur exactly twice in the whole corpus, and both are in the Mobile Pay Operator Guide, which routes the reader to an internal address -- 'For a list of PCI DSS products and services that NCR Hospitality validates, please see the list at the following link: https://ncr.sharepoint.com/sites/data_security/audit/SitePages/Home.aspx'. The DSS validation list is on a SharePoint site the public cannot read. https://docs.ncrvoyix.com/downloads/aloha-pos/AS2026_EnhancementReleaseGuide-HKS1801.pdf · retrieved 2026-09-10 adversarially verified

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

reliability-mfa-role-based-access

SHORTFALL CORRECTED AGAINST A CORPUS WE ALREADY HELD, VALUE UNCHANGED. The cell was scored on the classic POS security_roles page alone and generalised from it. The Aloha Insight help documents a per-user MFA block: 'Multifactor Authentication Type -- The Multifactor Authentication Type settings enable you to define which Aloha Insight users can access Secure Access and their rights', with 'Has access to `Secure Access'', an 'RSA SecureID Serial Number', an 'SMS Messaging Number' and 'Assigned Stores' scoping which stores a user may reach. So MFA is not absent from NCR Aloha -- it is absent from the POS terminal. HELD AT partial on that basis: no MFA is documented for the POS terminal's own manager or administrative login, which the reference guides secure with passwords, magnetic cards and fingerprint scanners. Two limits: the Insight block is per-user configuration and the help does not say an administrator can force MFA org-wide, and RSA SecurID implies a separate token deployment. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/security_roles · retrieved 2026-08-09

A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.

reliability-self-serve-training

The terminal half is documented: Job Codes defines 'Training mode (unpaid) -- Indicates an employee clocked in under this job code is working in training mode. A training mode job code allows access to all rights and menu navigation. The system records training sales in the Trans.log file but the sales do not appear in any Aloha reports or have any effect on payroll information. Training sales print only to the local chit printer. They do not open the drawer... The words Training Mode print at the top of all guest checks and chits.' SHORTFALL: no public free video or LMS training library exists for classic Aloha POS. docs.ncrvoyix.com publishes free Reference, User, Report and Feature Focus guides as PDFs, but the only customer training video library on the site (/restaurant/aloha-cloud/about/videos/customer_training_videos_english) covers Aloha Cloud Back Office and the Aloha Cloud POS, a materially different codebase, and www.ncrvoyix.com/support/ncr-voyix-customer-portal-training covers the customer portal, not the POS. Aloha POS operator training is delivered through the dealer/reseller channel. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/jobcodes · retrieved 2026-08-09 adversarially verified

Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator

reliability-failover-terminal-role

FLIPPED partial -> yes and grade D -> B, 2026-08-10. The prior note asserted that a grep of the implementing pages 'for redundancy, failover, master or backup returned nothing on point'; the answer is on one of those pages. Store Settings > System has a Redundancy group bar: 'Terminal automatically becomes fileserver in redundancy - Designates the selected terminal will take over as the file server in situations where the file server goes down unexpectedly. This process of redundancy helps to keep a restaurant functioning even when the BOH file server goes down', with 'Automatic fileserver recovery at EOD' governing the return. The v19.11 Reference Guides supply the master-terminal half and the scope: Mastercapable is 'an environment variable which stipulates whether a terminal is capable of taking over as the master terminal in the event that the true master terminal is down or cannot be located by other terminals on the network', and 'Redundancy architecture is designed to retain maximum system functionality in the event of common hardware failures. There are three types of failures: BOH file server down, master terminal down, and complete network failure (hub failure).' Operators can see which box took over: 'Show redundant mode indicator' labels the acting terminal MASTER on every terminal. Recorded so a later pass does not over-read it - takeover capability is designated per terminal by configuration, not inherent to every terminal. Grade D -> B: the citation moves off marketing copy onto vendor field definitions. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/store_settings_system_group · retrieved 2026-08-10 adversarially verified

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

reliability-cellular-backup

The vendor's hardware pages enumerate terminal connectivity explicitly and cellular is never among the options. The payment-devices page describes the Equinox Luxe 8500i as offering 'Flexible connectivity options: USB, Ethernet, Powered USB, and optional Wi-Fi models' and the Luxe 6200m as deployable 'tethered next to a fixed position point-of-sale or as a mobile WiFi option'; the CX5 datasheet lists '10/100/1000MB (Gigabit) Ethernet LAN' and no radio at all. Across the 304-page marketing site, the 17.9 MB PDF corpus and the docs.ncrvoyix.com trees, no document describes an automatic cellular failover for a terminal. Graded C because the ceiling is a marketing catalogue rather than a specification matrix. https://www.ncrvoyix.com/hardware/payment-devices · retrieved 2026-09-10 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

Read the full published Sales Orders Terms and Conditions (the vendor's only public contract text; it governs unless the customer has a master agreement). Sec. 1: 'This Order is non-cancellable.' Sec. 2: 'If the Product is provided on a subscription or other recurring fee basis, fees are fixed for one year following the date of the applicable Order.' Sec. 6.1: cloud-service access 'will end when the subscription expires, is terminated or cancelled' and NCR Voyix may cancel 'for convenience on thirty (30) days written notice' -- no matching customer right. Enumerated the full www.ncrvoyix.com sitemap (626 URLs): there is no pricing page and no published term option of any kind, so no month-to-month subscription is publicly offered. The initial term length itself is set in the unpublished Order, so the length of the commitment (36 months or otherwise) is not established here -- only that no month-to-month offer exists in public terms. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

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

Read the complete published Sales Orders Terms and Conditions (Sections 1-10). Nowhere do they state that no early termination fee or liquidated damages apply. Sec. 1 states 'This Order is non-cancellable'; Sec. 2 lets NCR Voyix suspend services and repossess Products for non-payment 'without waiving NCR Voyix's right to payment' and retains a purchase money security interest in each Product until paid. The only customer termination right in the document is Sec. 5.1, a sole remedy to 'terminate your subscription service' if NCR Voyix cannot cure a material non-conformance within a reasonable time. The claim asks whether published terms affirmatively disclaim an ETF; they do not. The dollar amount of any actual termination charge lives in the unpublished Order or master agreement and is not established here. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

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

Sec. 4.1: 'Maintenance services have an initial term as stated in this Order that will automatically renew for additional one year terms unless you or NCR Voyix provide written notice of non-renewal at least 90 days prior to the renewal date.' That is a publicly accessible auto-renewal term plus a stated 90-day cancellation notice window, which satisfies the claim for maintenance. Shortfall: Sec. 4 is headed 'Equipment & Software Maintenance Services' and this renewal language appears nowhere in Sec. 6 (Software as a Service / Cloud Services), which says only that access 'will end when the subscription expires, is terminated or cancelled' -- so for the SaaS subscription itself, both the initial term and any renewal/notice mechanics remain in the signed Order. Sec. 1 also makes the whole document yield to a master agreement, so a given operator's renewal terms may be unpublished. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

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

Aloha EDC supports third-party processors architecturally, but NCR Voyix Payments is commercially preferred and Aloha Cloud reportedly requires it. https://docs.ncrvoyix.com/downloads/aloha-pos/EDC199_UserGuide-HKS1618.pdf · retrieved 2026-08-01

Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator

commercial-interchange-plus-published

No processing rate of any structure is published — neither flat nor interchange-plus; the payments page routes to a contact form. https://www.ncrvoyix.com/platform/restaurant-applications/payments · retrieved 2026-08-01

The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator

commercial-rate-increase-clause

The published Sales Orders Terms and Conditions do the opposite of capping vendor-initiated increases. They reserve unilateral repricing outright -- 'NCR Voyix may change its prices and rates at any time' -- and then set an explicit annual escalator for recurring fees: 'If the Product is provided on a subscription or other recurring fee basis, fees are fixed for one year following the date of the applicable Order, and thereafter will be subject to annual adjustment by NCR Voyix.' A separate clause reserves cost pass-through for equipment and parts 'to the extent due to scarcity, industry or supply chain disruptions, competition, geopolitical events or trade policies'. No cap, no notice period, and no penalty-free exit on increase appears anywhere in the document. Scope note: this agreement governs equipment, software, supplies and services; the card-processing agreement is separate and is not published. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-09-10 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

UPHELD no 2026-08-10, now measured on six surfaces rather than the marketing page alone. The current Aloha POS platform page contains no dollar amount of any kind, no per-location or per-terminal software price, no tier table, and its only conversion path is a repeated 'Get in touch' button; the hardware pages are the same. Extending the search to everything that could have contradicted it - the 650-page Aloha POS doc tree, the Aloha Smart Manager and Aloha Insight/Enterprise help trees, the DevEx Knowledge Hub and all 150 first-party PDF guides - produces no software price either. The only recurring dollar figures NCR Voyix publishes anywhere in that set are card-processing fee-schedule items, such as 'NCP PS Pin Debit Access Fee will increase monthly from $4.25 to $10 per month' and a '$0.10 per transaction fee to merchants that are still processing MSD contactless transactions' in the DevEx card-brand update bulletins. Aloha software pricing is quote-only. https://www.ncrvoyix.com/platform/restaurant-applications/ordering-fulfillment/point-of-sale · retrieved 2026-08-10 adversarially verified

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

Modules are separately licensed and separately priced per site, but nothing published lets an operator cancel one independently. The Aloha Takeout v20.1.3 Implementation Guide's 'Security key requirements' enumerates additive licence capabilities: 'Enable Takeout for sites using any part of Aloha Takeout', 'Enable Takeout Delivery, in addition to the Takeout license above, for locations offering a delivery service', and 'Enable Takeout Delivery Mapping, in addition to the two license capabilities above, for sites using a mapping program'. The same mechanism gates other modules: the Quick Count (inventory) Feature Focus Guide states 'You must enable Quick Count on your Aloha security key to use Quick Count functions. Contact your account representative for assistance'; the QS v19.11 Reference Guide's customer-survey option 'is available for an additional cost and requires a new security key code'; and Aloha Gift Certificates 'requires a security key license' where 'the Basic Gift Certificates feature does not'. On the cloud side the picture is the opposite of a la carte, and it is now read from the guides rather than from a release-note summary: the ASM with Aloha Essentials User Guides (November 17 2025) state 'ASM is offered in four packages which you can opt based on your restaurant's size and business requirement', and those packages are cumulative tiers - 'Base - The `Base' package is included with any Aloha Traditional or Aloha Cloud subscription' (platform single sign-on and user management, sales reporting and dashboard, POS transaction viewer, POS audit log); 'Starter ... includes all the Base package capabilities and in addition' employee data and labor cost, weekly scheduling, house accounts, invoices and the employee website; and 'Core - The Core package includes all capabilities from Base and Starter.' The earlier citation of ASM release note ASM-1607 ('Core, Advanced, and Premium, as well as multiple sub-packages') is superseded by the guides' own four-package naming and described NCR-side provisioning rather than a purchasable menu. NAMED SHORTFALL: enablement is an NCR-side licensing action through an account representative, not a self-serve a la carte purchase; the cloud back office is sold as nested tiers in which a higher package necessarily contains the lower ones; no price list for the restaurant portfolio is published; and nothing addresses cancelling a module independently or repricing the base subscription - the published Sales Orders Terms and Conditions say only 'This Order is non-cancellable'. https://docs.ncrvoyix.com/downloads/aloha-takeout/ATO2013_ImplementationGuide-HKS326.pdf · retrieved 2026-08-09 adversarially verified

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

Sec. 2 of the published terms treats equipment as a purchase: 'All equipment purchased under this Agreement will be supplied and fulfilled by NCR Voyix or Supplier', 'title and risk of loss to equipment will pass to you from Supplier upon delivery', and 'NCR Voyix or Supplier, as applicable, retains and may perfect a purchase money security interest in each Product until you pay for it' -- a PMSI is a financed sale, not a lease. Rental is referenced only as an alternative invoicing basis ('in advance for recurring services and rental'), and nothing in the document makes a lease mandatory. Named shortfall: 'at a published price' fails. The hardware product pages (for example www.ncrvoyix.com/hardware-products/cx7ii-all-in-one-pos and the /hardware/point-of-sale, /hardware/kitchen, /hardware/peripherals category pages) carry no price, MSRP, 'starting at' figure or buy-now path, and the 626-URL corporate sitemap contains no price list; every purchase is quote-only. Also note NCR Voyix is transitioning the hardware business to Ennoconn and may act only as 'a sales agent on behalf of a Supplier' for equipment. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

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

Aloha POS documents third-party peripherals by name. The Printers field definitions state 'Model -- Designates the model of the printer you are configuring. The drop-down list contains a list of typical printers that work with Aloha' and name Epson TM-80, Epson TM-L90, Radiant SRP350, Bixolon SLPD420, Zebra LP2044 and Datamax E4203, alongside vendor-neutral 'Windows Printer', 'OPOS' and 'Fiscal Manager' printer types. Cash drawers are configured by OPOS driver name ('the OPOS name for a Panasonic cash drawer'), payment devices include Verifone PIN pads and Ingenico IPP units, and scales carry an appendix on 'supporting nonintegrated scales'. Residual limit, short of the claim's bar: the terminal Model list itself is not published - 'Contains a list of the typical terminals encountered in an Aloha system environment. If the type of terminal you are using does not appear in the list, contact Technical Support' - so third-party TERMINAL support is not affirmatively stated even though the software is ordinary Windows software. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/field_definitions/printers · retrieved 2026-08-09 adversarially verified

One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.

commercial-implementation-fee-published

UPHELD no 2026-08-10 on more than the platform page. Neither the live Aloha POS page nor /services nor /services/deployment-services publishes any one-time implementation, onboarding, menu-build or training fee, and none is stated as $0; deployment is described only qualitatively ('Dedicated teams plan, coordinate, and execute technology deployments across your environment') and routed to 'Get in touch'. Searching the 150 first-party guides and the DevEx Knowledge Hub for implementation, onboarding, training, installation, menu-build, setup and activation fees returns a single hit, and it is a third party's and carries no amount: JTECH wireless paging 'requires a one-time setup fee, per site, for the transmitter'. No NCR Voyix implementation charge is published on any surface we hold. https://www.ncrvoyix.com/platform/restaurant-applications/ordering-fulfillment/point-of-sale · retrieved 2026-08-10 adversarially verified

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

Data Sharing 'replaces legacy SQL replication mechanisms used by Insight and NCR Voyix Back Office (NBO)' and supports classic Aloha POS v19.6+ / Configuration Center v21.x+. Mechanics per the doc: generation is triggered by each site's end of day, files are delivered as Parquet via 'Signed URLs with a one-hour TTL', a Data Feed is the combination of sites, data sets and a Data Consumer identified by a DevEx service account, and the product page advertises 'Self service access: Easily manage access to your data yourself without having to go through a support or enablement team.' Coverage is real transaction detail, not just totals: Check Summary is 'a record with key metrics for each check or transaction' (TransactionNumber, EmployeeId, GuestCount, NetSales, TaxAmount, CheckCloseTime) and Item Sales is 'a record for each item sold or returned' (ProductId, ItemId, ParentItemId for modifiers, ItemPrice, DiscountedPrice, Quantity, IsReturned), alongside Tenders, Taxes, Comp Summary, Item Discount, Item Voids, Promotion Summary and Sales Totals. NAMED SHORTFALLS, TWO OF THEM CORRECTED 2026-08-10 AGAINST THE PRODUCT'S OWN RELEASE NOTES, WHICH THE CONCEPT PAGE HAS NOT CAUGHT UP WITH: (1) labor is absent FROM THE CLASSIC-ALOHA FEED, and this must be stated with its scope rather than as a flat absence - a Labor Shift data set shipped in v1.17 (December 15, 2025) but DATA-449 scopes it 'For organizations using both Aloha Cloud and Aloha Smart Manager', which is not the classic lineage, so for classic Aloha labor export remains a separate Aloha Smart Manager report ('Generic payroll export', downloadable in CSV from Labor > Reports); (2) retention is THIRTY days, not seven - the concept page still says 'Data is maintained in cloud storage for seven days from time of generation' while release notes v1.18 (January 12, 2026) say 'The Data Sharing exports are now stored for 30 days instead of seven days. (DATA-478)' - and the shortfall survives the correction unchanged, because a 30-day rolling window is still a forward-going daily feed and not a way to pull full history; (3) output is Parquet, explicitly 'a binary file format, making it not human-readable', not CSV; (4) access requires a provisioned DevEx service account and a configured Data Feed. Whether Data Sharing carries a separate fee is not stated in the documentation. https://docs.ncrvoyix.com/restaurant/data-sharing/using/introducing_data_sharing · retrieved 2026-08-10

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

UPHELD partial 2026-08-10. Guest records now have two machine-readable routes rather than one: Consumer Marketing's segment export produces an operator-composed .CSV, and Aloha Insight's Loyalty Card Lookup writes profile_export.csv, with Insight's Active Reports exporting 'as a PDF, Excel, Rich Text Format, or a delimited file ... either .csv or .txt'. Loyalty ledgers are covered: the Loyalty Balance report tracks balances and liabilities with an Aging export giving 'an Excel file with a burndown of all balances', and the accounting family adds a card-level Detail Export. GIFT-CARD LIABILITY FAILS ON ALL THREE SURFACES NOW TESTED. Insight's Aloha Stored Value category holds 'four different Stored Value ACH reports' (Transaction Status, Transaction Exception, Merchant Account Number Audit, Financial Authorizer Email Notification) plus Stored Value Sales and Stored Value Reconciliation - settlement and audit, no balance report - and the only aggregate-liability object in the tree is a bank account rather than a report: 'The gift card sponsor maintains a central bank account (funds pool), which contains the outstanding liabilities of the Aloha Stored Value gift card program.' Consumer Marketing's Reward Balance report cannot substitute: it 'only appears if your brand utilizes a custom balance type, such as cash back.' In the DevEx API Explorer, 'liability' returns zero rows across 379 ProductHowTo and 3,122 SwaggerOperation documents with the control passing. https://docs.ncrvoyix.com/restaurant/consumer-marketing/using/working_with_segments/exporting_a_segment · retrieved 2026-08-10 adversarially verified

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

UPHELD no 2026-08-10; both load-bearing quotes re-verified live and every other published NCR Voyix agreement checked. robots.txt for www.ncrvoyix.com read whole (95 bytes) disallows nothing. This is a DOCUMENTED REFUSAL rather than an absence, and the claim is disjunctive with both halves failing. Sales Orders Terms and Conditions Sec. 6.1: 'This access right is non-exclusive and non-transferable and will end when the subscription expires, is terminated or cancelled', and 'Upon termination, you will immediately disable all access to the services and return or destroy all copies of NCR Voyix-provided software used in conjunction with the services.' Sec. 8.1 disclaims liability for 'LOSS OF ... DATA, OR ACCESS TO DATA'. The words transition, retrieve and retention appear ZERO times in the 36,000-character agreement. The refusal is published twice more: the Customer Portal Terms and Conditions carry the identical Sec. 6.1, and the Customer Portal User Agreement Sec. 1.7 adds 'Upon termination, all rights and licenses granted by NCR Voyix to you will cease, and you will stop using NCRV Customer Portal.' The Privacy Policy governs only NCR's own retention of Personal Data and grants the operator no export right, and the sitemap publishes no DPA or separate cloud-subscription terms. On the documentation side Data Sharing's storage window is rolling rather than post-termination, and its own docs now disagree on its length: the release notes say 'The Data Sharing exports are now stored for 30 days instead of seven days' (DATA-478, 12 January 2026) while introducing_data_sharing still says seven. A negotiated master agreement could add a window; nothing public does. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-10 adversarially verified

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

Read the complete published Sales Orders Terms and Conditions. The document defines 'Customer Content' (Sec. 6.5) but never states that the merchant owns it; the only ownership clause runs the other way -- Sec. 3.2: 'All intellectual property rights in and to Products, NCR Voyix documentation, and other intellectual property used by NCR Voyix to provide the Products, and all releases, revisions, modifications, improvements, enhancements, extensions, or derivatives thereof or thereto, whether made by you or otherwise, are and will remain, or will be, owned by NCR Voyix or its licensors.' Sec. 6.4 grants a broad use right: 'NCR Voyix may use and disclose transaction-related and system information: to provide the products, software, materials and services under this Order or another agreement between you and NCR Voyix; for product and service enhancements, as well as research and development purposes; and after it has been aggregated, for analytics, commercial, and benchmarking purposes.' The aggregation qualifier attaches only to the analytics/commercial/benchmarking limb, so R&D and product-enhancement use of identifiable transaction data is expressly permitted. The corporate privacy policy (www.ncrvoyix.com/legal/privacy-policy) adds no merchant-ownership or resale constraint and offers no DPA. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-08-08

The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).

commercial-source-available-selfhost

UPHELD no 2026-08-10, and worth stating precisely because half of it is true. Classic Aloha IS self-hosted by design - it installs on a BOH file server in the restaurant, and EDC runs as a background process on that server - but the source is not published, and the claim's own parenthetical is explicit that an open API does not count. Every first-party guide, the TS and QS v19.11 Reference Guides and the EDC v19.9 User Guide included, opens 'The products described in this document are proprietary works of NCR Voyix' and footers each page 'NCR Voyix - Confidential. Use and Disclose Solely Pursuant to Company Instructions'. The docs overview sells Aloha as 'an end-to-end solution' on 'an all-in-one subscription model'. No source repository, licence text or build instruction exists in the 650-page doc tree or in the 150 published guides. On-premise deployment is not source availability. https://docs.ncrvoyix.com/restaurant/aloha-pos/about/overview · retrieved 2026-08-10 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

DOWNGRADED partial -> no ON A DOCUMENTED REFUSAL, WHICH IS STRONGER EVIDENCE THAN ABSENCE. The claim requires validated P2PE plus a named SAQ. The cell's own cited guide says the opposite, twice -- once in the TSYS/Voltage flow and once in the First Data/TransArmor flow: 'Keep in mind, this is not a PCI P2PE validated solution; however, the merchant's PCI QSA or the acquirer shall determine the PCI scope reduction.' So NCR disclaims validation and explicitly declines to state the scope reduction. Separately, 'SAQ' and 'Self-Assessment Questionnaire' occur zero times across the 150-document /downloads/ PDF corpus, and the only DevEx hits are a generic PCI DSS v4.0 card-brand bulletin naming no SAQ letter. Format-preserving encryption and PAN tokenization are real and documented -- that is why this is not graded lower -- but the two elements the claim actually tests are affirmatively refused. https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_PointtoPointEncryptionFFG-HKS374.pdf · retrieved 2026-08-09

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

NCR Voyix's only PCI DSS v4 communication is a merchant bulletin in the Payments card-brand-updates series, and it defers rather than documents: it announces that 'The Payment Card Industry Security Standards Council (PCI SSC) has released the latest version of the PCI Data Security Standards, PCI DSS v4.0', notes that 'many of the newly added requirements of PCI DSS v4.0 are best practices until March 31st, 2025', and says of the vendor's own position that 'Details about the transition plans for Merchants using the NCR Payment Solutions PCI Apply validation portal will be forthcoming'. The future-dated controls themselves are documented nowhere: `v4.0.1`, `script integrity`, `6.4.3` and `11.6.1` occur zero times across every corpus. Multi-factor authentication exists as a product feature in the developer portal and Consumer Marketing but is never tied to the cardholder data environment or to a PCI requirement. https://developer.ncrvoyix.com/portals/dev-portal/help-center/documentation/card-brand-updates · retrieved 2026-09-10 adversarially verified

Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.

commercial-soc2-attestation

UPHELD unknown 2026-08-10, now including the API Explorer tier that the prior note could not reach. Probed both tiers with the order control passing on every run: attestation 0, SOC 0, SOC2 0, ISO27001 0, certification 0, auditor 0, GDPR 0, encryption 0. The few near-hits are all something else - trust returns Banking Image Services and Disclosures (customer trust, not a trust centre), PCI returns an Emerald culture-code list and Selling Cart's 'It is important not to save any PCI sensitive data on the cart', compliance returns data-retention purge jobs and Selling Configuration's item-level 'Regulatory Compliance configuration', ISO returns date and currency codes, and audit returns shift audit trails. Nothing organizational. That is consistent with the earlier enumeration of the 626-URL www.ncrvoyix.com sitemap, which contains no trust, compliance or certifications page (www.ncrvoyix.com/trust serves the site 404), the 1,941-article help-center dump, and the 150-guide PDF corpus, whose only formal validation is PCI Software Security Framework validation of Aloha Solution v19.9 - a secure-software standard rather than an organizational attestation. UNKNOWN STANDS RATHER THAN no: SOC 2 Type II reports are routinely furnished to prospects under NDA with no public statement at all, so silence here is uninformative. What would settle it is a trust centre, a security-whitepaper page, or an attestation clause in a published MSA or DPA, none of which exists on any surface checked. SUPERSEDED 2026-09-10: Reopened from unknown once the marketing site was crawled in full, which the prior pass had not done. `SOC 2`, `SOC2`, `ISO 27001` and `trust center` occur zero times across all 304 non-Japanese www.ncrvoyix.com pages including the seven legal pages, About, and the corporate governance and security-adjacent copy, and zero times across the 150 product PDFs, 2,320 developer-portal docs, 1,238 docs.ncrvoyix.com pages and the 292-page Insight help. `attestation` matches once in that entire body, in the Mobile Pay Operator Guide, and it is a PCI DSS Attestation of Compliance whose list the vendor places on an internal SharePoint site. The published Sales Orders Terms and Conditions, the vendor's most detailed public commitment document, contain no security-attestation or audit-report undertaking of any kind. https://www.ncrvoyix.com/legal/ncr-voyix-sales-orders-terms-and-conditions · retrieved 2026-09-10 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

UPHELD partial 2026-08-10, BUT THE PRIOR NOTE'S FIRST SHORTFALL WAS FALSE AND IS WITHDRAWN. It read 'no erase/right-to-be-forgotten workflow appears in any classic Aloha tree' - measured on Consumer Marketing and published about the vendor, the same error the ASM labor flip exposed. Two other classic trees document deletion. Aloha Insight carries a Configuring Data Privacy tab 'to manage any sensitive data collected with the Aloha Loyalty system based on your business needs or regulatory requirements', whose 'Delete member account data after X days of inactivity' option 'will delete any an all member profile data stored in Aloha Loyalty' once the inactivity threshold is reached, MemberLink account included. Aloha Takeout deletes a named individual on demand: the Takeout Customer Organizer searches by customer name and 'Delete Customers Deletes the profiles you selected in the Selected Customers panel from the Aloha Takeout database', warning that 'once you delete a profile, you cannot undo the action', with 'Max days of inactivity' as a standing purge. Locating and exporting are documented too. STILL PARTIAL, ON THE REMAINING CONJUNCT: no DPA is published that an operator can execute. The Sales Orders Terms and Conditions carry no processor obligations and no data-subject-request assistance clause, placing Personal Information safeguards on the merchant instead and reserving broad vendor use rights. Erasure is also per-tree rather than one queue: Insight's is inactivity-triggered and company-wide, ATO's reaches only the local site database. The published merchant-agreement-ac.pdf is Aloha Cloud and must not be cited here. https://support.alohaenterprise.com/wwapp/en_US/helpdata/AlohaMarketing/Config_dataPrivacy.html · retrieved 2026-08-10 adversarially verified

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

NCR Voyix does accessibility work on its consumer ordering surface and does not publish a conformance report for it. The Digital Ordering release notes record the work item by item -- 'To support Web Content Accessibility Guidelines (WCAG), you can now tab through the Cart and Sign In/Sign Out modals without using a mouse', and elsewhere 'The Digital Ordering experience is improved with increased screen-reader voice-out coverage, desktop keyboard navigation, mobile device hand gesture navigation, and focus cue coverage.' The word WCAG occurs four times in the entire corpus and every one was read: those two release notes, and twice in a company blog on accessible design which discusses the standards generally and observes that 'following WCAG color contrast guidelines makes text more readable for anyone approaching a self-checkout or point-of-sale customer display'. None of the four claims a conformance level. VPAT occurs zero times across the 150 product PDFs, 2,320 developer-portal docs, 1,238 doc pages and all 304 non-Japanese marketing pages. No ACR is published and no tactile or audio non-visual access mode is documented for a self-order kiosk; the blog's nearest mention is a generic list of assistive options including 'Braille options at kiosks'. https://docs.ncrvoyix.com/restaurant/digital-ordering/about/release_notes/version-21x · retrieved 2026-09-10 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

Aloha POS v19.12+ (with CFC v21.23 and the 2025 product stack) supports cash discounting in Quick Service and Table Service: 'You use a percentage-based comp that automatically applies for a cash transaction. The system calculates the discounted amount for you and applies it the check.' Configuration is a Regular comp with Method 'Fixed percent' -- 'the only method supported for cash discounting' -- surfaced in the Tender function; v19.11 and earlier used a Check Reduction promotion applied by a dedicated FOH button. Receipt disclosure is documented: 'The cash discount and the cash discount message print on the receipt', and a guest-check footer message ('Pay with cash and get a 3% discount') is configurable under Maintenance > Messages > Guest Check Message. The docs also state the network-compliance framing: 'It is the responsibility of the merchant to ensure the standard (non-discounted) price appears to the consumer at all times. This includes all public displays at the door and counter, printed guest checks, printed and digital menus', and 'The merchant must adhere to network operating guidelines which can change over time.' Named shortfalls: (1) the only documented model is cash discounting -- no card surcharging / non-cash adjustment engine is documented in the classic Aloha trees, so there is no automatic exclusion of debit and prepaid cards from a surcharge because no surcharge is assessed; the Maintenance > Taxes > Surcharge function (field_definitions/surcharge) is an item-level excise surcharge for things like alcohol volume taxes, not a card fee; (2) the discount applies only to checks 'fully paid in cash' and is 'invalid if the check has a partial payment by a non-cash tender'; (3) menu-board and door signage disclosure is a manual merchant obligation, not a POS-enforced or POS-generated artifact; (4) the feature 'is available when using Connected Payments and NCR Voyix Payment Processing', so it is unavailable on other processors. https://docs.ncrvoyix.com/restaurant/aloha-pos/implementing/cash_discounts/implementing_cash_discounts_pos1912 · retrieved 2026-08-08