NCR Voyix Aloha

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-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

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

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

order-capture-bar-tab-preauth differentiator

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

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

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

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

order-capture-qr-same-check differentiator

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

order-capture-kiosk-first-party differentiator

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

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

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

order-capture-voice-ai differentiator

Checked all three corpora this record has. (1) The 150-document /downloads/ guide library (17.9MB of extracted text; aloha-pos 99, aloha-takeout 30, aloha-kitchen 9, digital-ordering 7, ASM 3, order-direct 2) returns ZERO hits for 'voice ordering', 'speech recognition', 'artificial intelligence' or ' AI ' - including the QS and TS v19.11 Reference Guides (HKS1779/HKS1780, 2.0MB and 2.1MB of complete Maintenance-menu field definitions), which is the whole configurable surface of the POS. The only 'voice' strings anywhere are gift-card voice-authorization phone numbers. (2) The 1,941-document DevEx help-centre dump (developer.ncrvoyix.com) has no voice article in any classic topic. (3) docs.ncrvoyix.com's sitemap lists no voice page in the aloha-pos, aloha-takeout, aloha-kitchen, aloha-digital-ordering, aloha-online-ordering or consumer-marketing trees. On the partner half, the hub documents NCR Voyix Marketplace with Self-Serve Integration Onboarding, where an activated partner 'can read menus and inject orders' over the Business Services Layer Order Service, but nothing in it is scoped to voice AI and no voice partner is named. Unresolved because the Marketplace product catalogue that would list one is eligibility-gated ('Check in with your NCR Voyix Account Representative to see if you are eligible'), and a gated directory cannot carry an absence argument.

order-capture-throttling differentiator

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

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

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

order-capture-order-ready-signal differentiator

Read the two vendor guides that define the aggregator path, now held locally. The Aloha Takeout Virtual Kitchen FFG (HKS1718, docs.ncrvoyix.com/downloads/aloha-takeout/) is the complete documented marketplace integration and its procedure list is inbound-only: create Concepts, create a revenue center per concept/aggregator combination, add Aggregator columns to the ATO Pickup and All Orders panels, add the Aggregator element to a header/footer, to a bag label and to a production or order-taker chit, refresh POS data. The order 'is submitted to Business Services Layer (BSL), and then injected into Aloha Takeout (ATO), and then to Aloha Kitchen (AK)' - the aggregator appears downstream only as a printed label. The Digital Ordering and ATO Integration Guide (HKS1516) likewise keeps status internal: ATO 'Monitors the order status, and updates, as appropriate' and 'Auto fulfill orders' has ATO 'change an online order status to closed'. The only webhook on the platform is Data Sharing's feed-event subscription, which notifies the operator about their own export files. Unresolved: the BSL Order Service reference that would define an outbound status call sits inside the gated API Explorer on developer.ncrvoyix.com, so no outbound leg could be confirmed or excluded.

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

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

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

menu-pricing-fractional-placement differentiator

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

menu-pricing-half-and-half-rule differentiator

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

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

menu-pricing-size-style-matrix differentiator

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

menu-pricing-included-allowance differentiator

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

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

menu-pricing-upsell-prompts differentiator

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

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

menu-pricing-countdown-auto-86 differentiator

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

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

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

menu-pricing-dual-pricing differentiator

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-pricing-versioning-effective-dates differentiator

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

menu-pricing-franchise-hierarchy differentiator

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

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-pricing-recipe-linkage differentiator

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

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

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

payments-processor-choice differentiator

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

payments-published-rates differentiator

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

payments-dual-pricing differentiator

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

payments-surcharge-guardrails differentiator

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

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

payments-softpos-tap-to-pay differentiator

Three corpora checked. (1) The 150-document /downloads/ guide library returns ZERO case-insensitive hits for 'softpos', 'tap to pay' or 'tap-to-pay' across 17.9MB, including the QS and TS v19.11 Reference Guides (HKS1779/HKS1780) and the 372KB Aloha EDC v19.9 User Guide (HKS1618), which is the complete payment-device and processor configuration surface. (2) On developer.ncrvoyix.com the nearest first-party product, Aloha OrderPay (topic 'Aloha Orderpay'), is explicitly the opposite of softPOS: 'a combination of sleek, purpose-built hardware and intuitive software' with 'built-in payment capabilities that support EMV chip cards, NFC tap-to-pay cards, mobile wallets like Apple Pay and Google Pay' on an Android handheld 'roughly the size of a smartphone' - a purpose-built device with an integrated reader. (3) docs.ncrvoyix.com's Aloha POS Payment Devices field definitions still support one wireless model only ('We currently only support the Verifone VX 680 payment device for this solution'), and Aloha Mobile Pay is guest-facing web checkout, not staff acceptance. Aloha Cloud's tap-on-phone material was excluded deliberately - wrong codebase. Unresolved: NCR publishes no certified-hardware matrix for Aloha on either host, and the OrderPay setup and implementation guides (HKS1664/HKS1665) are served from the developer host's gated media endpoint and could not be retrieved.

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

payments-qr-guest-pay differentiator

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

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

payments-tip-pooling differentiator

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

payments-offline-store-and-forward differentiator

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

payments-offline-decline-liability differentiator

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

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

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

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

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

payments-chargeback-tooling differentiator

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

payments-card-on-file differentiator

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

payments-payout-timing differentiator

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

payments-multi-entity-routing differentiator

Re-read the two guides that bear on this in the local /downloads/ corpus. The Aloha EDC v19.9 User Guide (HKS1618, 372KB, the complete EDC configuration surface) does document more than one merchant ID under one Aloha configuration: the processor record's 'Index' field 'Allows you to set up multiple merchant IDs for the same credit card processor... if you already defined CES as a processor, and require another CES record with a different merchant ID, set the Store Index to 2 on the second record', and processor tabs carry separate 'Credit card merchant ID', 'Gift card merchant ID' and 'Gift card alternate merchant ID' fields. What no page does is bind a merchant ID to a bank account or a legal entity: 'NCR Payment Solutions with the Aloha POS System - Settlement, Reconciliation, and FAQ' (HKS508) describes funding only in the singular - batch close, 'NCR Payment Solutions deposits the Settlement total... into your bank account' the following day, a funding schedule table, the Funding Category List report for reconciling deposits - with no construct for more than one destination account under one organization. Also re-checked payments/merchant-id-faq, merchant-portal-reference-guide and merchant-portal-faqs on docs.ncrvoyix.com and the 54-article Payments topic in the DevEx dump; the only multi-entity construct on the platform is BSL organizations and enterprise taxonomy, which govern data access rather than fund destination. Unresolved: multiple MIDs are configurable, but settlement banking is set in the merchant agreement, which NCR does not publish, so neither per-entity routing nor its absence is established.

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

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

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

kitchen-course-firing differentiator

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

kitchen-prep-time-pacing differentiator

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-order-throttling differentiator

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

kitchen-channel-pause-propagation differentiator

Aloha has an outbound availability path but every document that describes it stops inside NCR. Item level: the Aloha POS Items and Modifier Groups field definitions carry a 'Catalog' group bar whose 'Available for online' flag exports the item to the Business Services Layer Catalog service, a 'BSL Item Availability service' is named in the Aloha Digital Ordering v22.x release notes, and Aloha Online Ordering's 'Supporting Item Availability Updates' documents the receiving end; the Item Availability FFG (HKS368, 92KB) in the /downloads/ corpus is entirely POS-side count-down and 86 handling. Store level: grepped the 150-document guide corpus and the 1,941-document DevEx dump for pause, suspend, snooze, closed and store hours against every marketplace-facing surface and found only Aloha Takeout's aggregator label and column display (Virtual Kitchen FFG HKS1718, whose entire procedure list is inbound), Digital Ordering's Emergency Closed toggle acting on NCR's own ordering channel, and the DevEx tenancy article noting partners can 'view data such as their store hours and menu items' - a read, not a push. The complete Aloha Kitchen v19.13 Reference Guide (HKS1720, 311KB) and the ATO v20.1 Reference Guide (HKS1661, 322KB) contain no outbound pause option. Unresolved: partner-facing behaviour of the BSL Catalog and Item Availability services is defined in the API Explorer on developer.ncrvoyix.com, which is gated, so whether a pause reaches DoorDash is undetermined.

kitchen-order-ready-callback differentiator

Read the Aloha Kitchen side end to end in the local /downloads/ corpus. The AK v19.13 Reference Guide (HKS1720, 311KB) and Implementation Guide (HKS328, 354KB) document bump and recall in full ('Maximum order recall time in minutes', 'Allow Recall of Immediate Orders') and the only outbound notification tied to a bump is guest paging - the Wireless Text Paging FFG (HKS367) sends an SMS to the guest's own phone number. The ATO and AK Integration Guide (HKS327, 102KB) documents the internal leg, sending cooking status from AK to ATO with an Order Status column on the ATO screen. On the marketplace side the Virtual Kitchen FFG (HKS1718) and the DevEx Marketplace onboarding article describe the integration one-directionally: an activated partner 'can read menus and inject orders'. Unresolved: no order-ready callback to an aggregator is documented in the 150-guide corpus, the 1,941-article DevEx dump or the docs.ncrvoyix.com aloha-kitchen tree, but the BSL Order Service contract that would define one sits behind the gated API Explorer, so absence of the document is not absence of the call.

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

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

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

kitchen-printer-fallback differentiator

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

kitchen-offline-operation differentiator

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

kitchen-item-build-screens differentiator

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

kitchen-pizza-fractional-display differentiator

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

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

kitchen-order-modification-alerts differentiator

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

kitchen-guest-ready-notification differentiator

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

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

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

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

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

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

delivery-route-map differentiator

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

delivery-driver-tracking differentiator

The complete delivery surface is now readable and contains no driver telemetry. The Aloha Takeout v20.1 Reference Guide (HKS1661, 322KB) and Implementation Guide (HKS326, 367KB) model a driver as a terminal-side state machine - open on clock in, assign, dispatch, return, with cash-carry limits, itinerary printing and prompts 'for drivers to approve dispatch, return' - and the Driver screen is a list sorted alphabetically, not a map of driver positions. Grepping all 150 /downloads/ guides (17.9MB) for 'GPS', 'driver location', 'driver app', 'driver phone' and 'driver handheld' returns nothing; the single geo-fence reference in the corpus is the Delivery Area FFG (HKS351) describing the delivery boundary itself - 'an odd-shaped polygon radiating out from a site, with a geo-fence border... designed to ensure you only accept orders from within your area' - which is address validation for order acceptance, not driver position. The 1,941-article DevEx dump has no driver application in any classic topic; its only GPS string is the Axium handheld hardware spec. Unresolved: a driver app would be a separate product rather than an ATO setting, and NCR's Marketplace catalogue of third-party solutions is eligibility-gated and could not be enumerated, so a partner dispatch app cannot be ruled out.

delivery-zones-polygon differentiator

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

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

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

delivery-driver-comp differentiator

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

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

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

delivery-daas-fallback differentiator

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

delivery-3p-direct-integration differentiator

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

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

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

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

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

delivery-3p-reconciliation differentiator

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

delivery-injection-error-visibility differentiator

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

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

delivery-promise-time differentiator

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

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

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

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

digital-native-app differentiator

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

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-upsell-engine differentiator

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

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

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

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

digital-kiosk differentiator

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

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

digital-catering-portal differentiator

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

digital-voice-ai-phone differentiator

Run against all three corpora. The 150-document /downloads/ guide library (17.9MB, including the Digital Ordering Implementation Guide HKS1518, the ATO v20.1 Reference and Implementation Guides, and the QS/TS v19.11 Reference Guides) returns zero hits for 'voice ordering', 'speech recognition', 'artificial intelligence' or ' AI '. The 1,941-article DevEx help-centre dump returns only gift-card voice-authorization phone numbers in the Aloha POS Tenders and Gift Card/Certificate Sales field definitions and a generic IVR glossary entry in the Payments topic. The only telephony in the documented ordering path is Aloha Online Ordering call-centre order entry, which is staff transcription, and Aloha Kitchen wireless text paging, which is outbound guest SMS. No partner is named as certified for AI phone ordering: NCR Voyix Marketplace's Self-Serve Integration Onboarding names only DoorDash as a worked example. Unresolved because the claim can be satisfied by a named certified partner and the Marketplace product catalogue is exactly what is unreadable - 'Check in with your NCR Voyix Account Representative to see if you are eligible to access NCR Voyix Marketplace'.

digital-drivethru-ai

The drive-thru material is now held locally and is display, detection and timing only. The Drive-Thru Vehicle Identification FFG (HKS352, https://docs.ncrvoyix.com/downloads/aloha-pos/QS_DriveThruVehicleIdentificationFFG-HKS352.pdf) and the Aloha Kitchen guides cover lane assignment, quote times and order display; ATO's Multi-Lane Drive-Thru FFG (HKS1670) and reference-id-and-lane-number integration pass a lane number to Aloha Kitchen. Nothing in the 150-document /downloads/ corpus captures audio, transcribes an order or hands a conversation to a human: grepping 17.9MB for 'voice ordering', 'speech recognition', 'artificial intelligence' and ' AI ' returns nothing, and the same terms return nothing in any classic topic of the 1,941-article DevEx dump. No lane-voice partner is named on either host. Unresolved rather than absent: absence from NCR's own product documentation does not establish that no certified drive-thru voice partner exists in the eligibility-gated NCR Voyix Marketplace catalogue.

digital-sms-ordering

Every SMS occurrence in the vendor's own guide corpus is one-way and outbound. Grepping all 150 /downloads/ guides for SMS and 'text message' returns exactly five contexts: the Aloha Kitchen Wireless Text Paging FFG (HKS367), guest order-ready messages; the Alerts FFG (HKS334) and the QS/TS v19.11 Reference Guides, manager alerting; the Digital Receipts FFG (HKS1784), receipt delivery; and ASM notifications. The Digital Ordering Implementation Guide (HKS1518, https://docs.ncrvoyix.com/downloads/aloha-digital-ordering/DO_ImplementationGuide-HKS1518.pdf), which is the complete company-settings field enumeration for a Digital Ordering site, contains no SMS, text-message or text-to-order setting at all. In the 1,941-article DevEx dump the same terms across the Aloha Digital Ordering, Aloha Online Ordering, Aloha Takeout, Aloha Engage Mobile and Consumer Marketing topics return only Aloha Mobile Pay's Text2Pay payment link and Consumer Marketing mobile messages, which are marketing sends measured on delivery, clicks and opt-outs and windowed 8:00 AM to 8:00 PM local. No conversational text-to-order or reorder-by-text path into the POS is documented. Unresolved rather than absent: an ordering channel of this kind would be a partner product and NCR's Marketplace solution catalogue is eligibility-gated.

digital-google-order differentiator

Checked the settings surface and then the whole guide library. The Digital Ordering Implementation Guide (HKS1518) is the complete company-settings enumeration for a Digital Ordering site and every Google field in it is unrelated: Google reCaptcha v2/v3 site and secret keys, a Google Play badge image and a Google Play deep link for the Engage Mobile app. Grepping all 150 /downloads/ guides (17.9MB) for 'Google Business' and 'Order with Google' returns ZERO hits, and the same two terms return zero hits across the 1,941-article DevEx dump. The only Google integrations documented anywhere in classic Aloha are Google Pay as a tender, Google Analytics on the Aloha Online Ordering site, and the Google Wallet FFG (HKS365), a terminal-side coupon/loyalty and payment integration. Unresolved rather than absent: Order with Google is normally delivered as a feed arranged between the ordering provider and Google rather than as an operator-facing setting, so its absence from an operator settings enumeration is not evidence that the link is not provisioned.

digital-apple-business-connect

Ran the Order-with-Google enumeration a second time for Apple. In the Digital Ordering Implementation Guide (HKS1518, the complete company-settings field list) every Apple field is app-store plumbing or payment: 'Apple Store App URL', 'Apple App Deep Link', the Apple_Store_Badge.png website badge, and Apple Pay as a tender. Grepping all 150 /downloads/ guides for 'Apple Wallet', 'Apple Business Connect', 'Apple Maps' and 'place card' returns ZERO hits across 17.9MB, and the same terms return zero hits across the 1,941-article DevEx dump and the consumer-marketing, engage-mobile and digital-ordering trees on docs.ncrvoyix.com. No Order Food custom action or Apple Maps place-card provisioning is documented, and none was found in vendor marketing. Unresolved rather than absent: like Order with Google, an Apple Business Connect action is provisioned outside the POS settings surface, so its absence from that surface is not evidence.

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

digital-subscriptions

Checked all three corpora for a recurring-billing membership. In the 150-document /downloads/ guide library the word 'subscription' appears only in the two Aloha Smart Manager Essentials user guides, where it means subscribing to a report or a notification, and 'recurring billing' returns zero hits across 17.9MB. The Digital Ordering Implementation Guide (HKS1518), which enumerates every Digital Ordering company setting including checkout and payment options, contains no subscription, membership or recurring setting - stored cards exist for convenience, not scheduled billing. The nearest construct in classic Aloha is Table Service Club Membership in the TS v19.11 Reference Guide (Club Member records with anniversary and expiration dates, charging privileges and hold reasons), a private-club account with no recurring charge, no delivery-fee waiver and no per-period entitlement. Consumer Marketing's product card enumerates its program shapes as 'Bankable Rewards, Currency Based Plans, Items Based Plans, Visits Based Plans, Points Based Plans, and more' with offer management covering 'creation, eligibility, expiration and redemption of coupons, offers and promotions' - no paid tier, but the trailing 'and more' is why this is not scored as absent. The one page titled Subscriptions in the Aloha trees on docs.ncrvoyix.com is Aloha Mobile Pay administrator email alerting. Unresolved.

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

digital-guest-data-ownership differentiator

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-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-surcharge-transparency differentiator

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

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

guest-loyalty-thirdparty-identity-attach differentiator

Held at unknown. Zero hits for OAuth, single sign-on, Facebook, Google, social login and aggregator across the 292-page Aloha Insight help system. Classic Aloha Loyalty identity is card-first and manual, assigned at the terminal by swipe or alternate-ID lookup; the corpus is simply silent on marketplace-order identity attach.

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

guest-loyalty-tiers differentiator

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

guest-loyalty-offline-behavior differentiator

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

guest-loyalty-offer-stacking-rules differentiator

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

guest-loyalty-targeted-offers differentiator

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

guest-loyalty-rfm-segmentation differentiator

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

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

guest-loyalty-native-email-sms differentiator

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

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

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.

guest-loyalty-campaign-attribution differentiator

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

guest-loyalty-data-export-portability differentiator

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

guest-loyalty-cdp-event-api differentiator

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

guest-loyalty-review-capture-routing differentiator

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

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

guest-loyalty-wallet-pass differentiator

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.

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

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

guest-loyalty-ai-offer-recommendation differentiator

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

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

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

labor-photo-punch-verification differentiator

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

labor-geofenced-mobile-punch

Held at unknown, bounded now on a sixth surface. geofence, geo-fence and GPS occur zero times across all 75 ASM web pages, and the ASM Labor module states its own scope in one line - a manager adds and adjusts punches, and the employee role can only "log in and view their schedule and change their personal information". That is the same structural limit already recorded for Insight: ASM never documents punch CAPTURE at all, so its silence cannot settle terminal behaviour in either direction. Only a terminal or FOH-level document can, and none of the six surfaces now read is one. adversarially verified

labor-offline-time-punch differentiator

Held at unknown. offline occurs zero times across all 75 ASM web pages. ASM is a cloud back office - its overview gives "Installation method: Remote installations" - and its punch page describes editing punches after the fact, so like Insight it is structurally incapable of settling whether a terminal captures punches locally during an outage. Only a terminal or FOH-level document can. Local capture remains very likely on architecture grounds and undocumented in fact, which is unknown, not partial. adversarially verified

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

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

labor-native-scheduling differentiator

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

labor-demand-labor-forecast differentiator

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

labor-realtime-labor-percent differentiator

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

labor-overtime-prevention differentiator

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

labor-break-compliance-by-state differentiator

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

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

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

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

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

labor-qualified-tips-w2-reporting differentiator

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

labor-native-payroll differentiator

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

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

labor-shift-swap-workflow differentiator

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-08-10 · not refetchable · site policy · graded B when read adversarially verified

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

labor-server-performance-metrics differentiator

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

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

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

inventory-theoretical-vs-actual differentiator

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

inventory-realtime-depletion differentiator

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

inventory-86-auto-sync differentiator

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

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

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

inventory-vendor-catalogs-edi differentiator

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

inventory-invoice-ocr differentiator

'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

inventory-price-change-alerts differentiator

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

inventory-par-auto-suggest differentiator

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

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

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

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

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

inventory-shelf-life-expiry

Checked both inventory modules, not one. POS-side, the Quick Count FFG (HKS316, https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_QuickCountFFG-HKS316.pdf) is the complete classic-Aloha stock module and its whole counting model is Opening, Add (delivery), Waste, Usage and Closing counts - it is aimed at 'high cost items that tend to shrink and have a short shelf life' and records waste 'for items thrown away or unused, for reasons such as over-production or spoilage', but no item carries an expiration or use-by date and no report projects one; the only forward-looking report is Product Projection, built from about three weeks of sales history. Back-office side, the ASM Essentials inventory user guide (262KB, https://docs.ncrvoyix.com/downloads/aloha-smart-manager/ASM_ASMwithAlohaEssentialsInventoryUserGuide.pdf) yields one 'shelf' hit and it is a sort order ('rearrange the items according to sheet-to-shelf sequence'); raw items carry only a future deactivation date for the configuration record and recipes carry start and end availability dates, neither an expiry on received or prepped stock. Its one documented inventory notification event is stock running low or at zero, and its report set (Invoice history, Cost of goods sold) has no expiring-soon report. The only shelf-life construct anywhere in the 150-guide corpus is Aloha Kitchen's forecast bin - 'Shelf life in seconds - Specifies the number of seconds, from 0-9999, that you want bin quantities to remain in the Cooked section of the forecast bin, before the system automatically moves them to the Waste section' - holding time under a heat lamp, with no inventory effect. Unresolved rather than absent: NCR Voyix Back Office inventory, which carries the deeper features, publishes no user guide on either host.

inventory-bar-partial-bottle

Checked the counting surface, the units surface and the scale surface. Units: the ASM Essentials inventory user guide defines a Volume class 'for items dispensed by volume measurement regardless of weight, typically liquid measurements' with Fluid Ounce, Quart, Milliliter, Pint, Gallon and Liter available, raw-item categories include Liquor, Bar consumables, Bottle beer, Draft beer and Wine, and vendor-item conversion quantities accept 'up to two decimals' - so liquid stock CAN be held by volume. Counting: the same guide's count procedure documents a per-item tile with only three affordances - type the count, mark Out of stock, or Skip - plus a previous-count reference, and its one weight sentence ('The system auto-calculates the weight of the inventory item and the result appears next to the inventory item name. Additionally, the unit of measure appears to easily understand the conversion details') is a units-of-measure conversion display, not a device reading; the guide also states 'Verify Catch weight item is not selected as it is currently not supported', the platform's only explicit statement about variable-weight receiving. POS-side, the Quick Count FFG (HKS316) counts by unit of measure ('either a single menu item, such as a bottle of beer, or the...') with no fractional-bottle affordance. Scales: the Scales FFG (HKS1480, https://docs.ncrvoyix.com/downloads/aloha-pos/QSTS_ScalesFFG-HKS1480.pdf) is entirely point-of-sale weighing for quantity pricing - serial pin-outs, tares, certification display, manual weight entry - and its only inventory touch is 'Select Affects inventory, if you want to deduct the item from inventory, when sold.' Unresolved: nothing states whether the count tile accepts a fractional or decimal bottle value, and no bar-inventory scale integration is documented in the 150-guide corpus or on either host.

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-native-not-partner differentiator

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

inventory-menu-margin-linkage differentiator

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

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

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

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

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

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

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

reporting-server-scorecards differentiator

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

reporting-channel-profitability differentiator

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

reporting-multiloc-drilldown differentiator

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

reporting-custom-report-builder differentiator

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

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

reporting-raw-warehouse-export differentiator

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

reporting-public-api differentiator

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

reporting-webhooks differentiator

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

reporting-api-not-upcharged differentiator

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

reporting-tier-paywall differentiator

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

reporting-history-retention differentiator

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

reporting-anomaly-alerts differentiator

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

reporting-nl-query

Checked the guide corpus and both hosts. Grepping all 150 /downloads/ guides (17.9MB, including the QS and TS Report Guides, which are the complete report catalogues, and the ASM Essentials user guides) for 'artificial intelligence', ' AI ', 'natural language', 'assistant' and 'ask a question' returns nothing; every report in those catalogues is a fixed or parameterised report. The 1,941-article DevEx dump returns zero hits for natural language, AI assistant, copilot and generative in any topic. The newest analytics features are manual: ASM Advanced Analytics v1.27 (March 2026) is custom report building - choose a dataset, select columns and filters, save, favourite, publish to a shared organization catalogue - and Operations 360 is estate and service analytics driven entirely by widget interaction (Filter, Focus mode, Spotlight, Sort axis, hierarchical drilldown, per-widget export) with no query box. The only AI feature documented anywhere in the restaurant trees is Consumer Marketing's AI channel optimization, which picks a send channel for a campaign rather than answering questions about sales or labor. Unresolved: an assistant could ship in a release after these corpora were captured (2026-08-08/09), and the Aloha POS product page markets 'AI operational insights' without documenting any query interface.

reporting-guest-cohorts differentiator

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

reporting-sales-forecast differentiator

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

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

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

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

multi-location-local-override-policy differentiator

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

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

multi-location-scheduled-publish differentiator

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

multi-location-new-store-template differentiator

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

multi-location-corp-vs-franchisee-roles differentiator

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

multi-location-royalty-calculation differentiator

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

multi-location-royalty-collection

Withdrawing the earlier argument and still finding nothing. That argument was that fee collection 'has no place in a POS field set at all', so its absence from the POS and payments documents carried no weight. It is now clear NCR's above-store product does run a funds-movement engine: Aloha Stored Value ACH 'enables you to transfer funds between store bank accounts via an automatic clearing house (ACH) network', generates a daily transaction file 'by card series for each merchant account number for all stores designated for inclusion', submits it to an ACH processor for 'multi-settlement of funds among various merchant accounts', settles within 48 hours, is switched on in Company Setup > Polling and System Admin, requires a corporate financial authorizer to accept each store's merchant account number, and explicitly contemplates franchisees - 'your franchisees can participate in your corporate gift card programs'. It has reconciliation reports and a bank-statement reconciliation procedure. But what it moves is gift-card liability between the funds pool and the selling or redeeming store: 'The Aloha Stored Value system generates a transaction file that contains your daily sales and redemptions', and 'Service charges are not included in the ACH transaction file'. Nothing in the 292-page Aloha Insight help system, the 150 /downloads/ guides (zero hits for 'royalt' across 17.9MB, including the NCR Payment Solutions Settlement and Reconciliation guide HKS508 and the Aloha EDC v19.9 User Guide) or the 1,941-article DevEx Knowledge Hub describes debiting a franchisee account for a calculated royalty, ad fund or marketing fee, and none describes a franchisee-visible statement of what was charged. Recorded as unresolved rather than absent: NCR ships the plumbing for a different purpose, and whether a franchisor fee service exists as a commercial arrangement is not settled by any document either corpus holds.

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

multi-location-normalized-item-rollup differentiator

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

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

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

multi-location-multi-brand differentiator

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

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

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

multi-location-config-audit-log differentiator

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

multi-location-enterprise-sso differentiator

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

multi-location-enterprise-api differentiator

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

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

hardware-commodity-devices differentiator

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

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

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

hardware-handheld-battery-swap differentiator

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

hardware-handheld-lte

The only cellular statement in the whole NCR corpus is out of scope. 'Setting up Axium handheld device' on developer.ncrvoyix.com says the handheld can 'run off Wi-Fi or 4G cellular' and 'can support cellular connectivity using a cellular network provider SIM card to process transactions online in real time' - but that article's topic is Aloha Cloud, the SMB codebase this record is barred from citing and for which it already carries a verification downgrade. On the classic side, grepping all 150 first-party /downloads/ guides (17.9MB) for 'cellular' returns ZERO hits, and 'LTE', '4G' and 'failover' produce no hardware statement; that includes the QS and TS v19.11 Reference Guides, whose Terminals and hardware field definitions describe network nodes without a cellular option. The same Axium hardware carries Aloha OrderPay, whose overview on the developer host describes purpose-built hardware and payment acceptance and says nothing about connectivity or failover; the 1,429 classic-topic articles return no cellular hardware hit. The specific unread lead is unchanged: 'AOP Environment Setup Guide Axium - HKS1664', linked from that overview and served from the developer host's gated media endpoint. Unresolved: the device family plainly has a cellular option, but no classic-Aloha document states it.

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

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

hardware-kiosk differentiator

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

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

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

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

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

hardware-tap-to-phone differentiator

The claim is acceptance on a commodity phone or tablet with no separate reader. Grepping all 150 first-party /downloads/ guides (17.9MB) for 'softpos', 'tap to pay' and 'tap-to-pay' returns ZERO hits - including the QS and TS v19.11 Reference Guides (complete Maintenance field definitions, covering Terminals, Payment Devices and Tenders) and the 372KB Aloha EDC v19.9 User Guide, which is the complete processor and payment-device configuration surface. The same terms return nothing across the 1,429 classic-topic articles in the DevEx dump. The nearest and newest first-party product runs the other way: Aloha OrderPay's overview describes 'a combination of sleek, purpose-built hardware and intuitive software' on an Axium handheld accepting 'EMV chip cards, NFC tap-to-pay cards, mobile wallets like Apple Pay and Google Pay, and traditional magnetic stripe cards' - contactless acceptance on vendor hardware. That is consistent with the Payment Devices field definitions, whose only wireless entry states 'We currently only support the Verifone VX 680 payment device for this solution'. Held at unknown rather than no because NCR publishes no certified-hardware matrix for Aloha on either host and the Aloha Next content on the developer host is login-gated; Aloha Cloud material was excluded deliberately.

hardware-pricing-transparency differentiator

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-ownership-vs-lease differentiator

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

hardware-usable-after-churn differentiator

No document on any surface states whether NCR Voyix hardware runs third-party software after cancellation. Grepping all 150 first-party /downloads/ guides for bricked, decommission, deactivate and equipment return yields only RMA and return-material program material for OrderPay handhelds and configuration-record deactivation, never a post-termination software statement; the QS and TS v19.11 Reference Guides treat terminals purely as licensed nodes on the Aloha network. The closest first-party statement, in the DevEx Knowledge Hub's General Payments FAQ, points the other way but answers a different question: asked whether a merchant's existing POS equipment can be reused when moving to NCR Payment Solutions, it answers that reprogramming is sometimes possible over the phone but 'in many cases, for security reasons, your terminal may [be] locked and reprogramming may not be possible' - that is the incumbent provider's lock on equipment the merchant already owns, not NCR's own terminals post-churn. Set against the published Sales Order Terms and Conditions, where title and risk of loss pass to the buyer on delivery and repossession is reserved only for non-payment with no remote-disable right, the picture is that the operator owns the box and the vendor never says what it will run. Unresolved on the question as worded.

hardware-rma-sla differentiator

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

hardware-byod

Grepped all 150 first-party /downloads/ guides (17.9MB) and the 1,429 classic-topic articles in the DevEx dump for BYOD, 'personal device', 'personal phone', 'employee-owned' and 'own device': ZERO hits in either corpus, including the QS and TS v19.11 Reference Guides, whose Terminals field definitions license per order-entry terminal defined as a node on the Aloha network - a licensing model, not a permission or security model for personal phones - and the POS Access Levels field set, which governs functions rather than devices. The staff-facing mobile products point away from BYOD without ruling it out: Aloha OrderPay ships on purpose-built Axium handhelds and its published document set includes an 'AOP MDM User Guide', i.e. mobile device management of vendor-supplied hardware, while Aloha Mobile Pay is guest-facing pay-from-your-own-phone and Aloha Engage Mobile is a branded consumer app. Neither a positive nor a negative statement about staff running the ordering or payment app on their own phone exists on docs.ncrvoyix.com or developer.ncrvoyix.com; unresolved.

hardware-remote-device-management differentiator

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

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

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

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

extensibility-api-access-cost differentiator

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

extensibility-partner-revshare

Three corpora checked, none of which publishes partner economics. (1) All 13 Marketplace articles in the 1,941-document DevEx Knowledge Hub dump -- 'What Is Marketplace?', 'Integrating with Third Parties in Marketplace', 'Self-Serve Integration Onboarding (SSIO)' and the location- and user-management set -- are purely mechanical: browse products, click Activate Integration, accept a data release form, authenticate to the partner by OAuth, confirm the mapped site list and menus, activate, deactivate or reactivate, and submit a Create Partner Request for a partner not yet listed. No referral fee, revenue share or per-location partner fee appears in any of them, and there is no partner-terms article anywhere in the dump. (2) The 150-document /downloads/ guide corpus (17.9MB of first-party Reference, Implementation, Report, Feature Focus and Quick Reference Guides) returns zero occurrences of 'revenue share' and zero of 'referral fee'; these are technical configuration manuals and carry no commercial terms of any kind. (3) On the marketing host, www.ncrvoyix.com/partners/marketplace lists named partners with no commercial terms and /about/become-a-partner served no readable body. Unresolved rather than negative: partner economics normally live in a signed partner agreement, and absence from documentation is not evidence that no published terms exist.

extensibility-free-sandbox differentiator

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

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

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

extensibility-webhook-reliability differentiator

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

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

extensibility-menu-write-api differentiator

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

extensibility-data-symmetry differentiator

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

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

extensibility-doordash-preferred differentiator

Independently verified. The 2026 cohort is Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast and UrbanPiper, selected on performance as of May 8, 2026 against benchmarks including sub-1% order and error rates, self-service onboarding, real-time menu sync, live item availability and order-ready notifications. NCR Voyix is absent — and notably, three of those qualifying criteria are cells the dossier scores unknown for Aloha, which is internally consistent. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01 adversarially verified

extensibility-first-party-delivery-integrations differentiator

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

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

extensibility-accounting-connectors

No vendor-maintained QuickBooks Online connector with mapped journal entries was located, and the accounting integration that IS documented is file-based. The 150-document /downloads/ guide corpus (17.9MB) contains zero occurrences of 'QuickBooks', 'Xero', 'NetSuite' and 'journal entry'. Its ten 'general ledger' hits are all in the ASM with Aloha Essentials Inventory and Starter user guides, where a GL category, GL sub-category and GL account number are attributes attached to inventory items and vendor A/P codes -- coding, not posting. The one documented path to an external accounting system is explicitly CSV: the Aloha Takeout Reference Guide's centrally managed house accounts section requires 'A robust accounting package with the ability to export a LegacyMember.csv file in the defined [format]' and 'An Insight export file to import house account activity back into the accounting package', naming Great Plains as the example package. In the DevEx Knowledge Hub the QuickBooks material is out of scope or adjacent: 'Integrating with Shogo' (a third party that 'pulls sales data directly from your POS system and automatically posts the data to QuickBooks' nightly) sits under the Aloha Cloud topic and cannot be cited for classic Aloha, and the single classic-topic QuickBooks hit is an NCR Insights bullet in the General Payments FAQ -- 'Connect to QuickBooks so you can see your credit card sales and other revenue in one place' -- which is analytics visibility, not GL posting. Consumer Marketing's 'Accounting Reports' set is Loyalty Activity, Loyalty Balance, Reward Activity, Reward Balance and Transactions; Aloha Smart Manager publishes a Generic payroll export to CSV; Data Sharing's ten datasets are scheduled file feeds. Unresolved rather than no: the Marketplace carries an Accounting category whose members render client-side and could not be enumerated, and a directory is not evidence either way.

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

extensibility-bi-data-warehouse differentiator

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

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

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

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

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

extensibility-data-portability-exit differentiator

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

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

reliability-offline-card-auth differentiator

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

reliability-offline-decline-liability differentiator

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

reliability-lan-degraded-multi-terminal differentiator

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

reliability-local-transaction-engine differentiator

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

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

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

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

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

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

reliability-contractual-uptime-sla differentiator

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

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

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

reliability-onsite-install differentiator

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

reliability-menu-build-service differentiator

No onboarding scope document exists on any of the three corpora. www.ncrvoyix.com/services, /services/deployment-services and /services/managed-services are silent on menu build. The DevEx Knowledge Hub dump has no onboarding-scope, statement-of-work or implementation-deliverables article for classic Aloha, and grepping the 1,429 classic-topic articles for 'menu build' returns nothing. The 150-document /downloads/ guide corpus (17.9MB) likewise returns zero occurrences of 'menu build' and zero of 'statement of work'; its seven 'implementation team' mentions are all narrow configuration asides -- the team runs the wizard that creates the Aloha Online Ordering Digital Ordering App ID, sets 'ManuallyApplyRewardDollars' during onboarding to match the customer's Consumer Marketing reward-redemption setting (Digital Ordering/Engage Mobile and Consumer Marketing Integration Guide, Chapter 1), and the Payments Implementation team installs and upgrades Aloha Connected Payments -- plus two references to an NCR Voyix Professional Services representative receiving a Connected Payments RSA key. Aloha Smart Manager release note ASM-1607 adds that the team 'uses a tool to update an organization's subscribed packages, to ensure alignment with the customer contract'. Those establish that NCR staff perform configuration at onboarding; none says the initial menu build is a vendor deliverable, and Aloha is largely dealer-sold, so the builder may well be the reseller. Unresolved rather than partial: there is no evidenced deliverable to qualify. adversarially verified

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

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

reliability-pci-dss-4-attestation

The only formal validation NCR publishes for this product is a different standard from the one this claim asks about. The Aloha Solution v19.9 Enhancement Release Guide states under 'What you need to know before installing': 'Aloha Solution v19.9 is validated against PCI Software Security Framework (SSF) standards', which the same page says 'Replace PA-DSS with modern, future-proof requirements' -- a secure-software validation, not a PCI DSS Attestation of Compliance and not a P2PE solution listing, and it is quoted without a listing number or validation date. That guide then points to the 'Aloha Solution v19.8 Data Security Handbook Implementation Guide - HKS1653' for the detail; that handbook is referenced four times across the corpus but is not among the 152 PDFs enumerated from the six product overview pages, and five filename probes under /downloads/aloha-pos/ all 404 at 215 bytes, so the document that would carry compliance detail is not publicly linked. Elsewhere: the DevEx Knowledge Hub's 54-article Payments library returns nothing for attestation, AoC or PCI listing about NCR Voyix's own compliance; its most recent PCI item is the November-2023 card-brand update, which is merchant-facing and forward-looking ('Details about the transition plans for Merchants using the NCR Payment Solutions PCI Apply validation portal will be forthcoming as we work with vendor Aperia on PCI DSS v.4.0 migration planning'); and docs.ncrvoyix.com/payments/p2pepim remains the v2.9 P2PE Instruction Manual dated October 2019 with a generic PCI SSC index link in place of a solution listing number. The 150-guide corpus returns zero occurrences of 'attestation'. Unresolved rather than absent: AoCs are normally released under NDA.

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

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

reliability-failover-terminal-role differentiator

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

reliability-cellular-backup

Nothing on any corpus describes cellular failover, and the resilience story that IS documented is a different mechanism. The 150-document /downloads/ guide corpus (17.9MB, including the QS and TS v19.11 Reference Guides and the Aloha EDC v19.9 User Guide) contains zero occurrences of 'cellular', zero of '4G' or '3G' as connectivity terms, and zero of 'wireless WAN' or 'hotspot'; its 161 'modem' hits and 27 'dial-up' hits are the EDC redundancy story -- 'EDC and redundancy', 'Redundant dial-out', and 'EDC also supports a dial-up connection with the processor as a redundancy feature' -- which is a payment-authorization backup path, not terminal connectivity, and the 'Connection type' and 'Communication Type' enumerations in the EDC guide are TCP/IP, SSL/TLS and PIN-pad USB/serial. In the DevEx Knowledge Hub, grepping the 1,429 classic-topic articles for cellular, LTE, 4G and failover returns two hits, neither supporting the claim: a Kubernetes analogy in a technical glossary, and a Valutec gift-card topic stating the processor 'uses a hard-coded URL, embedded in the UPI plugin ... and does not support any failover mechanism, such as a dialup connection.' The documented resilience in classic Aloha is LAN-local: Store > Store Settings > System group, Redundancy group bar, has a terminal take over as file server when the back-of-house server fails, keeping the restaurant trading with no wide-area path at all. The single cellular statement in the whole NCR corpus is the Axium handheld setup article, filed under the Aloha Cloud topic and not citable here. Unresolved rather than no: nothing published enumerates the supported WAN connectivity options for a site, so absence here is not an exhaustive list.

commercial-month-to-month-contract differentiator

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

commercial-no-early-termination-fee differentiator

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

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

commercial-processing-not-bundled differentiator

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

commercial-interchange-plus-published differentiator

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

commercial-rate-increase-clause differentiator

The processing agreement itself is not published on any host. The DevEx Knowledge Hub's Payments library, where merchant contract questions are answered, gives only the term -- 'An NCR Payment Solutions service agreement is for 3 years. Your contract may have an early termination fee if you terminate before the end of 3 years' -- while the Merchant Fees FAQ explains interchange, monthly minimums and end-of-month fee deduction and then tells the merchant 'it is important to be familiar with your merchant account agreement, which should outline your exposure', explicitly deferring to a document NCR does not publish. The card-brand update bulletins show NCR both passing through and adding fees unilaterally (a $0.10 per-transaction fee on merchants still processing MSD contactless from April 2023; the PIN debit access fee rising from $4.25 to $10 per month), but a fee bulletin is not a rate-change clause and none of them states a cap, a notice period or an exit right. The 150-document /downloads/ guide corpus is technical configuration documentation and carries no contract terms; its handful of 'additional fee' hits are about card-network surcharges and pre-authorization behavior, and the only NCR Payment Solutions commercial document in it is the Settlement, Reconciliation and FAQ guide, which covers batching and funding rather than pricing terms. The published Sales Orders Terms and Conditions govern equipment, software and cloud subscriptions rather than card processing. Unresolved.

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

commercial-module-unbundling differentiator

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

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

commercial-hardware-not-locked differentiator

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

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

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

commercial-export-customer-and-loyalty differentiator

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

commercial-post-termination-export-window differentiator

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

commercial-data-ownership-clause differentiator

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

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

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

commercial-pci-dss-4-controls

Nothing on any of the three corpora documents the v4.0.1 future-dated controls for this product, and the guide library's PCI content is a decade older than the question. Sixty-eight chapter headers reading 'Using this guide to meet PCI requirements' appear across the 150-document /downloads/ corpus, but their substance is pre-4.0 -- the Quick Service Report Guide's 'Configuring BOH Audit report to meet PCI-DSS' is about masking card numbers to the last four digits and notes 'When you upgrade to v6.4, the BOH Audit report masks credit and debit card information, by default' -- and the corpus returns zero occurrences of 'multi-factor', 'multifactor', 'MFA', 'script integrity', '6.4.3' and '11.6.1' across 17.9MB. In the DevEx Knowledge Hub's Payments library the PCI FAQ still quotes pre-4.0 numbering ('PCI DSS requirement 3.3') and is about the Annual PCI Service Fee and the Aperia SAQ partnership; the only v4.0 item, the November-2023 card-brand update, tells merchants the future-dated requirements exist and that NCR's own transition plans are 'forthcoming'. On MFA the corpus is specific and the gap is the point: MFA is documented only for cloud identity -- NCR Voyix Loyalty 'now enforces Multifactor Authentication (MFA) compliance across all identity-integrated cloud applications', the Marketplace portal offers opt-in user-level two-factor with a Disable MFA button, Data Sharing added MFA for EMEA customers (DATA-519), and Consumer Marketing supports Google Authenticator or hardware tokens -- none of which is cardholder-data-environment access, while the POS's own Store Settings Security group field definitions offer only password length and complexity rules and manager-approval options. No payment-page script-integrity or change-and-tamper-detection content appears anywhere in the 1,941-article dump. Unresolved rather than negative: a QSA-attested 4.0.1 readiness statement would not normally be published, and the vendor's own Aloha Solution Data Security Handbook (HKS1653), referenced by the release guides, is not among the publicly linked PDFs.

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. adversarially verified

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

commercial-wcag-kiosk-accessibility differentiator

No conformance report exists on any host, though accessibility work is visibly happening, which is what makes the missing ACR the finding rather than an oversight. Aloha Digital Ordering release notes record 'AO-12728: To support Web Content Accessibility Guidelines (WCAG), you can now tab through the Cart and Sign In/Sign Out modals without using a mouse' (v21.x) and screen-reader support for the Find Your Local Menu modal (DO-3449, v24.x), and Voyix Kitchen's KDS notes cite full keyboard navigation, ARIA roles and updated colour contrast (KIT-2773). All are release-note lines; none claims WCAG 2.1 AA conformance and none is a VPAT or ACR. Grepping the 1,429 classic-topic DevEx articles for VPAT, ACR, Section 508, tactile and assistive returns nothing. The 150-document /downloads/ guide corpus (17.9MB) returns zero occurrences of 'VPAT' and zero of 'WCAG'; its 42 'accessib*' hits are all ordinary-language usage about screens or records being reachable, and its 26 'kiosk' hits are POS configuration only -- Installed Products 'Uses Kiosk', a kiosk interface terminal and its virtual interface employee -- with no kiosk accessibility topic and no non-visual access mode anywhere. Unresolved: a VPAT for a partner-built kiosk would most likely be published by the kiosk vendor, and NCR Voyix publishes no accessibility page (www.ncrvoyix.com/accessibility 404s).

commercial-dual-pricing-compliant differentiator

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