Vendors / Enterprise & chain restaurant POS
Qu
Qu (Qu POS, Inc. / qubeyond.com)
dossier live
- Claims in scope
- 314
- Scored
- 314
- Assessed
- 278
- Unknown
- 36
- Not applicable
- 0
- Values challenged
- 101
Identity
- Owner
- Independent, venture-backed. Investors named in Qu's own releases: Cota Capital (lead), NRD Capital, Bobby Cox Companies (multi-chain restaurant operator), and Enlightened Hospitality Investments (Danny Meyer's growth fund, joined Nov 2023). Sources: https://www.qubeyond.com/qu-continues-its-momentum-in-enterprise-pos-market-through-10-million-series-b-funding-round/ and https://www.qubeyond.com/resource-center/enlightened-hospitality-investments-partners-with-qu-to-accelerate-innovation-for-the-restaurant-industry
- Founded
- 2012, as Gusto POS; rebranded to Qu. HQ originally Bethesda, MD; support page now lists 1100 Wilson Blvd, Suite 2920, Arlington, VA 22209 (https://www.qubeyond.com/support)
- Scale
- unknown for revenue/ARR/market share. Vendor-claimed logos on qubeyond.com include Jack in the Box, Shake Shack, Dave's Hot Chicken, Blaze Pizza, Auntie Anne's, Carvel, Cinnabon, Golden Chick, Jamba, Golden Corral, Schlotzsky's, Taco John's, Church's Chicken, Hot Head Burritos, Pokeworks. Church's Chicken deal was announced as covering ~1,000 US locations (https://www.businesswire.com/news/home/20210218005023/en/Churchs-Chicken-Selects-Qu-POS-as-Part-of-Global-Technology-Stack-Refresh) — claim-level, and Qu publishes no total installed-location count.
- Who it is for
- Multi-unit QSR and fast-casual chains, self-described target of 20 to 200+ locations, up to ~1,000-unit brands. Qu's own POS page states the product is "not designed for single-location restaurants or table-service concepts" (https://www.qubeyond.com/ordering/pos). Buyer is a corporate/franchisor technology team replacing legacy POS, not an independent operator.
- Site
- https://qubeyond.com/
Pricing
transparency: quote-only · unit: unknown · processor lock-in: no
- Software
- quote-only. No pricing page exists on qubeyond.com; the site funnels to https://www.qubeyond.com/get-a-demo. No dollar figures are published anywhere on the vendor's own site.
- Card processing
- unknown — Qu Pay publishes no rates. Qu Pay marketing mentions "on-demand settlements" and processing-history-based working capital but no bps, per-transaction, or interchange-plus figures (https://www.qubeyond.com/payments/qu-pay)
- Contract
- unknown — no publicly accessible MSA, ToS, or order-form terms found
- Early termination
- unknown
API posture
public API: partner-gated
- Cost to integrate
- unknown. Qu operates a certified partner ecosystem (~150 listed integrations, https://www.qubeyond.com/about/qu-technology-partners/) and describes a "robust certification process," but publishes no partner fee, revenue share, or certification cost.
- Webhooks
- unknown. The publicly indexed v3 documentation describes a pull model — third parties POST orders in and "POS systems in stores pull online orders" — with no outbound webhook contract, signing, or retry policy documented. Qu's status page does list a "DataExport API" component (https://status.qubeyond.com/).
- Data export on exit
- unknown. No published post-termination data-retrieval window or export commitment. Qu's website privacy policy explicitly scopes itself out of platform data: "This Privacy Policy does not apply to: Information processed on behalf of our customers through Qu products and services, where separate contractual terms may apply."
- Notes
- Qu markets itself as "API forward" and its differentiation story is API-first architecture, but the developer surface is not self-serve: no public sandbox signup, no published rate limits, no changelog/deprecation policy, and documented auth is a static APIKey header rather than OAuth 2.0. The broken TLS on both documentation hosts is a real, checkable defect for a vendor whose central claim is API quality.
Capabilities
Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.
Order capture & FOH workflow
Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.
order-capture-floor-plan-editor
Qu's POS page affirmatively states the product is not designed for table-service concepts; no floor plan or section objects exist. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-01
Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.
order-capture-seat-level
No table-service model; seat numbering not applicable per vendor's own scope statement. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-01
Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.
order-capture-coursing-hold-fire
KDS supports fire on tender, fire on next, fire on fly, and manual fire/suspend. Course assignment from a handheld is not documented. https://www.qubeyond.com/kitchen-solutions/kitchen-display-system · retrieved 2026-08-01
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
Seat/table splitting and table merging presuppose table service, which Qu states it does not support. Item-level splitting is undocumented. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-01
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
No Qu source addresses card pre-authorization or bar tabs. 'bar tab', 'pre-auth', 'preauth' and 'open tab' return zero matches across all 199 uncited www.qubeyond.com pages, and the check-handling features Qu does describe (Combine Checks merging into a parent check, Check Search filters) carry no tab or open-authorization concept. Qu's /multi-unit-pos-guide comparison table states 'Built exclusively for QSR and Fast Casual' under an 'Industry Focus' row, but that is a market-segment positioning statement in a competitive sales guide, not a feature enumeration or a statement of non-support. Product documentation is behind support.qubeyond.com, which redirects to a login on every path, so the capability is undetermined. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: bar tab opened against a card pre-authorization with a configurable auth amount, incremental re-auth, and auto-close of stale tabs. VERDICT unknown. EVIDENCE: this KB is the first Qu surface on which `pre-auth` is not zero, but the object is a printed slip, not a tab. v139: 'A Pre-auth check which includes a Tip + Signature line is able to be printed from the POS. There is a platform setting which enables this button to display on the Terminal', listed again under new EI settings as 'New Print Pre Auth Slip platform setting to enable check printing option on POS'; v141 adds 'POS permissions - Manager's Approval for Pre-auth Slip modifications.' That is the tip-adjust slip after an authorization: no auth amount, no incremental re-auth, no stale-tab handling. `bar tab` and `open tab` = 0 across the 205 articles and the 53 PDFs, and the check-lifecycle articles that do enumerate states (Suspend a Check, Find Closed Checks, Split a Payment) carry no tab concept. Retrieved 2026-09-18. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. Tokenised `bar tab`, `open tab`, `pre-auth`/`preauth` = 0/209. NEW SURFACE READ FOR THIS CELL: the Qu Pay merchant portal bundle (pay-admin.qubeyond.com/assets/index-DePrXYp5.js, on disk from the 325th) DOES carry a preauthorization, and it is not a tab: it sits on the saved-payment-method form ('Preauthorize Amount (Optional)') and its help string reads 'Preauthorization a dollar amount from {minAmount}-{maxAmount}. This allows you to verify if a card can cover the charge without completing the transaction ... Preauthorized funds are automatically released after 5 minutes.' The same portal shows Adyen lifecycle labels ('Authorization Adjusted', 'Capture', 'Are you sure you want to capture {amount}?'), i.e. back-office handling of authorisations, with no tab object, no incremental re-auth action and no stale-tab close. It is the payments back office, not the store POS, so it bounds nothing about bar tabs. Retrieved 2026-09-18. || 333rd: 333rd NEW CORPUS: Qu's video library - the YouTube channel @QuBeyond (85 uploads listed with yt-dlp; 54 caption tracks pulled into .cache/q333/qu/b/tr) plus the 45 Wistia media embedded on www.qubeyond.com resource-centre pages (media ids from the 331st rc corpus; public fast.wistia.com/embed/medias/<id>.json + /embed/captions/<id>.json, 42 English caption tracks, incl. 8 not on YouTube: the 05-07-26 webinar recording, Digital-First POS 1-Minute Demos 1-4, Winter 2025 highlights, FSTEC Innovation Forum, State of Digital LinkedIn Live, Trust & Technology) = 96 transcripts, 1.56 MB. Vendor video = grade C. In it `bar tab`, `pre-auth`, `preauth` = 0 (tokenised); the 2 `open tab` hits are POISON (OpenTable). NEW, adjacent: the Winter 2025 release video (Wistia hrstnqffun, 1080p MP4 read frame by frame, sharpest frame at 94 s) shows the CURRENT store POS payment screen: side actions Discounts, Service Charges, Donations, Rewards, Combine Orders, 'Pre Auth Slip' (greyed), Print Check, No Sale; tender bar Quick Cash, Exact Cash, Next $, Next $5, Credit Card, 'Quick Chip Pre-read'. The 2020 POS Interface demo (YouTube 3c0DpW8Onp0, 33 frames) tender bar has no Pre Auth Slip, so it was added since. So the store POS now has a card pre-authorization slip action, but no frame shows a tab object, a configurable auth amount, incremental re-auth or stale-tab close, and a pre-auth slip is equally the pre-auth-then-tip-adjust flow. Adjacent, not a partial; held. Retrieved 2026-09-18. adversarially verified
An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.
order-capture-transfer-audit
Qu First Gen 2.0 Admin Guide Chapter 8, Section 4 (updated April 2020; Wayback capture 2020-08-06): 'Check Sharing Groups share checks and clock ins/outs among all of the terminals that have been added to that group.' The Enterprise Configuration reference adds 'Allow Peer Refresh: If "true", terminal will refresh display immediately whenever a check is received from another terminal', and the v140 release note records that 'a check can be suspended on one terminal after items have been added' and resumed elsewhere. Checks can also be table-assigned ('Fixed Check Label: The category label on the POS terminal for checks that are assigned to a table'). SHORTFALL: only device-level check sharing is documented; there is no documented server-to-server or table-to-table transfer action, and no audit entry naming both the transferring and receiving employee - Chapter 12: Audit Trail covers configuration changes, not check ownership. Vintage: First Gen 2.0 / Next Gen 3.5 archive, 2020. https://web.archive.org/web/20200806003551/https://support.qubeyond.com/hc/en-us/articles/360001252212-Chapter-8-Printing-First-Gen-2-0- · retrieved 2026-09-03
Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.
order-capture-native-handheld
Drive-thru page cites mobile/tablet order-taking beyond fixed terminals; no purpose-built handheld with integrated tableside card capture is documented. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-01
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
Qube edge: ordering, payments and kitchen routing continue during outages. Vendor publishes no list of what does not work offline. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-01
Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator
order-capture-qr-same-check
Re-fetched the Online Ordering page: "tableside" is listed as a fulfillment/hand-off mode alongside in-store, curbside and white-label delivery. Shortfall: the page never describes a guest QR scan writing items onto an existing server-opened check rather than creating a new order/ticket, and Qu's own POS page states the product is "not designed for... table-service concepts", which is the model this claim presupposes (an open check with server-entered items already on it). https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-04
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
First-party kiosk (Qu Flex) uses the same single menu as POS; ADA is addressed as feature claims (audio output, adjustable interaction), not a published conformance report. https://www.qubeyond.com/ordering/kiosk · retrieved 2026-08-01
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
Dedicated drive-thru product with 5+ concurrent orders on screen and flexible order injection; order-point/window separation, tandem lanes and pull-forward are not documented. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-01
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
Re-fetched the drive-thru page: "Operators get real-time speed-of-service data through Qu Notify and a real-time Kitchen Intelligence Score so managers can act on bottlenecks before they impact guests," plus a claimed "up to 50% faster service times." Shortfall: this is a rolled-up operational score, not the segmented order/total/window timers tied to individual orders that the claim names — no per-segment timer breakdown or per-order timer report is documented. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-04
Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator
order-capture-voice-ai
The drive-thru page says verbatim: 'Qu's open Intelligent Commerce Platform integrates with AI voice-ordering partners — including ConverseNow and Presto.' That is an explicit third-party integration, not a Qu capability. The researcher's own note concedes 'third-party, not first-party' and then scored it yes anyway. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-01 adversarially verified
Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator
order-capture-throttling
Qu versioned release notes 'December 16th (v140)' (Wayback capture 2021-01-25) enumerate store/group-level platform settings that can be scoped to an order channel: 'Future Order Acceptance Days, Min Max Order Limits, Bucket Scheduling, Kitchen Buffer Lead Time, Print Kitchen Ticket', and state that 'all platform settings use the catering channel as well, allowing the customer to change order limits and timings to be specific to catering'. That establishes per-channel order limits and time-bucket scheduling. SHORTFALL: 'Bucket Scheduling' and 'Min Max Order Limits' appear only as setting names with no documented mechanics, and nothing in the corpus describes automatic quote-time extension when kitchen load crosses a configured threshold. Vintage: Next Gen 3.5-era v140, December 2020; live site silent. https://web.archive.org/web/20210125175255/https://support.qubeyond.com/hc/en-us/articles/360054441371-December-16th-v140- · retrieved 2026-09-03 adversarially verified
Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.
order-capture-scheduled-orders
Qu versioned release notes 'December 16th (v140)' (Wayback capture 2021-01-25) document the future-order setting: 'Future Order Acceptance Days... Minimum days - lowest number of days in advance an order can be placed. 0 = same day, 1 = tomorrow... Maximum days - highest number of days in advance an order can be placed', and 'This setting can be set with a context specific to web and/or catering to allow for differing order limits', i.e. per-channel. The same note lists 'Kitchen Buffer Lead Time' and 'Print Kitchen Ticket' among the store/group-level settings that take a per-channel context. SHORTFALL: the release note names 'Kitchen Buffer Lead Time' as a setting without describing the mechanism, so automatic injection of a future-dated order into the make queue at a computed fire time (rather than on receipt) is not documented. Vintage: Next Gen 3.5-era v140, December 2020; not verified against the current Intelligent Commerce Platform. https://web.archive.org/web/20210125175255/https://support.qubeyond.com/hc/en-us/articles/360054441371-December-16th-v140- · retrieved 2026-09-03
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
EZCater is a named direct integration; no native catering quote/deposit/balance flow is documented. https://www.qubeyond.com/ordering/third-party-ordering · retrieved 2026-08-01
Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator
order-capture-order-ready-signal
Re-evidenced 2026-08-12. DoorDash's 18 May 2026 Preferred Integrations Program announcement names Qu in the 2026 cohort ('Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, and UrbanPiper', generated on performance and feature sets as of 8 May 2026), so Preferred status was retained a year after the inaugural 2025 cohort, which named the same ten plus ChowNow. DoorDash's provider-facing DPIP page makes 'Order Ready Signal' one of eight mandatory high-quality features and defines the bar: supporting a feature 'means that you've built and launched the feature and that it has been used by at least one DoorDash store'. Membership therefore asserts Qu shipped an order-ready signal on its DoorDash integration, not merely that DoorDash asks for one. Shortfall: the mechanism is undocumented -- no Qu-published page shows the signal is emitted automatically from POS or KDS state rather than a manual tap. Qu's own pages stop short: /kitchen-solutions/order-status is guest-facing ('shows guests the real-time progress of their order -- placed, in-prep, and ready'; 'pulls state changes directly from Qu KDS'), and /ordering/third-party-ordering says only 'bi-directional integrations sync with third-party providers in real time' and 'syncs automatically to Qu's KDS and Order Status to keep guests and drivers informed'. DoorDash's per-partner comparison tool renders no provider names in HTML, and no coverage beyond DoorDash (Uber Eats, Olo) is documented. Qu's API hosts are offline and its knowledge base is behind SSO. Prior note's quotation from the merchant criteria page ('Notify Dashers as soon as an order is ready for pick-up directly through your integration') was dropped: merchants.doordash.com/en-us/preferred-integrations has been redesigned and now carries only the bare bullet 'Order ready signals'. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-12 adversarially verified
Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.
order-capture-void-comp-controls
Qu First Gen 2.0 Admin Guide Chapter 6: Configuration (updated April 2020; Wayback capture 2020-08-08) documents operator-defined reason codes under System Lookups - 'add your own reasons for voiding a check or discounting an item... Void Reasons, Time Entry Reasons, Return Reasons, Paid In/Out Reasons, Discount Reasons'. Reason capture is enforced per-discount ('Require to Enter Reason for Discount?' in the discount definition) and per-void at the POS ('If required, you will be prompted for a void reason. Select the reason, and Tap Void/Remove Item', Next Gen 2020). Manager gating: 'Some discounts may be configured to require manager approval' (First Gen), and a 2020 Next Gen article gates restricted actions by job title so 'the POS will present a manager prompt to the cashier when performing restricted actions'. Exception reporting: the Qu Reports Quick Guide (Next Gen, Sept 2020) lists 'Voided Items - Displays all voided items by an employee', 'Refunds - Lists all refunded checks by an employee', a 'Discounts' report, and 'Labor Red Flag - ...useful for analyzing whether the store or employee uses specific actions (e.d voids) too often'. Vintage: documented for First Gen 2.0 and Next Gen 3.5 in 2020, not verified against today's Intelligent Commerce Platform; these are basic POS controls unlikely to have been removed. https://web.archive.org/web/20200808111044/https://support.qubeyond.com/hc/en-us/articles/360001267211-Chapter-6-Configuration-First-Gen-2-0- · retrieved 2026-09-03 adversarially verified
Menu, modifiers & pricing engine
Payments & money movement
The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator
payments-processor-choice
Status page lists FreedomPay and WorldPay as integrated payment providers; Aurus is a listed payments partner; online ordering supports "Qu Pay or third-party providers." https://status.qubeyond.com/ · retrieved 2026-08-01
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
No card-processing rates published anywhere on qubeyond.com; Qu Pay page is entirely qualitative. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-01
Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator
payments-dual-pricing
CLAIM: native dual-pricing / cash-discount mode storing two prices per item and printing both cash and card totals on the guest check and receipt. VERDICT no, on the same closed 177-file fixpoint census of admin.qubeyond.com detailed under menu-pricing-dual-pricing (172 loader-table chunks + 5 entry bundles, 24.0 MB, round-2 new refs 0). The receipt side is inside this corpus - the app owns /configuration/receipt-configuration and the kitchen-ticket settings - and nothing in it emits or formats a second total: 'cash price|card price' 0 hits, 'non-cash' 0, 'dual' in a pricing sense 0. The fee/service-charge editor is the only place a card cost could be added and it has no tender or card-product condition at all. This replaces the standing note's reliance on the Adyen-for-Platforms contract, which was the wrong object; the right object is Qu's own configuration app, and it is now held in full. BOUND: Qu's back office, not the POS terminal binary. Retrieved 2026-09-17. GRADE SET AT MERGE (324th): production JS bundle / script-loader census = grade B, not A, per the 321st precedent that downgraded sapaad override-audit A->B for source-map evidence. An anonymous OpenAPI spec can be A; first-party application code that the vendor does not publish as documentation cannot. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/015621cce7f2c63eedae.js · retrieved 2026-09-17 adversarially verified
Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator
payments-surcharge-guardrails
CLAIM: a surcharging engine that excludes debit and prepaid via BIN/product-code detection, enforces the network percentage cap, and toggles per location. VERDICT no. Bound to the closed 177-file fixpoint census of admin.qubeyond.com (see menu-pricing-dual-pricing for the census construction). EVIDENCE: Qu's fee engine is fully enumerated here and is a service-charge engine, not a surcharging engine. Its categories are gratuity, service charge and donation (categoryIds.gratuity, isServiceChargeDonationEnabled) and its types are percentage / fixed amount / open percentage / open amount. It DOES ship percentage and amount guardrails, but they cap a service charge, not a card surcharge: 'Maximum percentage of the check subtotal allowed as a service charge. If empty, no percentage limit applies. When both Max Percentage and Max Amount are set, the lower limit is enforced' and 'Maximum amount that can be applied as a service charge...'. There is no card-product dimension anywhere: the fee conditions are auto-apply/manual, prompt trigger, prompt on/after, item scope ('Apply only to these items'), and 'the operators will have the ability to add the service charge more than once'. CONTROLS over all 177 files: 'surcharge' 0; 'prepaid' 0; word-boundary 'debit' 0 and word-boundary 'BIN' 0 (the 5 apparent hits are KaTeX's binary-operator atom type, h="bin" / "mbin", inside 9d2ebbd87662f4946bbe.js - POISON); 'interchange' 0. Positive control: 'Fee', 'Service Charge', 'Gratuity', 'Donation', 'Tax Group' all present as UI strings. BOUND: this is Qu's own configuration app for POS fees; it is not the Adyen acquiring stack, so this says Qu ships no operator-configurable surcharging engine, not that Adyen could not surcharge. Retrieved 2026-09-17. GRADE SET AT MERGE (324th): production JS bundle / script-loader census = grade B, not A, per the 321st precedent that downgraded sapaad override-audit A->B for source-map evidence. An anonymous OpenAPI spec can be A; first-party application code that the vendor does not publish as documentation cannot. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/6609d6f8610f85dcfd3f.js · retrieved 2026-09-17 adversarially verified
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
Qu's Third Party Terms (the Adyen payment terms incorporated into Qu's Master SaaS Agreement) price "EMV-compliant payment terminal devices" as a one-time cost (17.4) and define a Payment Device as equipment that reads the card, registers the Shopper's approval and encrypts the Payment Details (18). Qu's Fall 2025 release also adds "Real-time payment connectivity visibility across EMV devices" for Aurus, FreedomPay, TriPOS and Verifone terminals. Shortfall: EMV chip acceptance is established, but nothing Qu publishes states that its terminals accept NFC contactless, Apple Pay or Google Pay — the only contactless/Apple Pay/Google Pay text on the site describes FreedomPay's own platform in a partnership press release, not Qu's terminal fleet. https://www.qubeyond.com/third-party-terms · retrieved 2026-09-03
Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator
payments-softpos-tap-to-pay
Zero hits for 'tap to pay', 'softpos' or phone-as-terminal across the legal set and all 199 pages. The Adyen contract is deliberately payment-method-agnostic — it says supported Payment Methods 'may change from time to time' and are set between Adyen, Qu and the schemes — so acceptance hardware is outside its subject. The Qu Pay launch release names the channels served ('point-of-sale, kiosks, drive-thru, web, and mobile') but that is a marketing selection, not an enumeration of acceptance methods. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: the phone itself accepts contactless cards and wallets (softPOS / Tap to Pay on iPhone or Android). VERDICT unknown. EVIDENCE: tokenised `tap to pay`, `softpos`, `contactless` = 0 across the 205 articles and the 53 PDFs. This is the first Qu corpus that enumerates acceptance hardware at all, and the enumeration is terminal-bound: an EMV reader ('How Do I Apply a Credit Card Payment Using the EMV Terminal?', 'What Should I Do if My EMV Reader is Not Working?'), an MSR ('How do I Use a Gift Card with an MSR?', the mag-stripe cleaning and driver articles), the Ingenico IPP320 PIN pad, and manual keyed entry ('How do I do a Manual (Keyed) Credit Card Entry?'). No phone-as-terminal form factor appears in either generation. The corpus predates Qu's move to Adyen, so it cannot exclude a current offering. Retrieved 2026-09-18. || 331st: NEW CONTROL (331st) on the rebuilt site's /pci-dss-compliance-guide, which enumerates in-person acceptance as terminals only ('The payment terminals provided by Adyen are all PTS-approved Point-of-Interaction (POI) devices'; E2EE or P2PE): that text is Adyen's generic guide copied word for word. Adyen's own page (docs.adyen.com/development-resources/pci-dss-compliance-guide/, robots.txt allows every agent incl. ClaudeBot at /) has the SAME terminal-only in-person section, while Adyen's own nav on that page describes in-person payments as 'Accept point-of-sale payments with our terminals and Tap to Pay'. So the guide's silence on phones is Adyen's boilerplate, not a statement about Qu's product, and cannot carry a `no`. The Qu Pay portal bundle's shopper-interaction list is POS / Ecommerce / ContAuth / POS MOTO / Pay by Link / Virtual Terminal, and its terminal-model fee table is data-driven (no model names in the bundle). NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. `tap to pay`, `softpos`, `NFC` = 0/209; the only `contactless` hits are the April 2023 FreedomPay partnership release ('supports contactless payments, QR technology, Apple Pay, and Google Pay' - card-present contactless on FreedomPay hardware, not the phone as terminal) and pandemic-era prose. Retrieved 2026-09-18. || 333rd: 333rd NEW CORPUS: Qu's video library - the YouTube channel @QuBeyond (85 uploads listed with yt-dlp; 54 caption tracks pulled into .cache/q333/qu/b/tr) plus the 45 Wistia media embedded on www.qubeyond.com resource-centre pages (media ids from the 331st rc corpus; public fast.wistia.com/embed/medias/<id>.json + /embed/captions/<id>.json, 42 English caption tracks, incl. 8 not on YouTube: the 05-07-26 webinar recording, Digital-First POS 1-Minute Demos 1-4, Winter 2025 highlights, FSTEC Innovation Forum, State of Digital LinkedIn Live, Trust & Technology) = 96 transcripts, 1.56 MB. Vendor video = grade C. In it `tap to pay`, `tap-to-pay`, `softpos`, `NFC` = 0; `contactless` = 2 (a customer's wish list, and curbside ordering 'contactless experience'). Fall 2025 highlights frames (Wistia pr1vxp0amv) show 'POS EMV Connectivity - comprehensive overview of your systems connectivity' across EMV devices, i.e. terminal-based acceptance; nothing shows a phone as the reader. Still no bound: the video set is marketing, not an acceptance-method enumeration. Retrieved 2026-09-18. adversarially verified
Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.
payments-pay-at-table
Vendor states the platform is not designed for table-service concepts; no pay-at-table handheld product is offered. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-01
Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator
payments-qr-guest-pay
Qu's only documented guest-phone QR flow is an ordering entry point, not scan-to-pay on an existing check: 'Tableside ordering allows guests to place and pay for their orders directly from their mobile devices while seated at the table, using a unique QR code to access the menu. The order is sent directly to the kitchen with the table number' — a feature of Qu's Online Ordering system, with curbside built the same way ('scanning a QR code displayed at the curb'). The guest authors and pays for their own order; no source describes a server-fired POS check being surfaced by a scan, viewed, paid and auto-closed. Whether Qu supports pay-the-check QR is undetermined on the open surface. || 325th: NEW SURFACE, measured, does not settle it. Qu's production web-ordering app (wo.qubeyond.com; script-loader fixpoint, 74 files, 4.6 MB, floor 71/73 chunk-table entries, soft-200 nonsense control documented on digital-group-ordering) has a complete 19-route table - login, loyalty-login, search-locations, menu-category, items, dashboard, recent-order, review-order-details, make-payment-screen, redirect-payment, order-confirmation, signup, forgot/reset-password, error - i.e. the guest can only pay for an order the guest is placing in that app. There is no check-lookup, view-check or pay-my-check route, and tokenised controls return `view check` 0/74, `pay my check` 0/74, `scan` 0/74. That is consistent with the existing note (Qu's QR flow is an ordering entry point) but does not close the cell, because the app that a printed-check QR would open has not been proven to be this one, and the POS itself is not a public surface. Retrieved 2026-09-17. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: guest scans a QR code on the printed check or table tent to view and pay the check from their own phone, closing the check in the POS. VERDICT unknown. EVIDENCE: the KB does contain an in-store QR payment flow, but its direction is the opposite of the claim. v139 (Nov 17 2020): 'In-Store Support for the Punchh “Single Scan Flow”. This enables a customer to scan a QR Code from their Punchh/Brand app and let them earn points for their purchases, redeem their rewards and pay using their stored gift card', with four named flows 'Customer Check-In with QR Code Flow / Customer Check-In and Pay with QR Code Flow / Customer Redeem Rewards and Check-In with QR Code Flow / Customer Check-In, Redeem Rewards and Pay with Gift Card via QR Code Flow'; the setup section adds 'The Single Scan workflow includes the ability to pay with a stored Mercury card.' The guest PRESENTS a code generated by the loyalty app and the terminal scans it; nothing renders a QR on a check or table tent, no guest-side check view exists, and the tender is a stored gift card rather than the guest's own card. `QR code` = 6 over the 205 articles, all Punchh Single Scan or the v142 bug 'Short QR Code scanning would fail'. Shortfalls every conjunct, so not a partial. Retrieved 2026-09-18. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. Every `QR` hit is off-claim: Winter 2025 tableside/curbside ordering (guest builds and pays their OWN order after scanning into the menu - already recorded), Fall 2025 'QR still works for loyalty' at the kiosk, and the April 2023 FreedomPay release's generic 'QR technology'. No page renders a QR on a printed check or table tent to pay an existing server-rung check. The Qu Pay portal bundle's remote-payment tools are 'Pay by Link' and a 'Virtual Terminal' ('Use this page to generate a payment link for a customer or pay from their primary stored payment method') - staff-initiated email links, not a guest scan of the check. Retrieved 2026-09-18. || 333rd: 333rd NEW CORPUS: Qu's video library - the YouTube channel @QuBeyond (85 uploads listed with yt-dlp; 54 caption tracks pulled into .cache/q333/qu/b/tr) plus the 45 Wistia media embedded on www.qubeyond.com resource-centre pages (media ids from the 331st rc corpus; public fast.wistia.com/embed/medias/<id>.json + /embed/captions/<id>.json, 42 English caption tracks, incl. 8 not on YouTube: the 05-07-26 webinar recording, Digital-First POS 1-Minute Demos 1-4, Winter 2025 highlights, FSTEC Innovation Forum, State of Digital LinkedIn Live, Trust & Technology) = 96 transcripts, 1.56 MB. Vendor video = grade C. NEW frames of Qu's own Tableside Ordering (Winter 2025 highlights, Wistia hrstnqffun): the guest phone flow is menu -> Checkout with a 'Table Ordering #8 - Your assigned table number is 8. We will deliver your order directly to you' banner and First/Last Name, Phone, Email fields, i.e. the guest authors a NEW order; no frame shows an existing server-rung check being fetched by scan. `scan to pay` = 0 in the 96 transcripts; the one `pay at the table` is a USHG guest on the podcast speaking generally. Adjacent (order-and-pay), held. Retrieved 2026-09-18. adversarially verified
Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.
payments-tip-adjust
Qu 'Next Gen 3.5' help article (updated April 2020; Wayback capture 2020-08-09) documents post-close tip adjust: check search, 'Select Payment to Adjust Tip (There could be more than one credit card on the check...)', enter the tip. It states the adjust window: 'Generally tips may only be adjusted on the same date.' The First Gen 2.0 Enterprise Configuration reference documents the pre-auth half - 'Require Credit Card Authorization: If set to "true", the terminal prints an authorization slip with tip line for credit card transactions... In Table Service mode, authorization slips are always printed for credit cards' - and a 2020 article gates tip adjust by job title so it 'will require manager approval to apply'. SHORTFALL: no on-device/customer-facing tip prompt on the EMV terminal is described in either generation's EMV payment article, and no manager screen listing unadjusted tips is documented (only a Labor 'Tip' report of tips collected by employee). Vintage: First Gen 2.0 / Next Gen 3.5 archive, 2020; live marketing site silent. https://web.archive.org/web/20200809112540/https://support.qubeyond.com/hc/en-us/articles/360042453371-How-Do-I-Adjust-a-Credit-Card-Tip-Next-Gen- · retrieved 2026-09-03
Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator
payments-tip-pooling
7shifts' "Tip Pooling for Qu POS" doc (updated 2026-06-24) states "Qu automatically transfers sales, payment, and tip information to 7shifts" and requires per-employee order/sale assignment in Qu POS, establishing per-employee tip capture in Qu. Shortfall: the pooling/distribution rule engine (by hours worked, sales, role percentage, or points) lives in 7shifts' separately licensed Tip Pooling module — "within 7shifts, the distribution of tips and gratuities among employees is automated" — not in Qu itself, which has no published tip-pool ledger. Same source/finding as labor-tip-pooling-rules and labor-tip-distribution-audit-trail. https://kb.7shifts.com/hc/en-us/articles/35540967177875-Tip-Pooling-for-Qu-POS · retrieved 2026-08-04
Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator
payments-offline-store-and-forward
POS page FAQ: "Does Qu POS work if the internet goes down? Yes. Qu POS processes transactions on Qu Business Edge (Qube), the on-site intelligence hub in every restaurant. Ordering, payments, and kitchen routing continue uninterrupted during connectivity outages, and data syncs to the smart cloud automatically when the connection is restored." Shortfall: offline card capture is asserted only as marketing on a feature page (grade C, below the grade-A/B floor a differentiator yes requires); no published documentation names a store-and-forward mechanism or any configurable per-transaction or cumulative offline limit. https://www.qubeyond.com/ordering/pos · retrieved 2026-09-03 adversarially verified
Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator
payments-offline-decline-liability
The claim is that the vendor PUBLICLY documents offline-decline loss allocation and a post-reconnect failure report. Qu's public offline-payments material — the Qu Business Edge page ('Full transaction processing continues... Sync resumes automatically with no manual intervention', 'No data loss during outages') and the 'Solving for In-Store Stability with Edge Computing' post ('offline payment acceptance') — promotes offline card acceptance without a word on who bears a decline on reconnect or any failed-offline-payments report. The help centre is login-gated (support.qubeyond.com 302s to Document360) and no public MSA/ToS exists, so the public documentation this claim requires verifiably does not exist. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-04
First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.
payments-gift-cards
Gift card is partner-delivered: Paytronix gift + loyalty integration across in-store, drive-thru, kiosk, mobile and web; Valutec/Worldpay gift processing appears on the status page. https://www.globenewswire.com/news-release/2026/06/23/3316041/0/en/paytronix-and-qu-further-integration-enabling-advanced-omnichannel-ordering-and-menu-management.html · retrieved 2026-08-01
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
Qu Next Gen 3.5 article (October/November 2020; Wayback capture 2020-11-28): 'Customers often use offline credit payment types to tender third-party DSP (DoorDash, Uber Eats, etc.), House Account, and other types of orders. However, managers would like to restrict their cashiers from using these without manager approval because they are not tied to a real tender type (cash, credit, or gift).' So a house account exists as an operator-created tender. SHORTFALL: it is only a payment type. The First Gen 2.0 Enterprise Configuration reference enumerates the payment-type categories available - 'Cash, Offline Credit, Check, Hotel Room Charge, Credit, Gift Card, GEM Room Charge, Marriott Room Charge, EmployeeMeal, Electronic Payment, Opera, StayNTouch' - with no house-account ledger among them, and no per-account credit limit, running balance, or statement/invoice generation is documented anywhere in the corpus. Vintage: First Gen 2.0 / Next Gen 3.5 archive, 2020. https://web.archive.org/web/20201128162138/https://support.qubeyond.com/hc/en-us/articles/360051880331-How-do-I-Prevent-Cashiers-from-Applying-Offline-Credit-Payment-Types- · retrieved 2026-09-03
A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.
payments-split-tender
Qu 'Next Gen 3.5' help article (updated April 2020; Wayback capture 2020-08-09): 'From the Payments screen, press the + number widget until you reach the number of desired payments... The amount due for each payment will automatically divide equally by the number of payments selected. To change the amount of a payment, touch the "Due" box and enter the desired amount. The other payments will automatically adjust. There is no limit to the number of payments or the combination of payment types.' Even shares, arbitrary amount and no cap are all explicit; the First Gen 2.0 Payments guide adds the same ('You may split check payments by any number of increments and by multiple methods') and a separate First Gen article documents splitting items between seats ('Seating allows you to split the items on a check between the customers on the check'). Vintage caveat: this is the archived 2019-2021 support site for First Gen 2.0 / Next Gen 3.5, not the current Intelligent Commerce Platform, and the live site is silent; multi-tender splitting is a basic POS mechanic unlikely to have been removed. https://web.archive.org/web/20200809111311/https://support.qubeyond.com/hc/en-us/articles/360041247211-How-do-I-add-an-Additional-Tender-Next-Gen- · retrieved 2026-09-03
Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.
payments-refund-void-controls
Qu Next Gen 3.5 article (October/November 2020; Wayback capture 2020-11-28): job-title switches in Enterprise Intelligence disable 'Perform Paid in and Paid Out', 'No Sale', 'Claim Till', and 'Once this change takes effect, the POS will present a manager prompt to the cashier when performing restricted actions'; sibling 2020 articles do the same for offline credit payment types and for Tip Adjust, and manager approval can be given by swiping a manager mag card. Discounts likewise: 'Some discounts may be configured to require manager approval.' SHORTFALL: the corpus documents role gating explicitly for no-sale, paid in/out, till claim/close, offline tenders and tip adjust - not for refunds or voids - and no immutable log identifying the APPROVING manager is documented. Chapter 12: Audit Trail covers admin-side configuration changes ('a detailed activity history of changes occurring within Qu... tracked based on Date, Employee, Module, Location'), while the Voided Items and Refunds reports name the acting employee only. Vintage: 2020 Next Gen 3.5 archive; live site silent. https://web.archive.org/web/20201128163422/https://support.qubeyond.com/hc/en-us/articles/360051880871-How-do-I-Prevent-a-Cashier-from-Performing-Manager-Related-Till-Functions-No-Sale-Paid-In-Out-and-Claim-Close-Till- · retrieved 2026-09-03 adversarially verified
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
Qu's merchant 'Payments Portal' at pay-admin.qubeyond.com is a Qu-controlled subdomain (Google Trust Services certs for pay-admin and test.pay-admin since 2026-02-12). It serves a white-labelled Zentact client on Adyen for Platforms (@3002097 "https://api.zentact.com/trpc"), and Qu is the Platform under its own Adyen for Platforms terms. The bundle has an in-product disputes table with 'Dispute Reason', 'Defendable' and 'Dispute Status' columns plus a row actions column (@2273204, @2275200). Status help for CHARGEBACK_UNDEFENDED reads "upload defense documents within the specified timeframe if you have compelling evidence to dispute this claim." (@2269401). The upload dialog reads "You can supply defense documents in the following file formats:" (@2280727). The Adyen defend flow has "disputes.management.defend.chargeback.title":"Defend chargeback" (@5734508). There is an 'Accept Dispute' action (@3007327, a key in the locale dictionary). SHORTFALL: evidence is JPG/TIFF/PDF documents the merchant uploads by hand, one per category. Nothing assembles it from the Qu POS transaction record. The portal is Zentact's product rather than Qu's POS, and neither Qu's site nor the bundle says which Qu Pay merchants can use it. The bundle never names Qu: all 13 `Qu` hits are a minified Sentry function name. https://pay-admin.qubeyond.com/assets/index-B_60PuKx.js · retrieved 2026-09-15 adversarially verified
Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator
payments-card-on-file
Qu's Zentact/Adyen-for-Platforms merchant 'Payments Portal' (pay-admin.qubeyond.com) keeps tokenised stored payment methods against a processor-side shopper record (merchantShopperId plus customerEmail), not against a documented Qu guest profile. The customer row has a 'Confirm Delete Card' dialog: "This will remove the card on file, and you will no longer be able to charge this card. Are you sure?" (@2207336, deleting by storedPaymentMethodPublicId). It has a 'No Saved Payment Methods' empty state (@2202226) and a preauthorise dialog ("Preauthorize Amount (Optional)" @2204089). That dialog sends paymentMethodIdToken with recurringProcessingModel:"UnscheduledCardOnFile" (@2214194). A merchant charge path uses the same model (@6220354). Portal role text grants "Initiate payments and pay with saved payment methods" (@2924201). SHORTFALL: this is a merchant-initiated charge of a vaulted card from a payments back office. Nothing shows the token on a Qu guest profile, or reused by the guest across Qu online ordering, phone orders and in-store. Nothing shows how cards get stored: no add-card or add-customer UI in the portal, and the Drop-in storePaymentMethod code (@~5.04-5.10M) is Adyen library code. The vault is Adyen's, reached through Zentact, and Qu's own pages never mention card-on-file. The no-merchant-PAN tail is implied by the token model and by clause 4.3 of Qu's Adyen terms, not stated in the portal. https://pay-admin.qubeyond.com/assets/index-B_60PuKx.js · retrieved 2026-09-15 adversarially verified
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
Qu Pay claims "on-demand settlements replace standard payout schedules" and unified payout reporting; no deposit schedule is published. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-01
A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator
payments-multi-entity-routing
Third Party Terms 7: "Adyen will Settle Customer Funds directly to each Customer on a gross basis ... meaning 100% of Transaction proceeds will be Settled daily", and "The Settlement of the Customer Funds will be exclusively made pursuant to Customer's binding Settlement instructions"; each legal entity is separately KYC'd and onboarded (3). The Qu Pay page markets "unified payout reporting across every location". Shortfall: the published terms achieve per-entity settlement by onboarding each legal entity as its own merchant of record rather than by routing one account's funds to multiple bank accounts, and no published source shows per-location bank-account routing configured inside a single merchant account. https://www.qubeyond.com/third-party-terms · retrieved 2026-09-03
Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.
payments-p2pe-pci4
Qu publishes a PCI DSS v4.0.1 compliance guide covering its payment stack. On in-person payments it states the terminals are "all validated and listed P2PE-approved solutions" with cardholder data "encrypted from the point of interaction until it reaches Adyen's secure decryption environment", that the processor is "a PCI DSS Level 1 Service Provider, with PCI DSS compliance assessed by an independent Qualified Security Assessor (QSA) annually", and instructs merchants to obtain the Service Provider's Attestation of Compliance. Shortfall: the guide describes the processor's (Adyen's) attestation, not a Qu-issued AoC or P2PE listing, and P2PE is one of two options — the default in-person integration is E2EE, not validated P2PE. https://www.qubeyond.com/pci-dss-compliance-guide · retrieved 2026-09-03
Kitchen & production
Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.
kitchen-station-routing
KDS offers load balancing with "flexible order routing, manual or intelligent rules-based" across production and fulfillment stations. https://www.qubeyond.com/kitchen-solutions/kitchen-display-system · retrieved 2026-08-01
An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.
kitchen-expo-consolidation
Item state syncs across production and fulfillment KDS stations in real time; a distinct expo screen with all-stations-bumped completion gating is not explicitly documented. https://www.qubeyond.com/kitchen-solutions/kitchen-display-system · retrieved 2026-08-01
Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator
kitchen-course-firing
KDS feature page lists 'Mulitple Firing Modes: Fire on tender, fire on next, fire on fly, and manual fire/suspend to fit any ordering or kitchen workflow.' A 2021 Qu post expands the same four modes (fire on fly / on next / on tender / manual fire). Shortfall: the mechanism is a per-item release rule plus a manual fire/suspend; nothing on qubeyond.com describes assigning items to named courses, nor firing a held course on demand from a server terminal, handheld or expo screen. https://www.qubeyond.com/kitchen-solutions/kitchen-display-system · retrieved 2026-09-03 adversarially verified
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
CLAIM: per-item cook times are configurable AND the KDS staggers item start/display so an order's items finish together. VERDICT partial - first conjunct met, second absent. NEW SURFACE: the standing note read only marketing release-highlights. In the closed 177-file fixpoint census of admin.qubeyond.com (172 loader-table chunks + 5 entry bundles, 24.0 MB, round-2 new refs 0) the menu item's operational-attributes form carries a validated per-item 'Prep Time' field (attribute.prepTime, integer, min 0 max 99999, shown only when isMenuItem; 6609d6f8610f85dcfd3f.js). SHORTFALL: nothing schedules or staggers from it. The only other time-aware kitchen objects in the whole census are batch production, not per-order coordination: /configuration/production-forecast with 'Minimum Production Threshold' ('Sets the minimum projected quantity required for batch production. When the threshold is not met, CTO (Cook to Order) is displayed instead of the forecasted quantity'), 'Hold Time' ('Maximum time (in minutes) a prepared batch can be held before it...'), 'Forecast Adjustment (%)', 'Forecast Rounding', and 'Prep guidance is based on sales forecasting, helping the kitchen prepare ahead for expected demand'. CONTROL: 'stagger' 0 hits; 'fire time|start time offset' 0; 'throttl' 30 hits, ALL POISON - VueUse's throttleFilter/throttledRef/throttledWatch in 114d90a8. Retrieved 2026-09-17. GRADE SET AT MERGE (324th): production JS bundle / script-loader census = grade B, not A, per the 321st precedent that downgraded sapaad override-audit A->B for source-map evidence. An anonymous OpenAPI spec can be A; first-party application code that the vendor does not publish as documentation cannot. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/6609d6f8610f85dcfd3f.js · retrieved 2026-09-17 adversarially verified
Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator
kitchen-order-throttling
No Qu source describes kitchen load throttling. The only adjacent material is a marketing bullet on the Oct 9 2024 'Qu's Smart Kitchen Vision' announcement — 'AI-generated promised ready times — improves delivery time accuracy by factoring in all channels, labor, and prep needs' — whose stated purpose is delivery-ETA accuracy, with no operator-configurable order-volume or ticket-time threshold, no gating condition and no pacing or delayed release of incoming digital orders. 'throttl' appears zero times across all 199 uncited www.qubeyond.com pages, and the ICP launch release mentions only 'production forecasting and dynamic kitchen load balancing to improve makeline speeds'. A predictive ready-time estimator is a different capability from a load-triggered throttle; undetermined on the open surface. || 324th: NEW SURFACE, not settling: the closed 177-file fixpoint census of admin.qubeyond.com holds Qu's whole kitchen and forecasting configuration and it paces PRODUCTION, never order release - /configuration/production-forecast with 'Minimum Production Threshold' ('When the threshold is not met, CTO (Cook to Order) is displayed instead of the forecasted quantity'), 'Hold Time', 'Forecast Adjustment (%)', 'Forecast Rounding', 'Number of minutes in which the forecast section will be updated', plus /configuration/kitchen-footprints and /configuration/kitchen-ticket-settings. No order-volume or ticket-time threshold, no delayed release and no quoted-time extension appears. CONTROL: the 30 'throttl' hits are all VueUse (throttleFilter/throttledRef/throttledWatch) - POISON. A digital-order release valve would sit in the order pipeline, not the back office, so this stays unknown. Retrieved 2026-09-17. || 325th: NEW CORPUS MEASUREMENT, no move. Over the production app corpora - admin.qubeyond.com's 175-chunk script-loader fixpoint (24 MB), the wo.qubeyond.com web-ordering fixpoint (74 files, 4.6 MB) and the 6.3 MB pay-admin Payments Portal bundle - tokenised controls return `throttling` 0 in all three and `throttle` 6/175 admin, 1/74 wo, 1 in pay-admin, ALL OF WHICH ARE LIBRARY POISON: RxJS/VueUse's throttle option destructuring ('{throttle:r=0,trailing:o=!0,leading:c=!0}'), the NuxtLoading progress bar's 'throttle:200' timer, and Sortable's throttle helper. `quote time` and `promise time` are 0 in all three. The one adjacent surface that is real is prep time (37 hits in 5/175 admin chunks), which the 324th already scored on kitchen-prep-time-pacing; nothing in it pages or delays release of digital orders on a volume or ticket-time threshold. Retrieved 2026-09-17. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: automatic pacing/delay of incoming digital order release, or extension of quoted prep times, once a configurable volume or ticket-time threshold is crossed. VERDICT unknown. EVIDENCE: tokenised `throttl*`, `pacing`, `conveyor` = 0 across all 205 KB articles and all 53 PDFs. The kitchen-side articles that would carry it document routing and bump behaviour only ('What are KDS/Printer Fire Modes and How are They Enabled?', 'How do I Prevent Bumping a Chit on the KDS?', v139 'Kitchen Routes - Added setting to Print Default Modifiers'), and the 56-page EI admin manual's Chapter 8 (Printing: Kitchen Print Groups, Terminal Print Groups, Printers, Check Sharing Groups) lists every kitchen configuration screen of that generation with no throttle, quota or pacing object among them. Retrieved 2026-09-18. || 328th: NEW CONTROL (328th) on the CURRENT back office, which the prior note did not cover (it bounded only the retired KB): `throttle` scores 8 in the 24.4 MB 177/177 admin.qubeyond.com census and all 8 are POISON - the Vue loading-bar option (`{throttle:200,duration:5e3}`, `clearTimeout(this._throttle)`) and a Sortable.js utility export `throttle:P`. `pacing`, `quota`, `conveyor` = 0. Order pacing would live in the store-level POS/KDS, for which Qu ships no readable public app, so the cell stays unknown rather than taking a `no` from a back-office census. Retrieved 2026-09-18. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. `throttl*`, `pacing`, `order release` = 0/209; the only load language is the ICP release's 'dynamic kitchen load balancing to improve makeline speeds' (already recorded) and generic cloud 'load balancing'. The current admin's one order-flow setting string is 'Determines how incoming orders are distributed across kitchen devices' - distribution across screens, not delay of release. Across the 1,398 distinct $gettext strings of the 177/177 admin census there is no busy-mode, quote-time, capacity or order-limit setting ('Production Lead Time', 'Prep Time', 'Hold Time' are production-forecast fields). Retrieved 2026-09-18. || 332nd: 332nd. NEW SURFACE (332nd): the ten Google Sheets IMPORT TEMPLATES linked from the admin.qubeyond.com bundle (templateUrl, docs.google.com/spreadsheets/d/<id>, anonymously exportable; docs.google.com robots is a generic `*` file naming no Claude agent): Menu, Item Master (v169 release), Kitchen Priority, Price (x2), Discounts Item Groups, Store, Employee, Employee Info, External ID. They are Qu's own column enumerations for bulk configuration. The Kitchen Priority Import Template's columns are exactly Item ID, Report Title, Kitchen Priority (example rows Fries, Curly Fries, Lettuce) - an item SEQUENCING priority for the make-line, not a volume threshold, release delay or quote-time extension; the Store Import Template (Store Group, Reporting/Receipt/Marketing Name, address, Time Zone, Day Start Time, Payroll/Reporting Period, Configuration Tags) has no capacity or pacing column. Back-office only; held. Retrieved 2026-09-18. || 333rd: 333rd NEW CORPUS: Qu's video library - the YouTube channel @QuBeyond (85 uploads listed with yt-dlp; 54 caption tracks pulled into .cache/q333/qu/b/tr) plus the 45 Wistia media embedded on www.qubeyond.com resource-centre pages (media ids from the 331st rc corpus; public fast.wistia.com/embed/medias/<id>.json + /embed/captions/<id>.json, 42 English caption tracks, incl. 8 not on YouTube: the 05-07-26 webinar recording, Digital-First POS 1-Minute Demos 1-4, Winter 2025 highlights, FSTEC Innovation Forum, State of Digital LinkedIn Live, Trust & Technology) = 96 transcripts, 1.56 MB. Vendor video = grade C. NEW, adjacent: (a) the Intelligent Commerce Platform video (Wistia md64bsf5be = YouTube wMlTC2ZM_nc, 126 distinct 1080p frames read) shows two live qu-kitchen KDS stations whose footer reads 'LOAD BALAN[CING]' | QUKDS-WIN-1/-2 | ORDERS | AVG 07:07/06:44 (dated 11/06/2025) under the caption 'Balance the kitchen in real time ... Orders route to least busy makeline' - load-based ROUTING across make-lines, not pacing, delayed release or quote extension. (b) In Qu's own webinar 'The Forgotten Kitchen' (YouTube YHhcFXc-wY8, ~2773 s) the Qu speaker says 'we have some customers that want to throttle, they want their in-store associates to have the ability to turn off individual channels, maybe have them auto-turn on after a certain daypart or a certain threshold has been reached; others ... want dynamic AI-based promise ready times as a mechanism to throttle ... that's a problem we want to tackle' - customer demand and roadmap, no shipped threshold. (c) The 2023 State of Digital report (Wayback, wp-content/uploads/2023/03, 43 MB, read whole) lists 'better predict and manage order flow, throttling, timing' only as a survey trend. `pacing` = 0 in the 96 transcripts. Held. Retrieved 2026-09-18. || 334th: CLAIM: see taxonomy. VERDICT: unknown (held). 334th: the on-disk KitchenUP-white-paper.pdf (.cache/q333/qu/a/pdf) was never read - it is TRUNCATED at exactly 1,048,576 bytes (no EOF marker), and the only Wayback capture (20230129001412) is truncated at the same byte, so it was salvaged by inflating its content streams (8.9 KB of text, pp. 1-6 of text recovered). It is a 2020 Networld Media Group white paper 'Restaurant Models for the Post-Pandemic World' ('Sponsored by Punchh'), third party and retired-generation: KitchenUP = Qu-1Tablet ('manages orders through a single interface and sends them directly to the kitchen') + Qu-1Menu, 'native third-party delivery integrations and multi-brand reporting', 'improves digital order production speed, efficiency and accuracy'. `throttl`, `delay`, `prep time`, `quote` = 0; the 2 `pac(e|ing)` substring hits are POISON (`spaces`, `space`) and the 2 `capacity` hits are 'dine-in capacity' / 'excess kitchen capacity' - POISON, host-kitchen business model). Retired doc: carries no no. 334th also fetched the Dynamic Stores (YouTube iMNqtW46VxU, 1080p, 101 frames) and Enterprise Intelligence (Vpx_HWZK2HQ, 6 frames) product videos: menu-item configuration and marketing slides only, no kitchen pacing. Retrieved 2026-09-18. adversarially verified
Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator
kitchen-channel-pause-propagation
DOWNGRADED FROM `yes`/B BY THE VERIFICATION PASS, 2026-09-12. The 2026-09-12 note correction was warranted and stands: the clause ‘item 86ing to DoorDash is a DPIP requirement Qu meets’ was an instance of the Preferred syllogism and DoorDash’s registry falsifies it — `ITEM_LEVEL_86` reads false for `qubeyond_v2`, which carries 7 of the 8 high-quality features, not 8. But withdrawing that clause removed the only documentation-grade support the `yes` had. What survives is Qu’s own Channel Management product page, which asserts that operators can pause third-party integrations and re-sync menus from one dashboard. That is a first-party feature page written to sell, so grade C, not B — the same page is the sole basis for several other Qu cells graded C and D. A differentiator `yes` may not rest on it. SHORTFALLS, all three real. First, the claim names DoorDash, Uber Eats and Grubhub, and only DoorDash carries counterparty attestation: `STORE_AVAILABILITY_WEBHOOKS` (‘Integrated close/pause store’) reads TRUE for `qubeyond_v2` in DoorDash’s partner registry (https://merchants.doordash.com/api/partner-integrations, retrieved 2026-09-12, md5 e638fc99931673ecdcdbbb3ea2fbbfaf) inside an `active: true` collection. Nothing establishes automatic propagation to Uber Eats or Grubhub. Second, the claim is a disjunction (‘Pausing a store or 86ing an item’) and only the pause disjunct is supported; the item-availability disjunct is unattested, `ITEM_LEVEL_86` being false — which is not read here as positive evidence of absence, merely as carrying nothing. Third, the vendor page documents an operator action taken in one dashboard, not that the resulting pause reaches each connected marketplace automatically, which is what the claim asserts. https://www.qubeyond.com/management/channel-management · retrieved 2026-08-01 adversarially verified
Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator
kitchen-order-ready-callback
Order ready signal is a required DPIP capability; Qu KDS syncs automatically to Qu Order Status and third-party channels. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
Qu blog on its KDS: 'Qu KDS also supports order navigation and bump bar functionality, allowing staff to move through orders, make check-level edits, and undo previous actions.' Shortfall: bump-bar support is asserted in a marketing post only; no supported bump-bar or programmable-keypad models are named anywhere on qubeyond.com, and support.qubeyond.com is login-walled. https://www.qubeyond.com/resource-center/qus-kds-delivering-a-holistic-view-of-your-ordering-production-capabilities · retrieved 2026-09-03
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
Fall 2025 release highlights, item 10: 'KDS Item Count View: Real-Time Kitchen Insights — Kitchen teams can now see, at a glance, how many of each item or ingredient needs to be prepped... a clear view of exactly how many items need to hit the grill or fryer.' The companion Fall 2025 overview repeats 'Real-time kitchen item counts'. Per-modifier aggregation is not stated. https://www.qubeyond.com/resource-center/qus-fall-2025-product-release-highlights · retrieved 2026-09-03
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
Qu Notify raises configurable alerts on service-time thresholds and a Kitchen Intelligence Score; per-station color escalation on the KDS is not documented. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-01
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
Qu's back-office configuration client lets an operator designate a 'Backup Device' for each kitchen printer or KDS device (field backupPrinterId, with a 'No Backup Device' option), and kitchen print routes carry backup printer lists alongside the primary printers; deleting a device that is in use warns it 'is being used as backup printer'. Shortfalls: nothing Qu publishes says when the backup is used -- whether tickets move to it automatically when the primary goes offline or only by operator action -- because the POS/KDS runtime that executes routing is not public; the 'considered offline' timeout in the same editor applies only to receipt printers, not kitchen devices; and no ticket-loss guarantee is stated. The feature is not offered for production optimization boards or load-balancer printers. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/749bc93baeb2fdcfa467.js · retrieved 2026-09-15 adversarially verified
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
Re-fetched 2026-08-02. The page states core services execute on-site - "POS, payments, order routing, and kitchen workflows" - with "uninterrupted operations with offline mode", "system state is preserved locally" and "sync resumes automatically with no manual intervention". Shortfall: this is contingent on deploying the Qu Business Edge (Qube) on-premise appliance, which Qu markets as a distinct offering with unpublished packaging and price; it is not established as a property of the base cloud platform. Nothing documents KDS ticket queueing, bump-state retention, or reconciliation on reconnect. Qu publishes no publicly retrievable product documentation: support.qubeyond.com (the 'Qu Campus' Document360 portal) redirects to a login, and both qu-api.qubeyond.com and qu-pos-api.qubeyond.com return HTTP 403 behind a mismatched TLS certificate. No grade A/B evidence is obtainable, so a differentiator 'yes' cannot stand. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-02 adversarially verified
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
"Dynamic order cells" with detailed order info; recipe-step or portioning build screens are not documented. https://www.qubeyond.com/kitchen-solutions/kitchen-display-system · retrieved 2026-08-01
Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator
kitchen-pizza-fractional-display
Qu's KDS is described as 'color-coded, fully configurable, displaying every order detail including modifiers across every channel in real time' (Smart Kitchen Vision), and Winter 2026 adds collapsible KDS cells and menu/modifier images at POS — but nothing addresses how a sectioned or fractional topping is rendered on the make-line. Make-line rendering of halves and quarters is a screen-behaviour detail that only operator documentation would show, and Qu ships a build-your-own pizza brand (Blaze), so an absence verdict here would be manufacturing. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: the make-line/KDS renders sectioned or fractional toppings (halves, quarters) with placement. VERDICT unknown. EVIDENCE: Qu's KDS rendering IS documented at portion granularity, and portions are sizes, not placements. v139: 'Items and modifiers now display with their portion amount on the same line on the Detail screen, KDS, Printers, and Customer Facing Displays'; v141: 'modifier deviation printing for Portions is now supported'; the EI manual's worked example is an item 'Mac & Cheese' with portions 'Regular' and 'Large'. Tokenised `fraction*`, `half and half`, `pizza` = 0 across the 205 articles and the 53 PDFs. Retrieved 2026-09-18. || 331st: NEW MEASUREMENT (331st): the 1,398 distinct $gettext strings of the 177/177 admin.qubeyond.com census model modifiers by PORTION only - 'Default Portion', 'Hide Portion' ('If checked, hides the portion prefix once the item is added to the order'), 'Edit Default Quantity and Portion', 'Print Checkboxes for Modifier Items', 'Send Defaults to Kitchen'. No placement/half/section attribute. Tokenised `half`, `quarter`, `placement` in the bundles are ALL POISON: Bulma CSS (`.column.is-half`), Font Awesome (`fa-battery-half`, `fa-pizza-slice`), moment/luxon (`quarter`), v-tooltip `placement:"bottom"`. NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. `pizza` never co-occurs with KDS/topping/make-line in any page, including both Blaze Pizza pages. Held unknown: the back-office data model does not bound what the store KDS renders. Retrieved 2026-09-18. || 332nd: 332nd. NEW SURFACE (332nd): the ten Google Sheets IMPORT TEMPLATES linked from the admin.qubeyond.com bundle (templateUrl, docs.google.com/spreadsheets/d/<id>, anonymously exportable; docs.google.com robots is a generic `*` file naming no Claude agent): Menu, Item Master (v169 release), Kitchen Priority, Price (x2), Discounts Item Groups, Store, Employee, Employee Info, External ID. They are Qu's own column enumerations for bulk configuration. The Menu Import Template's full column list is Action, Menu Path, Item Type, Item Report Title, Price Type, Portions, Base Price, Unit Type, Item Title, Description, Screen Title, Check Title, Kitchen Title, Min/Max Items Quantity, Quantity included in Price, Visible, Enabled, then Child Item 1..N (Item Type, Report Title): modifiers are child items with a Portions field and a Kitchen Title, and there is no placement/half/section column. Back-office data model only; it does not bound what the store KDS renders, so held. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACE: Qu's 'Product Feature | POS Interface' demo (YouTube 3c0DpW8Onp0, 2020 build, 1080p, 33 distinct frames read) shows a Build Your Own pizza on the store POS: modifier columns 'QuPizza - Crust Choice', 'Cheese Base', 'Meat Toppings 0 Total (Up to 5 More)', 'Veggie Toppings (Up to 7 More)', 'Cheese Toppings (Up to 4 More)', 'Sauce Choice', each topping a single tile priced 0.15-0.25 with NO left/right/whole placement control on that screen. It is the 2020 POS order-entry screen, not the KDS, and 2020 is a prior generation, so it bounds nothing about current make-line rendering. Held. Retrieved 2026-09-18. adversarially verified
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
Qu's KDS post says bump-bar navigation lets staff 'move through orders, make check-level edits, and undo previous actions', and that KDS cells use 'different colors for new, modified, voided, and resurrected orders' — a resurrected (recalled) order state. Shortfall: the described undo/resurrect is at check level; no per-item refire or ticket reprint without re-entering the order is documented. https://www.qubeyond.com/resource-center/qus-kds-delivering-a-holistic-view-of-your-ordering-production-capabilities · retrieved 2026-09-03
Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator
kitchen-order-modification-alerts
Staff can update submitted orders directly on the KDS with item state syncing in real time; explicit visual flagging of added/changed/removed items is not documented. https://www.qubeyond.com/kitchen-solutions/kitchen-display-system · retrieved 2026-08-01
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
Re-fetched 2026-08-02. Qu Order Status shows guests the "real-time progress of their order - placed, in-prep, and ready", pulling "state changes directly from Qu KDS", with layout, co-branding, orientation and multilingual header options. Shortfall: this is an in-store display only - the page contains no SMS, text, push, or pager notification to the guest's own device, so the guest must be present and watching a screen. Qu publishes no publicly retrievable product documentation: support.qubeyond.com (the 'Qu Campus' Document360 portal) redirects to a login, and both qu-api.qubeyond.com and qu-pos-api.qubeyond.com return HTTP 403 behind a mismatched TLS certificate. No grade A/B evidence is obtainable, so a differentiator 'yes' cannot stand. https://www.qubeyond.com/kitchen-solutions/order-status · retrieved 2026-08-02 adversarially verified
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Re-evidenced 2026-08-08 after the previously cited /products/ page went dead. The live Smart Kitchen Solutions index enumerates exactly three kitchen products - KDS ("brings clarity and control to high-volume kitchens"), Order Status, and Energy & Equipment Intelligence - and names no waste, spoilage, remake or reason-code function. The /platform Platform Solutions navigation lists the complete catalog (Ordering: POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering; Kitchen: KDS, Order Status, Energy & Equipment Intelligence; Payments: Qu Pay; Management: Unified Menu Management, Channel Management, Brand & Franchise Management, Notify, Unified Data & Reporting; plus Qube, Qu Equip, Qu Business Edge) with no inventory module. The /integrations directory (all 120 partners enumerated) files inventory and food cost under "Back of House + Labor" - MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet. With no native inventory ledger, a KDS waste entry that depletes inventory cannot exist. https://www.qubeyond.com/kitchen · retrieved 2026-08-08
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
Real-time prep tracking and service-speed metrics surfaced in Notify and reporting; percentile slicing and CSV/API export of station times are not documented. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-01
Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.
kitchen-prep-forecasting
The menu page claims "AI-connected demand and daypart intelligence," the same evidence already used for reporting-sales-forecast ("a daypart-granular forecast surface consumable by scheduling is not documented"). Shortfall: this is demand/daypart intelligence for menu and pricing decisions — nothing establishes it produces a prep list or predicted prep quantity surfaced to kitchen staff as a daily task list, which is what this claim specifically requires. https://www.qubeyond.com/management/unified-menu-management · retrieved 2026-08-04
Delivery, dispatch & third-party channels
Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).
delivery-driver-roster
Re-evidenced 2026-08-08 after the cited /products/ page began redirecting to the homepage; the reasoning is unchanged and both legs re-verified on live pages. Absence: the /ordering section index enumerates the complete ordering line-up - Point of Sale, Kiosk, Drive-thru, Third-party Ordering, Online Ordering - and the site-wide Platform Solutions nav enumerates the whole 14-product platform, with no delivery, driver or dispatch module anywhere. Affirmative alternative: the Online Ordering page enumerates fulfillment as 'Multiple Hand-Off Modes: Flexible fulfillment options including in-store, curbside, tableside, and white-label delivery', and the integrations directory carries a 'Delivery' category (Cartwheel, Checkmate, DoorDash, GrubHub, UberEats, ezCater). Drivers are not first-class entities in Qu; the vendor enumerates the third-party route instead. Same reasoning carries the sibling delivery-dispatch-board / route-map / driver-tracking / driver-comp / cash-reconcile 'no' scores, which cite the same dead URL and need the same re-pointing. https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-08 adversarially verified
Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).
delivery-dispatch-board
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The live Omnichannel Ordering index enumerates five products - POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering - and its only delivery statement is marketplace-facing: "Connect every major delivery marketplace directly to your POS - eliminating tablet chaos, manual entry, and costly middleware." No dispatch or expo-for-delivery screen appears in the /platform Platform Solutions nav either. The /integrations directory's "Delivery" category is six marketplaces and aggregators (DoorDash, UberEats, GrubHub, Checkmate, ezCATER, Bites) plus Cartwheel, a third-party delivery dispatch and driver-management platform - i.e. Qu routes the dispatch function to a partner. https://www.qubeyond.com/ordering · retrieved 2026-08-08
Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator
delivery-route-map
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The Platform Solutions navigation enumerates the entire product line - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip, Qu Business Edge - with no dispatch, mapping or routing product. The /ordering index describes delivery only as "Connect every major delivery marketplace directly to your POS". Route sequencing is a partner function: the /integrations "Delivery" category lists Cartwheel, a third-party dispatch and routing platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The Platform Solutions navigation enumerates every Qu product and the only mobile app in it is Qu Notify Mobile Insights, a manager reporting app - there is no driver-facing application, and therefore no source of driver GPS. The /ordering index describes delivery solely as "Connect every major delivery marketplace directly to your POS". Live driver location is a partner capability in Qu's own directory: the /integrations "Delivery" category lists Cartwheel, a third-party dispatch and driver-tracking platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator
delivery-zones-polygon
Qu Next Gen 3.5 release notes for v139 (17 Nov 2020; Wayback capture 2021-01-25) introduce a store-level Delivery Setting: 'New Delivery Setting at Store level that allows to set a Custom Area or a Delivery Radius.' The walkthrough is explicit: 'Besides being able to define delivery settings via a Maximum Delivery Radius, users will have the flexibility to configure their own custom delivery area... go to any Store, Delivery Settings tab and select: Custom Area. The system will request a KML file to be uploaded and once uploaded will show a map to preview the area.' The operator draws the shape in Google MyMaps ('Add lines or draw a shape. Draw the shape on the map to create your custom delivery zone'), exports KML, and sets Calculation Mode to Custom Area; the store must have a valid address 'so that the system can automatically generate coordinates.' That is an arbitrary map polygon, not a radius or ZIP list. VINTAGE: this is the 2020 Next Gen 3.5 generation, not the current Intelligent Commerce Platform; the live site (qubeyond.com/ordering/online-ordering, grade C) still advertises 'white-label delivery' as a hand-off mode but does not describe zone geometry, so persistence of the KML custom-area mechanism into the current product is not independently confirmed. Note also the article records that a drawable in-product map was then only 'in the roadmap'. https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360052896691-November-17th-v139- · retrieved 2026-09-03
Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.
delivery-zone-pricing
SHORTFALL: the documented model is one delivery area per store, not priced zones. Qu Next Gen 3.5 v139 (17 Nov 2020) documents a single store-level Delivery Settings tab whose Calculation Mode is either a 'Maximum Delivery Radius' or one uploaded KML 'Custom Area'; nothing in that configuration carries a fee, an order minimum or a quoted promise time. The delivery fee lives elsewhere entirely, as a service charge: Chapter 6 Configuration (First Gen 2.0) says 'Service charges such as gratuities or delivery fees may be added to Qu' with a Service Charge Category of 'Service Charge / Delivery Fee / Other Charge / Gratuity / Automatic Service Charge', configured at enterprise/store level against items, not against a geographic zone. So a fee and a validated delivery area both exist and are applied per store from the validated address, but per-zone fee/minimum/promise-time tiering is not documented anywhere in the archived corpus. VINTAGE: First Gen 2.0 (2018) settings reference plus Next Gen 3.5 v139 (2020); current product not covered. https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360052896691-November-17th-v139- · retrieved 2026-09-03
Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.
delivery-address-validation
Qu Next Gen 3.5 help article 'Changing Order Types from the Online Menu' (updated 19 Oct 2020; Wayback capture 2020-11-25): 'Guest will be prompted by the website to enter the delivery address to validate that delivery is available from this location. An actual physical address is required (i.e. 123 Main Street). If the store can deliver to the provided address, the user will get a success message... If the location cannot deliver to the provided address, the user will be prompted to either order pickup or search for other sites.' Out-of-zone addresses are therefore flagged and blocked before the order proceeds: 'Since a valid address is required to ensure the location can deliver, users will be required to enter and submit one before they can exit the prompt.' Geocoding against a mapping service is corroborated by the v139 delivery-area notes, which require a valid store address 'so that the system can automatically generate coordinates for the location' and use Google MyMaps/KML geometry for the area. VINTAGE: Next Gen 3.5, 2020 documentation; the live marketing site still lists delivery as a hand-off mode (grade C) but does not describe address validation, so the current implementation is not separately confirmed. https://web.archive.org/web/20201125102417/https://support.qubeyond.com/hc/en-us/articles/360048239071-Changing-Order-Types-from-the-Online-Menu-Next-Gen- · retrieved 2026-09-03
Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator
delivery-driver-comp
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The Platform Solutions navigation enumerates the whole catalog and contains no driver, delivery-dispatch or payroll product, so there is no place to record mileage, per-delivery reimbursement or driver-retained tips, and no first-party payroll target to export wage-versus-reimbursement lines to. The /integrations directory confirms both halves are bought in: "Delivery" carries Cartwheel (dispatch/driver management) and "Back of House + Labor" carries Proliant (payroll) alongside 7shifts, HotSchedules, Harri and Workstream. https://www.qubeyond.com/platform · retrieved 2026-08-08
Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.
delivery-cash-reconcile
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The Platform Solutions navigation enumerates every Qu product and includes no driver or delivery-dispatch module, so there is no driver to bank, no run assignment to reconcile against and no per-driver over/short report. The /ordering index treats delivery only as "Connect every major delivery marketplace directly to your POS", and the /integrations "Delivery" category assigns driver management to the partner Cartwheel. https://www.qubeyond.com/platform · retrieved 2026-08-08
Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.
delivery-daas-dispatch
Verified verbatim 'Flexible fulfillment options including in-store, curbside, tableside, and white-label delivery.' No courier network is named, no quote/assign/status contract is documented. Partial is the ceiling; do not let anyone read this as native dispatch. https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-01 adversarially verified
Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator
delivery-daas-fallback
NEW EVIDENCE from the production back-office bundle set (admin.qubeyond.com, the Nuxt script-loader corpus taken to a fixpoint in the 324th: 175 chunk files, 24 MB, held at .cache/q324/qu/nuxt). CLAIM: hybrid dispatch - rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. VERDICT: no. EVIDENCE: the back office's channel-attribute module carries the CLOSED enumerations that govern how a store's ordering channel fulfils orders, verbatim from admin chunk 8fc0d1fe5de12dff9911.js: availablePickupMethods 'e[e.WalkIn=0]="WalkIn",e[e.CurbsidePickup=1]="CurbsidePickup",e[e.DriveThru=2]="DriveThru"'; the delivery option enum 'e[e.OwnDelivery=0]="OwnDelivery",e[e.ThirdParty=1]="ThirdParty"'; the delivery provider enum 'e[e.DoorDash=1]="DoorDash"'; the channel enum 'e[e.Web=0]="Web",e[e.WebCatering=1]="WebCatering"'; and a catering provider enum 'e[e.DoorDash=1]="DoorDash",e[e.InHouse=2]="InHouse"'. The screen that writes them (chunk 87c2a3b01adfe10ed9b8.js, labels 'Delivery', 'Delivery Provider', 'DoorDash Drive', field doorDashDriveEnabled) binds a SINGLE method - every read and write is availableDeliveryMethods[0] - and its handler makes the two mutually exclusive: 'var e=r.value.availableDeliveryMethods[0].deliveryProvider; r.value.availableDeliveryMethods[0].deliveryOption = e===I.i.DoorDash ? I.b.ThirdParty : I.b.OwnDelivery'. There is no second method slot, no rule builder, no driver-availability, zone or wait-threshold input anywhere in the delivery configuration, and no courier-selection logic. BOUND/CONTROLS: corpus = 175 admin chunks + the 74-file wo.qubeyond.com web-ordering census described on digital-group-ordering + the 6.3 MB pay-admin Payments Portal bundle. Tokenised, word-boundary, case-insensitive: `courier` 0/175 admin, 0/74 wo; `own delivery` 4/175 (all the enum above); `delivery provider` 13 hits in 2/175 (all the screen above); `DoorDash Drive` 2 hits in 1/175. POISON, and it is severe on this cell: `dispatch` returns 1,032 hits in 103/175 admin files and every one is Vuex/Vue `store.dispatch()` - the prior note's finding that 'dispatch' was absent from the marketing corpus must not be read as a bundle result; and `fallback` returns 7 hits in 3/175, all vue-router mode fallback, Nuxt's client-only loading slot and Sortable's fallbackClass. NOT COVERED: if Qu ships a separate driver-dispatch console on another host, it is outside this corpus. Retrieved 2026-09-17. https://admin.qubeyond.com/ · retrieved 2026-09-17 adversarially verified
Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator
delivery-3p-direct-integration
Direct bi-directional integrations with Uber Eats, DoorDash, Grubhub, EZCater and Monkey, "no middleware required"; corroborated by DPIP 2026 membership. https://www.qubeyond.com/ordering/third-party-ordering/ · retrieved 2026-08-01
Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.
delivery-3p-injection
Orders inject straight into the POS and KDS with no tablet re-keying; Qu cites a 0.2% error rate vs 0.7% industry average and 99.8% order success. https://www.qubeyond.com/ordering/third-party-ordering/ · retrieved 2026-08-01
Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).
delivery-86-sync
331st. NEW SURFACE (331st): the rebuilt www.qubeyond.com RESOURCE CENTRE, never fetched by the 327th (which fetched only the 39 non-resource-centre pages of the 248-URL sitemap): 198 /resource-center/ + 11 /case-studies/ URLs, 207 at 200 and 2 at 301, 1.0 MB of stripped text, incl. new 2026 pieces (the Aug 4 2026 menu-management guide, Winter 2026 / Fall 2025 / Spring 2025 release highlights). Marketing = grade C. CLAIM: an 86 in the POS pushes item-level out-of-stock to connected third-party channels in near real time and restores on availability. VERDICT partial/C. EVIDENCE (first-party, current, re-fetched live 2026-09-18 at 200): the Aug 4 2026 guide https://www.qubeyond.com/resource-center/restaurant-menu-management-system-multi-location-guide - 'One edit on Qu's single menu system pushes everywhere at once, including DoorDash, Uber Eats, and Grubhub, so 86-ing an item takes effect in minutes rather than an afternoon'; '86 an item because you ran out, and within minutes, it's gone from every channel, no tablets touched, no separate logins'; 'Every 86, every price change, every LTO start and end date lives in one place and pushes to each delivery platform on its own'. Corroborated by two product pages already on disk that no prior pass cited for this cell: https://www.qubeyond.com/ordering/pos FAQ - 'Qu POS shares a single unified menu engine with kiosk, drive-thru, online, and third-party channels ... Price changes, modifiers, and 86'd items update everywhere simultaneously with no manual sync required'; https://www.qubeyond.com/ordering/online-ordering FAQ - 'price changes and item availability publish instantly across web, kiosk, POS, drive-thru, and third-party'. The back office corroborates the 86 object (0/1 inventory toggle, Revive, per-store propagation; 325th/328th). SHORTFALLS (why not yes): (1) marketing-only, grade C - no operator doc states the per-channel mechanism; (2) DoorDash's own partner registry reads ITEM_LEVEL_86 FALSE and ITEM_POLLING TRUE for qubeyond_v2, i.e. on the largest channel availability reaches DoorDash by DoorDash polling Qu, not a certified 86 push - consistent with Qu's own 'within minutes' rather than real-time wording; (3) restore-on-availability to 3P is stated only generically ('item availability publish'), and modifier-level 86 is not stated. Does not re-propose the withdrawn 2026-09-12 shape: that partial rested on ITEM_POLLING alone; this one rests on Qu's first-party statement that 86s reach DoorDash/Uber Eats/Grubhub, with the polling mechanism as the named limitation. Retrieved 2026-09-18. https://www.qubeyond.com/resource-center/restaurant-menu-management-system-multi-location-guide · retrieved 2026-09-18 adversarially verified
Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.
delivery-store-pause
DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: /, barring only /cdn-cgi/ and /monitoring). The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page at https://merchants.doordash.com/en-us/integrations. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general, so grade B is the ceiling here and it can never be A. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. VERIFICATION PASS 2026-09-12: all three sources were re-fetched independently of the frozen cache. The registry is byte-identical (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers, tiers tallying 12/47/5 and exactly 23 distinct flag names), and every quoted span below was re-checked as verbatim-present and contiguous in the file it is attributed to. The flag `STORE_AVAILABILITY_WEBHOOKS`, which DoorDash’s label dictionary renders ‘Integrated close/pause store’, is TRUE for `qubeyond_v2`, inside the FEATURE_COLLECTION_NAME_LIVE_ORDER_MANAGEMENT collection, which carries `active: true` for this provider. This replaces a grade-D marketing citation: Qu’s own Channel Management page (https://www.qubeyond.com/management/channel-management, retrieved 2026-08-01) asserts that operators can pause third-party integrations from one dashboard, and the registry now attests the same capability for DoorDash from the counterparty side. SHORTFALL UNCHANGED: the claim requires the pause on EACH connected marketplace plus a timed auto-reactivation, and neither source carries a reactivation timer — none of the 23 flags covers one — while only DoorDash is attested of the connected channels. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12 adversarially verified
Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator
delivery-3p-reconciliation
Qu markets third-party economics heavily (0.2% vs 0.7% order failure rate, direct injection ROI math, Bill Miller BBQ's '25% decrease in check reconciliations & lost online transactions'), and Winter 2026 adds 'Major Improvements to Digital Order Attribution: Enhanced flexibility in mapping and splitting digital order revenue across channels and providers'. All of that concerns attributing recorded order revenue to channels, not matching marketplace payout deposits against POS-recorded 3P sales with commission, marketing fees, refunds and unpaid-order detection itemized. The Bill Miller figure describes fewer reconciliations being needed, not a reconciliation report. Since none of these establishes the payout-matching object the claim names, and a report inventory would only appear in operator documentation, the cell is unresolved rather than absent. || 327th: MERGE HOLD (proposed no/B, held unknown): The admin bundle bounds report SCREENS only if report definitions are client-side; urbanpiper's Prime showed today that a report catalogue can be served wholly from the server. Not shown for Qu either way. PROPOSAL AS WRITTEN: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. CLAIM: a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemising commission, marketing fees, refunds/adjustments and identifying missing or unpaid orders. VERDICT no. EVIDENCE/BOUND: 3P payout reconciliation is a back-office report, so the right denominator is the EI back office itself -- the 177/177 admin.qubeyond.com chunk census. Tokenised over those 175 files, `reconcil` returns 48 occurrences and every one is CASH-DRAWER reconciliation: the identifiers are `reconcileCash` (19), `reconcileTill` (2), `reconcileDateTime` (5), plus the UI strings 'Unreconcile till', 'Till reconciled successfully', 'Till unreconciled successfully', 'Unreconciled', 'Reconciled'. `payout` 0, `settlement` 0, `commission` 0 and `deposit match` 0 across the whole app. The retired operator corpus corroborates without carrying the verdict: its 23 `reconcil` hits are the same till workflow ('type in the name of the employee that the till needs to be unreconciled for ... Click Unreconcile'). POISON: on the rebuilt marketing site `payout` scores 13 and all 13 are CARD payouts -- Qu Pay/Adyen 'On-demand settlements replace standard payout schedules' and the Adyen 'Sales Day Payout' definition -- not marketplace deposits; and the only 3P reconciliation language anywhere is a case-study metric, '25% decrease in check reconciliations and lost online transactions with 3PD integrations', which is a marketing outcome, not a report. Retrieved 2026-09-18. || 332nd: 332nd. Tested the 327th hold's premise (report catalogue may be server-side) against the admin census and it holds: the admin's report surfaces are data-driven - 'Scheduled Reports' with 'There was an error while trying to get scheduled reports', 'Unknown Report', and a store module `reports` hydrated at login (`r.dispatch("reports/...")`) - so the 177/177 bundle does not enumerate report types and cannot bound a payout-reconciliation report. The reporting service's own host, reporting-api.qubeyond.com, answers every /swagger/* path (incl. a nonsense /swagger/zzqq.json) with a 403 'Too many requests.' path rule and 404s elsewhere: a refusal, not a spec. The admin's digital-order-attribution rule editor (maps DoorDash 'Experience'/'Fulfillment Type' and UberEats fields onto Qu order channels/types) is REVENUE ATTRIBUTION, already recorded as not payout matching. Retrieved 2026-09-18. || 333rd: 333rd NEW CORPUS: Qu's video library - the YouTube channel @QuBeyond (85 uploads listed with yt-dlp; 54 caption tracks pulled into .cache/q333/qu/b/tr) plus the 45 Wistia media embedded on www.qubeyond.com resource-centre pages (media ids from the 331st rc corpus; public fast.wistia.com/embed/medias/<id>.json + /embed/captions/<id>.json, 42 English caption tracks, incl. 8 not on YouTube: the 05-07-26 webinar recording, Digital-First POS 1-Minute Demos 1-4, Winter 2025 highlights, FSTEC Innovation Forum, State of Digital LinkedIn Live, Trust & Technology) = 96 transcripts, 1.56 MB. Vendor video = grade C. `reconcil`, `payout` = 0 across it (`commission` = 2, both third-party fee talk); the Fall 2025 highlights show only 'POS Unified Reports - one-click access to all POS reports' (end of day, shift, tills). Nothing about marketplace deposit matching. Held. Retrieved 2026-09-18. adversarially verified
Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator
delivery-injection-error-visibility
RE-BASED 2026-09-12: this cell stood at `yes`/B on a note reading ‘Channel Management provides error visibility and validation reporting; detailed order error reporting is a DPIP requirement Qu meets.’ The second clause was an instance of the DoorDash Preferred syllogism, which DoorDash’s own partner registry (https://merchants.doordash.com/api/partner-integrations) falsifies as a general inference — 10 of the 12 PREFERRED providers carry 8 of 8 high-quality features but `qubeyond_v2` carries 7 and `checkmate` 6, so Preferred membership does not entail any particular feature. The clause is removed. What the cited page does carry, read 2026-09-12, is a Channel Health and Error Visibility section: ‘Built-in validation reports and error logging give operators full visibility into menu mismatches, sync failures, and integration issues, so teams can identify and resolve issues before they impact guests.’ It also lists ‘Channel-level controls for availability, routing, and status’ and ‘Downloadable reports for rapid issue resolution’. That is two of the claim’s three components — a failed-sync view and per-channel status. SHORTFALL: the third component, alerting on failure, is not attested; the string `alert` occurs zero times on this page, and that zero is bounded to this one page rather than to Qu’s corpus, so it is a shortfall and not a `no`. GRADE: C, not B. The page is a first-party product page written to sell — it carries a Schedule a Demo call to action and capability bullets rather than configuration instructions — and a differentiator `yes` requires grade A or B, which this does not reach. CORROBORATION, not the basis: the registry reads `DETAILED_ERROR_SPEC` TRUE for `qubeyond_v2`, whose feature-copy dictionary on https://merchants.doordash.com/en-us/integrations glosses it ‘Provide actionable error reasons for failed orders, reducing repeat order failures.’ That describes what the provider transmits into DoorDash’s contract, not what the vendor shows the operator, so it cannot carry this claim’s subject on its own. https://www.qubeyond.com/management/channel-management · retrieved 2026-09-12
Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.
delivery-tracking-page
Qu Order Status keeps guests and drivers informed via brandable status surfaces; a branded tracking page on the restaurant's own domain with driver state is not documented (no in-house drivers). https://www.qubeyond.com/kitchen-solutions/order-status · retrieved 2026-08-01
Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator
delivery-promise-time
Qu post: 'you can dynamically adjust ready times, turning a static promise into a responsive solution that adapts to real-time conditions' with 'estimates for order readiness by considering factors like historical and current order volume, labor availability, and preparation time'; Qu's Smart Kitchen page lists 'AI-generated promised ready times — improves delivery time accuracy by factoring in all channels, labor, and prep needs.' Shortfall: marketing/roadmap material describing a kitchen ready-time estimate; no evidence the quote factors driver availability or per-zone drive time, and no configuration documentation exists (support site login-walled). https://www.qubeyond.com/resource-center/5-reasons-why-your-kitchen-needs-a-smart-upgrade-now · retrieved 2026-09-03
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
Re-fetched the Qu Business Edge resilience page directly for delivery-specific offline language: it states only that "ordering, payments, and kitchen routing continue uninterrupted during connectivity outages" — a generic continuity claim with no mention of cash delivery orders, driver assignment, or driver settlement. Qu also ships no native driver/dispatch module at all (delivery-driver-roster, -dispatch-board, -driver-tracking, -driver-comp, -cash-reconcile are all documented "no" elsewhere in this record), so there is no native driver-assignment or driver-settlement process to have offline behavior for. Same "claims continuity, publishes no feature-level detail" pattern as reliability-offline-feature-matrix (also "no"). https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-04
Digital ordering & guest-facing channels
Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.
digital-first-party-web
First-party branded online ordering with custom subdomains, positioned explicitly against marketplace commissions ($60K–$180K+ annual savings claimed). https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-01
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
Qu's first-party ordering channel is described as web, not a native app: qubeyond.com/ordering/online-ordering offers 'Multi & Virtual Brand Support -- Manage multiple brands under one parent with custom subdomains and branding' and its FAQ says orders are placed 'through a branded web or mobile experience.' Branded native apps come from certified partners instead: the integrations directory lists Lunchbox (lunchbox.io), Olo, Onosys and Paytronix under 'Digital Ordering'/'Payments', and Qu's own release 'Paytronix & Qu Further Integration' (2026-06-23) describes Paytronix as providing 'loyalty programs, online ordering, gift cards, branded mobile applications' with 'orders placed through Paytronix's online ordering platform flow automatically into Qu.' Shortfall: no first-party Qu-published iOS/Android app; a branded native app depends on a third-party ordering partner, and neither source states that such an app is published under the restaurant's own brand in the App Store and Play Store. https://www.qubeyond.com/integrations · retrieved 2026-09-03
Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.
digital-account-saved-payment
SHORTFALL: saved payment is documented; saved addresses and one-tap reorder are not. Qu Web Ordering v139 (17 Nov 2020, Next Gen 3.5) documents guest accounts with stored cards under 'Store Saved Payment Information: (Same as Express) Saved payment is also supported with Aurus. Logged in users can save a card by clicking the checkbox. User can save multiple cards and can make payment using any single card at a time.' Card entry is through a hosted Aurus/Express iframe, i.e. the PAN is held by the processor. Logged-in accounts are further evidenced by the Punchh web-ordering flow ('Logged in users earn points by placing orders'). The archived corpus nowhere documents a saved-address book or one-tap reorder of a previous order, both of which the claim requires. VINTAGE: Next Gen 3.5 / Web Ordering 3.0, 2020-21; the current Intelligent Commerce Platform online-ordering page does not restate these mechanics. https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360052896691-November-17th-v139- · retrieved 2026-09-03
Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator
digital-upsell-engine
AI-driven upsell/cross-sell prompts documented for kiosk and referenced for digital channels; attach-rate reporting not documented. https://www.qubeyond.com/ordering/kiosk · retrieved 2026-08-01
Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.
digital-scheduled-pacing
SHORTFALL: scheduled/future ordering is documented; per-daypart capacity throttling is not. Qu Web Ordering v140 (16 Dec 2020, Next Gen 3.5) documents the platform setting 'Future Order Acceptance Days' with two parameters, 'Minimum days - lowest number of days in advance an order can be placed (0 = same day, 1 = tomorrow...)' and 'Maximum days - highest number of days in advance an order can be placed', settable per order channel (web vs catering); v140/v141 also reference a 'Future Order Calendar prompt' and v141 a checkout 'time slot' that updates on expiry, so time-slotted future ordering exists. The store/group settings checklist names 'Bucket Scheduling' and 'Min Max Order Limits' and 'Kitchen Buffer Lead Time' but never defines them, and no article describes slot capacity limits or automatic closing of saturated slots. VINTAGE: Next Gen 3.5, Dec 2020 / Jan 2021 release notes; not confirmed for the current platform. https://web.archive.org/web/20210125175255/https://support.qubeyond.com/hc/en-us/articles/360054441371-December-16th-v140- · retrieved 2026-09-03 adversarially verified
Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.
digital-fulfillment-modes
Online ordering supports in-store, curbside, tableside and white-label delivery handoff modes. https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-01
Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.
digital-qr-table
"Tableside" is a listed fulfillment mode; QR scan-to-order attaching to an existing POS check with split/tip is not documented and Qu disclaims table service. https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-01
Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator
digital-kiosk
Kiosk Marketplace, 2025-08-21, independently reports Qu shipping kiosk upgrades that let "Qu's Flex POS terminals switch between cashier and guest-facing modes", with "ADA screen reader support and multiple language options", naming Taco John's and WOWorks as early adopters. Shortfall: kiosk is a guest-facing mode of the Qu Flex POS terminal rather than a documented standalone kiosk product, so a terminal running as a kiosk is not simultaneously a cashier station; the vendor page claims only "software accessibility features" for ADA, with no tactile keypad, audio jack or physical accessibility hardware documented. Qu publishes no publicly retrievable product documentation: support.qubeyond.com (the 'Qu Campus' Document360 portal) redirects to a login, and both qu-api.qubeyond.com and qu-pos-api.qubeyond.com return HTTP 403 behind a mismatched TLS certificate. No grade A/B evidence is obtainable, so a differentiator 'yes' cannot stand. https://www.kioskmarketplace.com/news/qu-unveils-kiosk-upgrades-to-boost-revenue-ease-staffing-for-restaurants/ · retrieved 2026-08-02 adversarially verified
Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.
digital-group-ordering
NEW SURFACE, and it is the guest-facing app the record has never held: wo.qubeyond.com, Qu's production 'Webordering Application' (Angular). SCRIPT-LOADER CENSUS TO A FIXPOINT: runtime.c53cff06ce9d26e6.js carries a webpack chunk-hash table of 73 entries; fetching every entry, re-grepping each fetched chunk for further entries and repeating reached a fixpoint in 2 rounds (round 2 added 0). Corpus = 74 JS files, 4.6 MB (main 2.2 MB + 70 lazy chunks + runtime/polyfills/scripts). ROBOTS, measured 2026-09-17: wo.qubeyond.com/robots.txt is 26 bytes, 'User-agent: * / Disallow: /' - a GENERIC bar that does not name ClaudeBot, anthropic-ai or Claude-User, so it was fetched like a browser under the user's standing order; admin.qubeyond.com/robots.txt returns 404 and pay-admin.qubeyond.com/robots.txt returns 404, so neither of those hosts bars anything. FLOOR, NOT A CENSUS: 2 named chunks (2214.c8961a92c3ed4c69.js, 6748.5c5f23fb57b03028.js) do not serve - they return a 24,683-byte SPA shell, byte-identical (md5 5c29f52d0b0fe9afe53e45578f026956) to the nonsense control https://wo.qubeyond.com/9999.deadbeef.js, so this host is a soft-200 catch-all and only the 71 real chunks count. CLAIM: group ordering - a shareable link where multiple participants add items to one order under a per-person or total spend cap, with split or single payment. VERDICT: no. EVIDENCE: the app's complete route table, extracted from its own router configuration, is 19 routes - login, loyalty-login, search-locations, menu-category, items, dashboard, recent-order, order-confirmation, review-order-details, make-payment-screen, redirect-payment, signup, forgot-password, reset-password, redirect_reset_password, redirect_register, error, :id, :pathKey - with page titles 'Order For Pickup', 'Login Page', 'Loyalty Login', 'Search store page', 'Menu page', 'Dashboard', 'Customization page', 'Review Order', 'Payment page', 'Recent order page', 'Order confirmation', 'Favorites'. There is no shared-cart, invite, join, participant or group route, and no cap or split-payment surface in the checkout path (menu-category -> items -> review-order-details -> make-payment-screen). CONTROLS, tokenised word-boundary case-insensitive, over 74 wo files / 175 admin chunks: `group order` 0/74 and 1/175, and that one hit is poison - 'Error: There was a problem while updating the group order' is the drag-and-drop displayOrder of dietary groups (handleDragDrop sorting g.displayOrder), not guest group ordering; `shared cart` 0 / 0; `invite` 0 / 0; `participant` 0 / 0; `spend cap` 0 / 0; `split payment` 0 / 0; `split check` 0 / 0. Retrieved 2026-09-17. https://wo.qubeyond.com/ · retrieved 2026-09-17 adversarially verified
Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator
digital-catering-portal
Same evidence as order-capture-catering: EZCater is named as a direct integration partner. Shortfall: no distinct native catering flow — separate catering menu/minimums, lead-time rules, quotes/proposals, deposits, or invoice/house-account/ACH terms — is documented; catering is delegated to the EZCater integration. https://www.qubeyond.com/ordering/third-party-ordering/ · retrieved 2026-08-04
Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator
digital-voice-ai-phone
Named voice AI partners (ConverseNow, Presto) inject orders into POS/KDS; documented for drive-thru, not explicitly for inbound phone. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-01
Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.
digital-drivethru-ai
AI voice ordering integration at the drive-thru lane flowing into POS and KDS; escalation-to-human handoff is not documented. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-01
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
All four 'SMS' occurrences are unrelated: Adyen's terms listing SMS/IVR payment methods, Qu Equip's 'Multi-channel alerts via SMS, Email, and Notify' for equipment faults, and two marketing-cadence discussions in guest-engagement thought leadership. Qu's own guest-facing ordering entry points are enumerated as POS, kiosk, drive-thru, online ordering, third-party, plus QR-based tableside and curbside; conversational text-to-order is not among them. That list is a marketing selection rather than an exhaustive channel enumeration, so it will not be converted into an absence. || 332nd: 332nd. NEW CONTROLS over Qu's shipped ordering client and back office: in the 70 served wo.qubeyond.com files the ONLY guest-facing SMS is an identity check, component app-guest-verification-code in 6067.0c370bf60dbacca8.js ('To verify your transaction, we will send you a code via SMS', 'Please enter the code received on your phone via SMS'), posted to Qu's /account/verification-requests and /account/verified-token and shown only when a payment type has identityVerificationRequired - a one-time code, not an order channel. `text to order`, `order by text`, `text-a-link`, `reorder` via SMS, `Twilio` = 0 there and in the 177/177 admin census, whose two `sms` hits are POISON (DOMPurify's allowed-URI regex and Font Awesome `fa-sms`). The admin's external channel types are OLO, DoorDash and UberEats only. Held: a partner text-ordering product could inject through Qu's unpublished partner API, which no client census bounds. Retrieved 2026-09-18. adversarially verified
Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator
digital-google-order
No occurrence of 'Order with Google' or 'Google Business Profile' anywhere; the sole related line is advice in a 2020-era ghost-kitchen listicle — '6. Own your Google My Business page… You can direct customers to order directly from you' — which counsels the operator to do this themselves and claims nothing about Qu provisioning the link. This is a genuinely marketing-shaped feature and Qu's 177-piece resource centre argues relentlessly for shifting demand from marketplaces to first-party channels, so the silence is suggestive; but editorial silence across thought-leadership is not an enumeration, and whether Qu's white-label ordering URLs are provisioned to GBP is an onboarding step recorded only in operator documentation. || 332nd: 332nd. NEW CONTROLS over Qu's own shipped code, not run for this cell before: every `google` occurrence in the 24.4 MB admin.qubeyond.com 177/177 census is Maps address autocomplete/geocoding (`qu-google-address-autocomplete`, `/google-maps-api/address-validation`), Google Tag Manager, reCAPTCHA, the Sheets import templates, or the one $gettext string 'Generate and export the KML file using Google My Maps' (delivery-zone drawing); `Order with Google`, `Google Business`, `My Business`, `actionLink`, `Actions Center` = 0 there, 0 in the 70 served wo.qubeyond.com files (whose `google` is LOYALTY_AUTHORITY google:2, a sign-in option) and 0 in the Qu Pay bundle; `GBP` is POISON (the currency code, 25+ hits in pay-admin/Angular locale tables). The admin's digital-order-attribution rule editor knows exactly three external channel types (isOLOChannelType, isDoorDashChannelType, isUberEatsChannelType); no Google channel. webordering-sp.qubeyond.com (live, 200) serves the SAME build as wo (main.4b6c92ee3e2b2618.js), not a second client. Held: provisioning a GBP ordering link is an onboarding act no client bundle need encode, and Qu's training LMS 'Qu U' (campus.qubeyond.com and crew.campus.qubeyond.com, from the 325th crt.sh list, never opened) is a TalentLMS tenant whose only entry is SAML SSO ('/index/ssologin/service:saml'); /catalog 302s to /index, every other path to /index/error, /api/v1/catalog is 401 - no public course catalogue. With support.qubeyond.com a login-gated Document360, Qu's operator documentation is gated on BOTH surfaces, so its public publication set is www.qubeyond.com (sitemap.xml re-counted 2026-09-18: 248 URLs = 39 core pages + 209 resource-centre/case-study pages, both censused in the 327th/331st). Retrieved 2026-09-18. || 334th: CLAIM: see taxonomy. VERDICT: unknown (held). 334th NEW, confirms why no census can bound this cell: Google's own Business Profile help page 'Accept food orders through Order with Google' (support.google.com/business/answer/10918858, read 2026-09-18) names no Qu/Qu POS provider, but also says 'You can add custom links to your profile that direct customers to other web pages where they can place orders from your business' - so any Qu brand can place its native Qu online-ordering URL on its GBP itself, and an absence from Google's provider roster (a third-party list, grade D) does not show that Qu's direct link cannot be the GBP ordering option. The 332nd controls over Qu's shipped code (Order with Google / actionLink / Actions Center = 0) stand. Retrieved 2026-09-18. adversarially verified
Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.
digital-apple-business-connect
'Apple Business' and 'Apple Maps' occur zero times; the only Apple references in the corpus are 'Apple Pay', an 'Apple iOS and Android applications' aside about app development, and two idiomatic 'apples-to-apples' phrases. As with the Google cell, an Apple Maps 'Order Food' custom action is a per-brand provisioning task rather than a platform feature page, and Qu publishes no onboarding documentation publicly. Nothing read settles it. || 332nd: 332nd. NEW CONTROLS over Qu's own shipped code: `Apple Maps`, `Apple Business`, `Business Connect`, `MapKit`, `place card` = 0 across the 177/177 admin.qubeyond.com census, the 70 served wo.qubeyond.com files, the Qu Pay bundle and the Notify APK string tables, as over the 248 current public pages. The admin's only map dependency is Google Maps (address autocomplete, 'Google My Maps' KML for delivery zones). Held for the same reason as the Google cell: a place-card custom action is a per-brand provisioning step that no bundle need encode, and Qu's operator docs are gated (support.qubeyond.com Document360 login; the 'Qu U' TalentLMS at campus.qubeyond.com is SAML-only, found 332nd). Retrieved 2026-09-18. adversarially verified
Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.
digital-loyalty-attach
Loyalty accrual/redemption in digital ordering is delivered by the Paytronix integration across in-store, drive-thru, kiosk, mobile and web — partner, not native. https://www.globenewswire.com/news-release/2026/06/23/3316041/0/en/paytronix-and-qu-further-integration-enabling-advanced-omnichannel-ordering-and-menu-management.html · retrieved 2026-08-01
Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.
digital-subscriptions
NEW SURFACE (the wo.qubeyond.com web-ordering fixpoint census: 74 files, 4.6 MB, 71 of 73 chunk-table entries real, soft-200 control documented on digital-group-ordering). CLAIM: guest subscription/membership programs - recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier - managed in the platform. VERDICT: no. EVIDENCE: the guest ordering app's 19-route table (listed on digital-group-ordering) has no membership, subscription, plan or manage-billing route; its account surface is signup / login / loyalty-login / dashboard / recent-order / Favorites, and its checkout is a one-off payment path (review-order-details -> make-payment-screen -> redirect-payment -> order-confirmation). CONTROLS over 74 wo files / 175 admin chunks / the 6.3 MB pay-admin bundle, tokenised: `recurring` 0/74, 0/175; `membership` 0/74, 0/175; `plan` 0/74, 0/175; `enroll` 0/74, 1/175; `auto-renew` 0 everywhere; `tier` 0/74, 0/175; `punch card` 0 everywhere. POISON, and it is the entire reason this cell looked open: `subscription` returns 17 hits in 3/74 wo files and every single one is an RxJS Subscription object (this.subscription = new v.w; this.subscription.add(fromEvent(window,'online')...); ngOnDestroy(){this.subscription.unsubscribe()}), and the 2 admin hits are the report 'unsubscribe' page; in the pay-admin bundle `recurring` (205) and `membership` (60) are Adyen chargeback-defence document labels ('The cardholder renewed membership after cancellation.', 'The transaction was not a recurring transaction.'), not Qu features. Retrieved 2026-09-17. https://wo.qubeyond.com/ · retrieved 2026-09-17 adversarially verified
Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.
digital-promo-parity
Single menu/promotion database with channel-level rule configuration and eligibility; stacking/precedence semantics not documented. https://www.qubeyond.com/management/channel-management · retrieved 2026-08-01
Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator
digital-guest-data-ownership
Unified Data & Reporting FAQ: 'Qu's unified data layer supports API-based integrations with external BI platforms, enabling operators to pipe Qu data into the analytics environment of their choice'; the Online Ordering page pitches 'Retain Your Guest Data — Easily access and analyze data to foster repeat visits.' Shortfall: this is access to a data layer, not a documented bulk export of first-party guest records (email, phone, consent status, order history), and Qu makes no statement about export being free of fee or vendor approval. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-09-03
Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.
digital-checkout-pci-sca
Fetched the Qu Pay, Online Ordering, and platform pages directly for PCI language: none of the three — including Qu Pay, the page whose entire subject is payments — mentions hosted payment fields, a hosted payment page, or publishes any PCI DSS 4.0 compliance statement (including the March-2025 script-integrity requirement). Complete silence on the vendor's own payments product page, on the exact topic that page exists to cover, supports a documented absence rather than mere non-discovery. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-04
Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator
digital-surcharge-transparency
Service-fee half only. Qu's web ordering client adds operator-configured service charges to the basket (main.4b6c92ee3e2b2618.js @219109 addServiceCharge posting {serviceChargeId,value} to "/basket/servicecharges"), re-checks them when the order time changes (@220560 "Invalid service charge for the new date/time"), and refuses third-party ones (@223557 `Cannot add a third-party ${H} service charge`). At checkout (chunk 6067.0c370bf60dbacca8.js @151155) getVisibleServiceChanges draws each charge as its own row showing its title and amount, next to a separate " Tax " row (@148041). Shortfall: across all 77 JS files listed in ngsw.json there is no card surcharge, dual pricing or cash-discount code (surcharg=0, cash.?discount=0; the 12 'dual' hits in main are other words such as 'individual', not pricing). There is no disclosure text beyond the operator-typed charge title, no handling of card brands or jurisdictions, and nothing shows the charges match the POS setup. That zero covers this client only and says nothing about the POS. https://wo.qubeyond.com/main.4b6c92ee3e2b2618.js · retrieved 2026-09-15 adversarially verified
Guest data, loyalty & marketing
Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.
guest-loyalty-unified-profile
Qu claims a "single source of truth for guest data" normalizing guest records across POS, kiosk, drive-thru and online; dedup/merge behavior is not documented. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-08-01
Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator
guest-loyalty-thirdparty-identity-attach
Fully traversed Qu's certified-partner directory (https://www.qubeyond.com/integrations, 14 pages, 121 named partners, 11 category facets). Delivery marketplaces appear as their own facet (DoorDash, UberEats, GrubHub, ezCATER, Checkmate, Cartwheel, Bites) and loyalty/guest identity appears as a separate Loyalty facet (Incentivio, Paytronix, Punchh, SPARKFLY, SpendGo, Thanx, hang, tapmango). Qu publishes nothing about whether a marketplace order joins to a guest profile, and because the guest profile lives in a partner system the subject of this claim is the partner, not Qu. Grepped all 199 uncited pages: no page connects third-party order ingestion to guest identity. Note the directory is not exhaustive by Qu's own reckoning — its counter reads '150 integrations' while 121 are served. || 331st: NEW (331st), not settling: the rebuilt site now asserts cross-channel guest identity in general terms - /multi-unit-pos-guide comparison row 'Guest Data | One complete guest profile across every channel. Owned by you.' and /management/channel-management 'orders, payments, and guest data flow seamlessly across your entire ecosystem ... POS, kiosk, drive-thru, web, mobile, and third-party delivery all operate within a single system'. Neither sentence says a MARKETPLACE order carries or is matched to guest identity, and Qu's own product overview frames guest-data ownership as a reason to move guests OFF marketplaces ('Native online ordering to own your guest data and eliminate third-party fees'). NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. No page joins marketplace orders to a guest profile (tokenised co-occurrence of doordash/uber eats/grubhub/third-party/marketplace with guest/customer profile/data/identity = 0 outside those two marketing lines). Retrieved 2026-09-18. adversarially verified
Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.
guest-loyalty-accrual-models
Strengthened: beyond the Paytronix releases, Qu's own online-ordering page says 'third party loyalty', and loyalty is absent from the enumerated product catalog. Documented absence, not merely undocumented. https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-01 adversarially verified
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
Qu's own certified-partner directory carries a dedicated Loyalty category (Incentivio, Paytronix, Punchh, SPARKFLY, SpendGo, Thanx, hang, tapmango) and the /become-a-partner form lists 'Loyalty' as a partner Solution Type, so loyalty is partner-delivered and the tier engine's subject is the partner, not Qu. 'tier' occurs 6 times in the 199-page corpus and never as a loyalty status tier (price tiers, premium tier, tiers of support). Qu makes no claim to own this capability, so a Qu `no` would score the wrong object; the partners' tier behaviour is undocumented on any Qu surface. || 325th: NEW SURFACE that explains the whole loyalty family and still cannot settle it. In Qu's production web-ordering app (wo.qubeyond.com, 74-file script-loader fixpoint, 4.6 MB), loyalty is DELEGATED to an external provider over OAuth: the router carries '{path:"loyalty-login", loadChildren: ... LoyaltyLoginPageModule, data:{title:"Loyalty Login"}}', the app fetches a 'loyaltyConfig' ('Error while loading loyalty configuration.') and calls loginWithLoyalty(), and the handshake is an authorization-code exchange against a per-tenant authority - 'GRANT_TYPE.AuthorizationCode, authority: e._clientConfig.loyaltyType, code: e.code, redirectUrl: `${location.origin}/loyalty/loyalty-login`, orderChannelId' - after which an 'app-loyalty-coupon-tab-component' renders rewards ('rewardsModified'; `coupon` 43 hits in 2/74, `reward` 32 hits in 2/74). So Qu ships the guest-side plumbing to a third-party loyalty engine chosen per client (loyaltyType), which is why no tier machinery is present in Qu itself: `tier` returns 0 hits in 74/74 wo files and 0 in the 175 admin chunks, and `punch card`, `wallet`, `enroll` are 0 in wo. Held at unknown rather than no because the claim's subject - automatic promotion/demotion on rolling-window spend or visits - would live in the delegated provider (Punchh, Paytronix, Thanx et al. per Qu's partner directory), which Qu's own surface does not describe. Retrieved 2026-09-17. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: configurable loyalty status tiers with rules and benefits. VERDICT unknown. EVIDENCE: the KB confirms from the product side, not the partner directory, that the loyalty ENGINE is Punchh and that Qu ships only the POS and Web Ordering client for it. v139: 'Along with Punchh's Visit Based and Banked Rewards programs, Qu Web Ordering now supports the new Punchh “Points Unlock Redeemable” program. No specific configuration is required to support this program'; the program TYPES are Punchh's and Qu's own work is 'The Qu/Punchh API integration was updated to support identifying the type of rewards program used.' `tier` = 27 across the corpus and every hit is a menu PRICE tier ('How do I Implement Price Tiers?', and the 'Price Tiers' sections under both Enterprise Configuration and Store Configuration in the EI manual), never a loyalty status tier. Subject remains the partner. Retrieved 2026-09-18. || 331st: NEW (331st) from the wo.qubeyond.com constants (main.4b6c92ee3e2b2618.js): the guest-identity authorities Qu's ordering client knows are LOYALTY_AUTHORITY={qu:0,facebook:1,google:2,punchh:3,levelup:4,spendgo:5}, and QU_LOYALTY_TYPE=1 is Qu's NATIVE GUEST ACCOUNT (isLoyaltyQu() routes to signup/login/dashboard with e-mail verification), not a rewards engine. The only programme types the client encodes are Punchh's - PUNCHH_LOYALTY_PROGRAM_TYPE={BANKED_REWARDS:0,UNLOCKED_REWARDS:1,VISITS_BASED_REWARDS:2} - plus SpendGo single sign-on; no tier type exists. NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. Every `tier` hit (6/209) is price tiers, support tiers or AI pricing tiers. Subject remains the partner. Retrieved 2026-09-18. || 334th: CLAIM: see taxonomy. VERDICT: unknown (held). 334th NEW SURFACES (never held by any pass; Wayback CDX over qubeyond.com/wp-content/uploads/* lists 16 PDFs, 13 were on disk): (a) Qu-OnePage_Kiosk.pdf (May 2025 'Website One-Pager Downloads' series, 3 pp., https://web.archive.org/web/20250727155014/https://www.qubeyond.com/wp-content/uploads/2025/05/Qu-OnePage_Kiosk.pdf); (b) Copy-of-2021_Qu-Fact-Sheet.pdf (2 pp., https://web.archive.org/web/20220817122738/https://www.qubeyond.com/wp-content/uploads/2021/11/Copy-of-2021_Qu-Fact-Sheet.pdf). Sibling one-pagers (Qu-OnePage_{POS,KDS,DriveThru,Payments,Loyalty,EnterpriseIntelligence,...}, 84 name/revision guesses) are not in the Wayback index. EVIDENCE: the kiosk one-pager places loyalty OUTSIDE Qu's own modules - 'DIRECT LOYALTY, GIFT, AND PAYMENTS INTEGRATIONS - Integrate your loyalty, gift programs and payment systems through Qu's robust ecosystem'; the 2021 fact sheet's product list is 'In-Store Ordering (POS, Drive-Thru & Handhelds, Kiosk) / Digital Ordering (Native Online Ordering, Third-Party Delivery, Mobile/Custom Apps) / Kitchen Solutions (KitchenUP, KDS) / Platform as a Service' - no loyalty or marketing product. `tier`, `status`, `VIP` = 0 in both PDFs. This is consistent with the 331st wo.qubeyond.com LOYALTY_AUTHORITY list (punchh/levelup/spendgo partners beside Qu's native guest account) and with the merge rule that a product with NO MODULE = hold unknown, not no: a partner engine (Punchh etc.) may supply the capability through Qu. Vendor collateral = grade C. Retrieved 2026-09-18. adversarially verified
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
Re-fetched the Qu Business Edge offline-resilience page directly: its only offline statement is generic ("full transaction processing continues... system state preserved locally... sync resumes automatically"), with no mention of loyalty lookup, accrual, or redemption at all. The Qu Pay page is likewise silent. Loyalty itself is partner-delivered (Paytronix/Thanx), so the page that would need to document this behavior — and doesn't — is the one page describing Qu's own offline model. Same "claims continuity, silent on the named sub-behavior" pattern as reliability-offline-feature-matrix (also "no"). https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-04
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
Same evidence and finding as digital-promo-parity: a single menu/promotion database with channel-level rule configuration and eligibility is documented, but explicit stacking/precedence semantics (exclusive vs combinable, order of application) are not — for the promotion engine generally, which is the mechanism a loyalty offer-stacking rule would run on. https://www.qubeyond.com/management/channel-management · retrieved 2026-08-04
Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator
guest-loyalty-targeted-offers
Same partner-subject finding: the integrations directory's Loyalty facet holds eight certified partners and Qu ships no loyalty or marketing module. The corpus's only segmentation/one-to-one-offer passage is a Church's Chicken executive interview describing his own marketing practice, not a Qu product capability. 'segment' (14) and 'offer' (96) hits are thought-leadership prose. Audience-rule targeting belongs to the partner platform and Qu documents none of it. || 331st: NEW (331st), adjacent only: the current admin has 'Cross-sell Offers' (trigger items -> 'Offered Items', 'Add Cross-sell Offer') and 'Limited Time Offer' - basket/item-triggered offers, not an audience defined by recency/frequency/spend rules. NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. The only audience-segmentation prose is the Church's Chicken interview (already recorded) and Incentivio's 'Guest Journey Dashboard' churn targeting on the Loyalty 3.0 post, a partner product. Retrieved 2026-09-18. || 334th: CLAIM: see taxonomy. VERDICT: unknown (held). 334th NEW SURFACES (never held by any pass; Wayback CDX over qubeyond.com/wp-content/uploads/* lists 16 PDFs, 13 were on disk): (a) Qu-OnePage_Kiosk.pdf (May 2025 'Website One-Pager Downloads' series, 3 pp., https://web.archive.org/web/20250727155014/https://www.qubeyond.com/wp-content/uploads/2025/05/Qu-OnePage_Kiosk.pdf); (b) Copy-of-2021_Qu-Fact-Sheet.pdf (2 pp., https://web.archive.org/web/20220817122738/https://www.qubeyond.com/wp-content/uploads/2021/11/Copy-of-2021_Qu-Fact-Sheet.pdf). Sibling one-pagers (Qu-OnePage_{POS,KDS,DriveThru,Payments,Loyalty,EnterpriseIntelligence,...}, 84 name/revision guesses) are not in the Wayback index. EVIDENCE: the kiosk one-pager places loyalty OUTSIDE Qu's own modules - 'DIRECT LOYALTY, GIFT, AND PAYMENTS INTEGRATIONS - Integrate your loyalty, gift programs and payment systems through Qu's robust ecosystem'; the 2021 fact sheet's product list is 'In-Store Ordering (POS, Drive-Thru & Handhelds, Kiosk) / Digital Ordering (Native Online Ordering, Third-Party Delivery, Mobile/Custom Apps) / Kitchen Solutions (KitchenUP, KDS) / Platform as a Service' - no loyalty or marketing product. Adjacent only: the kiosk one-pager's 'smart cross-selling prompts and targeted promotions on kiosks' / 'Highlight limited-time offers and cross-sell promotions' are basket/item-triggered (matching the 331st admin 'Cross-sell Offers' and 'Limited Time Offer'), with no audience rule over recency/frequency/spend. This is consistent with the 331st wo.qubeyond.com LOYALTY_AUTHORITY list (punchh/levelup/spendgo partners beside Qu's native guest account) and with the merge rule that a product with NO MODULE = hold unknown, not no: a partner engine (Punchh etc.) may supply the capability through Qu. Vendor collateral = grade C. Retrieved 2026-09-18. adversarially verified
Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator
guest-loyalty-rfm-segmentation
Qu's own loyalty post describes lifecycle segmentation only inside a certified partner's product: "Incentivio's Guest Journey Dashboard leverages machine learning to automatically segment based on guest's visit frequency and spending habits" and "identifies guests at risk of churning." Shortfall: the capability is the third-party loyalty partner's (Incentivio), reached through the Qu integration; Qu describes its own role as the "foundational platform" / data layer and no source shows Qu computing recency-frequency-monetary or lifecycle segments natively. https://www.qubeyond.com/resource-center/loyalty-3-0-elevating-guest-engagement-through-deeper-insights · retrieved 2026-09-03
Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.
guest-loyalty-lifecycle-automation
'lifecycle' returns zero hits across all 199 uncited pages and the Adyen contract. Triggered birthday / first-visit / win-back campaigns would live in the loyalty-marketing engine, which the certified-partner directory shows is supplied by partners (Loyalty facet: Incentivio, Paytronix, Punchh, SPARKFLY, SpendGo, Thanx, hang, tapmango). The subject is the partner; Qu neither claims nor is enumerated to own lifecycle automation, and partner feature depth is not published on any Qu host. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. `birthday`, `win-back`, `first visit`, `lifecycle`, `drip` return 2 hits in 1/209, both on the Loyalty 3.0 post: Qu itself calls 'routine birthday offers' 'relics of the past', and the churn re-engagement it describes is Incentivio's ('The dashboard's proprietary churn management functionality identifies guests at risk of churning ... Incentivio is transforming...'). In the app bundles `lapsed` is POISON (`collapsed`, `elapsed`) - tokenise it. Subject is the partner. Retrieved 2026-09-18. || 334th: CLAIM: see taxonomy. VERDICT: unknown (held). 334th NEW SURFACES (never held by any pass; Wayback CDX over qubeyond.com/wp-content/uploads/* lists 16 PDFs, 13 were on disk): (a) Qu-OnePage_Kiosk.pdf (May 2025 'Website One-Pager Downloads' series, 3 pp., https://web.archive.org/web/20250727155014/https://www.qubeyond.com/wp-content/uploads/2025/05/Qu-OnePage_Kiosk.pdf); (b) Copy-of-2021_Qu-Fact-Sheet.pdf (2 pp., https://web.archive.org/web/20220817122738/https://www.qubeyond.com/wp-content/uploads/2021/11/Copy-of-2021_Qu-Fact-Sheet.pdf). Sibling one-pagers (Qu-OnePage_{POS,KDS,DriveThru,Payments,Loyalty,EnterpriseIntelligence,...}, 84 name/revision guesses) are not in the Wayback index. EVIDENCE: the kiosk one-pager places loyalty OUTSIDE Qu's own modules - 'DIRECT LOYALTY, GIFT, AND PAYMENTS INTEGRATIONS - Integrate your loyalty, gift programs and payment systems through Qu's robust ecosystem'; the 2021 fact sheet's product list is 'In-Store Ordering (POS, Drive-Thru & Handhelds, Kiosk) / Digital Ordering (Native Online Ordering, Third-Party Delivery, Mobile/Custom Apps) / Kitchen Solutions (KitchenUP, KDS) / Platform as a Service' - no loyalty or marketing product. `birthday`, `win-back`, `lapsed`, `automation` = 0 in both PDFs. This is consistent with the 331st wo.qubeyond.com LOYALTY_AUTHORITY list (punchh/levelup/spendgo partners beside Qu's native guest account) and with the merge rule that a product with NO MODULE = hold unknown, not no: a partner engine (Punchh etc.) may supply the capability through Qu. Vendor collateral = grade C. Retrieved 2026-09-18. adversarially verified
Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator
guest-loyalty-native-email-sms
Same page and finding underlying guest-loyalty-accrual-models: Qu's own Online Ordering page states "third party loyalty," and guest email/SMS messaging is consistently presented across Qu's resource-center posts as delivered through named partners (Thanx, Paytronix), never as a native Qu send capability. The claim specifically requires NOT solely handing the list to a third-party ESP — that is exactly what Qu's own language describes. https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-04
Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.
guest-loyalty-consent-management
The only consent machinery documented anywhere is OneTrust cookie consent on qubeyond.com itself ('Set by OneTrust to store the user's cookie consent preferences') plus GPC honouring for Qu's own site visitors — that is Qu's marketing site, not an operator's guest-messaging consent ledger. Per-channel marketing consent with timestamp and source, and non-keyword revocation handling, are product behaviours the privacy policy explicitly scopes itself out of and that no other document touches. || 331st: NEW SURFACE (331st): Qu's own guest sign-up form in the production web-ordering client (wo.qubeyond.com, component app-signup-component in 1058.3bdf03453ab53572.js, 47 template decls) collects exactly five fields - firstName, lastName, email, password, mobileNum ('Please use the form below to create an account.') - and no marketing-consent control of any kind. Tokenised `consent`, `opt-in`/`optIn`, `marketing`, `newsletter`, `promotional`, `receive offers` = 0 across the 70 served wo files (the only `opt` hits are Ionic picker `picker-opt` POISON; `STOP`/`unsubscribe` are Swiper/RxJS). The chunk table lists 73 entries: 3 (2214, 6748, 8592) are not served - they return a 7,052-byte text/html error page, distinct from the 24,683-byte nonsense-path shell - so the wo census is 70/73. Held unknown: Qu sends no guest marketing itself (guest-loyalty-native-email-sms is `no`), consent lives in the loyalty partner, and a product with no messaging module is held rather than scored. Retrieved 2026-09-18. adversarially verified
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
'10DLC' and 'A2P' return zero hits in the 199-page corpus and in the 69 KB Adyen contract. The four SMS hits are a payment-method clause, a Qu Notify alert-channel mention ('Multi-channel alerts via SMS, Email, and Notify'), and two customer interview quotes — none is guest marketing SMS. Since guest messaging is partner-delivered per the directory's Loyalty facet, carrier registration would be the partner's obligation and Qu's silence is not a denial. A marketing site would not necessarily document 10DLC even if handled. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW BOUND (327th), still unknown: tokenised `10DLC` and `\bA2P\b` = 0 across all four corpora (and A2P was checked as a WORD, not a substring, because a minified symbol has faked this control before). `\bSMS\b` returns 2 hits in the entire 24.4 MB admin bundle set and both are POISON -- the DOMPurify allowed-URI-scheme regex `(?:(?:f|ht)tps?|mailto|tel|callto|sms|cid|xmpp|matrix):`. The EI back office therefore has no messaging, campaign or sender-registration module at all, and the marketing site's only SMS sentence is operational alerting ('Multi-channel alerts via SMS, Email, and Notify ensure the right team members are notified'). Guest messaging on Qu runs through Punchh, a different publisher whose KB does not bound Qu, so the cell is held unknown rather than scored. Retrieved 2026-09-18. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. Tokenised `10DLC`, `\bA2P\b`, `TCPA` = 0/209. The only SMS-to-guest statements are a May 2020 blog tip to 'Drop an Email & Text Message to Your Customer Database' (operator advice, no platform named) and a Blaze Pizza CTO quote ('texting guests when orders are ready') - transactional order-ready texts, not marketing campaigns. Retrieved 2026-09-18. || 332nd: 332nd. NEW (not settling): Qu's platform DOES send SMS to guests itself - the wo.qubeyond.com checkout component app-guest-verification-code (6067.0c370bf60dbacca8.js) posts the guest's phone to Qu's own /account/verification-requests ('To verify your transaction, we will send you a code via SMS') when a payment type is flagged identityVerificationRequired, and validates at /account/verified-token. That is Qu-originated transactional OTP traffic, not operator-sent SMS: no admin screen (177/177 census, 1,398 $gettext strings) lets an operator compose or send SMS, and `10DLC`, `A2P`, `brand registration`, `campaign registration`, `sender` = 0 in wo, admin and the Qu Pay bundle. The claim's subject (the operator sending SMS through the platform) still has no Qu surface. Retrieved 2026-09-18. adversarially verified
Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator
guest-loyalty-campaign-attribution
Spring 2025 release: "Qu tracks acceptance rates for both kiosk and POS, as well as the revenue impact and net sales lift for each cross-sell campaign" with "comprehensive, real-time metrics that show exactly which promotions are working." Shortfall: attribution is documented only for kiosk/POS cross-sell upsell campaigns; nothing in the corpus reports redemption or incremental sales for an issued loyalty offer or marketing campaign, which live in partner systems (Thanx, Paytronix, Spendgo). https://www.qubeyond.com/resource-center/qus-spring-2025-product-release-highlights · retrieved 2026-09-03
Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator
guest-loyalty-data-export-portability
Feature page lists "Normalized guest and operational data" in the unified data layer and states: "Qu's unified data layer supports API-based integrations with external BI platforms, enabling operators to pipe Qu data into the analytics environment of their choice." Shortfall: the page never states that the guest list with contact PII is exportable, never mentions CSV or a self-serve export, and says nothing about whether a fee or a support request is required; only BI piping of Qu data generally is established. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-09-03
Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator
guest-loyalty-cdp-event-api
A DataExport API component exists and Qu integrates named CDP/analytics partners (Bikky, Paytronix); no public event/webhook contract is documented. https://status.qubeyond.com/ · retrieved 2026-08-01
Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator
guest-loyalty-review-capture-routing
New evidence but not settling: the certified-partner directory includes feedback/reputation partners — Ovation and momos under Analytics, Marqii under Digital Ordering — so a review-capture route plainly exists via partner, but Qu describes none of their behaviour, and score-based routing (low to private recovery, high to public sites) is a property of the partner product that no Qu page states. Corpus 'review'/'rating' hits are all 'read the report' and star-rating prose. Partner is the subject; depth undocumented. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. The one first-hand feedback statement is a customer quote on Qu's 2025 Enterprise Restaurant Report post: Blaze Pizza's CTO, 'we use Qu's cutting-edge tech to enhance hospitality - texting guests when orders are ready, delivering tableside and capturing real-time feedback'. It names no trigger, no score and no routing, and no Qu product page, admin string (1,398 distinct) or wo string carries `survey`, `feedback` or `rating` as a guest feature (all bundle hits are Sentry's feedback envelope type and Font Awesome `fa-yelp`/`fa-tripadvisor` icons - POISON). Not a partial: it shortfalls routing entirely and the mechanism may be a partner's. Retrieved 2026-09-18. adversarially verified
Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.
guest-loyalty-referral-program
Re-evidenced 2026-08-08 after the cited /products/ page began redirecting to the homepage. The Platform Solutions nav (carried on /integrations and every product page, and matching the sitemap product tree exactly) still enumerates the full module line-up - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Qu Pay, Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify Mobile Insights, Unified Data & Reporting) - and no loyalty product appears in it. Qu's own Online Ordering page frames loyalty as external: 'Whether you use Qu Pay or an integrated provider, third party loyalty or Qu's built-in discounts, Qu Online Ordering fits the way you operate' - built-in discounts, third-party loyalty. The integrations directory carries a 'Loyalty' category whose members are Thanx, Paytronix, Punchh, Incentivio, SpendGo, Sparkfly, tapmango and hang. (The earlier note also named LevelUp; it is not in the current 150-entry directory and has been dropped.) With no native loyalty program there is no native referral mechanic, per-guest code or two-sided reward. https://www.qubeyond.com/integrations · retrieved 2026-08-08 adversarially verified
Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator
guest-loyalty-wallet-pass
All four 'wallet' hits in the corpus are payment wallets or the 'share of guest wallet' metaphor (Adyen/Olo Pay mobile wallets); none is a loyalty pass. A wallet loyalty pass is a loyalty-engine feature and the integrations directory establishes loyalty is delivered by eight certified partners, several of which issue passes in their own right — so the subject is the partner. Qu claims no loyalty module and therefore cannot be scored `no` for a pass it never offered. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: issues an Apple Wallet / Google Wallet loyalty pass. VERDICT unknown. EVIDENCE: tokenised `wallet`, `Apple Pay`, `Google Pay` = 0 across the 205 articles and the 53 PDFs. The guest-identity artefact Qu's POS actually handles is the partner app's own code - 'scan a QR Code from their Punchh/Brand app' - plus a stored Mercury gift card, so any pass lives in Punchh's app rather than Qu's. Subject is the partner. Retrieved 2026-09-18. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. `wallet pass`, `Apple Wallet`, `Google Wallet`, `passkit`, `pkpass` = 0/209 and 0 in the 70 served wo files. The wo client's only guest loyalty identities are Punchh (banked/unlocked/visits programmes), SpendGo SSO and LevelUp (LOYALTY_AUTHORITY constants); the GoTo Foods case study says 'Multiple loyalty programs are accepted - enabling guests to use the loyalty app of their choosing', i.e. the guest artefact is the partner's app. Subject is the partner. Retrieved 2026-09-18. || 334th: CLAIM: see taxonomy. VERDICT: unknown (held). 334th NEW SURFACES (never held by any pass; Wayback CDX over qubeyond.com/wp-content/uploads/* lists 16 PDFs, 13 were on disk): (a) Qu-OnePage_Kiosk.pdf (May 2025 'Website One-Pager Downloads' series, 3 pp., https://web.archive.org/web/20250727155014/https://www.qubeyond.com/wp-content/uploads/2025/05/Qu-OnePage_Kiosk.pdf); (b) Copy-of-2021_Qu-Fact-Sheet.pdf (2 pp., https://web.archive.org/web/20220817122738/https://www.qubeyond.com/wp-content/uploads/2021/11/Copy-of-2021_Qu-Fact-Sheet.pdf). Sibling one-pagers (Qu-OnePage_{POS,KDS,DriveThru,Payments,Loyalty,EnterpriseIntelligence,...}, 84 name/revision guesses) are not in the Wayback index. EVIDENCE: the kiosk one-pager places loyalty OUTSIDE Qu's own modules - 'DIRECT LOYALTY, GIFT, AND PAYMENTS INTEGRATIONS - Integrate your loyalty, gift programs and payment systems through Qu's robust ecosystem'; the 2021 fact sheet's product list is 'In-Store Ordering (POS, Drive-Thru & Handhelds, Kiosk) / Digital Ordering (Native Online Ordering, Third-Party Delivery, Mobile/Custom Apps) / Kitchen Solutions (KitchenUP, KDS) / Platform as a Service' - no loyalty or marketing product. `wallet`, `Apple Wallet`, `Google Wallet`, `pass` = 0 in both PDFs. This is consistent with the 331st wo.qubeyond.com LOYALTY_AUTHORITY list (punchh/levelup/spendgo partners beside Qu's native guest account) and with the merge rule that a product with NO MODULE = hold unknown, not no: a partner engine (Punchh etc.) may supply the capability through Qu. Vendor collateral = grade C. Retrieved 2026-09-18. adversarially verified
Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.
guest-loyalty-privacy-rights-tooling
The only rights tooling found is a guest deleting their own account; there is no operator tooling. In Qu's web-ordering client, the account-page chunk 65.cc643fc074acac2b.js (94,840 B, fetched live 2026-09-15) has an 'Account settings' block on the Preferences tab (template vt, rendered when isTabActive("preferenceContainer")). At @53099 it shows ' Deactivating your account , you won't be able to reactive it later. ', and at @53294 a 'delete account' button whose click calls deleteAccount(). The button has no disabled binding; the block's only two ngIf:false bindings hide sibling slots 1 and 33. A confirmation reads 'Do you really want to delete this account ? This process cannot be reverted.' (@62004). Confirming it calls _userService.deleteUserAccount() (@62524), which sends DELETE /account (main.4b6c92ee3e2b2618.js @272038). Shortfalls: (1) this is guest self-service on the ordering login, not operator admin tooling to find, export or delete a guest's records; (2) there is no data-access or export path; (3) the 'Deactivating' wording leaves it open whether data is deleted or only deactivated; (4) nothing shows the deletion reaching loyalty or marketing records. The same client hands loyalty to partners (LOYALTY_AUTHORITY={qu:0,facebook:1,google:2,punchh:3,levelup:4,spendgo:5} @292714), so it very likely does not. https://wo.qubeyond.com/65.cc643fc074acac2b.js · retrieved 2026-09-15 adversarially verified
Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.
guest-loyalty-redemption-fraud-controls
'velocity' occurs once and means drive-thru order velocity; the 17 'fraud' hits in the corpus and 17 in the Adyen contract are payment/chargeback fraud, never loyalty redemption. Redemption velocity limits, manual point-adjustment approval and self-redemption flagging sit inside the loyalty engine, which the certified-partner directory shows is partner-supplied. Subject is the partner; neither Qu nor its partner announcements address redemption fraud controls. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW BOUND (327th), still unknown: tokenised `redemption velocity` 0, `self-redemption` 0, `point adjustment` 0, `fraud` 0 across the 177/177 admin.qubeyond.com chunk census and the retired KB + 53 PDFs. CONTROL POISON: a naive `velocity` scores 13 hits in the admin bundle set and all 13 are the OpenLayers kinetic-scroll physics (`initialVelocity_`, `minVelocity_`, `getDistance`, `decay_`) -- a published 'zero' from an untokenised control here would have been an artefact either way. The back office does hold per-screen update permissions (e.g. `hasUpdateAttributePermission` gating each settings switch), but no loyalty point ledger exists in it: all 67 `loyalt` occurrences in the 24.4 MB bundle set reduce to exactly two objects, the item type `loyaltyDiscount` and the store setting 'Print Loyalty Barcode' with its per-order-channel selector (`loyaltyBarcodeOrderChannels`). The points ledger belongs to Punchh, a different publisher, so the subject of the claim is outside Qu's own corpus and the cell cannot be scored. Retrieved 2026-09-18. || 331st: NEW CORPUS (331st): www.qubeyond.com's /resource-center/ tree fetched WHOLE from the rebuilt site's sitemap.xml (197/197 URLs at 200, plus the 12 /case-studies/* pages = 209 pages, 1.8 MB of text; prior passes held the pre-rebuild 199-page site and the 39 non-blog pages). Marketing/blog = grade C. `fraud` = 0/209; `velocity` = 1 (Golden Chick's 'drive-through and in-store order velocity'). The wo reward component validates only that entered points do not exceed the balance ('rewardPoint>this.redeemablePoints') and that applied rewards/coupons do not exceed the order total ('You have applied more than the order total') - basket arithmetic, not velocity limits, approval or self-redemption flags. Retrieved 2026-09-18. || 332nd: 332nd. NEW, adjacent only: the wo.qubeyond.com checkout has a per-PAYMENT-TYPE identity check - initGFC() sets isGFCEnabled when any payment type has identityVerificationRequired, and checkout then requires an SMS one-time code to the guest's phone (app-guest-verification-code, /account/verification-requests -> /account/verified-token) before the order proceeds. It gates a tender (likely gift card / stored value), not loyalty reward redemption, and carries no velocity limit, approval threshold or self-redemption flag; the Punchh reward components in the same chunk (app-punchh-redeem-points/-rewards) still validate only balance and order-total arithmetic. Not a partial (adjacent feature). Retrieved 2026-09-18. adversarially verified
Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator
guest-loyalty-ai-offer-recommendation
Platform page, Enterprise AI Agents: "Performance data across locations is analyzed to highlight what's working and what's not. Enterprise Management enables teams to fine-tune promotions, reduce unnecessary discounting." The April 2026 ICP announcement repeats "Enterprise AI agents to optimize decisions like promotions and discounts." Shortfall: the AI agents are described as optimising network-level promotion and discount decisions; no source shows AI/ML recommendations for offer content, a target audience, or send timing to guests, and Qu ships no send channel of its own. https://www.qubeyond.com/platform · retrieved 2026-09-03
Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.
guest-loyalty-stored-value-gift
Stored value/gift is partner-delivered via Paytronix across all channels and locations; not a native Qu ledger. https://www.globenewswire.com/news-release/2026/06/23/3316041/0/en/paytronix-and-qu-further-integration-enabling-advanced-omnichannel-ordering-and-menu-management.html · retrieved 2026-08-01
Labor & workforce
Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.
labor-clock-in-at-pos
Qu holds punch and hours data natively: Notify can alert on "Number of Employees Clocked in ... in one or all of your stores", and the Winter 2025 release describes tip pooling "within the enterprise management solution" that distributes tips "based on hours worked" and is "closed at the end of each payroll week". Shortfall: no source in the 239-page corpus describes the punch mechanism itself - there is not a single mention of clock-in, time clock, punch or timecard at the terminal, so PIN/badge/card clock-in at the POS is not established (the word "punch" and "time clock" return zero hits site-wide). https://www.qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money · retrieved 2026-09-03 adversarially verified
Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator
labor-photo-punch-verification
CLAIM: captures a photo at punch (or facial verification) ATTACHED TO THE TIMECARD ENTRY, with a photo-only non-biometric mode. VERDICT no. NEW SURFACE: the standing note said 'punch', 'time clock' and 'clock-in' return zero hits - that was true of the marketing corpus only. Qu ships a native time clock and it is fully visible in the closed 177-file fixpoint census of admin.qubeyond.com (172 loader-table chunks + 5 entry bundles, 24.0 MB, round-2 new refs 0). EVIDENCE: routes /configuration/time-entries and /configuration/time-entry-grid; a $employeesTimeEntryService; an 'EditTimeEntryModal' whose validated field set IS the timecard entry and is complete - operationalUnitId, dateTime, activity, breakReasonId, jobTitleId, description (2cafb169cc01cb20198d.js), with shift validators 'The clock in time should be the earliest of all the entries in the shift' and 'The clock Out time should be the latest of all the entries in the shift'; a dedicated terminal type quTimeClock whose own required field is windowsComputerName (7e5f699696df7fa7804a.js); and break-rule configuration ('Break Rules by Hours Worked', 'Entitled Breaks', 'Minimum work time for paid break eligibility'). No image, attachment, template or verification field exists on the entry. CONTROLS over all 177 files: 'selfie|facial' 0 real hits; 'photo' 2 hits, BOTH POISON - the FontAwesome glyph .fa-photo-video and the emoji dictionary "selfie":"🤳"; 'camera' 6 hits, all poison (fa-camera, fa-camera-retro, and emoji "camera"/"video_camera"); 'biometric' 0; 'buddy' 0; 'fingerprint' 31 hits, ALL POISON (the FontAwesome glyph .fa-fingerprint and Sentry's Scope._fingerprint/setFingerprint). BOUND: Qu's back office is where a timecard entry is displayed and edited; the POS terminal binary is not in this corpus. Retrieved 2026-09-17. GRADE SET AT MERGE (324th): production JS bundle / script-loader census = grade B, not A, per the 321st precedent that downgraded sapaad override-audit A->B for source-map evidence. An anonymous OpenAPI spec can be A; first-party application code that the vendor does not publish as documentation cannot. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/2cafb169cc01cb20198d.js · retrieved 2026-09-17 adversarially verified
Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.
labor-geofenced-mobile-punch
CLAIM: mobile clock-in restricted by geofence or location validation for staff with no fixed terminal. VERDICT no, on the same closed 177-file fixpoint census of admin.qubeyond.com described under labor-photo-punch-verification. EVIDENCE: the punch device is enumerated and it is fixed. The terminal editor's type discriminators are POS, drive-thru, OCS, kiosk, QuBox, ORB, OMS and quTimeClock (isTypePosOrDriveThru, isTypeDriveThru, isTypeOCS, isTypeKiosk, isTypeQuBox, isTypeORB, isTypeQuTimeClock in 7e5f699696df7fa7804a.js), and the quTimeClock branch requires windowsComputerName - a named Windows machine, not a phone. No mobile-punch surface and no location validation exists on the time entry, whose whole field set is operationalUnitId / dateTime / activity / breakReasonId / jobTitleId / description. CONTROLS over all 177 files: 'geofenc' 0; word-boundary 'radius' 415 hits, ALL POISON - every one is the CSS property border-radius (and one Syncfusion ripple option), never a fence radius; 'latitude|longitude|geolocation' 41 hits, ALL POISON - every one is the Google Places store-address autocomplete in 3f07ebe9 (e.location.lat()/lng(), placeId, formattedAddress) used to geocode an operational unit's street address, never an employee punch. Positive control: the time-clock vocabulary itself is present ('Break Reason', 'Entitled Breaks', clock-in/out shift validators). Retrieved 2026-09-17. GRADE SET AT MERGE (324th): production JS bundle / script-loader census = grade B, not A, per the 321st precedent that downgraded sapaad override-audit A->B for source-map evidence. An anonymous OpenAPI spec can be A; first-party application code that the vendor does not publish as documentation cannot. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/7e5f699696df7fa7804a.js · retrieved 2026-09-17 adversarially verified
Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator
labor-offline-time-punch
Qu's offline claims are consistently scoped to commerce, not labor — the Business Edge story is that ordering, payments and kitchen routing continue and 'Sync resumes automatically' — and no page extends that to time punches or describes duplicate-free reconciliation on reconnect. The claim explicitly requires the behaviour be documented, and Qu documents its offline scope only at the level of order flow; but this surface would never enumerate which subsystems are excluded from local execution, so the omission cannot be converted into a no. || 324th: NEW SURFACE, still not settling: the closed 177-file fixpoint census of admin.qubeyond.com (Qu Enterprise Intelligence back office, build 3.6.234-260914.1; 172 loader-table chunks + 5 entry bundles, 24.0 MB) proves Qu ships a FIRST-PARTY time clock - a quTimeClock terminal type, /configuration/time-entries and /configuration/time-entry-grid, an EditTimeEntryModal with clock-in/clock-out shift validators, break reasons and break rules - so the claim's subject exists and is Qu's, not a partner's. But the back office holds no offline or reconciliation semantics for it: 'offline' returns 398 hits and every one is POISON, the Syncfusion DataManager's dataSource.offline/enablePersistence plumbing in 1d26096a; 'reconcil' returns 48 hits and every one is TILL CASH reconciliation (reconcileCash, expectedCash, reconcileDateTime, codeEnum.reconcile in 47af17a8) - POISON for this cell - while 'duplicate punch' and 'sync on reconnect' are 0. Offline punch buffering would live in the terminal binary, which is not served by this host. Retrieved 2026-09-17. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: time punches are recorded while the POS is offline and reconciled on reconnect without loss or duplicates, with the behaviour documented. VERDICT unknown. EVIDENCE: Qu published a dedicated offline-behaviour article for each generation and both scope the guarantee to commerce only. 'What Happens if My Store Loses Internet? (First Gen 2.0)': 'Qu remains fully operational on the terminal in the event of an internet outage. For our Worldpay customers credit cards can be processed offline and checks may be closed. Orders may be sent to the kitchen and sharing checks between terminals will not be affected so long as there is no impact to the local network. However, it's important to note that checks will be queued locally on the terminals until internet service is restored.' The Next Gen article repeats it. Only CHECKS are named as queued and posted; time entries are named in neither. The clock-in/clock-out articles of both generations, their PDFs, and the EI manual's Chapter 9 'Time Entries' describe punching and payroll editing with no offline or reconciliation statement, and `time punch` = 0 across both corpora. Retrieved 2026-09-18. || 328th: NEW SURFACE (328th), third-party (grade D) but CURRENT and about the shipping product: 7shifts' Qu POS integration article (updated 2026-08-04) states 'Version 3.5+ of Qu POS is required', that 7shifts 'pulls employee punches and labor costs', and documents Schedule Enforcement - 'staff can only clock into Qu POS when they have a scheduled shift in 7shifts... If an employee is not scheduled, a manager override on the POS terminal is required to allow the clock-in' - configured on Qu's side at admin.qubeyond.com/configuration > Stores > Platform Settings > include 'Labor Schedules' > 'Enable Labor Schedule' plus grace periods, then a manual terminal update. Qu's own bundle corroborates the setting (feature `EI-LaborSchedule`, route configuration/employees/<id>/labor-schedule). Nothing in it, or anywhere else, states what happens to a punch taken while the terminal is offline: `time punch` = 0 and the offline statements Qu does publish name only checks and credit payments. Retrieved 2026-09-18. || 332nd: MERGE HOLD (proposed no/C, held unknown): Qu's operator documentation exists but is login-gated (support.qubeyond.com Document360, Qu U TalentLMS), so the public site is not a census of what the vendor documents; and /qu-business-edge's 'All transactions are written locally ... No data loss during outages' may cover time entries. PROPOSAL AS WRITTEN: 332nd. OWNER RULING 2026-09-18 (Q7): labor-offline-time-punch ('...with the behavior documented') is DOCUMENTATION-SHAPED, so a publication census that finds no documented offline time-punch behaviour carries `no` (square, spoton landed on the same shape). CLAIM: time punches recorded while offline and reconciled on reconnect without loss or duplicates, with the behaviour documented. VERDICT: no/C. NEW SURFACE (332nd): Qu's training LMS 'Qu U' (campus.qubeyond.com and crew.campus.qubeyond.com, from the 325th crt.sh list, never opened) is a TalentLMS tenant whose only entry is SAML SSO ('/index/ssologin/service:saml'); /catalog 302s to /index, every other path to /index/error, /api/v1/catalog is 401 - no public course catalogue. With support.qubeyond.com a login-gated Document360, Qu's operator documentation is gated on BOTH surfaces, so its public publication set is www.qubeyond.com (sitemap.xml re-counted 2026-09-18: 248 URLs = 39 core pages + 209 resource-centre/case-study pages, both censused in the 327th/331st). BOUND/CONTROLS: tokenised, word-boundary, case-insensitive over all 248 current public pages (the 39 core pages of the 327th + the 209 resource-centre/case-study pages of the 331st): `time clock`/`timeclock` 0, `clock in`/`clock-in`/`clock out` 0, `clocking` 0, `punch`/`punches`/`time punch` 0, `timecard`/`time card` 0, `time entry`/`time entries` 0 - Qu's public site never describes its time clock at all, offline or online. KNOWN-POSITIVE controls fire on the same corpus (`offline` 31 over www + resource centre; and the identical time-clock regex fires 11 times on the admin $gettext table - 'Add Time Entry', 'The clock in time should be the earliest of all the entries in the shift' - and 177 times on the retired KB), so the regex works. WHAT QU DOES DOCUMENT OFFLINE (re-fetched live 2026-09-18, https://www.qubeyond.com/qu-business-edge, 200): 'Write-Local, Sync-Global Data Model All transactions are written locally at the edge and propagated to the cloud in real time. - No batch reconciliation as a primary model - No data loss during outages - Automatic conflict resolution and state reconciliation on reconnect'; 'During network disruption: - Full transaction processing continues - System state is preserved locally - Sync resumes automatically'. That is a generic TRANSACTION model; it names no labour object, and Qu's only dedicated offline article (retired KB, both generations; corroboration only, it carries no `no`) names checks and card payments as what is queued. The time clock itself is Qu's (admin: quTimeClock terminal type, /configuration/time-entries; 7shifts pulls 'employee punches' from Qu POS), so this is not a no-module hold. WEAKEST ROW, stated plainly: grade C (marketing pages are the whole public set), and a reader who takes 'All transactions' to include time entries would call the generic model a partial; the claim's 'behaviour documented' for PUNCHES is what is absent. If the merge reads the generic line as covering punches, hold unknown. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES (not settling; the 332nd hold stands - gated docs): (a) go.qubeyond.com/taco-johns-faq, an unlinked HubSpot landing page found by a /_hcms/search sweep (52 LANDING_PAGEs; 14 of them answer plain curl with a Cloudflare 'Checking browser' interstitial and open with Sec-Fetch headers): 'Qu is "Cloud-Deployed", not Cloud-Dependent ... The Qu POS terminals continue to operate without the internet, and can even continue to create guest checks and accept credit card payments if the in-store network goes down', plus EMV store-and-forward - offline scope is named as checks and card payments, not time punches. (b) Qu's CEO in the State of Digital LinkedIn Live (Wistia c0oq8mnex4): 'All the clock in and clock out happens on the POS. The POS ends up becoming the system of record of how much I should pay someone.' So punches are taken on the POS and the POS runs offline, but no source states what happens to a punch taken offline; `time clock` = 0 and `punch` never about offline in the 96-transcript video corpus. Retrieved 2026-09-18. adversarially verified
Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.
labor-granular-rbac
Granular permissioning, user administration and role-based permission management are claimed across brands and locations; per-action grant lists are not published. https://www.qubeyond.com/management/brand-franchise-management · retrieved 2026-08-01
Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.
labor-manager-override-audit
Chapter 12: Audit Trail (First Gen 2.0, updated 2020-04-20): 'The Qu audit trail provides a detailed activity history of changes occurring within Qu. Changes can be tracked based on Date, Employee, Module, Location and any combination of the above. The report can also be exported as a csv document. Audit Trail can only be accessed from the Enterprise Level of Qu Enterprise Intelligence.' Approver attribution exists at the POS: restricting till functions means 'the POS will present a manager prompt to the cashier when performing restricted actions', and per 'Assigning an Employee Mag Card to a User' (Jan 2021) the manager clears it by swiping their own card. EI time-entry edits are attributed (a 'Last Edit By' field and an 'Edited shifts' filter in Labor Summary, v141-v143 release notes) and 'you are required to enter a comment to indicate the reason for manually updating the entries'. Shortfall: the docs never state that POS manager overrides themselves land in the audit trail, and immutability or tamper-evidence is nowhere asserted. Vintage: First Gen 2.0 (2018-2020) and Next Gen 3.5 (2020-21). https://web.archive.org/web/20200809112957/https://support.qubeyond.com/hc/en-us/articles/360001271931-Chapter-12-Audit-Trail-First-Gen-2-0- · retrieved 2026-09-03
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
Re-evidenced 2026-08-08: /about/qu-technology-partners/ now 301s to /integrations, which carries the same evidence. Qu ships no scheduling product - the site-wide Platform Solutions enumeration (five ordering products, three kitchen products, Qu Pay, five management products), corroborated item for item by the sitemap's product URL tree, contains no workforce, scheduling or time-and-attendance module. Scheduling is partner-delivered: the integrations directory's 'Back of House + Labor' category lists 7shifts, Altametrics, HotSchedules, Harri, Workstream and Proliant among its 150 certified integrations. Schedule building and publishing therefore happen in a third-party app, not in the platform holding the sales data. https://www.qubeyond.com/integrations · retrieved 2026-08-08 adversarially verified
Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator
labor-demand-labor-forecast
"The machine learning models and AI function within Notify provide sales and labor forecasting based on previous store performance. These predictive analytics help you adjust staffing levels in advance." The Notify product page repeats "predictive analytics help you forecast trends and optimize staffing". Shortfall: the forecast is advisory output in the Notify mobile app built on the operator's own store history; the corpus never shows recommended staffing levels or labor hours broken out by daypart, and Qu ships no scheduling surface (7shifts and Altametrics sit in Qu's "Back of House + Labor" partner category). https://www.qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money · retrieved 2026-09-03
Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator
labor-realtime-labor-percent
Notify is described as "Qu's voice-activated and AI-enabled real-time reporting app" where a manager can "check on store sales, top selling items, labor to net sales percentage", with configurable alerts on "Labor to net sales percentage". Shortfall: the only evidence is a 2022 vendor blog post; the current Notify product page reduces this to "sales, labor, and operational metrics", and no product documentation states the refresh interval or that the figure is available on the POS itself during service. https://www.qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money · retrieved 2026-09-03 adversarially verified
Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator
labor-overtime-prevention
Notify alerts can be configured on KPI thresholds "including staff overtime", and the listed example is "get alerted any time of the day about: Employees who are close to overtime". Shortfall: this is a threshold alert pushed to a manager's phone, not a warning or block presented at clock-in on the terminal; nothing in the corpus prevents or interrupts the punch, and the overtime threshold is described only as a configurable Notify KPI. https://www.qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money · retrieved 2026-09-03
Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator
labor-break-compliance-by-state
Re-evidenced 2026-08-08: /about/qu-technology-partners/ now 301s to /integrations, which carries the same evidence. Qu ships no labor module: the site-wide Platform Solutions enumeration (ordering, kitchen, payments, and menu/channel/brand/notify/data management), corroborated by the sitemap's product URL tree, has no workforce, scheduling or time-and-attendance product, and Qu's own directory delegates the category - 'Back of House + Labor' lists 7shifts, Altametrics, HotSchedules, Harri, Workstream and Proliant. Per-state break-rule configuration, break-attestation prompts and missed-break premium flagging are workforce-module features that live in those partner products, not in Qu. (7shifts' Qu integration article remains unreadable: kb.7shifts.com returns HTTP 403 to both direct fetch and the Zendesk help-center API, re-probed 2026-08-08.) https://www.qubeyond.com/integrations · retrieved 2026-08-08 adversarially verified
Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.
labor-fair-workweek-support
Re-evidenced 2026-08-08: /about/qu-technology-partners/ now 301s to /integrations. The chain established for labor-native-scheduling and labor-shift-swap-workflow (both 'no') re-verified on live pages: Qu's enumerated platform - five ordering products, three kitchen products, Qu Pay, five management products, matching the sitemap product tree exactly - contains no workforce module, and the integrations directory routes 'Back of House + Labor' to 7shifts, Altametrics, HotSchedules and Harri. Predictive-scheduling ordinance support requires a native scheduling system to measure schedule publication and employer-initiated changes against; Qu has none, so advance-notice tracking and predictability-pay calculation are properties of the partner product. https://www.qubeyond.com/integrations · retrieved 2026-08-08 adversarially verified
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
Re-evidenced 2026-08-08: /about/qu-technology-partners/ now 301s to /integrations. The claim requires enforcement at both scheduling and clock-in. Qu has no native scheduling surface at all - the site-wide Platform Solutions enumeration and the sitemap's product URL tree agree on fourteen products (ordering, kitchen, payments, management) with no workforce module - and the vendor's own directory routes the category to 'Back of House + Labor' partners 7shifts, Altametrics, HotSchedules and Harri. Age-based hour caps, prohibited time windows and school-day limits therefore cannot be enforced natively at scheduling; any such enforcement is a property of the partner product. The nearest thing Qu ships is reporting, not enforcement: Qu Notify Mobile Insights offers 'real-time reporting across stores, labor, and items'. https://www.qubeyond.com/integrations · retrieved 2026-08-08 adversarially verified
Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.
labor-tip-pooling-rules
Same source as labor-tip-distribution-audit-trail and payments-tip-pooling: Qu "automatically transfers sales, payment, and tip information to 7shifts," giving Qu per-employee tip capture. Shortfall: the automatic per-shift pooling computation from configurable rules (hours worked, sales percentage, role, points) happens inside 7shifts' separately licensed Tip Pooling module, not in Qu, which publishes no native pooling rule engine. https://kb.7shifts.com/hc/en-us/articles/35540967177875-Tip-Pooling-for-Qu-POS · retrieved 2026-08-04
Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.
labor-tip-distribution-audit-trail
7shifts' 'Tip Pooling for Qu POS' doc (updated 2026-06-24) states 'Qu automatically transfers sales, payment, and tip information to 7shifts' and requires 'user assignments to orders/sales in Qu POS', establishing per-employee tip capture in Qu. Shortfall: pool contribution rules, distribution calculation, reports and payroll export all live in 7shifts' separately licensed Tip Pooling module, not in Qu — Qu publishes no first-party tip-pool ledger or export (its help centre is login-gated). Article HTML is bot-gated; body read via the site's public Zendesk article API for the same article id. https://kb.7shifts.com/hc/en-us/articles/35540967177875-Tip-Pooling-for-Qu-POS · retrieved 2026-08-03
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
Report Calculations (First Gen 2.0, updated 2020-04-20, archived 2020-12-01) shows the Tip Track report separating the two tip populations explicitly: 'Total Receipts = Gross Sales + Charged Tips + Cash Tips' and 'Total Direct Tips = Charged Tips + Cash Tips'; the Next Gen Labor reports add a Tip report that 'Displays all tips collected by each employee' and a Payroll Summary of regular/overtime hours and earnings per employee. Shortfall: cash-versus-charged separation is present but nothing in the corpus carries a Treasury tipped-occupation code, a W-2 Box 12 code TP field or Box 14b output, and no payroll-export format is documented at all. Vintage: First Gen 2.0 / Next Gen 3.5, 2017-2020 - this documentation predates the TY2026 requirement entirely, so the missing conjunct is untested rather than refuted. https://web.archive.org/web/20201201062202/https://support.qubeyond.com/hc/en-us/articles/115006316228 · retrieved 2026-09-03
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The /platform Platform Solutions navigation enumerates the complete catalog - ordering, kitchen, payments and platform management - with no payroll or HR product, and /management's five products (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting) name no labor function at all. Positively, Qu's own integrations directory (all 120 partners enumerated) files payroll under "Back of House + Labor" as a partner category: Proliant (payroll processing), alongside 7shifts, HotSchedules, Harri and Workstream. Qu does not file tax or run direct deposit itself. https://www.qubeyond.com/integrations · retrieved 2026-08-08
Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).
labor-payroll-export-formats
Qu's certified-partner directory (Webflow CMS, walked ?12898331_page=1..14, 121 items served against a page label reading 'Showing 1 to 9 of 150') lists under category 'Back of House + Labor': Proliant (proliant.com), Fourth/HotSchedules (fourth.com/product/hotschedules), Altametrics, 7shifts, Harri and Workstream. Qu's own post 'What Qu's Doubled Integration Network Means For You' (qubeyond.com/resource-center/what-qus-doubled-integration-network-means-for-you, grade D) groups them explicitly: 'Labor Management: Optimize your workforce with sophisticated tools from HotSchedules, Proliant, and Rippling.' So direct certified integration with at least two payroll/HCM providers exists. Shortfall: payroll reaches the operator only through those third-party partners -- Qu publishes no export file format or field list, neither the directory nor the post states that timecards, wages or tips are the data exchanged, and none of Gusto, ADP, Paychex or QuickBooks appears anywhere in the 121-partner directory or the 239-page qubeyond.com corpus (Rippling is named in the post but is absent from the directory, so the directory is not exhaustive). https://www.qubeyond.com/integrations · retrieved 2026-09-03
Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator
labor-shift-swap-workflow
Re-evidenced 2026-08-08: /about/qu-technology-partners/ now 301s to /integrations. Qu ships no native scheduling product - the enumerated platform (Omnichannel Ordering, Smart Kitchen Solutions, Qu Pay, Unified Platform Management; fourteen products, matching the sitemap product tree) has no workforce module, and the integrations directory's 'Back of House + Labor' category lists 7shifts, Altametrics, HotSchedules, Harri and Workstream. With no schedule to swap against and no employee self-service app in the line-up, there is no shift-swap or open-shift-claim workflow with manager approval in Qu itself; those are properties of the partner scheduling product. https://www.qubeyond.com/integrations · retrieved 2026-08-08 adversarially verified
Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.
labor-digital-onboarding-i9
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The /platform Platform Solutions navigation enumerates the entire product line with no HR, hiring or onboarding module, and /management's five products name no employee function. Qu's own integrations directory (all 120 partners enumerated) places hiring and onboarding in the "Back of House + Labor" partner category - Workstream and Harri are both hiring/onboarding platforms, with 7shifts and HotSchedules for scheduling and Proliant for payroll. No Qu-published page mentions W-4, I-9 or E-Verify. https://www.qubeyond.com/integrations · retrieved 2026-08-08
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
Qu Reports Quick Guide (Next Gen 3.5, Oct 2020) documents per-employee exception metrics - 'Voided Items - Displays all voided items by an employee', 'Refunds - Lists all refunded checks by an employee', 'Labor Red Flag - Displays the total activity for several KPIs. This report is useful for analyzing whether the store or employee uses specific actions (e.d voids) too often' - plus an employee filter on every report so sales can be sliced per cashier. Shortfall: void and refund activity by employee is documented but average check per server, items-per-check and category attachment rate are not; comps are folded into discounts ('Discounts generally include manager comps and coupons', Report Calculations) with no per-employee comp rate. Vintage: Next Gen 3.5, 2020 archived help centre. https://web.archive.org/web/20201128174707/https://support.qubeyond.com/hc/en-us/articles/360049022511-Qu-Reports-Quick-Guide-Next-Gen- · retrieved 2026-09-03
Inventory, purchasing & cost control
Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.
inventory-recipe-bom-costing
Re-evidenced 2026-08-08 after the cited /products/ page went dead. The /platform Platform Solutions navigation enumerates the complete catalog - Omnichannel Ordering, Smart Kitchen Solutions, Smart Payment Solutions, Unified Platform Management, Qube, Qu Equip, Qu Business Edge - with no inventory module, and neither /management nor /kitchen names inventory, recipes or food cost. Qu's own integrations directory (all 120 partners enumerated) carries nine inventory and recipe-costing vendors under "Back of House + Labor": MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics and Rosnet. Multi-level recipe/BOM costing is bought from one of those, not built into Qu. https://www.qubeyond.com/integrations · retrieved 2026-08-08
Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.
inventory-unit-conversion-yields
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. purchase/recipe/count units with conversion factors and a yield percentage are attributes of an inventory item master. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. I re-fetched the whole 233-URL sitemap on 2026-08-08 and searched the rendered text: "par level", "purchase order", "spoilage", "depletion" and "commissary" return zero occurrences anywhere on qubeyond.com, and "invoice" appears only in a blog post about POS billing. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. Unit conversion and yield are configured in whichever of those the operator buys, not in Qu. https://www.qubeyond.com/platform · retrieved 2026-08-08
Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator
inventory-theoretical-vs-actual
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. a theoretical-vs-actual variance report needs both recipe-driven theoretical usage and counted actual usage, and Qu ships neither. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. The word "theoretical" occurs exactly once on qubeyond.com, in an unrelated sentence about connectivity risk. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. Variance reporting is what those partners sell. https://www.qubeyond.com/platform · retrieved 2026-08-08
Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator
inventory-realtime-depletion
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. Qu's actual item-availability mechanism is manual, not ingredient-driven. The Fall 2025 release highlights describe it plainly: "Notify Item Availability: Manage in and out of stock items anywhere - Mark items in/out of stock from your phone and set a 'Revive Date' to auto-restock later." A product that ships a manual in/out-of-stock toggle with a timed revive is not depleting ingredient on-hand quantities as orders fire. "Depletion" returns zero occurrences across the whole site, and the /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. https://www.qubeyond.com/resource-center/qus-fall-2025-product-release-highlights · retrieved 2026-08-08
Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator
inventory-86-auto-sync
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. the propagation half is real and the trigger half is not. /ordering/pos states "Price changes, modifiers, and 86'd items update everywhere simultaneously with no manual sync required", and the Fall 2025 release highlights give the mechanism: "Notify Item Availability ... Mark items in/out of stock from your phone and set a 'Revive Date' to auto-restock later." The 86 is entered by a human and revived on a clock. Threshold-driven auto-86 needs ingredient on-hand levels, and the /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. https://www.qubeyond.com/resource-center/qus-fall-2025-product-release-highlights · retrieved 2026-08-08
Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.
inventory-count-modes
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. full physicals, spot counts and recurring cycle counts with retained per-count variance history all presuppose a count ledger. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. I re-fetched the whole 233-URL sitemap on 2026-08-08 and searched the rendered text: "par level", "purchase order", "spoilage", "depletion" and "commissary" return zero occurrences anywhere on qubeyond.com, and "invoice" appears only in a blog post about POS billing. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.
inventory-mobile-count-offline
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. Qu's mobile app is Qu Notify, and its own page enumerates its key features: "Customizable Real-Time Alerts", "Intelligent Data Access" (voice commands and an AI chatbot), "Visual Analytics & Forecasting" and "Performance Reporting". Its FAQ describes it as "a mobile insights app ... that delivers real-time operational alerts, AI-driven insights, end-of-day summaries, and a real-time Kitchen Intelligence Score". No counting workflow, no barcode or QR scanning, no offline count buffer. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-08
Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator
inventory-vendor-catalogs-edi
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. there is no purchasing surface to hang EDI on. The phrase "purchase order" returns zero occurrences across all 233 pages of qubeyond.com, no broadline distributor (Sysco, US Foods, PFG) appears anywhere on the site, and the /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. Buyers Edge Platform, the one procurement name in the directory, is a partner rather than a Qu module. https://www.qubeyond.com/integrations · retrieved 2026-08-08
Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator
inventory-invoice-ocr
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. the word "invoice" appears on exactly one page of qubeyond.com, a blog post about POS billing practices, and never as a product capability. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. Invoice capture is supplied by partners in the enumerated /integrations directory - marginedge under Analytics, and Restaurant365, Compeat and Crunchtime under "Back of House + Labor". https://www.qubeyond.com/integrations · retrieved 2026-08-08
Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator
inventory-price-change-alerts
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. per-item purchase price history is a purchasing-ledger feature and Qu has no purchasing ledger: "purchase order" and "invoice" as a capability return zero hits site-wide. Qu Notify's alerting is enumerated on its own page as "sales anomalies, service-time thresholds, equipment issues, the real-time Kitchen Intelligence Score, and other configurable operational exceptions" - no received-price threshold among them. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/integrations · retrieved 2026-08-08
Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator
inventory-par-auto-suggest
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. "par level" returns zero occurrences across all 233 pages of qubeyond.com. The nearest thing Qu ships is Smart Kitchen production forecasting - /platform: "Smart Kitchen uses production forecasting and kitchen load balancing to help teams stay ahead of demand and prepare the right amount of food at the right time" - which forecasts prep quantities for the line, not order quantities against a stocked par, and produces no purchase order. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.
inventory-waste-logging
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. "spoilage" returns zero occurrences site-wide, and every use of "waste" on qubeyond.com is an outcome claim, not a logging feature - /platform: production planning means "less waste, better throughput"; /kitchen-solutions/energy-equipment-intelligence flags "energy waste". Reason-coded waste entries that debit stock and report waste cost apart from usage variance require an inventory ledger, and the /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.
inventory-transfers
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. a two-sided transfer with an in-transit state requires per-location stock balances to credit and debit. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. I re-fetched the whole 233-URL sitemap on 2026-08-08 and searched the rendered text: "par level", "purchase order", "spoilage", "depletion" and "commissary" return zero occurrences anywhere on qubeyond.com, and "invoice" appears only in a blog post about POS billing. Multi-location functionality on /management is menu, channel and brand configuration plus cross-brand reporting - no stock movement between stores. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.
inventory-commissary
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. "commissary" and "central kitchen" return zero occurrences across all 233 pages of qubeyond.com. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. Smart Kitchen Solutions covers KDS, Order Status and equipment monitoring for a single restaurant's line; nothing issues prep items to other locations at a computed transfer cost. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.
inventory-lot-traceability
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. lot capture at receiving presupposes a receiving function, and Qu has none: "purchase order" and "invoice" as capabilities return zero hits site-wide, and the /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. No recall, traceability or lot/batch language appears anywhere in the re-fetched corpus. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.
inventory-shelf-life-expiry
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. expiry tracking needs dated received or prepped stock records. The /platform Platform Solutions catalog enumerates every product family Qu sells - Omnichannel Ordering (POS, Kiosk, Drive-Thru, Online Ordering, Third-Party Ordering), Smart Kitchen Solutions (KDS, Order Status, Energy & Equipment Intelligence), Smart Payment Solutions (Qu Pay), Unified Platform Management (Unified Menu Management, Channel Management, Brand & Franchise Management, Qu Notify, Unified Data & Reporting), Qube, Qu Equip and Qu Business Edge - and there is no inventory, purchasing or food-cost product among them. I re-fetched the whole 233-URL sitemap on 2026-08-08 and searched the rendered text: "par level", "purchase order", "spoilage", "depletion" and "commissary" return zero occurrences anywhere on qubeyond.com, and "invoice" appears only in a blog post about POS billing. The only date-driven availability feature Qu documents is the Fall 2025 "Revive Date" on a manually 86'd menu item, which restores an item on a schedule rather than warning that stock is about to expire. Qu's own /integrations directory, walked page by page through all 17 pages (121 named partners), files nineteen vendors under "Back of House + Labor" including MarketMan, Restaurant365, Crunchtime, Compeat, COGS-Well, Decision Logic, SynergySuite, Altametrics, Rosnet, Ctuit and Buyers Edge Platform. https://www.qubeyond.com/platform · retrieved 2026-08-08
Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.
inventory-bar-partial-bottle
Re-evidenced 2026-08-08: the cited https://qubeyond.com/products/ now 301s to the homepage, so the original "no native inventory module" leg is withdrawn and replaced. Qu is a multi-unit QSR and fast-casual platform (/payments/qu-pay: "Qu Pay is built for multi-unit QSR") with no inventory ledger at all, let alone weight-based or fractional bottle counting; no scale integration appears among the 121 enumerated partners. Beverage-level monitoring in Qu's ecosystem is a partner concern - DigitalPour is listed under "Back of House + Labor" in /integrations. https://www.qubeyond.com/integrations · retrieved 2026-08-08
Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.
inventory-cogs-gl-export
Accounting is a listed partner category and Restaurant365 publishes a Qu POS connector; Qu ships no first-party GL export with mapping. https://www.restaurant365.com/partners/qu-pos/ · retrieved 2026-08-01
Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator
inventory-native-not-partner
Inventory and recipe costing are explicitly partner-delivered (MarketMan, Restaurant365) and absent from Qu's enumerated product catalog. https://www.marketman.com/partner/qu · retrieved 2026-08-01
Reporting, BI & data access
Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.
reporting-realtime-dashboard
Unified Data & Reporting plus the Qu Notify mobile app; Qu claims live system-wide data access in under two seconds. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-08-01
Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.
reporting-eod-closeout
Qu Notify delivers end-of-day summaries; a full reconciling close-out document (tax, tips, tenders, expected deposit) is not documented. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-01
Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.
reporting-pmix-modifier-level
Product page FAQ: "Qu lets operators compare performance across locations, dayparts, and channels in one view, surfacing top performers, operational gaps, and revenue opportunities without exporting data to spreadsheets." Item-level sales are evidenced on the Notify blog, whose dashboard list includes "Net Sales, Check Counts, Payments, Average Check Size, Gross Sales, Discounts, Cash, Voids, Service Charges, Taxes, Item Sales & Gift Card Sales" (qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money). SHORTFALL: nothing on any of the 239 reachable qubeyond.com pages describes a product-mix report at MODIFIER level, nor an item-level gross-vs-net sales split, nor a revenue-center filter. No grade-A/B documentation exists to check: qu-api.qubeyond.com and qu-pos-api.qubeyond.com both answer with a Microsoft *.azurewebsites.net certificate (TLS altname mismatch) and support.qubeyond.com 302s every path to /login. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-09-03
Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.
reporting-comps-voids-audit
Notify's dashboard metric list includes "Discounts, Cash, Voids, Service Charges" and alerts can be configured on "staff overtime, cash, voids, and more". The Winter 2025 release post adds Notify Check Search, which "allows staff to filter transaction data based on a wide range of criteria, including Date, Employee, and Order Type". SHORTFALL: voids and discounts appear only as aggregate dashboard metrics plus a generic transaction filter; no reachable Qu page describes a comps/voids/override audit report carrying reason codes, timestamps, the applying employee AND the approving manager. Qu publishes no help centre or admin guide (support.qubeyond.com login-walled; both qu-api hosts fail TLS identity), so no grade-A/B source exists to settle it. https://www.qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money · retrieved 2026-09-03
Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.
reporting-cash-over-short
Fall 2025 release: "We've added a single 'Reports' button on the POS that consolidates End of Day, End of Shift, and Tills reports in one spot." Notify separately alerts on "Cash" as a monitored metric. SHORTFALL: a Tills report at the terminal is evidenced, but no reachable Qu surface states that it computes an over/short variance (counted cash vs expected cash from tenders and paid-outs) or attributes that variance per drawer and per employee. No vendor documentation is reachable to confirm the report's contents (support portal login-walled; both API hosts fail TLS identity). https://www.qubeyond.com/resource-center/qus-fall-2025-product-release-highlights · retrieved 2026-09-03
Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.
reporting-labor-productivity
Labor metrics alongside sales are surfaced in Notify; sales-per-labor-hour by hour/department/employee is not documented. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-01
Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator
reporting-server-scorecards
Qu Reports Quick Guide (Next Gen 3.5, Oct 2020): every report carries an 'Employee Filter - Each report shows data for all employees, and the user can filter them to display data for a specific employee'; the Labor group includes a Tip report ('Displays all tips collected by each employee') and a Labor Red Flag report ('Displays the total activity for several KPIs... useful for analyzing whether the store or employee uses specific actions (e.d voids) too often'); Voided Items 'Displays all voided items by an employee' and Refunds 'Lists all refunded checks by an employee'. Shortfall: there is no per-server scorecard object - average check appears only on Hourly Sales (by hour, not by server), and items per check, category attachment rate and tips as a percentage of sales are not documented anywhere in the catalogue. Vintage: Next Gen 3.5, 2020. https://web.archive.org/web/20201128174707/https://support.qubeyond.com/hc/en-us/articles/360049022511-Qu-Reports-Quick-Guide-Next-Gen- · retrieved 2026-09-03
Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator
reporting-channel-profitability
Reporting is channel-aware and Qu argues "different channels have different economics"; margin net of marketplace commission is not documented. https://www.qubeyond.com/management/channel-management · retrieved 2026-08-01
Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator
reporting-multiloc-drilldown
Product page FAQ: "Qu lets operators compare performance across locations, dayparts, and channels in one view, surfacing top performers, operational gaps, and revenue opportunities." Notify adds "Monitor one store, a group of stores, or your full enterprise from one screen" and Check Search, which displays individual checks chronologically filtered by Date/Employee/Order Type. SHORTFALL: side-by-side location comparison and transaction-level lookup exist as SEPARATE features; no reachable page documents a continuous drill path from group total to one location to one transaction - and Qu markets Notify as delivering "Real-time insights in feed format - no drill-downs required!". Differentiator weight and the best available source is a grade-C feature page, so `yes` is not available. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-09-03 adversarially verified
Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator
reporting-custom-report-builder
"Data-rich reporting and insights with deep customization options" claimed; a named self-service dimension/measure builder is not documented. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-08-01
Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.
reporting-scheduled-delivery
Qu Reports Quick Guide (Next Gen 3.5, updated 2020-10-19, archived 2020-11-28): 'the user can save each report as a custom report (with the filters and customizations that you have selected), scheduled (to be emailed regularly), exported (downloaded or emailed as either an Excel file, CSV, or PDF), and printed' - i.e. any report in the catalogue, not a fixed subset. The companion article 'How do I schedule reports to auto-send? (Next Gen)' gives the mechanics: select the report, Click Schedule, then set Send Time, Time Zone, Frequency and Employees (recipients must have an email on their profile). The First Gen 2.0 admin guide documents the same Email Reports feature from 2017. Vintage: Qu Next Gen 3.5, 2020 archive; not re-verified against today's Intelligent Commerce Platform, but recurring emailed reports are a basic mechanic and the live Brand & Franchise Management page still lists 'Native reporting and notification capabilities'. https://web.archive.org/web/20201128174707/https://support.qubeyond.com/hc/en-us/articles/360049022511-Qu-Reports-Quick-Guide-Next-Gen- · retrieved 2026-09-03
Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator
reporting-raw-warehouse-export
A DataExport API component exists and Qu supports API connections to external BI tools; scheduled push to a customer-controlled S3/SFTP/warehouse is not documented. https://status.qubeyond.com/ · retrieved 2026-08-01
Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator
reporting-public-api
A REST Data Access API exists and is documented: 'All Data Access API calls prefixed with api/v3', with basket/order endpoints under customers/{customerId}/locations/{locationId}/baskets. But the documentation is no longer served -- qu-pos-api.qubeyond.com and qu-api.qubeyond.com both return Azure's 'Error 403 - This web app is stopped' (HTTP 403 Site Disabled, 1148 bytes) on 2026-08-09, and Wayback shows that same stopped-app page from 2023-12-30 onward; the quoted text is from the last good capture (2022-07-24). Documented scope is ordering/baskets only, not payments, menu or labor. No self-serve credentials: support.qubeyond.com redirects every path to a Document360 OIDC login, and integrations are onboarded by partner certification. https://web.archive.org/web/20220724113646/https://qu-pos-api.qubeyond.com/ · retrieved 2026-08-09
Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator
reporting-webhooks
Publication/capability split applied strictly: the claim's head verb is 'Emits', a capability. 'webhook' returns zero hits in the 199-page corpus and zero in the Adyen contract, and Qu publishes no API documentation anywhere (docs./api./developer./developers.qubeyond.com are ENOTFOUND, support.qubeyond.com 302s every path, no llms.txt), so an unpublished partner webhook contract remains a live possibility. Marketing 'open API' / 'bi-directional' copy is grade-C brochure language that enumerates no event or retry semantics. May not be scored `no`. || 324th: NEW SURFACE, not settling: a closed fixpoint census of Qu's production back office admin.qubeyond.com (webpack loader table in 5715f647f5d13934f84e.js lists 172 chunks; all 172 plus the 5 entry bundles fetched, 24.0 MB, 0 new chunk references on round 2) returns 'webhook' 0, 'callback url' 0, 'HMAC' 1 hit, POISON (a base64 blob inside 8fc0d1fe), 'signature' 0 in an event sense, and the 103-route admin map (/configuration/*, /operations, /reports) contains no developer, API-key, integration or webhook-subscription screen at all. That is consistent with Qu exposing integrations only through certified partner onboarding rather than self-service, but a back office is not an API reference, so the claim's capability verb ('Emits') still has no instrument. The cell remains unscoreable rather than negative. Retrieved 2026-09-17. || 325th: MERGE HOLD (proposed partial/B, held unknown): the Payments Portal's roles read as vendor-operated and the portal is an Adyen-for-platforms surface; it is not established that a customer can register an endpoint, the events are payment-only, and retry behaviour is undocumented. PROPOSAL AS WRITTEN: MOVED off unknown: 'webhook' is no longer absent from Qu's surface. NEW SURFACE: pay-admin.qubeyond.com, Qu's production 'Payments Portal' (a single Vite bundle on Qu's own host, /assets/index-D6ChSTf8.js, 6,358,057 bytes, re-fetched live 2026-09-17 and byte-for-byte the same size as the /assets/index-DePrXYp5.js name it was served under earlier the same day, with every string below present in the current bundle; pay-admin.qubeyond.com/robots.txt is 404, i.e. no bar; 1,682 references to Adyen, i.e. Qu Pay on Adyen for Platforms). CLAIM: emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behaviour AND payload signature verification. VERDICT: partial. EVIDENCE: the bundle ships Qu's own API error catalogue including 'WEBHOOK_HMAC_KEY_NOT_FOUND: "Webhook hmac Key not found."', 'WEBHOOK_CONFIG_NOT_FOUND: "Webhook config not found."' and 'WEBHOOK_CONFIG_ALREADY_EXISTS: "Webhook config already exists."' - so webhook CONFIGURATIONS are first-class objects and they are HMAC-signed - and the portal's role catalogue gives a DEVELOPER role whose capability list is 'Manage API keys and authentication / Configure webhook endpoints / Set up integration settings / Manage fee configurations / Configure terminal devices / Access customer data for testing'. The payment lifecycle these would carry is enumerated in the same bundle: AUTHORIZED, AUTHORIZATION_FAILED, CAPTURE_REQUESTED, VOID_REQUESTED, VOIDED, REFUND_REQUESTED, REFUNDED, PARTIAL_REFUND_REQUESTED, PARTIALLY_REFUNDED, PAYMENT_REVERSED, PAYMENT_REFUSED. NAMED SHORTFALL: (1) retry behaviour is documented nowhere - Qu publishes no API reference on any host (docs./api./developer. do not resolve and support.qubeyond.com is a login-gated Document360 KB), so the claim's 'documented retry behaviour' conjunct fails outright; (2) the portal's other roles read as vendor-operated (FINANCE_MANAGER 'Manage customer financial settings', SUPPORT, 'Access customer data for testing'), so whether the endpoint is supplied by the customer or entered by Qu staff on their behalf is NOT established; (3) the evidence is payment-side only - no order-lifecycle event catalogue appears, and `webhook` is 0/175 admin chunks and 0/74 wo files. Retrieved 2026-09-17. || 327th: MERGE HOLD (proposed no/B, held unknown): A webhook surface is a partner/API capability; an undocumented partner API is not bounded by a back-office bundle (326th hold shape). Qu sells an API-first platform whose developer docs are unpublished, which is a refusal of visibility, not an absence. PROPOSAL AS WRITTEN: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. CLAIM: emits outbound webhooks for order and payment lifecycle events to a CUSTOMER-SUPPLIED endpoint, with documented retry behaviour and payload signature verification. VERDICT no. EVIDENCE/BOUND: tokenised `webhook` = 0 across all four corpora -- the 24.4 MB / 177-of-177-chunk admin.qubeyond.com EI back office (where an endpoint registration screen would have to live), the 39-page rebuilt marketing site, and the retired operator KB's 205 articles + 53 PDFs. `callback url` 0, `subscribe` 0 in an event sense, `HMAC` 0, `signature` 0 except receipt signature lines. Qu's own named APIs are all PULL-shaped: the Data Export API and the Labor API in the retired release notes, and no developer portal exists to publish anything else (developers./developer./docs. qubeyond.com do not resolve; every /swagger, /openapi.json, /v3/api-docs and /api-docs probe on 18 Qu hosts returned 404 or no TLS). The partner order integrations Qu names (DoorDash, UberEats, Postmates, Olo, Punchh, Aurus) are connectors Qu builds and operates, not endpoints a customer registers. Retrieved 2026-09-18. || 328th: NEW SURFACE (328th) - the Qu Pay portal bundle's webhook machinery, read in full, and it CONFIRMS the earlier hold rather than lifting it. pay-admin.qubeyond.com ships a webhook configuration object with signing: error enum `WEBHOOK_HMAC_KEY_NOT_FOUND`, `WEBHOOK_CONFIG_NOT_FOUND`, `WEBHOOK_CONFIG_ALREADY_EXISTS` ('Webhook hmac Key not found.', 'Webhook config not found.', 'Webhook config already exists.', localised into Danish among others), and a Developer role whose published description is 'Manage API keys and authentication / Configure webhook endpoints / Set up integration settings / Manage fee configurations / Configure terminal devices / Access customer data for testing'. The sibling roles in the same enumeration are 'View merchants, stores, and organizations', 'Manage customer financial settings', 'View and manage customer accounts', 'Help resolve payment disputes' - i.e. these are QU STAFF roles administering merchants on an Adyen-for-platforms back office, not merchant self-service. So the webhook endpoints are Qu's own platform plumbing; nothing shows an operator registering an endpoint. Qu's customer-facing partner API remains unpublished, so this stays unknown. Retrieved 2026-09-18. || 331st: 331st NEW SURFACE, not settling: Qu's CURRENT job board (ats.rippling.com/qu-careers; the board API https://api.rippling.com/platform/api/ats/v1/board/qu-careers/jobs lists exactly 2 open roles) describes the payments webhooks the 325th/328th found in pay-admin: 'Sr. Software Engineer (Payments & Data)' will 'Own terminal-to-cloud payment flows: device initialization, transaction processing, Store & Forward, and webhook-based reconciliation' with 'PSP integration experience: gateway APIs, terminal APIs, management APIs, webhook notifications'. That reads as INBOUND PSP (Adyen) notifications that Qu reconciles, consistent with the 328th hold, not customer-registered outbound endpoints. Also new: Qu's 2022 API landing page (Wayback, qu-api.qubeyond.com, 'Qu API v 3.0.93.12') describes order intake as store POS systems that 'pull online orders' - a poll model - and names no event or callback. Retrieved 2026-09-18. || 332nd: 332nd NEW SURFACE, not settling: Qu's July 2022 white paper 'Going Beyond POS to a Unified Commerce Platform' (grade C, still linked from the current site) - 'webhook' / 'callback' = 0; its only outbound mechanisms are 'Alerting - Configure and receive alerts about enterprise-level rules on sales, labor, and other key metrics' and an unspecified 'real-time data feed' for custom dashboards. Neither names a customer-supplied endpoint, order/payment lifecycle events or retry behaviour. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `webhook`/`callback` = 0 in both. (c) SwaggerHub org `qubeyond` exists with 0 public APIs. Retrieved 2026-09-18. adversarially verified
API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator
reporting-api-not-upcharged
Commercial claim, not a publication claim. Qu publishes no pricing of any kind; the /become-a-partner page is a HubSpot lead form with no fee, revenue-share or certification-cost statement, and the integrations page's only programme prose is 'Our robust certification process ensures that integrations are tested and reliable.' The Adyen contract governs payments economics only and never mentions API or data-access fees. Nothing public establishes whether raw-data access is included or gated. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW BOUND (327th), still unknown: same denominator as reporting-tier-paywall -- the rebuilt 248-URL site is a fixpoint and contains no pricing, plan or fee schedule, and the only legal instruments it publishes are a website terms of use, a privacy policy, a third-party-components list and the Adyen-for-platforms payment terms, none of which prices data access. Tokenised `API fee` 0, `per location` 0 as a charge, `revenue share` 0, `data access fee` 0 across the site, the 177/177 admin census and the retired KB + 53 PDFs. Qu's APIs are named (Data Export API, Labor API) but never priced, and no developer portal resolves on which terms could be published. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). The only commercial text Qu publishes to buyers (Taco John's FAQ: 5-year initial term, hardware covered, 24-hour support; Church's: $250/month service credit for 12 months; DQ: 'DQ Corporate-negotiated pricing') never mentions data or API access, reporting tiers or add-on SKUs. Retrieved 2026-09-18. || 334th: CLAIM: API/raw-data access included in the standard subscription, not gated by a per-location fee, revenue share or enterprise contract. VERDICT: unknown (unchanged). 334th NEW SURFACE (none of the 331st-333rd opened it): customer-brand FRANCHISE DISCLOSURE DOCUMENTS on the Minnesota Commerce CARDS public registry (anonymous GET: https://cards.web.commerce.state.mn.us/franchise-registrations?doSearch=true&franchisor=<name>). 30 franchisor names searched (Qu customers named in Qu case studies/videos plus QSR peers); latest Clean FDD fetched for 27; 13 bodies read in full (Taco John's 2026-07 amendment, Blaze Pizza 2026, Dave's Hot Chicken 2026, Del Taco 2025, Saladworks 2026, Auntie Anne's, Cinnabon, Schlotzsky's, Jamba 2026, Sonic, Nathan's, Papa Murphy's, a Dairy Queen area developer); 14 returned empty bodies (throttled, a refusal, not an absence); Church's, Golden Chick, Freebirds, Jack in the Box, Hot Head, Rapid Fired are not MN-registered. Tokenised `Qu` names Qu in only TWO: Taco John's (operations-manual TOC 'Qu Point of Sales (POS) System/Kitchen Video System (KVS)', beside separate entries 'Decision Logic Back of House System', 'Olo Dashboard', 'Punchh', 'FlyBuy') and Blaze Pizza (Standards Guidelines TOC 'Qu (POS Training)'); Saladworks' hit is an officer bio ('Director of Operations for Qu POS'), and Papa Murphy's 5 hits are POISON (mis-encoded 'Québec' in MTY's address). An FDD is the FRANCHISOR's filing, i.e. third-party evidence about Qu (grade E at best), and neither FDD names Qu in the fee tables. What it adds: Taco John's Item 11 - 'we have full rights and access to the information and data stored in your Point of Sale System. We have developed interfaces with our preferred providers that facilitate this access' (p.39) - and the Item 6 fee table lists no POS data-access or API fee payable by the franchisee. Why it does not settle: the franchisor-to-Qu contract (where an API/data fee would sit) is not disclosed; an FDD lists only fees the FRANCHISEE pays. Retrieved 2026-09-18. adversarially verified
Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator
reporting-tier-paywall
Commercial claim. Qu publishes no plan structure, tier names, or feature-by-tier matrix on any of the 239 sitemap URLs, and /integrations and /become-a-partner add nothing about packaging. The Adyen contract addresses payments economics and is silent on subscription tiers. Which reporting features sit on an entry-level plan cannot be determined. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW BOUND (327th), still unknown, and the reason is now stated precisely: Qu publishes NO pricing surface at all. The rebuilt www.qubeyond.com was taken to an href fixpoint (248 sitemap URLs, 39 core pages fetched, no unlisted internal href) and there is no /pricing, no plan table and no tier name anywhere in it; tokenised `tier` = 0 in the 177/177 admin.qubeyond.com chunk census and 0 on the site, and in the retired operator corpus every `tier` hit is a menu PRICE tier. The reports themselves are not tier-labelled in the back office: the retired Qu Reporting Guide describes a single report library with filters, saved custom reports and column/field selection ('Some reports allow the addition or removal of columns/Fields... the user can save each report as a custom report'), with no plan gating shown. Nothing establishes what an entry-level plan includes. Retrieved 2026-09-18. || 328th: NEW SURFACE (328th): the current admin ships a 50-entry per-tenant ENTITLEMENT REGISTRY, `FeaturesObj`, read through a `features/isEnabled` getter that hides whole navigation sections. Entries include EI-V2-Reporting, EI-ReportsItemGroupRatios, EI-V2-Inventory, EI-V2-TipPooling, EI-TipPooling, EI-LaborSchedule, EI-ShiftSchedules, EI-V2-ShiftSchedules, EI-V2-DigitalChannels, EI-BulkMenuRefreshOLO, EI-OloDigitalChannelMenuSync, EI-ProductionForecastBoard, EI-KDSBulkBoard, EI-StoreInstallations, EI-QuBoxDiagnostics, EI-PriceImportTool, EI-ArchiveStores, EI-MenuPreview, EI-ShowVersioningMenuToggle. Reporting specifically is behind `EI-V2-Reporting` (the whole reports index) and `EI-ReportsItemGroupRatios`, so report access is per-tenant switchable in the CURRENT back office - which the prior note, bound to the retired Reporting Guide, could not see. It still does not settle the claim: an entitlement flag is not a plan tier and carries no price, and Qu publishes no plan table. Notes only, per the flag-payload rule. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). No plan or tier appears on any of the 52 pages; the franchisee commercial pages describe a single negotiated sales order per franchise system, not tiers. Retrieved 2026-09-18. || 334th: CLAIM: core reporting beyond basic sales summaries is on the entry-level plan, not a higher tier or add-on analytics SKU. VERDICT: unknown (unchanged). 334th NEW SURFACE (none of the 331st-333rd opened it): customer-brand FRANCHISE DISCLOSURE DOCUMENTS on the Minnesota Commerce CARDS public registry (anonymous GET: https://cards.web.commerce.state.mn.us/franchise-registrations?doSearch=true&franchisor=<name>). 30 franchisor names searched (Qu customers named in Qu case studies/videos plus QSR peers); latest Clean FDD fetched for 27; 13 bodies read in full (Taco John's 2026-07 amendment, Blaze Pizza 2026, Dave's Hot Chicken 2026, Del Taco 2025, Saladworks 2026, Auntie Anne's, Cinnabon, Schlotzsky's, Jamba 2026, Sonic, Nathan's, Papa Murphy's, a Dairy Queen area developer); 14 returned empty bodies (throttled, a refusal, not an absence); Church's, Golden Chick, Freebirds, Jack in the Box, Hot Head, Rapid Fired are not MN-registered. Tokenised `Qu` names Qu in only TWO: Taco John's (operations-manual TOC 'Qu Point of Sales (POS) System/Kitchen Video System (KVS)', beside separate entries 'Decision Logic Back of House System', 'Olo Dashboard', 'Punchh', 'FlyBuy') and Blaze Pizza (Standards Guidelines TOC 'Qu (POS Training)'); Saladworks' hit is an officer bio ('Director of Operations for Qu POS'), and Papa Murphy's 5 hits are POISON (mis-encoded 'Québec' in MTY's address). An FDD is the FRANCHISOR's filing, i.e. third-party evidence about Qu (grade E at best), and neither FDD names Qu in the fee tables. What it adds: the only disclosed price for a Qu deployment (Taco John's FDD Item 11, p.39) varies by terminal count alone ('$475 to $750 per month depending on the number of terminals selected') and names no reporting tier or analytics SKU; Taco John's back-office/financial reporting runs on a different vendor (Decision Logic, $145/month; plus a 'Financial Reporting System Fee ... Currently, none'). Why it does not settle: a franchisor's summary price is not Qu's plan structure, and it cannot show whether Qu reporting is included or add-on. Retrieved 2026-09-18. adversarially verified
Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator
reporting-history-retention
Non-publication, measured across two product generations rather than inferred from the marketing site. Qu's help centre was public on Zendesk 2019-2021 and 210 articles survive in the Wayback CDX index; 'retention'/'retain' occurs in none of them, including every document that would carry a window -- the Reporting Guide (which enumerates each report and its calculations), Report Calculations, the Enterprise Intelligence Guide, 'How do I Set the Reporting Periods for My Store', 'Qu 3.5 Reporting Documentation', Chapter 5: Reporting, and Chapter 12: Audit Trail, which states only that 'Audit Trail can only be accessed from the Enterprise Level of Qu Enterprise Intelligence' and names no window. Live side, management/unified-data-reporting says only 'historical data' with no figure, and the privacy policy's retention clause is scoped to website visitors. The claim's verb is 'Documents', so non-publication is the finding. Caveat: the current help centre is login-gated, so a gated admin guide could state a window we cannot see; this rests on the enumerated public and archived reporting documentation. https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360049022511 · retrieved 2026-09-03
Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator
reporting-anomaly-alerts
Re-fetched 2026-08-02. Qu Notify "pushes AI-powered alerts on sales anomalies, service-time thresholds, equipment issues, the real-time Kitchen Intelligence Score, and other configurable operational exceptions, delivered straight to mobile devices". Shortfall: no threshold-configuration mechanism is shown, no definition of what constitutes an anomaly (baseline, sensitivity, comparison window), and the page does not say whether Qu Notify is included with the platform or separately licensed; its quantified benefit claim ("30-50% faster issue resolution") is unsourced. Qu publishes no publicly retrievable product documentation: support.qubeyond.com (the 'Qu Campus' Document360 portal) redirects to a login, and both qu-api.qubeyond.com and qu-pos-api.qubeyond.com return HTTP 403 behind a mismatched TLS certificate. No grade A/B evidence is obtainable, so a differentiator 'yes' cannot stand. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-02 adversarially verified
Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.
reporting-nl-query
Verified verbatim is a single marketing line: 'Operate hands-free with simple voice commands and surface insights through an AI chatbot.' No product documentation, no examples of queries, no scope of data addressable. Marketing copy for an AI feature is the single most inflated category in this space; a 'yes' needs docs. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-01 adversarially verified
Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator
reporting-guest-cohorts
Qu Reports Quick Guide (Next Gen 3.5, Oct 2020) enumerates a Customers report: 'Included all customers and their information entered on the POS or the web ordering site. The collected information includes first name, last name, phone number, email address, last order date, total orders, the total dollar amount spent, and registration status.' That is guest-level lifetime spend and visit count tied to identifiable records from POS and online ordering. Shortfall: the report is a flat customer list - the guide documents no new-versus-returning guest counts, no visit-frequency cohorting and no loyalty-linked segmentation (loyalty in this vintage is the third-party Punchh integration). Vintage: Next Gen 3.5, 2020; the live site markets 'normalized guest and operational data' but publishes no cohort report. https://web.archive.org/web/20201128174707/https://support.qubeyond.com/hc/en-us/articles/360049022511-Qu-Reports-Quick-Guide-Next-Gen- · retrieved 2026-09-03
Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator
reporting-sales-forecast
Notify claims predictive analytics for trend forecasting and the menu module claims AI demand/daypart analysis; a daypart-granular forecast surface consumable by scheduling is not documented. https://www.qubeyond.com/management/notify-mobile-insights · retrieved 2026-08-01
Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.
reporting-tip-tax-compliance
7shifts' 'Tip Pooling for Qu POS' doc (updated 2026-06-24) states 'Qu automatically transfers sales, payment, and tip information to 7shifts', so per-employee tip capture exists in Qu. Shortfall: the payroll- and tax-ready outputs this claim names are not Qu's — 'within 7shifts, the distribution of tips and gratuities among employees is automated' in a Tip Pooling module operators 'trial or purchase' separately, and neither declared-vs-charged tip breakdowns nor a jurisdictional tax liability summary is documented anywhere public for Qu itself (help centre login-gated). Article HTML is bot-gated; body read via the site's public Zendesk article API for the same article id. https://kb.7shifts.com/hc/en-us/articles/35540967177875-Tip-Pooling-for-Qu-POS · retrieved 2026-08-04
Multi-location, franchise & enterprise governance
Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.
multi-location-org-hierarchy
Brand administration with dynamic store groupings and location-based customization inside one enterprise tenant. https://www.qubeyond.com/management/brand-franchise-management · retrieved 2026-08-01
Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator
multi-location-local-override-policy
"Standardize where it matters and customize where it counts" with local overrides within approved parameters; per-field lock enforcement is not documented. https://www.qubeyond.com/management/brand-franchise-management · retrieved 2026-08-01
Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.
multi-location-price-zones
This is the researcher's own two-step inference ('dynamic store groupings' + 'channel-specific pricing' therefore price zones). Neither cited page documents assigning a price to a location group. Inference stacking is not documentation. https://www.qubeyond.com/management/channel-management · retrieved 2026-08-01 adversarially verified
Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator
multi-location-scheduled-publish
Fall 2025 release: "A new set of icons shows each menu's status, version, and update schedule - all available through the POS", distinguishing "what's live, what's pending, and what needs attention"; the Fall 2025 recap calls these "traffic light menu status indicators so your team always knows what's live, updating, or needs attention". SHORTFALL: a pending/scheduled menu update is evidenced, but no reachable Qu page states that the activation time is interpreted in each target location's own timezone, nor that an activated change can be rolled back. Differentiator weight with only grade-D evidence, so `yes` is unavailable regardless. https://www.qubeyond.com/resource-center/qus-fall-2025-product-release-highlights · retrieved 2026-09-03
A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator
multi-location-new-store-template
Winter 2026 release, under "Enterprise Agility & Rollout Speed": "Consistent Store Creation with Templates - Pre-built configuration templates standardize new store setup across formats", with the stated advantage "Reduce human error, accelerate openings, and ensure operational consistency from day one". SHORTFALL: the claim's second half is unmet - Qu publishes no expected time-to-open for a templated new location, and the template's contents (menu, taxes, roles, printers, modifiers, tenders) are not enumerated anywhere reachable; the customer portal that would carry a setup guide is login-walled. https://www.qubeyond.com/resource-center/qus-winter-2026-product-release-highlights · retrieved 2026-09-03
The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator
multi-location-corp-vs-franchisee-roles
Franchisor enforces brand standards centrally while franchisees operate locally on Qube, with granular permissioning; a distinct franchisee tenant owning its own banking/labor data is not documented. https://www.qubeyond.com/management/brand-franchise-management · retrieved 2026-08-01
Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator
multi-location-royalty-calculation
CLAIM: calculates franchise royalty, ad-fund and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). VERDICT partial. NEW SURFACE beyond the 305th pass's rejected proposal, which cited only the fee list: the mechanism has TWO halves in admin.qubeyond.com and both are now held. (1) A fee engine under /configuration/reports/fees, permission scope reporting_fees (create/read), whose editor (85b8f000ea1ba917931f.js) is Title + 'Net Sales %' (numeric, step 0.001, min 0) + 'Effective From' / 'Effective To' dates + scope by 'Select Store', 'Select Store Group' and 'Select Reporting Groups'; the list view (015621cce7f2c63eedae.js) renders columns Title, 'Net Sales %', Stores. So a percentage-of-net-sales charge is computed automatically per location over a dated window. (2) An enterprise-wide 'Gross and Net Sales' configuration page (/configuration/gross-and-net-sales, 4d3bef03ef0588d4acf6.js) that makes the BASIS configurable: the operator chooses what Gross Sales and Net Sales include from Revenue Item Sales, Non-Revenue Item Sales, Discounts, Service Charges and Taxes, with the rules 'Discounts are always subtracted in the gross/net sales equation', 'All remaining discounts that are not Manager Comp nor Coupon. Gift Card Discounts are always excluded from Gross and Net Sales', 'Revenue item sales cannot be excluded from the equation. Use Reporting Item Groups to identify these items', and the warning 'This change will have an impact on the entire enterprise and will affect future sales reporting'. SHORTFALLS (why not yes): the feature is unnamed as franchise machinery - 'royalt', 'franchise fee' and 'ad fund' are 0 hits across all 177 files of the closed fixpoint census, and the 5 'franchise' hits are a hardcoded demo fixture ('Franchise Group Level' menu-version rows dated 2018) rather than a fee surface (the sole prior 'royalty-free' hit is the website T&Cs IP licence), so nothing distinguishes a royalty from an ad fund or a marketing fee except the Title the operator types; there is no 'defined schedule' - the fee is effective-dated and lands in reporting rather than being generated on a billing cycle; and the basis is one enterprise-wide Gross/Net definition, not a per-agreement royalty basis, with third-party sales having no explicit include/exclude toggle (only Reporting Item Groups). Retrieved 2026-09-17. GRADE SET AT MERGE (324th): production JS bundle / script-loader census = grade B, not A, per the 321st precedent that downgraded sapaad override-audit A->B for source-map evidence. An anonymous OpenAPI spec can be A; first-party application code that the vendor does not publish as documentation cannot. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/85b8f000ea1ba917931f.js · retrieved 2026-09-17 adversarially verified
Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.
multi-location-royalty-collection
Same corpus-wide silence as royalty calculation. The Adyen contract is the one document in the set that could plausibly carry a fee-sweep mechanism, and it does describe money movement in detail — settlement, set-off, rolling reserve — but every one of those flows is between Adyen and the merchant for transaction proceeds; there is no franchisor sweep, no ACH/debit collection of fees from franchisee accounts and no franchisee-visible fee statement. Qu Pay's launch release mentions franchisee 'on-demand settlements' of their own funds, which is the opposite direction of flow. || 324th: NEW SURFACE, not settling: the closed 177-file fixpoint census of admin.qubeyond.com now shows Qu DOES compute a percentage-of-net-sales fee per store over a dated window (/configuration/reports/fees, 'Net Sales %', 'Effective From/To', 'Select Store Group', 'Select Reporting Groups') - see multi-location-royalty-calculation. What it does not show is any collection leg: the fee object has no bank account, no debit authorisation, no charge run and no franchisee-facing statement; word-boundary 'ACH' returns exactly 1 hit and it is POISON - the Acholi locale code 'ach' in the plural-rules table inside 9d2ebbd8, and the only money-movement UI in the whole census is store-level cash handling ('Deposit Cash', 'Actual Cash', 'Expected Cash', 'Cash Drawers'). Whether Qu sweeps the calculated fee remains undetermined. Retrieved 2026-09-17. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW BOUND (327th), still unknown: tokenised `royalt` = 0 in the 177/177 admin.qubeyond.com chunk census, 0 in the retired operator KB and its 53 PDFs, and 1 on the rebuilt marketing site -- that one being POISON, the boilerplate 'royalty-free, perpetual, and worldwide license' in the website terms of use. `\bACH\b` 0, `franchise fee` 0, `direct debit` 0, `franchisee statement` 0 across all four corpora. Qu DOES ship franchise governance (/management/brand-franchise-management) but the rebuilt page describes configuration propagation, not money movement, and no fee-collection object appears in the back-office app. Held unknown rather than no because franchise billing could sit in a Qu Pay / Adyen-for-platforms flow that is not published on any surface we can read. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `royalt` 2 in captions, both POISON (idiom 'treated like royalty', 'RLC ... royalty' crosstalk); `ACH`/`franchise fee`/`direct debit` = 0 on the landing pages, incl. the three franchisee-program pages. Retrieved 2026-09-18. || 334th: CLAIM: the POS supports automated ACH/debit collection of calculated royalties/fees from franchisee accounts, with a franchisee-visible statement. VERDICT: unknown (unchanged). 334th NEW SURFACE (none of the 331st-333rd opened it): customer-brand FRANCHISE DISCLOSURE DOCUMENTS on the Minnesota Commerce CARDS public registry (anonymous GET: https://cards.web.commerce.state.mn.us/franchise-registrations?doSearch=true&franchisor=<name>). 30 franchisor names searched (Qu customers named in Qu case studies/videos plus QSR peers); latest Clean FDD fetched for 27; 13 bodies read in full (Taco John's 2026-07 amendment, Blaze Pizza 2026, Dave's Hot Chicken 2026, Del Taco 2025, Saladworks 2026, Auntie Anne's, Cinnabon, Schlotzsky's, Jamba 2026, Sonic, Nathan's, Papa Murphy's, a Dairy Queen area developer); 14 returned empty bodies (throttled, a refusal, not an absence); Church's, Golden Chick, Freebirds, Jack in the Box, Hot Head, Rapid Fired are not MN-registered. Tokenised `Qu` names Qu in only TWO: Taco John's (operations-manual TOC 'Qu Point of Sales (POS) System/Kitchen Video System (KVS)', beside separate entries 'Decision Logic Back of House System', 'Olo Dashboard', 'Punchh', 'FlyBuy') and Blaze Pizza (Standards Guidelines TOC 'Qu (POS Training)'); Saladworks' hit is an officer bio ('Director of Operations for Qu POS'), and Papa Murphy's 5 hits are POISON (mis-encoded 'Québec' in MTY's address). An FDD is the FRANCHISOR's filing, i.e. third-party evidence about Qu (grade E at best), and neither FDD names Qu in the fee tables. What it adds: at the one Qu brand whose FDD names Qu, royalty collection is run by the FRANCHISOR, outside the POS: 'We currently require that all fees due to us be paid directly and automatically from your bank account ... sign and deliver to us and your bank the authorization agreement for direct payments attached as Exhibit II' (TJ FDD Item 6 note 2, p.16; the Exhibit II form 'I authorize TJI to initiate a debit to the account'). Blaze likewise collects by 'electronic funds transfer'. Consistent with Qu not providing the sweep, but a franchisor using its own ACH authorisation does not prove the POS cannot - capability not bounded. Retrieved 2026-09-18. adversarially verified
Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.
multi-location-consolidated-reporting
Every transaction from every channel and location flows into one reporting layer with cross-location and cross-daypart comparison and real-time exception alerts. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-08-01
Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator
multi-location-normalized-item-rollup
A single central menu database implies shared corporate item identity across locations, but Qu does not document rollup behavior for locally renamed items. https://www.qubeyond.com/management/unified-menu-management · retrieved 2026-08-01
Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.
multi-location-cross-location-giftcard
Cross-channel/cross-location gift is delivered through the Paytronix integration rather than a native Qu liability ledger. https://www.globenewswire.com/news-release/2026/06/23/3316041/0/en/paytronix-and-qu-further-integration-enabling-advanced-omnichannel-ordering-and-menu-management.html · retrieved 2026-08-01
A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.
multi-location-cross-location-loyalty
Brand-wide loyalty profile is Paytronix-delivered across in-store, drive-thru, kiosk, mobile and web. https://www.globenewswire.com/news-release/2025/10/07/3162505/0/en/paytronix-and-qu-partner-to-deliver-smarter-more-personalized-guest-experiences.html · retrieved 2026-08-01
A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator
multi-location-multi-brand
Re-fetched 2026-08-02. The brand & franchise page states "Operate every brand and location from a single system" and "Qu gives corporate teams a master control layer to enforce brand standards while franchisees can manage local overrides within approved parameters"; the online-ordering page adds "Manage multiple brands under one parent with custom subdomains and branding". Shortfall: the original note's "separately reportable revenue" per brand appears on neither page, virtual brands are not mentioned on either, and the brand/location hierarchy model is nowhere described. Multi-brand is attested at marketing level only. Qu publishes no publicly retrievable product documentation: support.qubeyond.com (the 'Qu Campus' Document360 portal) redirects to a login, and both qu-api.qubeyond.com and qu-pos-api.qubeyond.com return HTTP 403 behind a mismatched TLS certificate. No grade A/B evidence is obtainable, so a differentiator 'yes' cannot stand. https://www.qubeyond.com/management/brand-franchise-management · retrieved 2026-08-02 adversarially verified
Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.
multi-location-multi-tax-jurisdiction
Tax, pricing and discount configuration across brands and locations is claimed; jurisdiction-specific rules and per-location exemptions are not documented. https://www.qubeyond.com/management/brand-franchise-management · retrieved 2026-08-01
Supports locations operating in different currencies and languages within one enterprise account, with consolidated reporting converted to a reporting currency.
multi-location-multi-currency-locale
Verified verbatim on the POS page: 'Accept US Dollars, Canadian Dollars and Mexican pesos, with seamless conversion and unified reporting.' Specific and on point. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-01 adversarially verified
Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator
multi-location-config-audit-log
Chapter 12: Audit Trail (First Gen 2.0, updated 2020-04-20) documents a corporate-level change log: 'a detailed activity history of changes occurring within Qu. Changes can be tracked based on Date, Employee, Module, Location and any combination of the above. The report can also be exported as a csv document. Audit Trail can only be accessed from the Enterprise Level of Qu Enterprise Intelligence.' Who / when / where / which module, queryable and CSV-exportable by corporate, is therefore established. Shortfall: the article does not enumerate which configuration objects the 'Module' axis covers - price, tax, permission and discount are each configurable per Chapter 6 but none is named as audited - and immutability is not claimed. Vintage: First Gen 2.0, article dated 2018-02-27 and updated 2020; the live site markets 'Centralized Data Governance' and 'Granular permissioning and user administration' but publishes no audit-log page. https://web.archive.org/web/20200809112957/https://support.qubeyond.com/hc/en-us/articles/360001271931-Chapter-12-Audit-Trail-First-Gen-2-0- · retrieved 2026-09-03
Supports SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. differentiator
multi-location-enterprise-sso
Zero occurrences of SAML, SCIM, 'single sign' or SSO as a word in the legal set or the 199 pages (apparent 'OIDC' and 'SSO' hits are substrings — 'signin-oidc' in the Document360 login URL in every page footer, and 'Processor' in the Adyen contract). Qu publishes no security or trust page and no developer host exists, so staff federation for above-store users has no surface that would necessarily document it; a payments contract and a website privacy policy would not. No guest-identity feature was mistaken for staff federation here. || 324th: NEW SURFACE, not settling, and the standing note's 'zero occurrences of SSO' is superseded: admin.qubeyond.com ships live SSO routes (/sso, /sso-error) and a global 'sso' middleware in 8fc0d1fe5de12dff9911.js that reads the AWS ALB OIDC headers x-amzn-oidc-accesstoken / x-amzn-oidc-data / x-amzn-oidc-identity and calls authService.loginSSO keyed by host - i.e. federation is terminated at the load balancer per tenant host. But the claim's conjuncts are not reachable from that: 'SAML' 0, 'SCIM' 0, 'provisioning' 0 and there is no identity-provider configuration screen among the 103 admin routes, so whether an operator can bring their own IdP, and whether group-to-role mapping or deprovisioning exists, is still undetermined. Bound: closed 177-file fixpoint census of this app only. Retrieved 2026-09-17. || 325th: MERGE HOLD (proposed partial/B, held unknown): OIDC login exists per host, but that it authenticates against the CUSTOMER's identity provider is inferred from the handshake, not shown; the 324th refused the same shape on conversenow. No SCIM, no SAML. PROPOSAL AS WRITTEN: MOVED off unknown on new bundle evidence that contradicts the prior note's 'zero occurrences of SSO as a word' (that was measured on the marketing corpus, not on the app). CLAIM: SSO via SAML or OIDC against the CUSTOMER's identity provider for back-office/above-store users, WITH SCIM or equivalent for automated deprovisioning. VERDICT: partial. EVIDENCE, from the production back-office bundles (admin.qubeyond.com, 175-chunk fixpoint corpus): the router ships dedicated SSO routes - '{path:"/sso",component:...,name:"sso"},{path:"/sso-error",...,name:"sso-error"}' - the auth middleware exempts them from the local-token check ('if("/login"===o.path||"/logout"===o.path||o.path.includes("sso"))'), the login call carries an SSO flag ('this.$auth.loginWith("local",{data:{payload:f({sso:!0},t)}})'), and the SSO handshake is OIDC terminated at the AWS load balancer and exchanged for a Qu session: 'l=n["x-amzn-oidc-accesstoken"],c=n["x-amzn-oidc-data"],d=n["x-amzn-oidc-identity"] ... r.$authService.loginSSO({host:n.host,oidcAccessToken:l,oidcData:c,oidcIdentity:d})', with a debug line rendering 'AUTH ID: x-amzn-oidc-identity'. So OIDC SSO into the above-store back office is shipped, host-scoped, in production. NAMED SHORTFALL: (1) SCIM or any automated deprovisioning is absent - `SCIM` 0/175 admin, 0/74 wo, 0 in the pay-admin bundle, and `SAML` is 0 in all three as well, so the protocol evidenced is OIDC only; (2) the IdP is configured at Qu's own ALB rather than through any customer-facing IdP/metadata/certificate screen, none of which exists in the bundle set, so 'against the customer's identity provider' is inferred from the per-host handshake, not documented; (3) Qu publishes no documentation of the feature at all (support.qubeyond.com is a Document360 knowledge base that redirects every path to a login, so it cannot corroborate). Retrieved 2026-09-17. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: above-store staff authenticate through the customer's own identity provider (SAML/OIDC) with SCIM-style provisioning. VERDICT unknown. EVIDENCE: tokenised `SSO`, `SAML`, `single sign` = 0 across the 205 articles and the 53 PDFs. The EI admin manual enumerates the complete identity model of that back office and it is entirely local: Chapter 3 'Adding Employees / Creating Job Titles / Creating Enterprise Roles', a 'Password' section under Enterprise Configuration, and the dedicated articles 'How do I Change a User's Password in Qu EI?' (both generations), 'How do I Change an Employee's PIN?', 'Assigning an Employee Mag Card to a User' and 'How do I add or update a Users' Enterprise Role?'. No federation object exists in that generation's admin surface. Note this corpus is the LEGACY EI back office, not the current admin.qubeyond.com the 325th read. Retrieved 2026-09-18. || 328th: NEW MECHANISM DETAIL (328th), still not settling: the current admin's SSO is an AWS Application Load Balancer authenticate-oidc action, not an in-app federation config. The bundle reads the ALB-injected headers `x-amzn-oidc-accesstoken`, `x-amzn-oidc-data`, `x-amzn-oidc-identity` and calls `$authService.loginSSO({host, oidcAccessToken, oidcData, oidcIdentity})`, routing to `/sso` or `/sso-error`; the IdP is therefore bound to the HOST, and crt.sh lists wildcard certs `*.eisso-dev.qubeyond.com` and `*.eisso-stg.qubeyond.com`, i.e. a per-tenant SSO hostname scheme (dev/stg only; no prod eisso host resolves). There is still no customer-facing federation screen: tokenised `SAML`, `SCIM`, `identity provider`, `Azure AD`, `single sign-on` = 0 across the 24.4 MB admin census AND the 6.3 MB pay-admin bundle (30.7 MB combined), and `Okta` = 5, all inside the pay portal's own staff login. Whose IdP the ALB points at remains unobservable from outside. Retrieved 2026-09-18. || 332nd: 332nd NEW SURFACES, not settling. (1) certspotter (after crt.sh) lists wildcard SSO hosts *.eisso-dev.qubeyond.com and *.eisso-stg.qubeyond.com ('EI SSO', i.e. per-tenant SSO hosts for the Enterprise Intelligence back office, consistent with the admin bundle's ALB-OIDC 'loginSSO' keyed by host). Only *.eisso-stg resolves (AWS ALB, STAGING, notes only); a nonsense label and 31 of 32 guessed tenant labels (one DNS timeout) (jackinthebox, deltaco, churchs, goldenchick, daves, blaze, freebirds, tacojohns, goto, woworks, krystal, charleys, fazolis, demo, test, sandbox, etc.) all return a plain 404, so no IdP redirect could be observed and whose IdP terminates the login is still not shown; no production eisso host resolves. (2) Qu's manager/corporate app 'Notify by Qu POS' (the publisher's only app; APK unpacked in the 307th, Hermes string table 73,982 strings re-grepped now): login is Qu-credential only - 'LoginForm', 'Login2FaForm', 'BiometricLoginForm', 'Forgot password?', 'The user and password you entered does not match our records.'; tokenised sso/oidc/saml/okta/msal/cognito/'identity provider' = 0 (POISON: 'openid', 'microsoft-azure' etc. are icon-font glyph names). So the mobile client for above-store users has no federation, while the web back office does have host-keyed OIDC; SAML/SCIM still 0 everywhere. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `SSO`/`SAML`/`single sign`/`Okta`/`identity provider` = 0 in both. Retrieved 2026-09-18. adversarially verified
Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator
multi-location-enterprise-api
Reporting and DataExport APIs are enterprise-scoped and Qu markets API access to external BI; no public multi-location API reference or auth model is available. https://status.qubeyond.com/ · retrieved 2026-08-01
Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.
multi-location-central-labor-policy
What is a Payroll Profile? (Next Gen 3.5, April 2020): payroll profiles are created under Employee Groups and configure 'Weekly Overtime Starts After' plus an overtime multiplier, a daily overtime threshold, a double-overtime threshold and multiplier, and break rules (Paid or Unpaid, maximum paid time on break, minimum time on break before paid, minimum work time for paid-break eligibility). Terminal-level enforcement is documented separately in Chapter 6: Configuration, whose Labor setting reads 'Clock in Tolerance Minutes - When labor management is in use, this value limits an employee clockin to the scheduled shift time +/- the specified tolerance in minutes. Default 5' - and Chapter 6 settings are set at Enterprise level and overridden per store or revenue centre. Shortfall: the overtime and break rules attach to employee groups rather than location groups and are pay calculations applied after the fact; only clock-in tolerance is enforced at the terminal, and predictive-scheduling compliance appears nowhere in the corpus. Vintage: Next Gen 3.5 and First Gen 2.0, 2018-2020. https://web.archive.org/web/20200806012955/https://support.qubeyond.com/hc/en-us/articles/360042408211-What-is-a-Payroll-Profile-Next-Gen- · retrieved 2026-09-03
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
The archived Hardware Videos section documents Qu running on a general-purpose Windows PC terminal built by a third-party OEM rather than a Qu-proprietary device: 'Swap SSD Hard Drive on Touch Dynamic Acrobat Terminal', 'Replace Terminal MSR (Magnetic Stripe Reader)' on a Touch Dynamic terminal, 'Removing terminal cable and port covers', and a troubleshooting step reading 'Tap the windows icon in the bottom left of the screen'. The MSR driver article names the part as a 'Magtek MagneSafe Magnetic Stripe Reader Device' reinstalled from Windows Device Manager. Shortfall: nothing documents an operator buying or supplying their own terminal - Chapter 7: POS Terminals states flatly 'Activating a new terminal must be completed by Qu' - and no iPad or Android tablet POS client appears anywhere in the 210 archived articles. Vintage: First Gen 2.0 / Next Gen 3.5, 2020 captures; today's product is the Qu Business Edge (Qube) edge appliance, which this archive predates. https://web.archive.org/web/20200920081822/https://support.qubeyond.com/hc/en-us/articles/360038050532-Swap-SSD-Hard-Drive-on-Touch-Dynamic-Acrobat-Terminal · retrieved 2026-09-03
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
No public spec sheet: the POS page names no client OS, minimum versions, or device specs, and Qu Campus documentation is login-gated. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-01
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
Same evidence as order-capture-native-handheld: the drive-thru page cites mobile/tablet order-taking beyond fixed terminals. Shortfall: no purpose-built handheld with an integrated card reader is documented, and no drop rating or IP ingress rating is published anywhere on qubeyond.com. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-04
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
'battery' occurs zero times in 1.85 MB. Qu publishes no hardware catalogue at all — its own solutions navigation lists ordering, kitchen, payments and enterprise-management pages and nothing device-related, and /modules turned out to be an unpublished Webflow template full of lorem ipsum. The only handheld-adjacent first-party facts are Golden Chick's 'outside line-busting tablets' and an architecture line about 'store-level APIs uniformly communicate with in-store POS, kiosk, drive-through, and handheld devices'. With no hardware spec page in existence, neither the hot-swap capability nor a published shift battery rating can be assessed. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: field-replaceable or hot-swappable handheld battery, or a published rated battery life for a full shift. VERDICT unknown. EVIDENCE: tokenised `battery` and `handheld` = 0 across the 205 articles and the 53 PDFs, including the only three field-service articles Qu ever published, which are component-level and battery-free: 'Swap SSD Hard Drive on Touch Dynamic Acrobat Terminal', 'Replace Terminal MSR Magnetic Stripe Reader' and 'Removing terminal cable and port covers'. The only devices named anywhere in the corpus are the Touch Dynamic Acrobat countertop terminal, the Ingenico IPP320 PIN pad ('Manual Transaction Guide for Ingenico IPP320') and an undescribed 'OMS Tablet' whose article body is empty. No mobile device is specified, so this is an absence about a device class Qu does not document rather than a stated limitation. Retrieved 2026-09-18. || 331st: 331st. NEW SURFACE (331st): APP-STORE CENSUS. iTunes search (qubeyond / 'qu pos' / 'qu beyond' / 'qu kds' / 'qu handheld') and artist lookup on developer id 1494062412 (QU POS, INC) return ONE app, 'Notify by Qu POS' (com.qubeyond.notify, v3.6.234, 2026-09-15: 'Enterprise tool for restaurant managers and corporate users. Provides real-time access to business performance data'); Google Play search returns the same single package com.qubeyond.notify. Qu publishes NO store-level POS, handheld or payment app on either store, so there is no APK or listing to read device specs from. Also (331st) the RETIRED WordPress marketing site on Wayback (5,508 CDX rows): the 2019-2021 /products-solutions/ page lists 'Hardware That Delivers Speed & Agility for Your Enterprise: Kiosk | Qu Terminals | Qu Tablet | Qu Go Handheld | EMV Payment Processor | Cash Drawer | Printers | Kitchen Display System | Contactless Payments' - a named handheld existed - but no spec page for it was ever archived; the hardware images (Qu-Trio-Hardware, Qu-POS-Hardware_02, read at full resolution) show two countertop terminals, a tablet on a stand, a kiosk and an Ingenico-style PIN pad, no handheld; the 14-page 2019 'Qu Product LookBook' flipbook PDF (wp-content/uploads/2019/11/Qu-Product-LookBook.pdf, found in the flipbook's base64 config) was never archived and 404s live. Controls: `battery` 0 across the new 207-page resource centre, the Wayback WP pages + 3 archived PDFs (2021 Fact Sheet, Pioneering-Next-Gen-POS, 2025 Kiosk one-pager), and the Qu Pay admin bundle (6.4 MB); the 7 hits in the 24.4 MB admin.qubeyond.com bundle are all POISON (Font Awesome fa-battery-* glyphs and an emoji table). No rated battery life or swap statement exists for Qu Go or any device; unknown. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `battery` in captions = 4, all POISON (a car key fob, a car battery in guest anecdotes); 0 on the landing pages. The CEO says in 'Edge Computing & Real-Time Data for Restaurants' (youtube.com/watch?v=BBIZFo6nhac, ~7:11) 'your existing POS devices your kitchen devices your handheld devices in the store they can continue to talk to the public cloud or to the in-store cloud' - handhelds exist, no spec. Retrieved 2026-09-18. adversarially verified
Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.
hardware-handheld-lte
No cellular or LTE reference exists anywhere on Qu's open surface ('cellular' zero hits; all 'LTE' matches are substrings). Golden Chick's case study describes tablets used outdoors for drive-thru line busting, which is precisely the deployment where an LTE fallback would matter, yet the study names no connectivity mechanism. Because Qu publishes no device specifications of any kind, the absence of an LTE mention is uninformative about whether handhelds carry or can fail over to cellular. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW BOUND (327th), still unknown: tokenised `\bLTE\b` and `cellular` = 0 across the 177/177 admin.qubeyond.com chunk census, the 248-URL rebuilt marketing site and the retired operator KB + 53 PDFs; `failover` 0, `\b4G\b` 0, `\b5G\b` 0, `hotspot` 0, `SIM` 0. The rebuilt site's new /qu-business-edge page is the closest statement and it is about an ON-PREMISE appliance, not a cellular path: 'Qube puts a powerful on-site hub in every location, keeping your operations running ... even when the internet is down', 'Triple redundancy', 'Uninterrupted operations with offline mode'. Qu publishes no handheld device specification on any surface that resolves, so the connectivity fallback conjunct cannot be settled either way. Retrieved 2026-09-18. || 331st: 331st. NEW SURFACE (331st): APP-STORE CENSUS. iTunes search (qubeyond / 'qu pos' / 'qu beyond' / 'qu kds' / 'qu handheld') and artist lookup on developer id 1494062412 (QU POS, INC) return ONE app, 'Notify by Qu POS' (com.qubeyond.notify, v3.6.234, 2026-09-15: 'Enterprise tool for restaurant managers and corporate users. Provides real-time access to business performance data'); Google Play search returns the same single package com.qubeyond.notify. Qu publishes NO store-level POS, handheld or payment app on either store, so there is no APK or listing to read device specs from. Also (331st) the RETIRED WordPress marketing site on Wayback (5,508 CDX rows): the 2019-2021 /products-solutions/ page lists 'Hardware That Delivers Speed & Agility for Your Enterprise: Kiosk | Qu Terminals | Qu Tablet | Qu Go Handheld | EMV Payment Processor | Cash Drawer | Printers | Kitchen Display System | Contactless Payments' - a named handheld existed - but no spec page for it was ever archived; the hardware images (Qu-Trio-Hardware, Qu-POS-Hardware_02, read at full resolution) show two countertop terminals, a tablet on a stand, a kiosk and an Ingenico-style PIN pad, no handheld; the 14-page 2019 'Qu Product LookBook' flipbook PDF (wp-content/uploads/2019/11/Qu-Product-LookBook.pdf, found in the flipbook's base64 config) was never archived and 404s live. Controls: tokenised `LTE` 0 and `cellular` 0 across the new 207-page resource centre and the Wayback WP pages/PDFs; the 21 `LTE` hits in the Qu Pay admin bundle are POISON (`lte` = zod's less-than-or-equal validator, `S1E` luxon/libphonenumber symbols). Qu's only offline story remains the Qube edge appliance. Unknown. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `LTE`/`cellular` = 0 in Qu-authored content (1 caption hit is a VC guest describing smartphones). The CEO's handheld statement (youtube.com/watch?v=BBIZFo6nhac, ~7:11: handhelds 'can continue to talk to the public cloud or to the in-store cloud and they can be smart enough to just switch back and forth') describes cloud/edge failover, not a cellular path. Retrieved 2026-09-18. adversarially verified
Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).
hardware-offline-mode
Qube edge keeps ordering, payments and kitchen routing running offline with auto-sync on reconnect; Qu publishes no list of which functions degrade. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-01
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
QuKitchen KDS is a first-party product with its own status-page component and product page. https://www.qubeyond.com/kitchen-solutions/kitchen-display-system · retrieved 2026-08-01
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
Qu Flex switches between POS and guest-facing kiosk on one device; freestanding form factor and an ADA/VPAT conformance report are not published. https://www.qubeyond.com/ordering/kiosk · retrieved 2026-08-01
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
Dedicated drive-thru software channel with voice AI partners; menu boards, confirmation displays and headsets appear only as a partner category (Hardware + Digital Signage), and no timer spec is published. https://www.qubeyond.com/ordering/drive-thru · retrieved 2026-08-01
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
Chapter 8: Printing (First Gen 2.0, updated 2020-04-20): 'Qu supports two types of printers: Receipt printers and kitchen printers'; receipt printers are configured per terminal by 'Scroll to Printer, select POS Printer Model... Select the desired printer model', and kitchen printers by 'Select the printer model' plus a path and routing into kitchen print groups and terminal print groups. Network attachment is documented in troubleshooting: 'Ensure the Ethernet cord is securely fastened at the printer port and the wall/switch', and disconnecting the POS 'will affect the communication between POS and any network printers'. Shortfall: a selectable model list implies more than one supported device, but the archive never names a printer manufacturer, never says ESC/POS, and publishes no compatibility list - so multi-manufacturer support is implied, not established. Vintage: First Gen 2.0, 2018-2020. https://web.archive.org/web/20200806003551/https://support.qubeyond.com/hc/en-us/articles/360001252212-Chapter-8-Printing-First-Gen-2-0- · retrieved 2026-09-03
Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.
hardware-peripherals
Chapter 6: Configuration (First Gen 2.0) enumerates a Barcode Scanner settings block ('Number of sentinel characters at end of string provided by symbol/barcode scanner (if any). These characters are removed from the scan output. Default 3', plus a start-sentinel length) and a Tills block whose 'Require Till Assignment' setting governs whether 'users must claim till in order to accept cash transactions or open, or pop, the cash drawer'. Scales are supported for by-weight items - 'Why is the Scale Not Weighing? (Next Gen)' instructs 'Remove all items from the scale, Power down the scale for thirty seconds... ensure that the scale is showing a 0.00 weight'. Customer-facing displays are a first-class output surface in the v139 release notes: modifiers 'now display with their portion amount on the same line on the Detail screen, KDS, Printers, and Customer Facing Displays.' Shortfall: no published compatibility list of any kind, and multi-drawer-per-terminal is nowhere documented. Vintage: First Gen 2.0 / Next Gen 3.5, 2018-2021. https://web.archive.org/web/20200808111044/https://support.qubeyond.com/hc/en-us/articles/360001267211-Chapter-6-Configuration-First-Gen-2-0- · retrieved 2026-09-03
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
Fetched the Qu Pay page directly, the one page whose entire subject is card acceptance: it contains no PCI-listed PTS device claim, no P2PE validation statement, and no merchant SAQ type. The claim specifically requires the vendor to state the SAQ type, and nowhere on qubeyond.com does it. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-04
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
'tap to pay' returns nothing and the Adyen for Platforms terms — Qu's payments contract, and the densest new document in this record — is a generic processor agreement defining Authorisation, Capture and Capture Period without enumerating acceptance form factors, so it cannot settle whether softPOS acceptance is offered. Qu routes payments through Adyen, which does offer Tap to Pay on iPhone and Android, meaning the capability could be present without appearing in any Qu-authored text. Unresolved rather than absent. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: same softPOS capability scored on the hardware axis. VERDICT unknown. EVIDENCE: as for payments-softpos-tap-to-pay - the KB's acceptance-hardware set (EMV reader, MSR, Ingenico IPP320, manual keyed entry) contains no phone-as-reader device, and `tap to pay` / `contactless` / `softpos` = 0 over the 205 articles and the 53 PDFs. Floor only: the corpus stops in 2021 and Qu's processor stack has since changed. Retrieved 2026-09-18. || 331st: 331st. NEW SURFACE (331st): APP-STORE CENSUS. iTunes search (qubeyond / 'qu pos' / 'qu beyond' / 'qu kds' / 'qu handheld') and artist lookup on developer id 1494062412 (QU POS, INC) return ONE app, 'Notify by Qu POS' (com.qubeyond.notify, v3.6.234, 2026-09-15: 'Enterprise tool for restaurant managers and corporate users. Provides real-time access to business performance data'); Google Play search returns the same single package com.qubeyond.notify. Qu publishes NO store-level POS, handheld or payment app on either store, so there is no APK or listing to read device specs from. Also (331st) the RETIRED WordPress marketing site on Wayback (5,508 CDX rows): the 2019-2021 /products-solutions/ page lists 'Hardware That Delivers Speed & Agility for Your Enterprise: Kiosk | Qu Terminals | Qu Tablet | Qu Go Handheld | EMV Payment Processor | Cash Drawer | Printers | Kitchen Display System | Contactless Payments' - a named handheld existed - but no spec page for it was ever archived; the hardware images (Qu-Trio-Hardware, Qu-POS-Hardware_02, read at full resolution) show two countertop terminals, a tablet on a stand, a kiosk and an Ingenico-style PIN pad, no handheld; the 14-page 2019 'Qu Product LookBook' flipbook PDF (wp-content/uploads/2019/11/Qu-Product-LookBook.pdf, found in the flipbook's base64 config) was never archived and 404s live. NEW SURFACE (331st): the rebuilt www.qubeyond.com RESOURCE CENTRE, never fetched by the 327th (which fetched only the 39 non-resource-centre pages of the 248-URL sitemap): 198 /resource-center/ + 11 /case-studies/ URLs, 207 at 200 and 2 at 301, 1.0 MB of stripped text, incl. new 2026 pieces (the Aug 4 2026 menu-management guide, Winter 2026 / Fall 2025 / Spring 2025 release highlights). Marketing = grade C. Controls: `tap to pay`/`tap-to-pay`/`softpos` 0 across the resource centre, the Qu Pay page and the Qu Pay admin bundle (pay-admin.qubeyond.com, 6.4 MB; no Adyen device model string V400/S1F2/AMS1/P400 either); `iPhone`/`Android` hits there are all user-agent sniffers (POISON). The resource centre's Fall 2025 release notes enumerate Qu's EMV devices as 'Aurus, FreedomPay, TriPOS, and Verifone' - all separate-reader payment stacks. No phone-as-reader statement anywhere; with no Qu POS app on either store there is no app to carry one. Unknown, not no: Qu Pay runs on Adyen, which offers Tap to Pay, and no enumeration of Qu Pay acceptance form factors is published. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `tap to pay`/`softpos` = 0; `contactless` 2 on the pages (both OrderUP 2020, 'Contactless payments and orders for your pick-up and to-go services' = online payment) and 1 in captions (a Freebirds CTO's wishlist). The franchisee FAQ names only 'EMV payment terminals' with Store and Forward. Retrieved 2026-09-18. adversarially verified
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
No hardware SKU prices anywhere on qubeyond.com; the only commercial path is a demo request. https://www.qubeyond.com/get-a-demo · retrieved 2026-08-01
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Same finding as the already-scored commercial-hardware-purchase-outright: fetched the POS page directly and it names no hardware price, purchase term, or lease term at all — the only hardware reference is the Qube edge appliance with no commercial terms attached, and every commercial path funnels to the get-a-demo quote form. The vendor does not state which model applies, which is what this claim requires. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-04
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
The claim asks whether vendor documentation confirms that vendor-purchased hardware stays usable with other software after cancellation. Qu's complete published legal set (site terms of use, privacy policy, Adyen-for-Platforms T&Cs) contains no hardware terms, no title or ownership clause for terminals or the Smart Edge device, and no post-termination hardware provision; /hardware-terms and /warranty 404 (probed 2026-09-04). Qu publishes thought-leadership arguing the lock-in risk exists at other vendors — 'Proprietary hardware means your repair options are limited' — while making no commitment about its own. No documentation confirms the position in either direction, and the contract that would is not public. || 325th: MERGE HOLD (proposed no/B, held unknown): the return-and-no-resale clause binds Payment Devices only; terminals, KDS and kiosks are not addressed, so the claim is not settled either way. The agent flagged this as a weakest row. PROPOSAL AS WRITTEN: NEW SURFACE - A FOURTH PUBLISHED LEGAL DOCUMENT the record's 'three documents' legal set does not contain. https://www.qubeyond.com/third-party-terms is in Qu's own sitemap (www.qubeyond.com/sitemap.xml, 247 <loc> entries, re-derived 2026-09-17) and fetched at HTTP 200, 116,598 bytes of HTML / 41,122 characters of stripped text: 'Third Party Terms ... apply to the use of the Qu payment processing services ordered by Customer pursuant to the Master SaaS Agreement between the Parties ... which are provided by Adyen N.V. ("Adyen") through Qu.' CLAIM: vendor documentation confirms whether hardware purchased from the vendor stays usable with other software after cancellation, i.e. is not software-locked. VERDICT: no - the documentation now exists and it confirms the opposite for the one hardware class Qu's legal set covers. EVIDENCE, verbatim from section 11: '11.1 Use of Payment Devices. All Point of Sale Transactions enabled for use with Adyen will be submitted to Adyen for processing through Equipment approved by Qu'; '11.2 Return of Payment Devices. Upon the occurrence of (a) the end of the term of these Third Party Services, (b) early termination of the Payment Services or (c) cessation of use of Payment Devices by Customer, all Payment Devices must be returned to Qu for proper disposal or reported as lost or stolen as set forth below. Customer acknowledges that Payment Devices (a) contain sensitive and proprietary data; (b) must be destroyed in a manner that is compliant with PCI DSS requirements; and (c) can only be used in connection with Payment Services. Consequently, Customer agrees that it will not resell, distribute and/or make available Payment Devices to any third party.' A device that must be returned for destruction, may only be used with the vendor's own service, and may not be transferred to a third party is the negation of this claim. SCOPE LIMIT, stated so it is not over-read: the clause binds Payment Devices (card-reading Equipment) only; Qu still publishes no terms for tablets, kiosks or KDS hardware, and `hardware` returns 0 word-boundary hits in the whole document. BOUND: the four published legal documents (/terms-and-conditions, /privacy-policy, /adyen-for-platforms-terms-and-conditions, /third-party-terms) plus the 247-URL sitemap; controls over the new document - `warranty` 1 (an Adyen KYC representation), `RMA` 0, `SLA` 0, `service level` 0, `uptime` 0, `backup` 0, `surcharge` 0, `dual pricing` 0, `tap to pay` 0. Retrieved 2026-09-17. || 333rd: 333rd NEW SURFACE, not settling: Qu's franchisee contract FAQ (https://go.qubeyond.com/taco-johns-faq, HubSpot landing page found by site-search sweep, grade C) asks the question directly - 'Is the hardware really free? What happens after 5 years?' - and answers only 'There are several potential options for the end of the initial term of the contract and the path forward will largely depend on what Taco John's and Qu determine ...' and 'The hardware is covered during the term of the agreement with an advanced replacement depot program.' Hardware is supplied within the subscription term, but nothing says whether it stays usable with other software after cancellation; `resell` and `own the hardware` = 0 on the 52 landing pages. Retrieved 2026-09-18. || 334th: CLAIM: vendor documentation confirms whether vendor-purchased hardware stays usable with other software after cancellation. VERDICT: unknown (unchanged). 334th NEW SURFACE (none of the 331st-333rd opened it): customer-brand FRANCHISE DISCLOSURE DOCUMENTS on the Minnesota Commerce CARDS public registry (anonymous GET: https://cards.web.commerce.state.mn.us/franchise-registrations?doSearch=true&franchisor=<name>). 30 franchisor names searched (Qu customers named in Qu case studies/videos plus QSR peers); latest Clean FDD fetched for 27; 13 bodies read in full (Taco John's 2026-07 amendment, Blaze Pizza 2026, Dave's Hot Chicken 2026, Del Taco 2025, Saladworks 2026, Auntie Anne's, Cinnabon, Schlotzsky's, Jamba 2026, Sonic, Nathan's, Papa Murphy's, a Dairy Queen area developer); 14 returned empty bodies (throttled, a refusal, not an absence); Church's, Golden Chick, Freebirds, Jack in the Box, Hot Head, Rapid Fired are not MN-registered. Tokenised `Qu` names Qu in only TWO: Taco John's (operations-manual TOC 'Qu Point of Sales (POS) System/Kitchen Video System (KVS)', beside separate entries 'Decision Logic Back of House System', 'Olo Dashboard', 'Punchh', 'FlyBuy') and Blaze Pizza (Standards Guidelines TOC 'Qu (POS Training)'); Saladworks' hit is an officer bio ('Director of Operations for Qu POS'), and Papa Murphy's 5 hits are POISON (mis-encoded 'Québec' in MTY's address). An FDD is the FRANCHISOR's filing, i.e. third-party evidence about Qu (grade E at best), and neither FDD names Qu in the fee tables. What it adds: Taco John's Item 11 says 'You must purchase, from our approved vendor, and install the specific electronic cash register, freestanding kiosks, kitchen video monitors, receipt printers ...' at 'between $20,000 and $46,300', and 'If we require you to use a different Point of Sale System, you must stop using the old Point of Sale System, acquire the new Point of Sale System, sign any required software license agreement' (p.39) - a franchisor rule, silent on whether the Qu-supplied devices can run other software; it also sits in tension with Qu's own Taco John's FAQ ('Is the hardware really free?'), so the commercial model differs by deal. No vendor document; third-party and silent. Retrieved 2026-09-18. adversarially verified
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
CLAIM: publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround. VERDICT: partial/C (moved off unknown). NEW SURFACE (333rd): Qu's HubSpot LANDING-PAGE estate on go.qubeyond.com, found by sweeping HubSpot site search (`/_hcms/search?term=<w>&type=LANDING_PAGE`, 50 terms incl. stopwords, all offsets) - 52 live landing pages, most never in the Wayback CDX the 331st used (238 rows, 25 slugs); all 52 fetched at 200 and grepped, plus 6 hubfs PDFs they link (OrderUpFlyer.pdf, 'Qu Energy & Equipment Intelligence 10.2025.pdf', 'Qu OnePage Qu Business Edge 11.2025.pdf', and the Restaurant Models / Rise-Fall / Third-Party e-books). Among them are FRANCHISEE-facing pages never read by any pass: /taco-johns-faq (a Qu-authored contract FAQ for Taco John's franchisees, sibling of the 'Taco John's Conference 2022' pages), /churchs-pos-incentive-program (2022) and /dq-connect-conference-2026. Vendor-authored marketing host = grade C. EVIDENCE, verbatim on https://go.qubeyond.com/taco-johns-faq: 'What is covered, is support included? The hardware is covered during the term of the agreement with an advanced replacement depot program. Qu also offers a 24-hour support center.' and, in the same FAQ, 'The initial term of the contract is 5 years.' So Qu PUBLISHES a hardware coverage term (the agreement term, 5-year initial) and an ADVANCE-REPLACEMENT DEPOT program - two of the claim's three parts - which the prior note's 'no warranty term, no advance exchange' could not see. NAMED SHORTFALL: no turnaround (next-business-day or otherwise) is stated anywhere: `next business day`, `next-day`, `overnight`, `within 24`, `48 hours` = 0 across the 52 landing pages; the '24-hour support center' is a support-line availability, not a swap time. Marketing-host grade C also caps a differentiator at partial. Consistent with the 328th's gtf.portal.qubeyond.com hardware Return/Transfer workflow. Retrieved 2026-09-18. https://go.qubeyond.com/taco-johns-faq · retrieved 2026-09-18 adversarially verified
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
'BYOD' occurs zero times. The only personal-device workflows Qu describes are guest-facing — tableside and curbside ordering where the guest scans a QR code and orders 'directly from their mobile devices' — not staff running the ordering or payment app on their own phone. A BYOD permission and security model is precisely the kind of admin-and-security documentation Qu publishes nowhere publicly (no docs, developer, help or university host exists; support.qubeyond.com 302s on every path), so the marketing silence carries no weight for this cell. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: staff can run the ordering or payment app on their own personal phone, with a documented permission and security model. VERDICT unknown. EVIDENCE: tokenised `BYOD` and `personal device` = 0 across the 205 articles and the 53 PDFs. Qu's documented terminal model runs the other way: the EI manual's Chapter 7 'POS Terminals' registers terminals centrally, Store Configuration carries a 'Client Update' section, v139 adds till attachment permissions ('There are new permissions to allow for Detaching and Reattaching a drawer'), and staff sign-in is by PIN or mag card ('Assigning an Employee Mag Card to a User', 'How do I Change an Employee's PIN?'). The only non-terminal device named is 'the OMS Tablet', whose article has no body. Retrieved 2026-09-18. || 331st: 331st. NEW SURFACE (331st): the rebuilt www.qubeyond.com RESOURCE CENTRE, never fetched by the 327th (which fetched only the 39 non-resource-centre pages of the 248-URL sitemap): 198 /resource-center/ + 11 /case-studies/ URLs, 207 at 200 and 2 at 301, 1.0 MB of stripped text, incl. new 2026 pieces (the Aug 4 2026 menu-management guide, Winter 2026 / Fall 2025 / Spring 2025 release highlights). Marketing = grade C. The only `BYOD` hit (1) is a POISON for this cell: the resource-centre piece 'Finally, an App That Saves Your Store Managers Time & Money' says of Notify 'It's BYOD/OS agnostic, accessible anytime from your Android or iPhone device(s)' - Notify is the manager analytics/86 app (the only Qu app on either store, com.qubeyond.notify), not a staff ordering or payment app, and no permission/security model is described. No Qu ordering or payment app exists on the App Store or Google Play. Unknown. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `BYOD`/`personal device`/`own phone` = 0 in both. Retrieved 2026-09-18. adversarially verified
Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator
hardware-remote-device-management
The note claims 'Qu Pay cites remote device management and nightly updates' — I fetched the Qu Pay page and it contains no device-management or nightly-update language whatsoever. The only real evidence is a status-page component literally named 'Esper KDS Device Management', i.e. a third-party MDM (Esper) scoped to KDS devices, not a Qu first-party fleet-management product covering POS/kiosk/drive-thru. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-01 adversarially verified
Integrates with specialty beverage hardware — self-pour tap walls, flow meters, or liquor pour spouts — such that pours post to a POS tab automatically.
hardware-selfpour-scales
Enumerated all 121 partners in Qu's certified directory across 11 facets: there is no self-pour, flow-meter or pour-spout partner (DigitalPour is filed under Back of House + Labor and is draft-beverage menu/inventory management, not pour-to-tab metering) and no beverage-hardware facet. But the directory is NOT exhaustive by Qu's own reckoning — its counter reads '150 integrations' while only 121 are served across all 14 pages — so absence from it is not load-bearing. 'self-pour' and 'tap wall' return zero corpus hits. Consistent with Qu's QSR/fast-casual ICP but not positively established. || 327th: MERGE HOLD (proposed no/B, held unknown): A peripheral integration lives in the STORE-LEVEL POS, which Qu ships no readable public app for; a back-office census does not bound it (the agent's own caveat). PROPOSAL AS WRITTEN: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. CLAIM: integrates with specialty beverage hardware -- self-pour tap walls, flow meters or liquor pour spouts -- such that pours post to a POS tab automatically. VERDICT no. EVIDENCE/BOUND: tokenised `self-pour` / `selfpour` / `tap wall` / `flow meter` / `pour spout` = 0 across all four corpora: the 177/177 admin.qubeyond.com chunk census (24.4 MB, where a peripheral/terminal configuration would live -- the app does enumerate device objects, 'Unnamed Terminal', 'Unnamed Lane', 'Receipt Printers', footprints and routes), the 248-URL rebuilt marketing site including its /integrations partner directory (whose own category enumeration is Accounting, Delivery, Digital Ordering, Gift Cards, Hardware, Kitchen/KDS, Loss Prevention, Loyalty, Payments, Other -- no beverage category exists), and the retired operator KB's 205 articles + 53 PDFs. `Berg` 0, `Azbar` 0, `draft beer` 0, `keg` 0. Qu also scopes itself away from the segment on the rebuilt site: 'Built exclusively for QSR and Fast Casual', consistent with the existing no verdicts on this record's table-service cells. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `self-pour`/`tap wall`/`flow meter` = 0; `weigh` 2 = a guest's 'weigh and pay' self-serve bar anecdote in a podcast, not a Qu integration. Retrieved 2026-09-18. adversarially verified
Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.
hardware-callerid-integration
No telephony or caller-ID facet exists among the directory's 11 categories and no caller-ID partner appears among the 121 enumerated; the eight voice partners (ConverseNow, SoundHound Ai, VOICEplug, Presto, Deepgram, Incept AI, Audivi.Ai, Monkey) are all AI order-taking under Digital Ordering, which is a different capability from popping a customer record on an inbound call. 'caller' returns zero corpus hits. Absence is not decisive because the directory publishes 121 of a self-declared 150. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: inbound caller ID pops the matching customer record for phone orders. VERDICT unknown. EVIDENCE: tokenised `caller` = 0 across the 205 articles and the 53 PDFs; `phone number` = 3 and all three are employee or store contact fields. The order-entry articles that enumerate how an order starts ('What are Order Types?' in both generations, 'How Do I Place an Order?', 'How do I use Drive Thru Mode?', 'Changing Order Types from the Online Menu') contain no telephone-order path at all, so in this generation there is no screen for a caller-ID pop to land on. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `caller ID`/`telephony` = 0; `phone orders` 1 = a podcast guest (Savory COO) naming third-party voice-ordering tools. Retrieved 2026-09-18. adversarially verified
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
No publicly readable API reference exists. Qu's two published API doc hosts, qu-api.qubeyond.com and qu-pos-api.qubeyond.com, both return Azure's 'Error 403 - This web app is stopped. The web app you have attempted to reach is currently stopped and does not accept any requests' (HTTP 403 Site Disabled) to HTTPS, HTTPS-without-verification and plain HTTP alike, and Wayback shows that page from 2023-12-30 onward -- the docs were public until roughly 2023 and were taken down. No developer/developers/docs/api/apidocs subdomain of qubeyond.com resolves. The vendor's only remaining documentation surface, support.qubeyond.com (Document360), 302s /, /hc/en-us and /sitemap.xml alike to identity.document360.io/Account/Login, and does so despite serving 'User-agent: * Disallow:' -- the gate is authentication, not crawler policy. API access is by partner certification. https://support.qubeyond.com/hc/en-us · retrieved 2026-08-09 adversarially verified
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
Commercial claim. The /become-a-partner page and the /integrations 'Become a Partner' block are the only surfaces that could price integration and neither states a fee, per-location charge, revenue share, or plan requirement — the only text is 'We believe responsible partnerships benefit everyone in the ecosystem. Our robust certification process ensures that integrations are tested and reliable.' A silence on a lead-capture form is not an assertion that access is free. Qu is quote-only with no published pricing. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW BOUND (327th), still unknown: identical bound to reporting-api-not-upcharged -- the rebuilt www.qubeyond.com fixpoint (248 URLs) publishes no price, plan or API fee; developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve; and 18 Qu hosts were probed for /swagger, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs and /docs with no anonymous spec found. The site's API language is architectural rather than commercial ('an API-first architecture that removes the middleware complexity common in legacy POS systems', /get-a-demo; 'An open architecture gives room to influence ordering, loyalty, promotions, and workflows while Qu maintains the transaction foundation', /build-buy-or-both). Nothing states whether access is included or charged. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). No API price or inclusion statement: `API` hits (35 in the pages/PDFs, 43 in captions) are all architecture talk ('API-first, cloud architecture', 'open APIs', middleware critique); the franchisee FAQ/incentive pages price hardware/support/service credits but never API access. SwaggerHub org `qubeyond` exists with 0 public APIs. Retrieved 2026-09-18. || 334th: CLAIM: API access included in the base subscription at no extra per-location fee, surcharge or plan requirement. VERDICT: unknown (unchanged). 334th NEW SURFACE (none of the 331st-333rd opened it): customer-brand FRANCHISE DISCLOSURE DOCUMENTS on the Minnesota Commerce CARDS public registry (anonymous GET: https://cards.web.commerce.state.mn.us/franchise-registrations?doSearch=true&franchisor=<name>). 30 franchisor names searched (Qu customers named in Qu case studies/videos plus QSR peers); latest Clean FDD fetched for 27; 13 bodies read in full (Taco John's 2026-07 amendment, Blaze Pizza 2026, Dave's Hot Chicken 2026, Del Taco 2025, Saladworks 2026, Auntie Anne's, Cinnabon, Schlotzsky's, Jamba 2026, Sonic, Nathan's, Papa Murphy's, a Dairy Queen area developer); 14 returned empty bodies (throttled, a refusal, not an absence); Church's, Golden Chick, Freebirds, Jack in the Box, Hot Head, Rapid Fired are not MN-registered. Tokenised `Qu` names Qu in only TWO: Taco John's (operations-manual TOC 'Qu Point of Sales (POS) System/Kitchen Video System (KVS)', beside separate entries 'Decision Logic Back of House System', 'Olo Dashboard', 'Punchh', 'FlyBuy') and Blaze Pizza (Standards Guidelines TOC 'Qu (POS Training)'); Saladworks' hit is an officer bio ('Director of Operations for Qu POS'), and Papa Murphy's 5 hits are POISON (mis-encoded 'Québec' in MTY's address). An FDD is the FRANCHISOR's filing, i.e. third-party evidence about Qu (grade E at best), and neither FDD names Qu in the fee tables. The Taco John's FDD (the one filing that names Qu as the POS) has no API or integration fee row in Item 6 and describes franchisor data access only as 'interfaces with our preferred providers' (p.39); the Blaze FDD names Qu only in a training TOC and prices its POS as an undifferentiated bundle ('monthly subscription access to the aforementioned software'). Neither discloses the brand-to-Qu contract, so API cost stays unmeasured. Retrieved 2026-09-18. adversarially verified
A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator
extensibility-free-sandbox
Positive evidence of the opposite, from Qu's own archived API reference rather than from the marketing site. The Data Access API documents an account-issued credential model: 'If an endpoint requires an API Key, the header APIKey =[string] should be present in the Request', with the worked example framed as 'All examples assume that company integrating with Data Access API is called "GoodEatsOrdering"' -- a named, onboarded partner, not self-serve signup. 'sandbox' occurs in none of the 210 archived help-centre articles. Measured 2026-09-03: sandbox.qubeyond.com does resolve (A 3.220.47.246, 100.31.229.247) but 502s on /, /robots.txt and /swagger/index.html and has never been captured by Wayback, so it is an internal environment hostname and not an offer to developers; the archived example base URL dev-data-access-api.azurewebsites.net resolves to 23.96.112.53, the same stopped Azure app as qu-api.qubeyond.com. https://web.archive.org/web/20220724113646/https://qu-pos-api.qubeyond.com/ · retrieved 2026-09-03
Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).
extensibility-oauth-partner-apps
Qu's own Data Access API documentation states the authentication mechanism outright: 'Important: If an endpoint requires an API Key, the header APIKey =[string] should be present in the Request.' A static shared-secret header, with no authorization endpoint, no token exchange, no scopes and no per-operator grant or revocation. The doc page is no longer served -- qu-pos-api.qubeyond.com returns Azure 'Error 403 - This web app is stopped' on 2026-08-09 -- so this is quoted from the last good capture (2022-07-24, doc header 'API v 20190222.1'); the identical sentence appears in the qu-api.qubeyond.com capture of 2022-06-30 ('API v 3.0.93.12'). No OAuth, scope or consent language appears anywhere on qubeyond.com or in its partner material. https://web.archive.org/web/20220724113646/https://qu-pos-api.qubeyond.com/ · retrieved 2026-08-09 adversarially verified
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
Capability verb ('pushes'), so the exhausted host set cannot convert this to `no`. 'webhook' is absent from all 199 uncited pages. The corpus's strongest architecture statements are marketing — 'Built on REST APIs... an open, bi-directional infrastructure' and 'The APIs leverage bi-directional data syncs' — which describe direction of data flow, not push-vs-poll transport, and are grade C. With no developer host in existence, an unpublished push contract remains possible. || 325th: NEW SURFACE, measured, does not settle THIS cell - see reporting-webhooks for the full quotes. Qu's production Payments Portal bundle (pay-admin.qubeyond.com/assets/index-D6ChSTf8.js, 6,358,057 bytes, Qu's own host, robots.txt 404) proves webhook configurations with HMAC keys exist in the Qu Pay platform ('Webhook hmac Key not found.', 'Webhook config not found.', 'Webhook config already exists.', and a DEVELOPER role that 'Configure[s] webhook endpoints'). Why that does not settle this claim: the claim is order lifecycle (created, modified, paid, voided, refunded), and every event name in that bundle is a PAYMENT state (AUTHORIZED, CAPTURE_REQUESTED, VOIDED, REFUNDED, PARTIALLY_REFUNDED, PAYMENT_REVERSED); `webhook` returns 0 hits in the 175-file admin.qubeyond.com fixpoint corpus and 0 in the 74-file wo.qubeyond.com web-ordering census, so no order-event subscription surface has been located, and no Qu host publishes an API reference against which to check it. Retrieved 2026-09-17. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: the platform pushes events to a subscriber endpoint. VERDICT unknown. EVIDENCE: tokenised `webhook` = 0 across the 205 articles and the 53 PDFs - and this is the first Qu corpus that names Qu's APIs at all. Both named APIs are pull/export-shaped: 'Labor API - A stores locationId is now available with each labor schedule' and 'The Labor API now includes the locationId in each labor schedule' (v139), and 'as of v139, Data Export API will offer a new export structure that converts Items with Portions into individual Items'. The partner order integrations named (DoorDash, UberEats, Postmates, OLO, Punchh) are integrations Qu builds and operates, not endpoints a customer registers. Retrieved 2026-09-18. || 328th: NEW SURFACE (328th) - the Qu Pay portal bundle's webhook machinery, read in full, and it CONFIRMS the earlier hold rather than lifting it. pay-admin.qubeyond.com ships a webhook configuration object with signing: error enum `WEBHOOK_HMAC_KEY_NOT_FOUND`, `WEBHOOK_CONFIG_NOT_FOUND`, `WEBHOOK_CONFIG_ALREADY_EXISTS` ('Webhook hmac Key not found.', 'Webhook config not found.', 'Webhook config already exists.', localised into Danish among others), and a Developer role whose published description is 'Manage API keys and authentication / Configure webhook endpoints / Set up integration settings / Manage fee configurations / Configure terminal devices / Access customer data for testing'. The sibling roles in the same enumeration are 'View merchants, stores, and organizations', 'Manage customer financial settings', 'View and manage customer accounts', 'Help resolve payment disputes' - i.e. these are QU STAFF roles administering merchants on an Adyen-for-platforms back office, not merchant self-service. So the webhook endpoints are Qu's own platform plumbing; nothing shows an operator registering an endpoint. Event catalogue, subscription UI and retry policy are absent from both the payments portal and the 177/177 admin census; the partner API that would carry them is unpublished. Retrieved 2026-09-18. || 331st: 331st NEW SURFACE, not settling: Qu's API landing page qu-api.qubeyond.com, found through a web-search index hit and recovered from Wayback (captured 2022-06-30, 'Qu API v 3.0.93.12'; siblings qu-api-qa 'v 3.0.104.6', qu-integration-qa and qu-pos-api captured 2022). The live host now serves a certificate for another name and 403s every path (incl. a nonsense path) to curl, so it cannot be re-read. Its ORDER flow is poll-based, not push: 'With current implementation 3rd party vendors can send online orders to Qu Data Access API, orders will be saved in the database and POS systems in stores pull online orders and print them.' It documents only basket/order WRITE calls (ADD Items, DELETE Items, ADD Discounts, Calculate Totals, POST Order) with an 'APIKey' header, and names no event, callback or subscription. Retired 2022 copy: notes only, no `no` rests on it. Also new: Qu's CURRENT open role 'Sr. Software Engineer (Payments & Data)' (ats.rippling.com/qu-careers, board API lists 2 roles) says 'Own terminal-to-cloud payment flows: device initialization, transaction processing, Store & Forward, and webhook-based reconciliation' and asks for 'PSP integration experience: gateway APIs, terminal APIs, management APIs, webhook notifications' - i.e. the webhook machinery in pay-admin is Qu CONSUMING its PSP's notifications, not emitting order events to customers. Retrieved 2026-09-18. || 332nd: 332nd NEW SURFACE, not settling: Qu's July 2022 white paper 'Going Beyond POS to a Unified Commerce Platform' (still linked from the current resource centre; grade C) enumerates 13 API domains and none is an event/webhook subscription for order lifecycle. The two push-shaped phrases are 'Alerting - Configure and receive alerts about enterprise-level rules on sales, labor, and other key metrics' (KPI rule alerts, not order events) and 'Developers can use the real-time data feed from Qu to easily create their own custom dashboards' (transport unstated). Tokenised 'webhook' and 'callback' = 0 in its 42,486 chars of text, and neither of its 2 'event' hits is a subscription noun. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). Tokenised `webhook`/`callback` = 0 in both; the one `push notifications` caption hit is a guest-marketing channel in a podcast. (c) SwaggerHub: org `qubeyond` EXISTS (api.swaggerhub.com/apis/qubeyond 200) but lists totalCount 0 public APIs - Qu keeps its API specs private, so the partner API remains unpublished, not absent. Retrieved 2026-09-18. adversarially verified
Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator
extensibility-webhook-reliability
Capability claim, compounded (signing AND retry AND replay log). Zero 'webhook' and zero 'rate limit' hits in the 199-page corpus and the Adyen contract. No Qu host publishes an API reference, so HMAC signing, backoff policy and replay semantics are unmeasurable rather than absent. May not be scored `no` under the publication/capability split. || 327th: MERGE HOLD (proposed no/B, held unknown): Same as reporting-webhooks: the partner API is unpublished, so its delivery semantics are unmeasured, not absent. PROPOSAL AS WRITTEN: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. CLAIM: webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. VERDICT no, by entailment from the same census: there is no webhook mechanism at all to sign or retry. Tokenised `webhook` 0 and `callback url` 0 across the 177/177 admin.qubeyond.com chunk census (24.4 MB), the 248-URL rebuilt marketing site and the retired operator KB (205 articles + 53 PDFs), and Qu publishes no developer documentation on any host that resolves. CONTROL POISON: the obvious reliability controls are unusable raw on a bundle and are reported here so nobody re-runs them naively -- `replay` scores 176 in the admin bundles (session-replay/rrweb plus OpenLayers animation), `backoff` 3 and `HMAC` 1, all inside bundled third-party libraries, none of them a customer-facing delivery guarantee. The one delivery-guarantee language Qu does publish is about its own edge sync, not customer callbacks: 'Automatic conflict resolution and state reconciliation on reconnect' (/qu-business-edge). Retrieved 2026-09-18. || 328th: NEW (328th): the only delivery-semantics artefact anywhere in Qu's readable code is the payments portal's HMAC signing key (`WEBHOOK_HMAC_KEY_NOT_FOUND`, 'Webhook hmac Key not found.') on a Qu-staff-operated Adyen-for-platforms console. Measured over the same 30.7 MB: `redeliver`, `dead letter`, `at-least-once`, `idempotent`, `idempotency` = 0 outright; `retry` scores 149 in the pay bundle and 10 in the admin bundle and `replay` 87/95, but ZERO of those hits falls within +/-200 characters of any of the 73 `webhook` occurrences (they are HTTP-client and animation-replay internals) - so no delivery guarantee is stated anywhere, and HMAC signing alone is not a retry or ordering guarantee. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (a) the 52 go.qubeyond.com HubSpot landing pages (site-search sweep; incl. franchisee FAQ/incentive pages for Taco John's, Church's and Dairy Queen) + 6 linked hubfs PDFs; (b) Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `webhook`, `HMAC`, `retry`, `signature` = 0 in both. (c) SwaggerHub org `qubeyond` exists with 0 public APIs (private specs), so delivery semantics remain unmeasured. Retrieved 2026-09-18. adversarially verified
A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.
extensibility-order-injection-api
Qu's API documentation: 'Qu provides REST API for 3rd party ordering applications to place orders in Qu POS systems. With current implementation 3rd party vendors can send online orders to Qu Data Access API, orders will be saved in the database and POS systems in stores pull online orders and print them.' The reference documents the full write path -- basket create, add/delete items and discounts, Calculate Totals, then POST Order -- under api/v3/customers/{id}/locations/{id}/baskets. Note the shortfall in the mechanism: it is a PULL model, the store polls the cloud, not a push into the terminal. The doc host is no longer served (Azure 'web app is stopped', 403, on 2026-08-09), so this is quoted from the 2022-07-24 capture; that the path is live today is corroborated by Qu's own 2026-01-13 release announcing Onosys 'certification and production-ready integration' with 'deep, bi-directional integration', and by live Zuppler and 7shifts connectors. https://web.archive.org/web/20220724113646/https://qu-pos-api.qubeyond.com/ · retrieved 2026-08-09 adversarially verified
Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator
extensibility-data-symmetry
CLAIM: every core object the API can read (orders, menu, customers, employees, inventory) can also be written via the same API. VERDICT: partial/C (moved off unknown). NEW SURFACE (332nd): Qu's white paper 'Going Beyond POS to a Unified Commerce Platform: The New Path Forward for Enterprise Restaurants' (dated July 2022 on its cover; PDF CreationDate 2022-07-11; 8,684,391 bytes, 18 pp., HTTP 200 anonymous GET), which Qu STILL distributes from its CURRENT rebuilt site: the direct file link sits in the HTML of https://www.qubeyond.com/resource-center/going-beyond-pos-to-a-unified-commerce-platform (a HubSpot form wrapper; the file itself is an anonymous hubfs URL, no form was submitted). No prior pass opened it (grepped every .cache/q3*/qu* corpus for its filename and for 'inject menus': 0). Vendor-authored marketing = grade C; a 2022 document, so positives only. Part Four, 'Core APIs', is an ENUMERATION of Qu's API domains ('Qu's native applications and end-user touchpoints engage with our own purpose-built, bi-directional APIs ... we consume our own APIs'). EVIDENCE, verbatim from the Core APIs enumeration (pp.13-14): MENU 'Configuration - The main API used to read and write menus, discounts, service charges, stores, meal periods ... It can also be used by third-party menu management systems to inject menus'; EMPLOYEES 'Labor - Includes the ability to create, edit, or delete employees, and create and manage employee schedules'; USERS 'Authentication - ... This is used to create, edit, or delete users in the system'; CUSTOMERS 'Loyalty - Includes the ability to create and edit guest records, guest transaction tracking'; ORDERS 'Order - Includes Qu's pricing engine, discount engine, tax engine ... to price menu items and calculate the final order amount - both online and in-store' plus p.15 'plug into our APIs to create a fully customizable online ordering or mobile app experience ... build an order' (consistent with this record's extensibility-order-injection-api yes/B); READ side 'Data - Includes real-time data generated by Qu such as check, product, cash, payment, and labor information'. So four of the claim's five families (orders, menu, customers, employees) have a vendor-stated write path. Why not yes: INVENTORY is named only as a partner category ('reference integrations to traditional revenue and cost management products (Loyalty, Martech, Inventory, Labor, etc.)'), with no read or write API; marketing grade C on a differentiator; no reference doc exists to confirm parity per object. Retrieved 2026-09-18. https://5768638.fs1.hubspotusercontent-na1.net/hubfs/5768638/Qu-Unified-Commerce-Platform-for-Restaurants-White-Paper-FINAL-Hi-Res-1.pdf · retrieved 2026-09-18 adversarially verified
API rate limits are published as specific numeric quotas with documented throttling behavior and headers.
extensibility-published-rate-limits
The archived Data Access API reference's conventions section is complete and omits any quota. It reads in full: 'Message Format: All requests and responses bodies are in JSON format. API URLs: All Data Access API calls prefixed with api/v3... Important: If an endpoint requires an API Key, the header APIKey =[string] should be present in the Request.' No numeric quota, no throttling behaviour, no headers. 'rate limit', 'throttl' and 'quota' occur in none of the 210 archived help-centre articles. Re-measured 2026-09-03: docs./developer./developers./help./api./university.qubeyond.com are all ENOTFOUND; qu-api and qu-pos-api answer 403 Azure 'Web App - Unavailable' over plain HTTP and fail TLS identity; support.qubeyond.com/hc/en-us is a Document360 login page; the 239-URL live sitemap contains no developer or API-reference page. https://web.archive.org/web/20220724113646/https://qu-pos-api.qubeyond.com/ · retrieved 2026-09-03
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a features-completed count against the eight high-quality features the program requires. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is the instrument the program page points to when it says the roster is tracked in real time, and it supersedes the 2026 announcement post most of this corpus cited — that post introduces its ten names with the word `include`, which makes it a floor, not a ceiling. In that registry this vendor is the entry `qubeyond_v2`, rendered as 'Qu', with qualityStatus PREFERRED and 7 of the 8 high-quality features built. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11
Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator
extensibility-first-party-delivery-integrations
Direct bi-directional DoorDash, Uber Eats, Grubhub (plus EZCater, Monkey) integrations, explicitly "no middleware required." https://www.qubeyond.com/ordering/third-party-ordering/ · retrieved 2026-08-01
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
Qu blog (dated June 19, 2019): "Qu offers the flexibility of third party integration for customers that wish to continue to use smaller third party players and when direct integration is not yet an option. Qu's customer-first and API-first approach allows customers to integrate familiar platforms like Chowly and ItsaCheckMate into their existing ecosystem." That names two of the listed aggregation middleware platforms. SHORTFALL: the statement is seven years old and current Qu marketing positions the opposite - "Cut out middleware" and "no middleware required" (ordering/third-party-ordering, ordering/pos) - and it could not be confirmed against the live partner directory, which reports "Showing 1 to 9 of 150 integrations" and does not render the remaining pages to a plain fetch. Deliverect and Otter appear nowhere on the site. https://www.qubeyond.com/resource-center/third-party-delivery-blessing-or-technology-curse-for-operators · retrieved 2026-09-03
Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.
extensibility-accounting-connectors
Accounting is a listed partner category and Restaurant365 maintains a Qu POS connector; a vendor-maintained QuickBooks Online connector with mapped journal entries is not documented. https://www.restaurant365.com/partners/qu-pos/ · retrieved 2026-08-01
Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.
extensibility-payroll-export
Qu blog announcing 2024 certifications: "Labor Management Optimize your workforce with sophisticated tools from HotSchedules, Proliant, and Rippling", within "100+ industry-leading integration partners" whose "robust certification process ensures that integrations are tested and reliable". Proliant and Rippling are both payroll processors, so two named payroll providers are certified partners. SHORTFALL: no reachable Qu page states that LABOR HOURS flow to them, in which direction, or that manual re-keying is eliminated; the partner directory's Back of House + Labor category could not be enumerated past its first 9 of 150 rows; and Gusto, ADP, Paychex and Paylocity appear nowhere as Qu integrations. https://www.qubeyond.com/resource-center/what-qus-doubled-integration-network-means-for-you · retrieved 2026-09-03
Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator
extensibility-bi-data-warehouse
DataExport API exists and Qu markets API connections into external BI; scheduled delivery to a customer-controlled destination is not documented. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-08-01
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
Re-evidenced 2026-08-08: /about/qu-technology-partners/ now 301s to /integrations, a live public directory that states 'Showing 1 to 9 of 150 integrations' and is browsable and filterable by eleven categories - Accounting, Analytics, Back of House + Labor, Delivery, Digital Ordering, Hardware + Digital Signage, Kitchen / KDS, Loss Prevention, Loyalty, Other, Payments. Named entries include 7shifts, Altametrics, MarketMan, Restaurant365, Crunchtime, Olo, Paytronix, Thanx, DoorDash, UberEats, GrubHub, FreedomPay and Fiserv. Shortfall (the reason this is partial, not yes): there is no self-install. Every entry's only action is 'View Site', linking out to the partner; enablement runs through Qu's certification process - 'Our robust certification process ensures that integrations are tested and reliable' - with a 'Become a Partner' form rather than an operator-facing install button. Grade C rather than B: this is a first-party marketing/feature page, not product documentation. https://www.qubeyond.com/integrations · retrieved 2026-08-08 adversarially verified
Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.
extensibility-custom-fields-scripting
Chapter 6: Configuration (First Gen 2.0) documents two operator-defined extension surfaces inside Enterprise/Store Configuration. The Client settings block carries 'Prompt for Check Extension Data - Specify JSON Format Extension Data', i.e. operator-specified JSON fields prompted for and carried on a check. System Lookups let the operator 'Add custom values using System Lookups. For example, add your own reasons for voiding a check or discounting an item', covering Void Reasons, Time Entry Reasons, Return Reasons, Paid In/Out Reasons, Discount Reasons, Order Types and Inventory Units. Shortfall: these are configuration-driven custom values plus a custom JSON payload on one object, not user-defined fields across POS objects, and no vendor-hosted scripting or custom-logic runtime appears anywhere in the 210 archived articles or the v139-v143 release notes. Vintage: First Gen 2.0, 2018-2020. https://web.archive.org/web/20200808111044/https://support.qubeyond.com/hc/en-us/articles/360001267211-Chapter-6-Configuration-First-Gen-2-0- · retrieved 2026-09-03
The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.
extensibility-headless-embedded
Third-party ordering front ends (e.g. Zuppler, Bite) drive Qu through its ordering API, and Qu markets an "API forward" stack, but no formal headless/embedded mode is documented. https://www.zuppler.com/qu-beyond-pos · retrieved 2026-08-01
The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.
extensibility-api-versioning-deprecation
The claim is conjunctive and the deprecation half fails. Qu does publish release notes, so a 'no hits for changelog' reading would be wrong: seasonal recaps run publicly in the resource centre (Fall 2024 through Winter 2026) and dated versioned notes ran in the then-public help centre, some carrying real API changes -- 'Labor API - A store's locationId is now available with each labor schedule'; 'as of v139, Data Export API will offer a new export structure that converts Items with Portions into individual Items'. But the public recaps are feature marketing with no API section, and the only deprecation found anywhere is ad-hoc and about platform settings, not the API: 'Please review the soon to be deprecated Platform Settings (QuickSuspend, SuspendOrderAllowed, PrintOnSuspendByDefault, SendOrderOnSuspendByDefault)... they have been marked deprecated and will be deleted in the future when there are no POS running versions prior v142.' No stated deprecation or breaking-change notice policy appears on any enumerated surface: the 239-URL sitemap, the status page, the resource centre, the archived API reference, or six NXDOMAIN developer subdomains. https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360052896691-November-17th-v139 · retrieved 2026-09-03
A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator
extensibility-data-portability-exit
Product page FAQ: "Yes. Qu's unified data layer supports API-based integrations with external BI platforms, enabling operators to pipe Qu data into the analytics environment of their choice", alongside "Access up-to-date performance data across locations through Qu or your existing reporting tools"; the multi-unit guide claims "100% First-party guest data, owned". SHORTFALL: this is an ongoing BI pipe, not an exit right - no reachable Qu page commits to a COMPLETE historical export of orders, customers, menu and payment metadata AT CONTRACT END, names a machine-readable format, or states whether a fee applies. The only Qu-authored terms published are website terms of use, with no MSA and no data-return clause; no format or endpoint can be checked because both API hosts fail TLS identity and the customer portal is login-walled. https://www.qubeyond.com/management/unified-data-reporting · retrieved 2026-09-03
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
Qube executes POS, payments, order routing and kitchen workflows locally; ordering continues uninterrupted during outages. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-01
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
Qu Business Edge (Qube) product page asserts "Local Execution of Critical Services: POS, payments, order routing, and kitchen workflows execute on-site. There is no reliance on remote service calls for core operations", plus a "Write-Local, Sync-Global Data Model" where "All transactions are written locally at the edge and propagated to the cloud in real time... No data loss during outages" and "Resilience Without Degraded Modes... Full transaction processing continues". The Qu POS page FAQ repeats it: "Ordering, payments, and kitchen routing continue uninterrupted during connectivity outages, and data syncs to the smart cloud automatically when the connection is restored" (https://www.qubeyond.com/ordering/pos). SHORTFALL: this is asserted on grade-C vendor feature pages only. No store-and-forward mechanism, floor/ceiling limits, per-transaction or aggregate offline caps, maximum offline duration, or decline-on-reconnect handling is published anywhere on qubeyond.com; support.qubeyond.com is login-walled and there is no grade-A/B documentation. Whether card authorization is genuinely deferred and forwarded, or merely captured locally, is not documented. https://www.qubeyond.com/qu-business-edge · retrieved 2026-09-03 adversarially verified
The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator
reliability-offline-decline-liability
Duplicate claim of the already-resolved payments-offline-decline-liability ("no", same source): Qu's public offline-payments material — the Qu Business Edge page ("Full transaction processing continues... Sync resumes automatically with no manual intervention," "No data loss during outages") — promotes offline card acceptance continuity without a word on who bears a decline on reconnect, or any per-transaction/cumulative offline cap. No public MSA/ToS exists (privacy-policy page confirms the only legal document published is the privacy policy, which excludes customer/product terms) and the help centre is login-gated, so the public documentation this claim requires verifiably does not exist. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-04
Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator
reliability-lan-degraded-multi-terminal
Qube is a single on-premise hub serving the location's POS, kiosk, drive-thru and KDS, implying shared local state across terminals, but Qu does not document multi-terminal check sharing during a partition. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-01
The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator
reliability-local-transaction-engine
Qu Business Edge (Qube) is an explicitly documented on-premise edge hub running critical services locally without remote service calls; A / E / IQu hardware series. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-01
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
Offline kitchen ROUTING is affirmatively claimed and I verified the wording. Offline kitchen PRINTING is nowhere stated — Qu publishes no printer-fallback or impact-printer behavior at all (the dossier itself scores kitchen-printer-fallback and reliability-printer-fallback unknown, which contradicts a 'yes' here). https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-01 adversarially verified
The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.
reliability-printer-fallback
A backup printer or KDS device can be designated per kitchen device in Qu's back office ('Backup Device', stored as backupPrinterId), and print routes carry backup printer lists. Shortfalls: Qu's published code does not say the system switches to the backup automatically when a kitchen printer is unreachable (the executing POS runtime is not public), the offline 'Timeout' setting is shown only for receipt printers, and no staff alert for a failed or unreachable kitchen printer appears in the configuration client. https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/749bc93baeb2fdcfa467.js · retrieved 2026-09-15 adversarially verified
The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).
reliability-sync-conflict-handling
Qu Business Edge documents a 'Write-Local, Sync-Global' model: 'All transactions are written locally at the edge and propagated to the cloud in real time', 'System state is preserved locally', and — the operative line — 'Automatic conflict resolution and state reconciliation on reconnect'. The vendor publicly commits to conflict resolution existing. Shortfall: the resolution behaviour itself is never specified — nothing states last-write-wins, merge or operator prompt, which is precisely what this claim asks for — and the help centre where it might be specified is login-gated. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-04
The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).
reliability-offline-feature-matrix
Qu claims full offline continuity but publishes no list of degraded features; the Qube page does not detail what requires connectivity. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-01
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
status.qubeyond.com is public with per-component status (Qu Core APIs, QuKitchen KDS, Web Ordering, Reporting/Notify/DataExport APIs, QuBox, FreedomPay, WorldPay, DoorDash, UberEats, Olo, Esper, CrowdStrike, AWS) and incident history. No rolling uptime percentages published. https://status.qubeyond.com/ · retrieved 2026-08-01
A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator
reliability-contractual-uptime-sla
Qu markets 99.99%/99.997% as architecture design claims for Qube, but no customer-facing SLA with a service-credit remedy is published. https://www.qubeyond.com/platform · retrieved 2026-08-01
The vendor publishes written post-incident reports or root-cause summaries for major outages.
reliability-incident-postmortems
The status page carries incident history with narrative updates (e.g. real-time reporting delay, Valutec gift card processing via WorldPay); formal RCA postmortems are not published. https://status.qubeyond.com/ · retrieved 2026-08-01
24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.
reliability-247-live-support
"Qu offers 24x7x365 support to keep your restaurant cooking along," with a published phone line (844.464.8786). Whether it is included in base pricing is not stated. https://www.qubeyond.com/support · retrieved 2026-08-01
The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator
reliability-onsite-install
CLAIM: the vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. VERDICT: partial/C. NEW SURFACE (331st), never used by any prior pass: Qu's OWN careers pages on www.qubeyond.com/jobs/, recovered from the Wayback CDX index of qubeyond.com (8,012 captured URLs; 41 distinct /jobs/ postings; 16 fetched via /web/<ts>id_/). They describe Qu's own staff doing the installs. EVIDENCE: Implementation Specialist (captured 2021-04-26): 'provide the resources for the implementation of Qu, including but not limited to the new POS system, add-on installations, software and hardware installation, third-party integration, networking, customer training, and live support'; 'Travel to new or existing locations to install, upgrade and support Qu system solutions'; 'Provide onsite and remote support coverage on the system "lives" to ensure a smooth transition to the Qu solution and minimize post-installation support requirements'. Implementation Specialist (captured 2019-07-23): 'Manage and coordinate the install and launch process of Qu ... through the install and launch of Qu'; 'Willingness to travel, up to 50%, to customer sites for installation and training of Qu'. Project Manager (captured 2024-03-02, the previous site generation): 'Develop project plans, resource plans, training and test plans, and cutover plans'; 'Work with Procurement on coordinating equipment shipping and arriving to site on time'; 'Work with the Implementation team to ensure that projects provide the correct documentation and are clearly documented for the technicians. Create and deliver client communications for dispatched work on a daily basis.' Sr. Manager/Director of Configuration Services (captured 2024-08-07): 'Concierge Service is the next day "white glove" treatment for stores that have installed within the last 24 hours'. Dealer leg, from the CURRENT site: the Church's Chicken release on www.qubeyond.com/resource-center/ names a third-party installer - 'HonorBuilt for hardware installation and support'. NAMED SHORTFALL: (1) this is hiring copy and press text, not a published service description - no scope, SLA, fee or inclusion statement for on-site install exists on any Qu surface (the rebuilt site's /get-a-demo FAQ only says Qu 'deploys in phases'), so grade C and not yes on a differentiator; (2) the most explicit on-site sentences are 2019-2021 postings on the retired WordPress site, so under merge policy they carry a positive at most partial; (3) whether EVERY customer gets on-site go-live, or only brands that contract it, is not stated (the 2024 Configuration Services posting scopes its services to 'the Brands that have contracted these services'). Not a remote-only self-install model in any reading. Retrieved 2026-09-18. https://web.archive.org/web/20210426171709/https://www.qubeyond.com/jobs/implementation-specialist-2021/ · retrieved 2026-09-18 adversarially verified
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
CLAIM: a hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable. VERDICT: partial/C (moved off unknown). NEW SURFACE (333rd): Qu's HubSpot LANDING-PAGE estate on go.qubeyond.com, found by sweeping HubSpot site search (`/_hcms/search?term=<w>&type=LANDING_PAGE`, 50 terms incl. stopwords, all offsets) - 52 live landing pages, most never in the Wayback CDX the 331st used (238 rows, 25 slugs); all 52 fetched at 200 and grepped, plus 6 hubfs PDFs they link (OrderUpFlyer.pdf, 'Qu Energy & Equipment Intelligence 10.2025.pdf', 'Qu OnePage Qu Business Edge 11.2025.pdf', and the Restaurant Models / Rise-Fall / Third-Party e-books). Among them are FRANCHISEE-facing pages never read by any pass: /taco-johns-faq (a Qu-authored contract FAQ for Taco John's franchisees, sibling of the 'Taco John's Conference 2022' pages), /churchs-pos-incentive-program (2022) and /dq-connect-conference-2026. Vendor-authored marketing host = grade C. EVIDENCE, verbatim on https://go.qubeyond.com/taco-johns-faq: 'The hardware is covered during the term of the agreement with an advanced replacement depot program. Qu also offers a 24-hour support center.' - an advance-replacement program exists and is INCLUDED in the agreement, which is the program half of the claim. NAMED SHORTFALL: no turnaround time is stated (`next business day`/`overnight`/`within N hours|days` = 0 over the 52 landing pages and 6 hubfs PDFs), and the statement is made in a franchise-system FAQ (Taco John's, 2022), not a general service schedule. Retrieved 2026-09-18. https://go.qubeyond.com/taco-johns-faq · retrieved 2026-09-18 adversarially verified
Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.
reliability-backup-restore
CLAIM: operators can trigger and retrieve their own data backup/restore, OR the vendor publishes RPO/RTO figures. VERDICT no. Corpora re-grepped for this cell (328th): the 177/177 chunk census of the CURRENT back office admin.qubeyond.com (24.4 MB, .cache/q327/qu/nuxt-all.js), the pay-admin.qubeyond.com Qu Pay portal bundle (6.3 MB), the 248-URL rebuilt marketing/legal site (328 KB text), the retired operator KB (205 articles, 511 KB) and its 53 vendor PDFs (169 KB), plus the previously ungrepped com.qubeyond.notify.apk dex strings (18.5 MB, .cache/q307-qu-apk). EVIDENCE (publication leg): tokenised `RPO`, `RTO`, `recovery point`, `recovery time`, `disaster recovery`, `point-in-time` = 0 in every corpus above, including the whole rebuilt site (a publication census, which under the 327th rule does carry a `no` for a publish-shaped conjunct); the site's only continuity language is the Qube appliance's 'Triple redundancy / offline mode'. EVIDENCE (self-service leg): the complete current back office is censused (177/177 chunks) and contains NO tenant backup, restore, snapshot or full-data export object. Every gettext string in 24.4 MB that matches export/download/backup/restore/archive is one of: 'Export Prices' ('Select all the Price Groups you want to export. Only Fixed Prices will be exported.'), 'Export Item Display Attributes', 'Generate and export the KML file using Google My Maps', and 'The export is being processed and will be downloaded in a while.' POISON NAMED, and it is why an untokenised control would have manufactured a false `yes` here: `backup` scores 12 in the bundle and ALL 12 are the printer fallback field 'Backup Device' / 'No Backup Device' / 'the device you are about to delete is being used as backup printer'; `restore` scores 84 and the user-facing ones are the archived-store un-archive modal ('This will restore the store and make it available for management again.', permission `store.restore`, feature EI-ArchiveStores), the rest being Vue/webpack internals. SCOPE: this bounds the back-office configuration surface, which is where an operator-triggered backup would live, plus Qu's own publications; it does not speak for the store-level POS app. Retrieved 2026-09-18. https://admin.qubeyond.com/ · retrieved 2026-09-18 adversarially verified
The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.
reliability-pci-dss-4-attestation
Fetched the platform page directly, the page whose subject is Qu's architecture and enterprise capabilities: it describes unified commerce, kitchen orchestration, payments, and enterprise management but contains no PCI DSS v4.0/4.0.1 Attestation of Compliance, validated P2PE listing, or any compliance-attestation language at all. The Qu Pay page (fetched separately) is equally silent. No trust-center or security page exists on qubeyond.com to check instead. https://www.qubeyond.com/platform · retrieved 2026-08-04
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Role-based permissions and granular user administration are documented; MFA enforcement on back-office or POS admin logins is not. https://www.qubeyond.com/management/channel-management · retrieved 2026-08-01
A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.
reliability-self-serve-training
"Qu Campus" provides documentation and training but requires customer login; there is no free public training library, and a terminal training mode is not documented. https://www.qubeyond.com/support · retrieved 2026-08-01
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
Qube is marketed with "triple redundancy"; automatic promotion of a terminal to master on primary failure is not documented. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-01
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
'cellular' occurs zero times in the corpus and every apparent 'LTE' hit is a substring of ordinary words ('alternative', 'ultimate'). Qu's connectivity story is that the store keeps running locally when the internet drops ('System state is preserved locally,' 'Sync resumes automatically'), which describes surviving the outage rather than an alternate WAN path. A vendor-documented LTE failover would normally appear in a network-requirements or store-install document, a class of document Qu publishes nowhere publicly, so the marketing silence does not settle whether such failover is offered. || 326th: NEW SURFACE (326th): Qu's own operator KB, recovered whole from Wayback and never read by prior passes for this cell - 210 distinct support.qubeyond.com/hc/en-us/articles/* ids in the CDX index, 205 bodies fetched at 200 (498 KB of text), covering both product generations (First Gen 2.0 and Next Gen 3.5) plus the v139/v140/v141/v142 release notes; and the 53 vendor PDFs those articles embed from Google Drive (169 KB of text), including the 56-page 'Gusto(R) Enterprise Intelligence Guide v1.8.0.67' - the full back-office admin manual, with a chapter/section table of contents for every configuration screen - and the 5-page Qu Reporting Guide. The four Google DOCS embeds (Qu 3.5 POS User Guide, 3.5 EI Guide, 3.5 Reporting Documentation, the v139 detail doc) now return 401, sharing revoked, so those four are unrecoverable. This corpus is a 2018-2021 floor for a RETIRED Zendesk KB (support.qubeyond.com now 302s to a gated Document360), so under merge policy no `no` rests on it; it is recorded as measured evidence, not as a census. It covers the STORE-LEVEL POS and the EI back office, not Qu's current cloud product. CLAIM: terminals support an automatic cellular/LTE failover for connectivity, first-party or documented. VERDICT unknown. EVIDENCE: tokenised `cellular`, `LTE`, `4G`, `hotspot` = 0 across the 205 articles and the 53 PDFs (`Wi-Fi` = 2, both incidental). Qu's own troubleshooting treats the store link as a single wired path: 'What Happens if My Store Loses Internet? (Next Gen)' instructs that 'if the EMV reader does not process transactions while offline, you may need to manually disconnect the terminal from the internet by unplugging the Ethernet cable', and 'Is My Terminal Online?' describes a binary Online/Offline indicator with no alternate-WAN state. A documented automatic failover would have to appear in exactly these two articles. Retrieved 2026-09-18. || 331st: MERGE HOLD (proposed no/C, held unknown): 331st merge: Qu's 'three layers of redundancy' list is marketing copy (grade C) about DATA-PATH redundancy (peer-to-cloud, peer-to-peer, in-store cloud), not an enumeration of the store's connectivity options; a network-uplink LTE failover is a different layer that such a list need not mention. 'Never affirmed' is not a capability `no` (329th rule). PROPOSAL AS WRITTEN: CLAIM: terminals support an automatic cellular/LTE failover for connectivity, first-party or documented. VERDICT: no/C - WEAKEST ROW, flagged. NEW SURFACE (331st): the CURRENT resource centre of the rebuilt www.qubeyond.com, fetched whole (211 of the 248 sitemap URLs: 198 /resource-center/ + 13 /case-studies/, 209 x 200, 2 x 301), which the 327th census did not fetch (it took the 39 core pages). Qu publishes a CLOSED ENUMERATION of how a store stays up when connectivity fails, and no alternate WAN path is in it. EVIDENCE: 'Solving for In-Store Stability with Edge Computing' (updated November 2025): 'Operational continuity is bolstered with three layers of redundancy: Peer to Public Cloud: Every terminal and in-store device connects independently to the public cloud ... Peer to Peer: Every terminal and in-store device is connected to and shares check and order data with each other ... Peer to In-store Cloud: Every terminal is connected to an in-store cloud'; 'How Edge Computing is Revolutionizing Restaurant Tech': 'There are three layers of redundancy available in the commerce cloud model, to ensure restaurants stay online, even if network connectivity is lost. Each terminal and client is connected to each other ... The in-store cloud communicates with the public cloud / Every client automatically switches to the above-store public cloud if needed'. The product pages state the same design: /platform 'No internet? No problem. Stability is ensured through triple redundancy, uninterrupted operations with offline mode'; /qu-business-edge 'keeping your operations running ... even when the internet is down'. Qu's answer to WAN loss is local/offline operation on the Qube edge hub, not a second uplink. BOUND/CONTROLS: tokenised, word-boundary, case-insensitive over the 211 resource-centre/case-study pages + the 39 core pages (250 files): `cellular` 0, `LTE` 0, `4G` 0, `5G` 0, `SIM card` 0, `modem` 0, `hotspot` 0, `Cradlepoint` 0, `backup internet` 0, `secondary internet` 0, `wireless backup` 0; KNOWN-POSITIVE controls fire (`offline` 28, `redundancy` 41, `failover` 3 - all three `failover` hits are the three-layer enumeration or a buyer's-guide question, none a WAN path). POISON named: the prior note's 'LTE' hits inside 'alternative'/'ultimate' are why the control is word-bounded. WEAKNESS stated plainly: marketing/blog pages are grade C, and the enumeration answers 'how does the POS survive WAN loss', not 'can a terminal fail over to cellular'; an operator-supplied LTE router is outside the claim ('first-party or documented') and nothing Qu publishes documents one. If the merge treats this as 'never affirmed', hold unknown. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACE, not settling (and not re-proposing the 331st no): Qu's own franchisee FAQ answers 'Is Qu Cloud-based? What does this mean when the internet goes out?' with 'Qu is "Cloud-Deployed", not Cloud-Dependent. Qu has multiple layers of redundancy built into its platform, both in the cloud and on-premises ... The "EMV" payment terminals support "Store and Forward" ... The Qu POS terminals continue to operate without the internet' (https://go.qubeyond.com/taco-johns-faq) - again an offline-operation answer with no alternate uplink named; `cellular`/`LTE`/`4G`/`hotspot`/`backup internet` = 0 across the 52 go.qubeyond.com landing pages and the 2025 Business Edge one-pager ('Triple redundancy, offline mode, and smart cloud stability keep you live, even in outages'). Also new (333rd): Qu's YouTube channel @qubeyond, 86 uploads listed by yt-dlp; captions pulled for 54 (1.27 MB; the other 32, incl. the six 'Qu | Product Feature' demos, were IP-blocked/429 by YouTube this session). `cellular` 0 and `LTE` 1 (a VC guest describing smartphones) in those captions. Retrieved 2026-09-18. adversarially verified
Commercial, compliance & data ownership
Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator
commercial-month-to-month-contract
CLAIM: vendor publicly offers a month-to-month subscription with no minimum multi-year term for its core POS software tier. VERDICT: no/C (moved off unknown). NEW SURFACE (333rd): Qu's HubSpot LANDING-PAGE estate on go.qubeyond.com, found by sweeping HubSpot site search (`/_hcms/search?term=<w>&type=LANDING_PAGE`, 50 terms incl. stopwords, all offsets) - 52 live landing pages, most never in the Wayback CDX the 331st used (238 rows, 25 slugs); all 52 fetched at 200 and grepped, plus 6 hubfs PDFs they link (OrderUpFlyer.pdf, 'Qu Energy & Equipment Intelligence 10.2025.pdf', 'Qu OnePage Qu Business Edge 11.2025.pdf', and the Restaurant Models / Rise-Fall / Third-Party e-books). Among them are FRANCHISEE-facing pages never read by any pass: /taco-johns-faq (a Qu-authored contract FAQ for Taco John's franchisees, sibling of the 'Taco John's Conference 2022' pages), /churchs-pos-incentive-program (2022) and /dq-connect-conference-2026. Vendor-authored marketing host = grade C. EVIDENCE: the 325th hold was that the Third Party Terms' 'Initial Term' was a dangling reference of unknown length. Qu has now published that length itself, verbatim on https://go.qubeyond.com/taco-johns-faq: 'What is the term of the contract? Is the hardware really free? What happens after 5 years? The initial term of the contract is 5 years. Qu is providing an extremely aggressive offer to the Taco John's community ... provided you sign up for and install the Qu solution this year. There are several potential options for the end of the initial term of the contract ...'. Corroborating (same host): /churchs-pos-incentive-program: 'Sign the Qu Sales Order by 1/31/22 ... Begin receiving a $250 service credit for the first 12 months of service'; /dq-connect-conference-2026: 'Contract directly with Qu / DQ Corporate-negotiated pricing'. So every core-POS commercial statement Qu publishes is a negotiated, sales-order, multi-year (5-year initial) term with renewal, consistent with /third-party-terms 2.2 ('After the Initial Term ... renewal term'). COUNTER-EVIDENCE, stated so it is not missed: the 2020 COVID 'OrderUP' flyer (go.qubeyond.com/hubfs/OrderUpFlyer.pdf) says 'No annual contracts. No hidden fees. Enjoy the product and services at no charge for 90 days (thru July 31)' - but OrderUP was 'a dedicated online-only, all-digital POS product' that 'requires no hardware and no changes to your current technology' with orders 'routed to stores in real-time via email', i.e. a retired 2020 online-ordering promotion, not the core POS tier. CONTROLS over the 52 pages + 6 PDFs: tokenised word-boundary `month-to-month` 0, `cancel anytime` 0, `no (annual) contract` 1 (= the OrderUP flyer line quoted above); `contract` 6, all in the FAQ/DQ passages quoted; KNOWN-POSITIVE control `redundan*` 9 fires. Videos: `month-to-month` 0 in the 54 caption files (1.27 MB) of Qu's YouTube channel; the 9 `contract` caption hits are podcast guests talking about their own vendors. WEAKEST PART: the 5-year term is stated for one franchise system's program (2022); a merge that wants a general published term sheet should hold. Retrieved 2026-09-18. https://go.qubeyond.com/taco-johns-faq · retrieved 2026-09-18 adversarially verified
Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator
commercial-no-early-termination-fee
Same underlying fact as the already-scored commercial-autorenew-terms-published: re-fetched the privacy policy directly, the only legal document Qu publishes, and it explicitly states "This Privacy Policy does not apply to: Information processed on behalf of our customers through Qu products and services, where separate contractual terms may apply" — confirming no MSA, ToS, or order-form terms are publicly posted anywhere on qubeyond.com. A published term stating no early-termination fee cannot exist because no published contract terms exist at all. https://www.qubeyond.com/privacy-policy/ · retrieved 2026-08-04
The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.
commercial-autorenew-terms-published
No publicly accessible MSA, terms of service, or order-form terms exist on qubeyond.com; the website privacy policy explicitly excludes platform/customer data terms. https://www.qubeyond.com/privacy-policy/ · retrieved 2026-08-01
The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator
commercial-processing-not-bundled
Verified verbatim on the online-ordering page: 'Whether you use Qu Pay or an integrated provider, third party loyalty or Qu's built-in discounts...' — vendor-stated processor optionality, corroborated by FreedomPay and WorldPay appearing as live status-page components. https://www.qubeyond.com/ordering/online-ordering · retrieved 2026-08-01 adversarially verified
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
No processing rate of any structure is published. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-01
The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator
commercial-rate-increase-clause
Same fact as commercial-no-early-termination-fee: no processing agreement or any commercial terms are publicly posted (privacy policy re-fetched and confirms the scope exclusion for customer/product terms), so no published clause capping or prohibiting unilateral rate increases, or granting penalty-free exit on an increase, can exist. https://www.qubeyond.com/privacy-policy/ · retrieved 2026-08-04
Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).
commercial-pricing-published
Quote-only. No pricing page exists; the site routes all commercial inquiries to a demo request form. https://www.qubeyond.com/get-a-demo · retrieved 2026-08-01
Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator
commercial-module-unbundling
There is no published pricing, no module SKU list and no subscription agreement — the site T&Cs govern website use only and the Adyen document covers payments. The one page that would carry an enumeration, /modules, is an unfinished template: its body is repeated 'Placeholder Name / Placeholder Job Title' blocks around a single generic paragraph, with no module list at all. Whether modules can be bought and cancelled independently without repricing the base subscription is unmeasurable from Qu's public surface. || 327th: NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. NEW SURFACE (327th), still unknown: /modules has been REBUILT and is now a 23 KB page (it was 443 KB in the 325th corpus), and the rebuilt site publishes no price, plan, SKU or packaging table anywhere in its 248 URLs. What it does publish argues against a la carte purchasing without settling it: /build-buy-or-both frames Qu as the alternative to piecing modules together ('One tool for ordering, one for loyalty, one for menus... Five vendors cost five subscriptions plus the integration work, renewal negotiations, and API risk'), and /payments/qu-pay sells the opposite of unbundling -- 'one platform, one team, and one agreement, not a separate processor bolted onto the POS'. Tokenised `a la carte` 0, `add-on` 0 as a SKU, `bundle` 0 as pricing, `per location per month` 0. Positioning is not a commercial term, so the cell is held. Retrieved 2026-09-18. || 328th: NEW SURFACE (328th): the current admin ships a 50-entry per-tenant ENTITLEMENT REGISTRY, `FeaturesObj`, read through a `features/isEnabled` getter that hides whole navigation sections. Entries include EI-V2-Reporting, EI-ReportsItemGroupRatios, EI-V2-Inventory, EI-V2-TipPooling, EI-TipPooling, EI-LaborSchedule, EI-ShiftSchedules, EI-V2-ShiftSchedules, EI-V2-DigitalChannels, EI-BulkMenuRefreshOLO, EI-OloDigitalChannelMenuSync, EI-ProductionForecastBoard, EI-KDSBulkBoard, EI-StoreInstallations, EI-QuBoxDiagnostics, EI-PriceImportTool, EI-ArchiveStores, EI-MenuPreview, EI-ShowVersioningMenuToggle. So modules ARE switched on per tenant. Second new surface: gtf.portal.qubeyond.com, a Qu-operated Softr portal titled 'Qu Resource Manager' for the GoTo Foods estate, whose public page config carries an 'Add-On Hardware/Software' page with the request tabs 'Change | Add-On | Transfer | Return', a 'Request Sales Order' button and a 'What is Plan for Hardware?' selector (Hardware Management / Hardware Transfer / Hardware Return); the records behind it are gated (Airtable) and were not read. Both show mid-term ADD, neither shows independent CANCELLATION without repricing, and per the 323rd rule a flag name is not a priced SKU - no price, plan or SKU list exists on any Qu surface. Held unknown. Retrieved 2026-09-18. || 333rd: 333rd NEW SURFACES, not settling: (1) go.qubeyond.com/dq-connect-conference-2026 sells ONE Qu module on its own contract to Dairy Queen franchisees: 'Qu Energy & Equipment Intelligence ... Contract directly with Qu / DQ Corporate-negotiated pricing / Flexible for single or multi-unit operators', with its own sheet (hubfs 'Qu Energy & Equipment Intelligence 10.2025.pdf'); (2) the Qu Business Edge one-pager (hubfs 'Qu OnePage Qu Business Edge 11.2025.pdf') packages the edge appliance as a 'MODULAR INNOVATION PATH' of 'A Series (Maximum stability + uninterrupted service) / E Series (Smarter, more efficient facilities operations) / IQu Series (AI innovation ...)'. Both show separately contracted/packaged offerings, but the energy product is an IoT facilities add-on outside the claim's module list, and nothing states that a module can be cancelled without repricing the base POS subscription; no price or SKU list is published. Retrieved 2026-09-18. || 334th: CLAIM: modules can be bought a la carte and cancelled independently without repricing the base POS subscription. VERDICT: unknown (unchanged). 334th NEW SURFACE (none of the 331st-333rd opened it): customer-brand FRANCHISE DISCLOSURE DOCUMENTS on the Minnesota Commerce CARDS public registry (anonymous GET: https://cards.web.commerce.state.mn.us/franchise-registrations?doSearch=true&franchisor=<name>). 30 franchisor names searched (Qu customers named in Qu case studies/videos plus QSR peers); latest Clean FDD fetched for 27; 13 bodies read in full (Taco John's 2026-07 amendment, Blaze Pizza 2026, Dave's Hot Chicken 2026, Del Taco 2025, Saladworks 2026, Auntie Anne's, Cinnabon, Schlotzsky's, Jamba 2026, Sonic, Nathan's, Papa Murphy's, a Dairy Queen area developer); 14 returned empty bodies (throttled, a refusal, not an absence); Church's, Golden Chick, Freebirds, Jack in the Box, Hot Head, Rapid Fired are not MN-registered. Tokenised `Qu` names Qu in only TWO: Taco John's (operations-manual TOC 'Qu Point of Sales (POS) System/Kitchen Video System (KVS)', beside separate entries 'Decision Logic Back of House System', 'Olo Dashboard', 'Punchh', 'FlyBuy') and Blaze Pizza (Standards Guidelines TOC 'Qu (POS Training)'); Saladworks' hit is an officer bio ('Director of Operations for Qu POS'), and Papa Murphy's 5 hits are POISON (mis-encoded 'Québec' in MTY's address). An FDD is the FRANCHISOR's filing, i.e. third-party evidence about Qu (grade E at best), and neither FDD names Qu in the fee tables. What it adds: Taco John's runs Qu for POS + KVS only, while online ordering (Olo), loyalty (Punchh), curbside (FlyBuy) and back-of-house (Decision Logic, 'Currently, $145' per month, a separate fee row) are other vendors - so Qu's POS core is deployed WITHOUT Qu's own ordering/loyalty/BOH modules at a named customer. Item 11 prices the POS as 'a license fee currently in the amount of $475 to $750 per month depending on the number of terminals selected' (TJ FDD p.39, https://cards.web.commerce.state.mn.us/documents/%7B50C17F9F-0000-C21B-8DC2-FA5DF95B331E%7D/download?documentClass=FRANCHISE_REGISTRATIONS&contentSequence=0). Why it does not settle: that is one brand's negotiated deal disclosed by the franchisor; nothing shows Qu's own modules (Qu ordering, kiosk, Notify, Energy & Equipment) priced as separable SKUs or cancellable without repricing the base. Retrieved 2026-09-18. adversarially verified
All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.
commercial-hardware-purchase-outright
The claim requires purchase 'at a published price'. Qu publishes no prices at all: the POS page describes hardware only via 'Qu Business Edge (Qube)... the on-site intelligence hub in every restaurant' with no price, purchase, lease or rental term, qubeyond.com has no pricing page anywhere, and every path funnels to the get-a-demo quote form. Whether outright purchase is negotiable in a quote is unknowable, but the published-price condition is verifiably unmet, which fails the claim as worded. https://www.qubeyond.com/ordering/pos · retrieved 2026-08-04
Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator
commercial-hardware-not-locked
Qu's own help centre documents the product operating on third-party, non-proprietary hardware throughout: a 'Manual Transaction Guide for Ingenico IPP320' PIN pad (First Gen 2.0, March 2020); a 'Magtek MagneSafe Magnetic Stripe Reader Device' as the terminal MSR, whose driver the operator uninstalls and reinstalls from Windows Device Manager (Nov 2020); Touch Dynamic Acrobat Windows terminals with operator-serviceable SSD and MSR swaps; and ChefTab as the KDS, configured by the operator through 'Cheftab Settings/Preferences' ('How do I Prevent Bumping a Chit on the KDS?', Oct 2020). No Qu-branded terminal, printer or reader appears anywhere in the 210 archived articles. Corroborated live: ChefTab and Logic Controls both appear in Qu's certified-partner directory today, under Kitchen/KDS and Hardware + Digital Signage respectively. Vintage: First Gen 2.0 / Next Gen 3.5, 2020, with live partner-directory corroboration. https://web.archive.org/web/20200809113433/https://support.qubeyond.com/hc/en-us/articles/360040852811-Manual-Transaction-Guide-for-Ingenico-IPP320-First-Gen-2-0- · retrieved 2026-09-03
One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.
commercial-implementation-fee-published
No implementation, menu-build, or training fees published; Qu Pay claims onboarding timelines reduced up to 75% but states no cost. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-01
Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.
commercial-data-export-self-serve
A DataExport API exists as a platform component; self-serve export of full transactional history without a support ticket is not documented. https://status.qubeyond.com/ · retrieved 2026-08-01
Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator
commercial-export-customer-and-loyalty
Qu Reports Quick Guide (Next Gen 3.5, Oct 2020): the Customers report covers 'all customers and their information entered on the POS or the web ordering site... first name, last name, phone number, email address, last order date, total orders, the total dollar amount spent, and registration status', and every report can be 'exported (downloaded or emailed as either an Excel file, CSV, or PDF)' - so guest records are operator-exportable in machine-readable form. Shortfall: no loyalty point ledger or balance is exportable from Qu itself (loyalty in this generation is the third-party Punchh integration, whose 'LifetimePoints and totalActivePoints' live on Punchh's side per the v142 release notes), and while First Gen listed a Gift Cards report, no gift-card liability balance export is documented. Vintage: Next Gen 3.5, 2020. https://web.archive.org/web/20201128174707/https://support.qubeyond.com/hc/en-us/articles/360049022511-Qu-Reports-Quick-Guide-Next-Gen- · retrieved 2026-09-03
Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator
commercial-post-termination-export-window
Same underlying fact as commercial-no-early-termination-fee and commercial-rate-increase-clause: no contract or MSA is publicly posted anywhere on qubeyond.com (privacy policy confirms the scope exclusion and that separate, non-public contractual terms apply), so no publicly available document specifies a post-termination data-retrieval window versus an immediate cutoff. https://www.qubeyond.com/privacy-policy/ · retrieved 2026-08-04
Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator
commercial-data-ownership-clause
Third Party Terms 12.1: "Qu and Adyen may use de-identified and/or aggregated Transaction data solely for the purposes of creating, optimizing payment performance, and improving Adyen and Qu's products and services... In no event shall Adyen or Qu provide, sell, or otherwise disclose any de-identified and/or aggregated Transaction data to any third party (except as required by Applicable Law or the Scheme Rules)." The companion Adyen for Platforms Terms Qu publishes state at 9.1 "Each party remains the owner of all data made available to the other party." Shortfall: both clauses are scoped to payment-services transaction data only; the Master SaaS Agreement that would govern ownership of POS order, menu and guest records is not published, so no published Qu term states the merchant owns its full transaction and customer data. https://www.qubeyond.com/third-party-terms · retrieved 2026-09-03
The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).
commercial-source-available-selfhost
Proprietary, closed-source, vendor-hosted cloud plus vendor-supplied Qube edge appliance. No source or self-host option. https://www.qubeyond.com/platform · retrieved 2026-08-01
Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.
commercial-pci-p2pe-tokenization
Fetched the Qu Pay page directly: no validated P2PE or hardware-encrypted card-entry-plus-tokenization claim is made, and no SAQ type (A / P2PE-HW) is named anywhere on qubeyond.com. Same finding as hardware-p2pe-terminal. https://www.qubeyond.com/payments/qu-pay · retrieved 2026-08-04
Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.
commercial-pci-dss-4-controls
Fetched the Qu Pay, platform, and Qu Business Edge pages directly: none documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — no MFA-for-cardholder-data-environment statement covering POS/back-office logins, and no payment-page script-integrity monitoring statement. https://www.qubeyond.com/qu-business-edge · retrieved 2026-08-04
Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.
commercial-soc2-attestation
Fetched the platform page directly: it describes unified commerce, kitchen orchestration and enterprise management with no SOC 2 Type II or ISO 27001 attestation claim, and no trust-center link exists anywhere on qubeyond.com to request a report under NDA. https://www.qubeyond.com/platform · retrieved 2026-08-04
Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.
commercial-privacy-dsar-tooling
Conjunctive claim requiring in-app DSAR tooling PLUS 'a published DPA the operator can execute'. No DPA is published: the complete legal set is three documents (site terms of use, privacy policy, Adyen-for-Platforms T&Cs) and /dpa, /data-processing-agreement, /data-processing-addendum, /legal/dpa, /gdpr and /ccpa all 404 (probed 2026-09-04); the Adyen document's only privacy clause (9.2) allocates roles between Adyen and the merchant and cites Adyen's Privacy Statement. The privacy policy expressly excludes the product data plane from its own scope — 'Information processed on behalf of our customers through Qu products and services, where separate contractual terms may apply' — i.e. Qu locates guest-data processing terms in an unpublished contract. Request handling is email-only: 'To exercise any applicable privacy rights, please contact us using the information in Section 16.' The published-DPA conjunct fails, so the compound claim is not met; the in-app-tooling conjunct is separately unmeasured behind the gated customer portal. https://www.qubeyond.com/privacy-policy · retrieved 2026-09-04 adversarially verified
Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator
commercial-wcag-kiosk-accessibility
Kiosk page claims software accessibility features (audio output, adjustable screen interaction) "to support ADA compliance requirements"; no VPAT/ACR or WCAG 2.1 AA conformance claim is published. https://www.qubeyond.com/ordering/kiosk · retrieved 2026-08-01
POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator
commercial-dual-pricing-compliant
NEW SURFACES (327th), and this cell was never individually checked against the corpora later passes built. (a) www.qubeyond.com HAS BEEN REBUILT and was re-censused 2026-09-18 to an href fixpoint: sitemap.xml now lists 248 URLs, the 39 non-resource-centre pages were fetched at 200 and every qubeyond.com href inside them is already in that set. No new legal instrument exists -- /terms-and-conditions is a WEBSITE terms of use ('before using our website'), and the only other legal pages are /privacy-policy, /third-party-terms and /adyen-for-platforms-terms-and-conditions; /legal, /msa, /eula, /sla, /dpa, /master-services-agreement, /subscription-agreement, /hardware-terms, /support-terms and /security all 404. New product pages are /qu-business-edge (Qube edge appliance), /platform, /build-buy-or-both, /payments/qu-pay and /pci-dss-compliance-guide. Marketing = grade C. (b) The admin.qubeyond.com Nuxt chunk census from the 324th (177/177 loader entries, 175 chunk files, 24.4 MB) was RE-GREPPED per cell. This is Qu's CURRENT Enterprise Intelligence back office and it is grade B production code; it bounds the BACK OFFICE, not the store-level POS. (c) The 326th's retired-generation operator KB (205 Wayback articles + 53 Drive PDFs) was re-walked for POSITIVES only; under owner policy no `no` rests on it and a positive from it carries at most partial. (d) Host probe 2026-09-18: order, order-online, pos-config, qu-api, qu-api-prod, qu-pos-api, reports, ei, dashboard.qubox, configurations.qubox, gateway.qubox, drp, ops, int, sst, kiosk, kds, notify .qubeyond.com x {/, /swagger/index.html, /swagger/v1/swagger.json, /openapi.json, /v3/api-docs, /api-docs, /docs, /graphql, /sitemap.xml} -- all 000 (no DNS/TLS) or 404. admin.qubeyond.com/swagger/v1/swagger.json is a genuine 404 (22 bytes, application/json), not an SPA shell. developers.qubeyond.com, developer.qubeyond.com and docs.qubeyond.com do not resolve: Qu publishes no developer portal. CLAIM: POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. VERDICT no. EVIDENCE/BOUND: the pricing and fee configuration for Qu's POS lives in the EI back office, and that app is censused 177/177. Its fee object is generic and card-blind -- the i18n dictionary carries 'Add Fee', 'Fees', 'Search Fees by Title' and price machinery ('Price Groups', 'Only Fixed Prices will be exported', 'Update Gross and Net Sales', 'Convert to computed prices') with no card-type, BIN, network-cap or disclosure field anywhere. Tokenised `cash discount` 0, `non-cash` 0, `BIN` 0 as a card term, `debit` 0 as a card type, `prepaid` 0. CONTROL POISON WORTH PUBLISHING: a naive substring `dualPric` scores 16 hits in this bundle and every single one is inside the identifier `individualPriceToSchedule` / `individualPriceToScheduleWatcher` -- the scheduled-price-change modal. Tokenised, real dual-pricing hits are 0. The rebuilt marketing site is also 0 (its 6 `surcharg` hits are Adyen scheme-fine language and the Australian surcharging restriction inside /adyen-for-platforms-terms-and-conditions, which RESTRICTS the user rather than describing a Qu feature), and the retired operator KB's 4 hits are a 2016 Vantiv statement glossary ('Surcharges are downgrades'). Retrieved 2026-09-18. https://admin.qubeyond.com/ · retrieved 2026-09-18 adversarially verified
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 101 values — 67 upheld, 34 downgraded, 0 upgraded. It separately resolved 110 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Pricing and identity
| Field | Verdict | What the verifier found |
|---|---|---|
| pricing.software | upheld | Confirmed: no pricing page exists on qubeyond.com and the POS page carries no pricing information. All commercial paths route to a demo request. source |
| pricing.processing_rate | upheld | Fetched the Qu Pay page and asked specifically for rates/bps/fees: no dollar figure, no bps, no interchange structure. The only quantified claims on the page are '65% of transactions leave no usable guest identity behind' and 'reducing onboarding timelines by up to 75%'. Correctly unknown. source |
| pricing.contract_length | upheld | No MSA, ToS, or order-form terms are publicly reachable; nothing found to contradict unknown. Any third-party roundup asserting a Qu term length should be rejected as evidence. source |
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| kitchen-order-throttling | yes / claimed | downgrade-to-unknown | I fetched the cited KDS page twice and asked directly: throttling, kitchen-capacity management, and a 'global kitchen dashboard' are NOT PRESENT on it. The page's actual content is cross-channel order management, rules-based routing, fire modes, and real-time item-state sync. The researcher's quoted capability ('manage and throttle orders based on kitchen capacity') does not appear at the cited URL. A 'yes' on a differentiator resting on text I cannot find in the source is a fabrication risk. source |
| order-capture-throttling | partial / claimed | downgrade-to-unknown | Same defect: sourced to the KDS page, which contains no throttling or capacity language when fetched. source |
| digital-scheduled-pacing | partial / claimed | downgrade-to-unknown | Rests entirely on the same unverifiable KDS throttling sentence. No per-slot capacity, no order pacing, and no scheduled-order surface is documented anywhere on qubeyond.com. source |
| reliability-offline-card-auth | partial / claimed | downgrade-to-unknown | Flip cell, highest bar, and the evidence is one marketing sentence ('Ordering, payments, and kitchen routing continue uninterrupted during connectivity outages'). The Qu Business Edge page adds only 'Full transaction processing continues' with, in its own words, no offline payment detail. Nothing states card AUTHORIZATION occurs offline — 'payments continue' is equally consistent with cash/tender capture. No floor limit, no cap, no store-and-forward mechanism, no liability owner. Also note offline SAF is a processor capability (FreedomPay/WorldPay/Aurus), not necessarily Qu's, so the vendor sentence cannot even establish who provides it. Qu Pay's own page publishes nothing on offline behavior. source |
| payments-offline-store-and-forward | partial / claimed | downgrade-to-unknown | Identical single marketing sentence, restated. No store-and-forward mechanism, retry policy, cumulative cap, or reconciliation flow is documented; I confirmed the Qu Pay page contains no offline or store-and-forward language at all. source |
| reliability-offline-kds-printing | yes / claimed | downgrade-to-partial | Offline kitchen ROUTING is affirmatively claimed and I verified the wording. Offline kitchen PRINTING is nowhere stated — Qu publishes no printer-fallback or impact-printer behavior at all (the dossier itself scores kitchen-printer-fallback and reliability-printer-fallback unknown, which contradicts a 'yes' here). source |
| order-capture-voice-ai | yes / claimed | downgrade-to-partial | The drive-thru page says verbatim: 'Qu's open Intelligent Commerce Platform integrates with AI voice-ordering partners — including ConverseNow and Presto.' That is an explicit third-party integration, not a Qu capability. The researcher's own note concedes 'third-party, not first-party' and then scored it yes anyway. source |
| hardware-remote-device-management | yes / documented | downgrade-to-partial | The note claims 'Qu Pay cites remote device management and nightly updates' — I fetched the Qu Pay page and it contains no device-management or nightly-update language whatsoever. The only real evidence is a status-page component literally named 'Esper KDS Device Management', i.e. a third-party MDM (Esper) scoped to KDS devices, not a Qu first-party fleet-management product covering POS/kiosk/drive-thru. source |
| payments-refund-void-controls | partial / claimed | downgrade-to-unknown | Sourced to the Channel Management page, which I fetched: it says 'Role-based permissions for secure operational control' and nothing about refunds, voids, approvals, or thresholds. Generic RBAC boilerplate is not evidence of refund/void controls. source |
| order-capture-void-comp-controls | partial / claimed | downgrade-to-unknown | Sourced to Brand & Franchise Management, which lists only 'Granular permissioning and user administration'. I confirmed the page never mentions voids, comps, discretion limits, or reason codes. source |
| menu-pricing-channel-price-books | yes / claimed | downgrade-to-partial | The strongest verbatim on the cited page is 'Delivery orders may carry a fee surcharge, while kiosk may feature upsell-only items.' A delivery fee surcharge and channel item visibility are not an item-level price book per channel. Directionally right, but a 'yes' on marketing illustration rather than a documented pricing model overstates it. source |
| multi-location-price-zones | yes / claimed | downgrade-to-partial | This is the researcher's own two-step inference ('dynamic store groupings' + 'channel-specific pricing' therefore price zones). Neither cited page documents assigning a price to a location group. Inference stacking is not documentation. source |
| reporting-nl-query | yes / claimed | downgrade-to-partial | Verified verbatim is a single marketing line: 'Operate hands-free with simple voice commands and surface insights through an AI chatbot.' No product documentation, no examples of queries, no scope of data addressable. Marketing copy for an AI feature is the single most inflated category in this space; a 'yes' needs docs. source |
| labor-clock-in-at-pos | partial / claimed | downgrade-to-unknown | The only support is a feature bullet 'Employee and labor management tools' on a franchise marketing page. There is no labor product in Qu's enumerated catalog (I confirmed the products page lists Ordering, KDS, Order Status, Energy & Equipment Intelligence, Qu Pay, Menu Management, Channel Management, Brand & Franchise Management, Notify, Data & Reporting — no labor), and scheduling/payroll are partner-delivered. Nothing establishes a POS time-clock punch flow. source |
| labor-realtime-labor-percent | partial / claimed | downgrade-to-unknown | Notify's verified text is 'Stay on top of sales, labor, and operational metrics'. Labor as a percentage of sales, in real time, is not named — and with no native time-clock evidence, the punch data source for such a metric is itself undocumented. source |
| delivery-daas-dispatch | partial / claimed | upheld | Verified verbatim 'Flexible fulfillment options including in-store, curbside, tableside, and white-label delivery.' No courier network is named, no quote/assign/status contract is documented. Partial is the ceiling; do not let anyone read this as native dispatch. source |
| delivery-driver-roster | no / inferred | upheld | Normally I would push 'absent from a marketing catalog' back to unknown, but here the products page enumerates the complete product set with no delivery/driver module AND the online-ordering page affirmatively enumerates the alternative fulfillment path ('white-label delivery'). That clears the bar for a documented absence. Same reasoning carries the sibling delivery-dispatch-board / route-map / driver-tracking / driver-comp / cash-reconcile 'no' scores. source |
| menu-pricing-fractional-placement | unknown | upheld | Independently searched for Qu pizza/fractional/half-and-half configuration including via the Blaze Pizza case study and press coverage. Nothing on placement, per-section pricing, or fractional toppings exists publicly. Unknown is correct — and notably Qu runs Blaze Pizza, so the capability may well exist behind Qu Campus; the honest answer is that it is undocumented, not absent. source |
| menu-pricing-half-and-half-rule | unknown | upheld | Same search; no public evidence either way. Do not let the vs_reference narrative harden 'undocumented' into 'absent' — Qu counts Blaze Pizza as a reference customer, which is affirmative reason to doubt a flat absence. source |
| multi-location-royalty-calculation | unknown | upheld | Fetched Brand & Franchise Management in full: royalties are never mentioned. Franchise 'management' here is brand-standards and permissioning, not franchise financial administration. Unknown, correctly. source |
| extensibility-order-injection-api | yes / documented | upheld | I could NOT load qu-pos-api.qubeyond.com myself — it fails TLS with an Azure wildcard mismatch (cert altnames *.azurewebsites.net), which I independently reproduced. However the search index surfaces the doc text directly: 'Qu provides REST API for 3rd party ordering applications to place orders in Qu POS systems ... orders will be saved in the database and POS systems in stores pull online orders', and third parties (Zuppler, 7shifts) ship live Qu connectors. Yes stands, but flag it as pull-model order injection only, not a general open API. source |
| extensibility-oauth-partner-apps | no / documented | upheld | Corroborated the indexed doc text: 'if an endpoint requires an API Key, the header APIKey=[string] should be present in the Request.' Static shared-secret header, no OAuth, no operator-granted revocable scopes. source |
| extensibility-doordash-preferred | yes / documented | upheld | Verified at DoorDash's own newsroom: 'The 2026 cohort DoorDash Preferred Integration Partners include Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, and UrbanPiper.' Caveat the dossier does not: DoorDash's page names NO rating tiers, so Qu's 'first POS rated Excellent' remains a vendor claim, and the dossier repeats it as fact in best_at and in two score notes. source |
| delivery-86-sync | yes / documented | upheld | I verified the program requirements page independently: Preferred partners 'must support all of the following features' including real-time menu syncing, real-time 86ing, order ready signal, item polling, and detailed error reporting, with 'supporting' defined as built, launched, and used by at least one live store. Membership therefore is real evidence. Scope caveat: it evidences these capabilities on the DoorDash channel only, not platform-wide. source |
| order-capture-order-ready-signal | yes / documented | upheld | Same DPIP mandatory-feature list, plus Order Status is an independently enumerated first-party product on Qu's catalog page. Both legs check out. source |
| commercial-processing-not-bundled | yes / documented | upheld | Verified verbatim on the online-ordering page: 'Whether you use Qu Pay or an integrated provider, third party loyalty or Qu's built-in discounts...' — vendor-stated processor optionality, corroborated by FreedomPay and WorldPay appearing as live status-page components. source |
| guest-loyalty-accrual-models | no / documented | upheld | Strengthened: beyond the Paytronix releases, Qu's own online-ordering page says 'third party loyalty', and loyalty is absent from the enumerated product catalog. Documented absence, not merely undocumented. source |
| multi-location-multi-currency-locale | yes / claimed | upheld | Verified verbatim on the POS page: 'Accept US Dollars, Canadian Dollars and Mexican pesos, with seamless conversion and unified reporting.' Specific and on point. source |
| digital-kiosk | yes / grade D, cites qubeyond.com/ordering/kiosk | downgrade-to-partial | A differentiator yes at grade D. I went looking for the grade A/B source that would repair it and there is none: support.qubeyond.com ('Qu Campus') 302s to a Document360 login, and qu-api.qubeyond.com and qu-pos-api.qubeyond.com both return 403 behind a mismatched Azure TLS certificate (/swagger/index.html and /swagger/v1/swagger.json included); docs.qubeyond.com, developer.qubeyond.com and api.qubeyond.com do not resolve. The strongest independent evidence I could locate is Kiosk Marketplace's 2025-08-21 report, which corroborates that the kiosk ships and names Taco John's and WOWorks as adopters - but it also makes clear the kiosk is a guest-facing MODE of the Flex POS terminal, not a separate kiosk product, and that ADA support is screen-reader software only. Real capability, materially narrower than a yes. source |
| kitchen-course-firing | yes / grade D, cites the KDS page for 'fire on tender, fire on next, fire on fly, manual fire/suspend' | downgrade-to-unknown | I re-fetched the KDS page and asked it directly about coursing: the words coursing and course firing do not appear anywhere on it. The four fire modes the researcher quoted are order-level triggers for when a ticket hits the line, which is a different capability from sequencing an order into courses and holding the later ones. Nothing was found that lets a server or the system release course two after course one is cleared. Qu's own POS page independently says the product is 'not designed for single-location restaurants or table-service concepts' - coursing is a table-service construct - which cuts against the claim rather than for it. This is the researcher reading an adjacent feature as the claimed one. Unknown, not no: no source enumerates firing behaviour exhaustively enough to assert absence. source |
| kitchen-guest-ready-notification | yes / grade D, cites the Order Status page | downgrade-to-partial | The page does support more than nothing: Order Status renders 'placed, in-prep, and ready' and pulls 'state changes directly from Qu KDS', with co-branding, orientation and multilingual layout options. But I asked the page specifically for SMS, text, push and order-ready alerts and found none - the entire mechanism is an in-store screen the guest has to be standing in front of. A guest-ready NOTIFICATION claim carried by a display board is partial with a named shortfall, and with no documentation portal reachable there is no grade A/B source that could lift it back to yes. source |
| kitchen-offline-operation | yes / grade D, cites qu-business-edge for local kitchen routing during outages | downgrade-to-partial | The Business Edge page is more specific than most of Qu's marketing - it names 'POS, payments, order routing, and kitchen workflows' as executing on-site, claims 'system state is preserved locally' and 'sync resumes automatically with no manual intervention'. What the researcher did not carry across is that all of it is predicated on the Qube on-premise appliance, marketed as a separate Qu Business Edge offering whose packaging and price Qu does not publish; the claim is therefore conditional, not a property of the platform. Nothing describes KDS queue behaviour, bump-state retention, or reconciliation on reconnect. Note the prior pass already downgraded reliability-offline-card-auth to unknown on this same page, so it is not a page that survives scrutiny well. source |
| multi-location-multi-brand | yes / grade D, cites the online-ordering page for 'multi-brand and virtual-brand support with custom subdomains, brand-level configuration and separately reportable revenue' | downgrade-to-partial | Two of the three specifics in the researcher's note are not in the cited source. I fetched the online-ordering page and asked for each: it says 'Manage multiple brands under one parent with custom subdomains and branding' and nothing else - no virtual brands, no separately reportable per-brand revenue. I then fetched the dedicated brand & franchise page, which is the better source and which I have substituted: 'Operate every brand and location from a single system' and a 'master control layer to enforce brand standards while franchisees can manage local overrides within approved parameters'. That is genuine and consistent with Qu's enterprise ICP, but it is a vendor feature page describing an outcome, with no hierarchy model, no scoping rules and no per-brand reporting evidenced. Partial. source |
| reporting-anomaly-alerts | yes / grade D, cites the Qu Notify page | downgrade-to-partial | The quoted sentence does check out verbatim - Qu Notify 'pushes AI-powered alerts on sales anomalies, service-time thresholds, equipment issues, the real-time Kitchen Intelligence Score, and other configurable operational exceptions'. So this is not a fabrication, it is a grading failure. What is absent is everything that would make it a fact rather than a claim: no threshold configuration UI or mechanism, no definition of anomaly (no baseline, sensitivity or comparison window), no statement of whether Notify is bundled or separately licensed, and an unsourced '30-50% faster issue resolution' benefit figure sitting alongside forward-looking AI-chatbot and predictive-analytics language. With no documentation portal reachable, grade D is the ceiling and a differentiator yes cannot rest there. source |
| reporting-multiloc-drilldown | yes / grade D, cites unified-data-reporting for 'multi-brand, multi-location reporting with location and daypart comparison' | downgrade-to-unknown | I fetched the page and asked it separately about drilldown, brand comparison and daypart comparison. Daypart and location COMPARISON are there - 'compare performance across locations, dayparts, and channels in one view'. Drilldown is not: nothing describes moving from a group or region roll-up down into a single store, which is the capability this claim names and a different thing from a side-by-side comparison view. Brand comparison, which the researcher's note also asserted, is not addressed on the page at all. The page does not even enumerate report types. Consolidated reporting exists; the named drilldown does not survive, and with Qu Campus login-gated and the API doc hosts 403 there is nowhere left to check. source |
| labor-tip-distribution-audit-trail | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Claim sweep of a never-examined cell. 7shifts' 'Tip Pooling for Qu POS' doc (updated 2026-06-24) states 'Qu automatically transfers sales, payment, and tip information to 7shifts' and requires 'user assignments to orders/sales in Qu POS' — per-employee tip capture exists in Qu, but pool contribution/distribution rules, reports and payroll export are performed in 7shifts' separately licensed Tip Pooling module, not in Qu. The article HTML is bot-gated (403); the body was read via the site's public Zendesk article API for the same article id. source |
| payments-offline-decline-liability | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Claim sweep of a never-examined cell. The claim tests whether the vendor PUBLICLY documents offline-decline loss allocation and a post-reconnect failure report. Qu's public offline-payments surface was read directly: the Qu Business Edge page promises 'Full transaction processing continues' offline with 'Sync resumes automatically with no manual intervention', and the edge-computing blog post touts 'offline payment acceptance' — neither addresses who bears a decline on reconnect or any failed-offline-payments report. The help centre is login-gated (support.qubeyond.com 302s to a Document360 login) and no public MSA/ToS exists (per record). The public documentation the claim requires does not exist; this is a finding about public documentation, not about the product's internal behaviour. source |
| guest-loyalty-referral-program | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Claim sweep of a never-examined cell. Qu's products page enumerates the complete module line-up (five ordering products, three kitchen products, Qu Pay, five management products) and no loyalty product is among them; the partner directory carries a 'Loyalty' category and Qu's announcements name Thanx, Paytronix and LevelUp as the loyalty layer. A native referral mechanic with per-guest codes and two-sided rewards presupposes a native loyalty program Qu does not ship — the docs enumerate the alternatives and this is not among them. source |
| labor-break-compliance-by-state | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Claim sweep of a never-examined cell. Qu ships no workforce module: the products page enumerates the full line-up with nothing for labor, scheduling or time-and-attendance, and Qu's own partner directory delegates the category — 'Back of House + Labor' lists 7shifts and Altametrics. Per-jurisdiction break rules, attestation prompts and premium-pay flagging are workforce-module features; on Qu's own enumeration they live in partner products, not in Qu. 7shifts' Qu-POS KB article could not be read (HTTP 403 on kb.7shifts.com article HTML), so no partial-via-integration was asserted. source |
| labor-minor-labor-rules | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Claim sweep of a never-examined cell. The claim requires enforcement at both scheduling and clock-in; Qu has no native scheduling surface at all — no workforce module on the products page, labor delegated to 'Back of House + Labor' partners (7shifts, Altametrics) in the vendor's own directory — so the scheduling half cannot be met natively and the capability as defined is absent from Qu itself. source |
| reporting-tip-tax-compliance | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Claim sweep of a never-examined cell, consistent with the already-settled labor-tip-distribution-audit-trail cell. 7shifts' 'Tip Pooling for Qu POS' doc (updated 2026-06-24, read via the site's public Zendesk article API because the HTML is bot-gated) states 'Qu automatically transfers sales, payment, and tip information to 7shifts' — per-employee tip capture exists in Qu — but tip distribution 'within 7shifts... is automated' in a module operators 'trial or purchase' separately, and neither declared-vs-charged breakdowns nor a jurisdictional tax liability summary is documented anywhere public for Qu itself (Unified Data & Reporting page is silent on tips and payroll; help centre login-gated). Capture without the payroll/tax-ready outputs is the named shortfall. source |
| reliability-sync-conflict-handling | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Claim sweep of a never-examined cell. The claim asks whether the vendor documents its conflict-resolution behaviour for partition-time edits. Qu Business Edge publicly documents a 'Write-Local, Sync-Global' model and states 'Automatic conflict resolution and state reconciliation on reconnect' — so the vendor does publish that conflict resolution exists and runs automatically on reconnect — but nowhere specifies the strategy (last-write-wins, merge, or operator prompt), which is the substance the claim asks for. Existence documented, semantics not: partial with that shortfall named, grade C because the source is a product page written to sell the edge platform. source |
| commercial-hardware-purchase-outright | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Claim sweep of a never-examined cell. The claim's truth condition includes 'at a published price'. Qu publishes no prices anywhere: no pricing page exists on qubeyond.com (already established in the record), the POS page describes hardware only as the Qube on-site hub with no price, purchase, lease or rental term, and all paths funnel to the get-a-demo quote form. The published-price prong is verifiably unmet, so the claim as worded fails regardless of what is negotiable in a quote; the note says exactly that so the 'no' is not read as 'hardware must be leased'. source |
| order-capture-qr-same-check | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Re-fetched the Online Ordering page: "tableside" is listed as a fulfillment/hand-off mode alongside in-store, curbside and white-label delivery. Shortfall: the page never describes a guest QR scan writing items onto an existing server-opened check rather than creating a new order/ticket, and Qu's own POS page states the product is "not designed for... table-service concepts", which is the model this claim presupposes (an open check with server-entered items already on it). source |
| order-capture-drive-thru-timers | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Re-fetched the drive-thru page: "Operators get real-time speed-of-service data through Qu Notify and a real-time Kitchen Intelligence Score so managers can act on bottlenecks before they impact guests," plus a claimed "up to 50% faster service times." Shortfall: this is a rolled-up operational score, not the segmented order/total/window timers tied to individual orders that the claim names — no per-segment timer breakdown or per-order timer report is documented. source |
| payments-tip-pooling | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | 7shifts' "Tip Pooling for Qu POS" doc (updated 2026-06-24) states "Qu automatically transfers sales, payment, and tip information to 7shifts" and requires per-employee order/sale assignment in Qu POS, establishing per-employee tip capture in Qu. Shortfall: the pooling/distribution rule engine (by hours worked, sales, role percentage, or points) lives in 7shifts' separately licensed Tip Pooling module — "within 7shifts, the distribution of tips and gratuities among employees is automated" — not in Qu itself, which has no published tip-pool ledger. Same source/finding as labor-tip-pooling-rules and labor-tip-distribution-audit-trail. source |
| kitchen-waste-logging | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The claim explicitly requires that a logged waste/spoilage entry depletes inventory. Qu's products page enumerates the complete module line-up (Ordering, Kitchen, Qu Pay, Management) with no inventory module, and the record establishes across ~15 other cells that inventory/recipe costing is entirely partner-delivered (MarketMan, Restaurant365). With no native inventory ledger to deplete, a native waste-logging-that-depletes-inventory workflow cannot exist on the KDS. Same reasoning as inventory-waste-logging and the sibling inventory-* "no" cells. source |
| kitchen-prep-forecasting | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | The menu page claims "AI-connected demand and daypart intelligence," the same evidence already used for reporting-sales-forecast ("a daypart-granular forecast surface consumable by scheduling is not documented"). Shortfall: this is demand/daypart intelligence for menu and pricing decisions — nothing establishes it produces a prep list or predicted prep quantity surfaced to kitchen staff as a daily task list, which is what this claim specifically requires. source |
| delivery-offline-behavior | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Re-fetched the Qu Business Edge resilience page directly for delivery-specific offline language: it states only that "ordering, payments, and kitchen routing continue uninterrupted during connectivity outages" — a generic continuity claim with no mention of cash delivery orders, driver assignment, or driver settlement. Qu also ships no native driver/dispatch module at all (delivery-driver-roster, -dispatch-board, -driver-tracking, -driver-comp, -cash-reconcile are all documented "no" elsewhere in this record), so there is no native driver-assignment or driver-settlement process to have offline behavior for. Same "claims continuity, publishes no feature-level detail" pattern as reliability-offline-feature-matrix (also "no"). source |
| digital-catering-portal | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Same evidence as order-capture-catering: EZCater is named as a direct integration partner. Shortfall: no distinct native catering flow — separate catering menu/minimums, lead-time rules, quotes/proposals, deposits, or invoice/house-account/ACH terms — is documented; catering is delegated to the EZCater integration. source |
| digital-checkout-pci-sca | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Fetched the Qu Pay, Online Ordering, and platform pages directly for PCI language: none of the three — including Qu Pay, the page whose entire subject is payments — mentions hosted payment fields, a hosted payment page, or publishes any PCI DSS 4.0 compliance statement (including the March-2025 script-integrity requirement). Complete silence on the vendor's own payments product page, on the exact topic that page exists to cover, supports a documented absence rather than mere non-discovery. source |
| guest-loyalty-offline-behavior | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Re-fetched the Qu Business Edge offline-resilience page directly: its only offline statement is generic ("full transaction processing continues... system state preserved locally... sync resumes automatically"), with no mention of loyalty lookup, accrual, or redemption at all. The Qu Pay page is likewise silent. Loyalty itself is partner-delivered (Paytronix/Thanx), so the page that would need to document this behavior — and doesn't — is the one page describing Qu's own offline model. Same "claims continuity, silent on the named sub-behavior" pattern as reliability-offline-feature-matrix (also "no"). source |
| guest-loyalty-offer-stacking-rules | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Same evidence and finding as digital-promo-parity: a single menu/promotion database with channel-level rule configuration and eligibility is documented, but explicit stacking/precedence semantics (exclusive vs combinable, order of application) are not — for the promotion engine generally, which is the mechanism a loyalty offer-stacking rule would run on. source |
| guest-loyalty-native-email-sms | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same page and finding underlying guest-loyalty-accrual-models: Qu's own Online Ordering page states "third party loyalty," and guest email/SMS messaging is consistently presented across Qu's resource-center posts as delivered through named partners (Thanx, Paytronix), never as a native Qu send capability. The claim specifically requires NOT solely handing the list to a third-party ESP — that is exactly what Qu's own language describes. source |
| labor-fair-workweek-support | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same chain already established for labor-native-scheduling and labor-shift-swap-workflow (both "no"): Qu ships no native scheduling product — the enumerated catalog has no workforce module and the partner directory routes "Back of House + Labor" to 7shifts and Altametrics. Predictive-scheduling ordinance tracking (advance-notice deadlines for published schedules, predictability pay owed) requires a native scheduling system to track schedule publication against, which Qu does not have; any such compliance tracking is a property of the partner product. source |
| labor-tip-pooling-rules | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Same source as labor-tip-distribution-audit-trail and payments-tip-pooling: Qu "automatically transfers sales, payment, and tip information to 7shifts," giving Qu per-employee tip capture. Shortfall: the automatic per-shift pooling computation from configurable rules (hours worked, sales percentage, role, points) happens inside 7shifts' separately licensed Tip Pooling module, not in Qu, which publishes no native pooling rule engine. source |
| inventory-waste-logging | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same reasoning as the ~15 sibling inventory-* "no" cells already in this record: the products page enumerates Qu's complete module line-up with no inventory module, and recipe/inventory costing is explicitly delivered by partners (MarketMan, Restaurant365). A structured waste/spoilage logging workflow that debits inventory and reports cost separately from usage variance cannot exist without a native inventory ledger, which Qu does not ship. source |
| hardware-handheld-purpose-built | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Same evidence as order-capture-native-handheld: the drive-thru page cites mobile/tablet order-taking beyond fixed terminals. Shortfall: no purpose-built handheld with an integrated card reader is documented, and no drop rating or IP ingress rating is published anywhere on qubeyond.com. source |
| hardware-p2pe-terminal | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Fetched the Qu Pay page directly, the one page whose entire subject is card acceptance: it contains no PCI-listed PTS device claim, no P2PE validation statement, and no merchant SAQ type. The claim specifically requires the vendor to state the SAQ type, and nowhere on qubeyond.com does it. source |
| hardware-ownership-vs-lease | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same finding as the already-scored commercial-hardware-purchase-outright: fetched the POS page directly and it names no hardware price, purchase term, or lease term at all — the only hardware reference is the Qube edge appliance with no commercial terms attached, and every commercial path funnels to the get-a-demo quote form. The vendor does not state which model applies, which is what this claim requires. source |
| reliability-offline-decline-liability | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Duplicate claim of the already-resolved payments-offline-decline-liability ("no", same source): Qu's public offline-payments material — the Qu Business Edge page ("Full transaction processing continues... Sync resumes automatically with no manual intervention," "No data loss during outages") — promotes offline card acceptance continuity without a word on who bears a decline on reconnect, or any per-transaction/cumulative offline cap. No public MSA/ToS exists (privacy-policy page confirms the only legal document published is the privacy policy, which excludes customer/product terms) and the help centre is login-gated, so the public documentation this claim requires verifiably does not exist. source |
| reliability-pci-dss-4-attestation | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Fetched the platform page directly, the page whose subject is Qu's architecture and enterprise capabilities: it describes unified commerce, kitchen orchestration, payments, and enterprise management but contains no PCI DSS v4.0/4.0.1 Attestation of Compliance, validated P2PE listing, or any compliance-attestation language at all. The Qu Pay page (fetched separately) is equally silent. No trust-center or security page exists on qubeyond.com to check instead. source |
| commercial-no-early-termination-fee | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same underlying fact as the already-scored commercial-autorenew-terms-published: re-fetched the privacy policy directly, the only legal document Qu publishes, and it explicitly states "This Privacy Policy does not apply to: Information processed on behalf of our customers through Qu products and services, where separate contractual terms may apply" — confirming no MSA, ToS, or order-form terms are publicly posted anywhere on qubeyond.com. A published term stating no early-termination fee cannot exist because no published contract terms exist at all. source |
| commercial-rate-increase-clause | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same fact as commercial-no-early-termination-fee: no processing agreement or any commercial terms are publicly posted (privacy policy re-fetched and confirms the scope exclusion for customer/product terms), so no published clause capping or prohibiting unilateral rate increases, or granting penalty-free exit on an increase, can exist. source |
| commercial-post-termination-export-window | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same underlying fact as commercial-no-early-termination-fee and commercial-rate-increase-clause: no contract or MSA is publicly posted anywhere on qubeyond.com (privacy policy confirms the scope exclusion and that separate, non-public contractual terms apply), so no publicly available document specifies a post-termination data-retrieval window versus an immediate cutoff. source |
| commercial-pci-p2pe-tokenization | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Fetched the Qu Pay page directly: no validated P2PE or hardware-encrypted card-entry-plus-tokenization claim is made, and no SAQ type (A / P2PE-HW) is named anywhere on qubeyond.com. Same finding as hardware-p2pe-terminal. source |
| commercial-pci-dss-4-controls | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Fetched the Qu Pay, platform, and Qu Business Edge pages directly: none documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — no MFA-for-cardholder-data-environment statement covering POS/back-office logins, and no payment-page script-integrity monitoring statement. source |
| commercial-soc2-attestation | unknown / F placeholder ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Fetched the platform page directly: it describes unified commerce, kitchen orchestration and enterprise management with no SOC 2 Type II or ISO 27001 attestation claim, and no trust-center link exists anywhere on qubeyond.com to request a report under NDA. source |
| delivery-driver-roster | no, grade B - Normally I would push 'absent from a marketing catalog' back | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| order-capture-order-ready-signal | yes / B / "Same DPIP mandatory-feature list, plus Order Status is an independently enumer | downgrade-to-partial | The cited URL, qubeyond.com/products/, is a first-party catalog page -- grade C, and a differentiator yes needs A or B. Searching for real documentation: qu-api.qubeyond.com returns Azure 'Error 403 - This web app is stopped'; its 2022 Wayback copy documents only inbound order placement and store-side polling, with no outbound status endpoint; support.qubeyond.com 302s to identity.document360.io login; help/docs/developer/developers/api/university.qubeyond.com do not resolve; status.qubeyond.com enumerates 'DoorDash Integration', 'UberEats Integration' and 'QuKitchen KDS' components but describes no behaviour; the Order Status marketing page says it 'reflects orders placed at the counter, kiosk, drive-thru, online, and through third-party delivery in one guest-facing view' -- guest-facing, not an outbound marketplace push. The second leg of the original note ('Order Status is an enumerated product') therefore does not support the claim at all. The DPIP leg does survive on DoorDash's own pages, so the capability is real in some form, but the claim's distinguishing wording -- signalled from POS or KDS state rather than a tablet tap -- is nowhere published. Partial with that shortfall named. source |
| menu-pricing-recipe-linkage | no / E - No inventory/recipe module in Qu's product catalog; recipe costing is delivere | upheld | Citation-staleness audit. The cited https://www.qubeyond.com/products/ 301s to https://www.qubeyond.com/ under every user agent tried, so the enumeration the note relied on is no longer at that URL. I rebuilt it from the live site: the Platform Solutions nav enumerates 14 products in four groups and the sitemap's product tree (/ordering/*, /kitchen-solutions/*, /payments/qu-pay, /management/*) contains exactly the same 14 and nothing else - no inventory, recipe or food-cost product. The Unified Menu Management page's Features list covers items, prices, modifiers, store groupings, promotions, daypart intelligence and API structure, with no BOM, depletion or theoretical-cost capability. The full 150-entry integrations directory (retrieved page by page) puts MarketMan, Restaurant365, Crunchtime, SynergySuite and COGS-Well under 'Back of House + Labor'. Value stands on the replacement evidence; grade moved E->C because the source is a first-party feature page, not independent reporting. source |
| delivery-driver-roster | no / C - Normally I would push 'absent from a marketing catalog' back to unknown, but he | upheld | Citation-staleness audit. https://www.qubeyond.com/products/ 301s to the homepage, so the cited page proves nothing. I re-verified the 'white-label delivery' quotation verbatim rather than carrying it over: https://www.qubeyond.com/ordering/online-ordering reads 'Multiple Hand-Off Modes / Flexible fulfillment options including in-store, curbside, tableside, and white-label delivery'. The absence leg was rebuilt from the /ordering section index, which enumerates five ordering products and no driver module, and from the sitemap's product tree, which contains no delivery-operations URL. The 150-entry integrations directory has a 'Delivery' category holding the marketplaces plus Cartwheel, a third-party driver-dispatch product - the vendor delegating exactly the capability under test. Value and grade untouched; only the citation moved. source |
| guest-loyalty-referral-program | no / C - Qu's products page enumerates the full module line-up - Ordering (POS, Kiosk, Dr | upheld | Citation-staleness audit. The cited /products/ URL 301s to the homepage. I retrieved the whole 150-entry integrations directory page by page (Webflow pagination, ?12898331_page=1..14): the 'Loyalty' category holds Thanx, Paytronix, Punchh, Incentivio, SpendGo, Sparkfly, tapmango and hang - LevelUp, named in the old note, is not there, so I removed it rather than carry a claim I could not see. The module enumeration re-verified from the live Platform Solutions nav and the sitemap's product tree: fourteen products, no loyalty among them. New supporting quote found on https://www.qubeyond.com/ordering/online-ordering: 'third party loyalty or Qu's built-in discounts'. Value stands. source |
| labor-native-scheduling | no / E - No scheduling product in Qu's catalog; scheduling is partner-delivered (7shifts | upheld | Citation-staleness audit. The cited https://www.qubeyond.com/about/qu-technology-partners/ 301s to https://www.qubeyond.com/integrations; I fetched the destination and it is a live, filterable directory - 'Showing 1 to 9 of 150 integrations' across eleven categories including 'Back of House + Labor', which is where 7shifts, Altametrics, HotSchedules and Harri sit. The no-native-module leg was rebuilt independently from the Platform Solutions enumeration and the sitemap's product tree, neither of which contains a workforce product. No developer or documentation subdomain exists (developer./docs.qubeyond.com do not resolve), so there is no API surface that could contradict this. Value stands; grade E->C because the source is a first-party page, not third-party reporting. source |
| labor-break-compliance-by-state | no / C - Qu ships no labor module: the products page enumerates the entire line-up (order | upheld | Citation-staleness audit. The cited partner-directory URL 301s to https://www.qubeyond.com/integrations; the destination is the real directory, not a section index, and its 'Back of House + Labor' filter is where the labor vendors sit. I re-derived the absence from the live Platform Solutions enumeration and the sitemap product tree rather than trusting the dead page. I also re-probed the barrier the researcher recorded: kb.7shifts.com still returns 403 for the article HTML and for /api/v2/help_center/articles/search.json under a Googlebot agent, so the partner-side detail is still unreadable and nothing about jurisdictional break rules inside Qu could be established either way. Value stands. source |
| labor-fair-workweek-support | no / E - Same chain already established for labor-native-scheduling and labor-shift-swap- | upheld | Citation-staleness audit. The cited URL 301s to https://www.qubeyond.com/integrations, which I fetched and confirmed is the live 150-entry directory with a 'Back of House + Labor' category rather than a homepage or section index. The premise this cell actually rests on - Qu ships no native scheduling surface - does not depend on the dead page: the Platform Solutions nav and the sitemap's product tree independently enumerate fourteen products with nothing for workforce or scheduling, and no Qu developer or docs host exists to contradict it. Value stands; grade E->C for a first-party source. source |
| labor-minor-labor-rules | no / C - The claim requires enforcement at both scheduling and clock-in. Qu has no native | upheld | Citation-staleness audit. The cited partner page 301s to https://www.qubeyond.com/integrations, which I retrieved in full (all fourteen pagination pages) and which supports the delegation leg. I checked whether anything on the live site could meet the scheduling half and found only reporting: the /management index lists Qu Notify Mobile Insights as 'Real-time reporting across stores, labor, and items', which is labor reporting, not schedule construction or clock-in enforcement. No scheduling product exists in the enumeration or the sitemap. Value stands. source |
| labor-shift-swap-workflow | no / E - No native scheduling product, therefore no shift-swap workflow; handled by 7shif | upheld | Citation-staleness audit. The cited URL 301s to https://www.qubeyond.com/integrations; the destination carries the partner evidence, and the underlying premise was re-established without it from the Platform Solutions enumeration and the sitemap. The only employee-facing mobile surface Qu ships is Qu Notify Mobile Insights, described on /management as manager reporting and alerts ('Real-time reporting across stores, labor, and items', 'Prioritized alerts and operational visibility') - not an employee self-service scheduling app. Value stands; grade E->C for a first-party source. source |
| extensibility-app-marketplace | partial / B - Public integrations directory listing ~150 certified integrations by categor | upheld | Citation-staleness audit. The cited URL 301s to https://www.qubeyond.com/integrations. I fetched the destination and walked all fourteen pagination pages (?12898331_page=1..14) to enumerate the directory myself rather than accept the researcher's '~150': the page states '150 integrations' and the paged listing bears that out, across eleven filter categories. The no-self-install shortfall was re-checked directly - each card offers only 'View Site' out to the vendor, and the page's own copy routes enablement through certification and a 'Become a Partner' form - so partial is right. Grade lowered B->C: atlas-evidence-rules reserves B for product documentation, and this is a first-party feature page of the same kind the corpus-wide regrade pass already moved to C elsewhere in this record. source |
| kitchen-waste-logging | no / E, cites the now-dead https://qubeyond.com/products/: "Qu's products page enumerates the complete module line-up (Ordering, Kitchen, Qu Pay, Management) with no inventory module" | upheld | The cited /products/ URL is gone, so I re-walked the live catalog. The /kitchen section index names three kitchen products and none touches waste or inventory; the /platform nav carries no inventory module; the fully enumerated /integrations directory (120 partners across 14 pages, retrieved via the Webflow pagination parameter 12898331_page) lists nine inventory/food-cost vendors under "Back of House + Labor". The claim requires the logged entry to deplete inventory, and there is no native ledger to deplete. Value stands on new evidence; grade corrected from E (which is reserved for independent third-party reporting) to C, since every source here is first-party. source |
| delivery-dispatch-board | no / E, cites the now-dead https://qubeyond.com/products/: "No dispatch product in the catalog." | upheld | Re-walked the live catalog after the cited URL died. /ordering lists five ordering products and treats delivery only as marketplace injection into the POS; /platform's full solutions nav has no dispatch or driver product. The stronger new evidence is the /integrations Delivery category, which carries Cartwheel alongside the marketplaces - Cartwheel is a dispatch/driver-management product, so its presence in Qu's own partner directory is affirmative evidence the dispatch board is partner-supplied. Value stands; grade corrected E to C as all sources are first-party. source |
| delivery-route-map | no / E, cites the now-dead https://qubeyond.com/products/: "No dispatch/routing product in the catalog." | upheld | Differentiator weight, so I held this to the top bar and looked for any map or route artefact. The live /platform solutions nav, the /ordering section index, all 233 sitemap URLs and the fully enumerated 120-entry /integrations directory contain no map view, no geocoding and no route sequencing anywhere; the Winter 2026 release notes list ten features, none delivery-related. The routing capability appears in Qu's directory as a partner (Cartwheel), not as a Qu product. Value stands on replacement evidence; grade corrected E to C. source |
| delivery-driver-tracking | no / E, cites the now-dead https://qubeyond.com/products/: "No first-party driver app in the catalog." | upheld | Differentiator weight. I checked the live /platform solutions nav (the only Qu mobile app listed is Qu Notify Mobile Insights, for managers), /ordering, the 233-URL sitemap, and the fully enumerated 120-partner /integrations directory. Nothing names a driver app, a driver login, or GPS capture. Cartwheel, in Qu's Delivery partner category, is the product that does this. Value stands on replacement evidence; grade corrected E to C. source |
| delivery-driver-comp | no / E, cites the now-dead https://qubeyond.com/products/: "No in-house driver module, so no driver compensation tracking." | upheld | Differentiator weight. The replacement evidence is stronger than what it replaces: besides the live /platform nav showing no driver and no payroll product, the fully enumerated /integrations directory positively assigns dispatch to Cartwheel and payroll to Proliant. The 7shifts knowledge-base article already in this record covers tip pooling for Qu POS from the 7shifts side, which is consistent with labor economics living outside Qu. Value stands; grade corrected E to C. source |
| delivery-cash-reconcile | no / E, cites the now-dead https://qubeyond.com/products/: "No in-house driver module, so no driver bank/settle-up flow." | upheld | Re-walked the live catalog. /platform's full solutions nav, /ordering, /management (five products, no cash-management or driver function) and the 120-entry /integrations directory contain nothing resembling a driver bank or settle-up. Qu Pay's page is card-acceptance oriented and names no driver cash flow. The dispatch function is a named partner. Value stands on replacement evidence; grade corrected E to C. source |
| labor-native-payroll | no / E, cites the now-dead https://qubeyond.com/products/: "Payroll is not in Qu's product catalog; the platform is POS/kitchen/management only." | upheld | Differentiator weight, so I looked for any sign Qu had added a payroll bureau. It has not: /platform's solutions nav, /management, the 233-URL sitemap and the Winter 2026 release notes all contain no payroll product. The affirmative evidence is Qu's own partner directory, which I enumerated in full (14 pages, 120 entries, via the Webflow 12898331_page parameter) and which lists Proliant under "Back of House + Labor". A vendor that lists a payroll bureau as an integration partner is not processing payroll itself. Value stands; grade corrected E to C. source |
| labor-digital-onboarding-i9 | no / E, cites the now-dead https://qubeyond.com/products/: "No HR/onboarding product in Qu's catalog." | upheld | Re-walked the catalog after the cited URL died. No onboarding product appears in /platform's solutions nav, in /management, in the 233-URL sitemap or in the Winter 2026 release notes, and no Qu page anywhere mentions W-4, I-9 or E-Verify. The affirmative leg is the fully enumerated partner directory, where onboarding vendors Workstream and Harri sit under "Back of House + Labor". Value stands on replacement evidence; grade corrected E to C. source |
| inventory-recipe-bom-costing | no / E, cites the now-dead https://qubeyond.com/products/: "No native inventory module; recipe costing is partner-delivered (MarketMan, Restaurant365)." | upheld | This cell anchors roughly eighteen sibling inventory claims, so I re-established it directly rather than by inference. The live /platform nav, /management and /kitchen section indexes contain no inventory product; the 233-URL sitemap has no inventory page; the Winter 2026 release notes add none. Against that, the fully enumerated /integrations directory names nine back-of-house costing vendors as partners - three more than the record previously cited. Value stands on materially better evidence; grade corrected E to C, since qubeyond.com is first-party and E is reserved for independent reporting. source |
| hardware-printer-compatibility | unknown / F: "The partner directory lists a 'Hardware + Digital Signage' category, but only 9 of the stated 150 integrations render in a fetch..." | upheld | I removed the retrieval failure the rationale depended on: paginating /integrations with 12898331_page yields all 120 partners, and the Hardware + Digital Signage category is fully visible - 14 entries, every one a signage, menuboard or network vendor (WAND, spectrio, TRISON, Sagenet, The Howard Company, NCR Vitalcast and so on). No printer manufacturer is present and no Qu page names Epson or Star. Crucially this does not license a 'no': a partner directory is not a peripheral compatibility matrix, and absence from it is absence of mention. I re-probed both barriers rather than trusting the recorded note - support.qubeyond.com still 302s to Document360 login, and the two API hosts have regressed from readable to 403. Unknown stands, on corrected reasoning. source |
| extensibility-partner-revshare | unknown / F: "only 9 of the stated 150 integrations render... the full directory could not be enumerated via fetch to confirm no partner fee/revshare terms appear" | resolve-to-no | The original rationale named exactly one blocker - inability to enumerate the directory - and I removed it: paginating /integrations with 12898331_page returns all 120 partners over 14 pages, and no entry anywhere carries a fee, referral or revenue-share figure. I then checked the page such terms actually belong on, /become-a-partner, which publishes no tiers, no percentages and no per-location fee, only a contact form. The sitemap has no partner-program or pricing page to have missed. This is a publication claim, so an exhaustive check of the publication surfaces is positive evidence of absence rather than mere silence, and the honest answer moves up from unknown to no at grade C. source |
| inventory-unit-conversion-yields | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | The refuted /products/ leg is withdrawn. I re-walked the live /platform solutions catalog, the full 233-URL sitemap and all 17 pages of /integrations myself: no inventory item master exists anywhere in Qu's product line, and nineteen back-of-house vendors are listed as the place operators get one. Value unchanged; grade E to C, since qubeyond.com is first-party and E is reserved for independent reporting. source |
| inventory-theoretical-vs-actual | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | Differentiator, so held to the higher bar. I re-read /platform, /management, /kitchen and Unified Data & Reporting: Qu's reporting surface is sales, labor, channel and equipment data, never recipe-derived usage. A full-site text sweep finds "theoretical" only once, in an unrelated sense. Nothing supports a usage-variance report; the no stands on the live catalog rather than on the dead products page. Grade E to C. source |
| inventory-realtime-depletion | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | Differentiator. Rather than re-assert the dead page I found affirmative counter-evidence: Qu's own Fall 2025 release notes describe item availability as a manual phone toggle with a "Revive Date", which is what a POS ships INSTEAD of ingredient depletion. No ingredient-level on-hand quantity exists anywhere in the platform catalog. Value unchanged, grade E to C, and the reasoning is now positive rather than absence-of-mention. source |
| inventory-86-auto-sync | no / E, no / E, cited the dead https://qubeyond.com/products/: "Qu propagates manual 86s across channels, bu | upheld | Differentiator, and the one cell in this cluster where I found direct documentation of the mechanism instead of inferring from the missing module. Qu's Fall 2025 release notes and the /ordering/pos FAQ together show manual entry plus a time-based revive, propagated cross-channel - exactly the researcher's conclusion, now sourced. Value unchanged; grade E to C. source |
| inventory-count-modes | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | The /products/ leg is gone; I re-established the absence from the live Platform Solutions catalog and a full sitemap text sweep, neither of which contains any counting workflow, and from the enumerated partner directory that names where counts are actually done. Value unchanged, grade E to C. source |
| inventory-mobile-count-offline | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | Replaced the dead-page inference with the enumerated feature list on Qu's own Notify page, which is the only mobile app Qu ships: four named features, all reporting and alerting, plus an FAQ that defines the app as insights-only. The page's single use of the word "inventory" is in a forecasting sentence, not a counting feature. Value unchanged, grade E to C. source |
| inventory-vendor-catalogs-edi | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native purchasing modul | upheld | Differentiator. I searched the entire re-fetched site for "purchase order" and for each named broadline distributor: zero hits for all of them. The enumerated partner directory carries procurement (Buyers Edge Platform) as an integration, which is affirmative evidence that ordering to distributors happens outside Qu. Value unchanged, grade E to C. source |
| inventory-invoice-ocr | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native AP/invoice modul | upheld | Differentiator. The full-site sweep gives positive rather than negative evidence here: "invoice" occurs twice in the whole corpus and both are in one pricing-commentary blog post. Meanwhile the enumerated partner list names the AP/invoice-capture vendors (marginedge, Restaurant365, Compeat) Qu customers use. Value unchanged, grade E to C. source |
| inventory-price-change-alerts | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native purchasing modul | upheld | Differentiator. The obvious place a price-change alert would live is Qu Notify, so I read Notify's own alert enumeration rather than relying on the missing module: sales, service time, equipment, Kitchen Intelligence Score, configurable operational exceptions - nothing invoice-priced. Combined with zero site-wide hits for purchase orders or invoices as capabilities. Value unchanged, grade E to C. source |
| inventory-par-auto-suggest | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native purchasing modul | upheld | Differentiator, and the cell most at risk of being wrong, because Qu does ship forecasting. I read the Smart Kitchen copy directly: it forecasts food production for the kitchen line, not replenishment against par, and there is no purchase order anywhere in the product. "Par level" has zero occurrences site-wide. Value unchanged but the reasoning now distinguishes production forecasting from par-driven suggestion; grade E to C. source |
| inventory-waste-logging | no / E, no / E, cited the dead https://qubeyond.com/products/: "Same reasoning as the ~15 sibling inventory- | upheld | This cell's note explicitly deferred to the sibling cells' shared /products/ premise, so it collapsed entirely and had to be rebuilt. I checked every occurrence of "waste" in the re-fetched corpus: all 34 are marketing outcome language (less food waste from better forecasting, energy waste), never a logging workflow, and "spoilage" appears nowhere. Value unchanged; grade E to C. source |
| inventory-transfers | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | I read /management in full rather than inferring: Qu's multi-location story is Unified Menu Management, Channel Management, Brand & Franchise Management and cross-brand reporting, all configuration and analytics, with no stock balance per location to move. Value unchanged on live evidence; grade E to C. source |
| inventory-commissary | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | Zero site-wide occurrences of "commissary", and I read the Smart Kitchen pages to check the concept was not present under another name - KDS, Order Status and Energy & Equipment Intelligence, all single-site. Value unchanged, now resting on the live catalog and a full-corpus term search; grade E to C. source |
| inventory-lot-traceability | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | Traceability starts at receiving, so I checked for a receiving surface first: none exists, and "lot", "batch" and "recall" as capability terms are absent from all 233 pages. The no now rests on the live product catalog plus a full-corpus search instead of the dead products page; grade E to C. source |
| inventory-shelf-life-expiry | no / E, no / E, cited the dead https://qubeyond.com/products/ with the bare note "No native inventory modul | upheld | I checked whether an expiry feature might exist under different wording and found the closest thing is the Fall 2025 "Revive Date", which is the opposite operation - scheduling an item back on sale, not flagging stock going off. No dated stock records exist to expire. Value unchanged, grade E to C. source |
| inventory-bar-partial-bottle | no / E, no / E, cited the dead https://qubeyond.com/products/: "No native inventory module; QSR-only product | upheld | I walked all 17 pages of the partner directory looking specifically for a scale or liquor-weighing vendor and found none; the only beverage-inventory name is DigitalPour, a partner rather than a Qu feature. The QSR scope leg of the original note is corroborated by Qu's own Qu Pay page. Value unchanged, grade E to C. source |
| inventory-menu-margin-linkage | no / E, no / E, cited the dead https://qubeyond.com/products/: "Requires native recipe costing, which Qu doe | upheld | Differentiator. I did not simply inherit the recipe-costing head cell: I read what Qu's reporting products actually report - the /management Unified Data & Reporting section and the Notify feature list - and every named metric is sales, labor, channel, service time or equipment, with no ingredient cost to divide into price. Value unchanged, grade E to C. source |
| reporting-public-api | partial / B / 'A REST Data Access API (api/v3, orders/baskets) is indexed publicly, but both doc hosts se' | upheld | Re-probed both doc hosts on 2026-08-09 over HTTPS, HTTPS-without-verification and plain HTTP: all return HTTP 403 'Site Disabled' with Azure's 'This web app is stopped' body, so the cert mismatch recorded in the original note was a symptom, not the barrier -- the apps are switched off, and Wayback captures show that state since 2023-12-30. Recovered the documentation itself from the 2022-07-24 capture, which carries the api/v3 prefix, the basket/order endpoint shapes and the 'GoodEatsOrdering' worked example, so a REST API is real. Separately confirmed the self-serve-credential shortfall directly rather than by inference: support.qubeyond.com (Document360) 302s /, /hc/en-us and /sitemap.xml alike to identity.document360.io/Account/Login despite robots.txt allowing everything. Partial holds; the note is rewritten and re-cited. source |
| extensibility-oauth-partner-apps | no / B / 'Corroborated the indexed doc text: 'if an endpoint requires an API Key, the header APIKey=[' | upheld | The original researcher had this from a search index; I retrieved the primary text. The Wayback capture of the doc site carries the sentence verbatim -- 'Important: If an endpoint requires an API Key, the header APIKey =[string] should be present in the Request' -- on both doc hosts, and the surrounding reference describes no authorization endpoint, token lifetime, scope set or revocation path. That is positive evidence of the mechanism, which is what a `no` requires; the dead citation was never what carried it. Caveat now written into the note: the last public state of these docs is 2022, because the hosts have been stopped Azure apps since 2023-12-30, and Qu's only current doc surface (support.qubeyond.com) is entirely OIDC-gated, so a later change to OAuth could not be observed from outside. source |
| extensibility-order-injection-api | yes / B / 'I could NOT load qu-pos-api.qubeyond.com myself -- it fails TLS with an Azure wildcard mism' | upheld | I attacked this one hardest because a `yes` resting on a snippet from a host nobody could open is exactly the pattern that should fall. It did not: the last good Wayback capture of the doc site carries the quoted sentence in full and adds the endpoint sequence behind it (basket creation, ADD/DELETE Items and Discounts, Calculate Totals, POST Order, all under api/v3), and the same page states the injected orders are pulled and PRINTED by in-store POS, which is the KDS/printer half of the claim. Also corrected the original note's diagnosis: the host does not merely mis-serve a cert, it is a stopped Azure app returning 403 Site Disabled to plain HTTP as well. Currency checked against qubeyond.com's live 2026-01-13 Onosys certification release rather than the 2022 doc alone. source |
| extensibility-public-api-docs | partial / B / 'Data Access API docs are publicly indexed but both hosts serve invalid TLS certificates (Az' | downgrade-to-no | Re-probed on 2026-08-09 rather than trusting the recorded barrier, and the barrier turned out to be the wrong diagnosis. Bypassing TLS verification and dropping to plain HTTP both reach the origin, which answers 403 'Site Disabled' with Azure's stopped-web-app page (1148 bytes) for /, /index.html, /swagger/index.html and /swagger/v1/swagger.json; Wayback confirms the same body captured 2024-05-17 and 2024-10-04, so the apps have been off for over two years and the original 'publicly indexed' reading was a stale search index, not a live page. Enumerated the rest of the surface: six candidate doc subdomains fail DNS, www.qubeyond.com/llms.txt is a soft 404, and its 233-URL sitemap contains no developer or API-reference page. The one live doc host is authentication-gated on every path. An enumerated documentation surface with a stated login requirement and a withdrawn reference is positive evidence of absence, so this moves off partial rather than to unknown. source |
| order-capture-order-ready-signal | partial / E / downgraded 2026-08-06 on the stated ground that "the cited URL, qubeyond.com/products/, is a first-party catalog page -- grade C, and a differentiator yes needs A or B" | upheld | Value upheld, stated reasoning corrected -- the cell stands for a different reason than the one recorded. There is no products page to grade. Measured first-hand: https://qubeyond.com/products/ 301s to https://www.qubeyond.com:443/products/, which 301s to /products, which 301s to /, landing on the homepage -- 304,753 bytes, title 'Qu', sha256 e0935c07c1e48093, byte-identical to a direct fetch of https://www.qubeyond.com/ and of the apex root. The host has an honest hard 404 (71,363 bytes, title 'Not Found'), so this is a deliberate redirect of a deleted page, not a soft 404. The 2026-08-06 row therefore did not weigh a grade-C catalog page; it weighed nothing. Its conclusion survives on its independent legs, which I re-verified: www.qubeyond.com/kitchen-solutions/order-status is guest-facing only ('shows guests the real-time progress of their order -- placed, in-prep, and ready' / 'pulls state changes directly from Qu KDS ... The guest-facing display updates automatically'), with no outbound marketplace push, and the /ordering/third-party-ordering page goes no further than 'bi-directional integrations sync with third-party providers in real time' and 'syncs automatically to Qu's KDS and Order Status to keep guests and drivers informed' -- neither states the signal is emitted to the marketplace from POS or KDS state rather than a tablet tap, which is the claim's distinguishing wording. The DPIP leg is now stronger than when it was recorded: DoorDash's 2026 announcement (18 May 2026, cohort as of 8 May 2026) lists Qu in a ten-name cohort -- 'Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, and UrbanPiper' -- so Preferred status was retained a year on, and developer.doordash.com's DPIP page both makes 'Order Ready Signal' one of eight mandatory high-quality features and defines supporting one as 'you've built and launched the feature and that it has been used by at least one DoorDash store'. That raises the DoorDash leg from a requirement to an assertion that Qu shipped it, but it still names no mechanism and no coverage beyond DoorDash, and the merchants.doordash.com per-partner comparison tool renders no provider names in HTML. Partial with the existing shortfall stands. robots.txt read in full before every fetch: www.qubeyond.com is 45 bytes, a lone Sitemap line with zero groups and no line terminator -- parse-empty because there are genuinely no rules, and the apex robots redirects to it with the path unchanged; about.doordash.com and merchants.doordash.com allow / and bar only /cdn-cgi/ and /monitoring; developer.doordash.com/robots.txt redirects to the locale-prefixed /en-US/robots.txt but parses to real rules (Allow: /, Disallow: /portal/*), so it is a relocated robots.txt and not a catch-all. Every path fetched is permitted. source |
| menu-pricing-countdown-auto-86 | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Fall 2025 release: "Notify Item Availability: Manage in and out of stock items anywhere. Mark items in/out of stock from your phone and set a 'Revive Date' to auto-restock later." The POS page adds that "Price changes, modifiers, and 86'd items update everywhere simultaneously with no manual sync required." Shortfall: the 86 is operator-initiated. The scheduled auto-restore half of the claim is evidenced (Revive Date); the automatic half is not — no per-item countdown or par count that decrements on sale and 86s the item at zero appears anywhere on qubeyond.com (no hit for 'countdown', 'par level' or 'depletion'). source |
| menu-pricing-versioning-effective-dates | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Fall 2025 release, POS item 1: "A new set of icons shows each menu's status, version, and update schedule—all available through the POS... you can instantly see what's live, what's pending, and what needs attention." So menus are versioned and changes are scheduled ahead of going live. Shortfall: no evidence of a preview-before-publish step, and none of rollback to a prior published version — 'preview', 'rollback' and 'roll back' return zero hits across the whole site. source |
| menu-pricing-allergen-nutrition | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu's store-group inheritance model lists the configurable menu attributes as "Menus — Dynamic items, prices, dietary needs, allergens", so allergen data is held per item in the menu database; the Fall 2025 release adds kiosk-side surfacing — "Guests can filter menu items by Vegan, Vegetarian, or Gluten-Free options, depending on what the brand sets up." Shortfall: allergen/dietary tags only. No evidence of stored per-item nutrition values, and none at all of deriving nutrition from linked recipe components; publication of allergen data to third-party marketplace menus is likewise not stated. source |
| payments-emv-nfc | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, Adyen/third-party legal terms. Qu's Third Party Terms (the Adyen payment terms incorporated into Qu's Master SaaS Agreement) price "EMV-compliant payment terminal devices" as a one-time cost (17.4) and define a Payment Device as equipment that reads the card, registers the Shopper's approval and encrypts the Payment Details (18). Qu's Fall 2025 release also adds "Real-time payment connectivity visibility across EMV devices" for Aurus, FreedomPay, TriPOS and Verifone terminals. Shortfall: EMV chip acceptance is established, but nothing Qu publishes states that its terminals accept NFC contactless, Apple Pay or Google Pay — the only contactless/Apple Pay/Google Pay text on the site describes FreedomPay's own platform in a partnership press release, not Qu's terminal fleet. source |
| payments-offline-store-and-forward | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, Adyen/third-party legal terms. POS page FAQ: "Does Qu POS work if the internet goes down? Yes. Qu POS processes transactions on Qu Business Edge (Qube), the on-site intelligence hub in every restaurant. Ordering, payments, and kitchen routing continue uninterrupted during connectivity outages, and data syncs to the smart cloud automatically when the connection is restored." Shortfall: offline card capture is asserted only as marketing on a feature page (grade C, below the grade-A/B floor a differentiator yes requires); no published documentation names a store-and-forward mechanism or any configurable per-transaction or cumulative offline limit. source |
| payments-p2pe-pci4 | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, Adyen/third-party legal terms. Qu publishes a PCI DSS v4.0.1 compliance guide covering its payment stack. On in-person payments it states the terminals are "all validated and listed P2PE-approved solutions" with cardholder data "encrypted from the point of interaction until it reaches Adyen's secure decryption environment", that the processor is "a PCI DSS Level 1 Service Provider, with PCI DSS compliance assessed by an independent Qualified Security Assessor (QSA) annually", and instructs merchants to obtain the Service Provider's Attestation of Compliance. Shortfall: the guide describes the processor's (Adyen's) attestation, not a Qu-issued AoC or P2PE listing, and P2PE is one of two options — the default in-person integration is E2EE, not validated P2PE. source |
| payments-multi-entity-routing | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, Adyen/third-party legal terms. Third Party Terms 7: "Adyen will Settle Customer Funds directly to each Customer on a gross basis ... meaning 100% of Transaction proceeds will be Settled daily", and "The Settlement of the Customer Funds will be exclusively made pursuant to Customer's binding Settlement instructions"; each legal entity is separately KYC'd and onboarded (3). The Qu Pay page markets "unified payout reporting across every location". Shortfall: the published terms achieve per-entity settlement by onboarding each legal entity as its own merchant of record rather than by routing one account's funds to multiple bank accounts, and no published source shows per-location bank-account routing configured inside a single merchant account. source |
| commercial-data-ownership-clause | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, Adyen/third-party legal terms. Third Party Terms 12.1: "Qu and Adyen may use de-identified and/or aggregated Transaction data solely for the purposes of creating, optimizing payment performance, and improving Adyen and Qu's products and services... In no event shall Adyen or Qu provide, sell, or otherwise disclose any de-identified and/or aggregated Transaction data to any third party (except as required by Applicable Law or the Scheme Rules)." The companion Adyen for Platforms Terms Qu publishes state at 9.1 "Each party remains the owner of all data made available to the other party." Shortfall: both clauses are scoped to payment-services transaction data only; the Master SaaS Agreement that would govern ownership of POS order, menu and guest records is not published, so no published Qu term states the merchant owns its full transaction and customer data. source |
| kitchen-course-firing | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. KDS feature page lists 'Mulitple Firing Modes: Fire on tender, fire on next, fire on fly, and manual fire/suspend to fit any ordering or kitchen workflow.' A 2021 Qu post expands the same four modes (fire on fly / on next / on tender / manual fire). Shortfall: the mechanism is a per-item release rule plus a manual fire/suspend; nothing on qubeyond.com describes assigning items to named courses, nor firing a held course on demand from a server terminal, handheld or expo screen. source |
| kitchen-bump-bar-hardware | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu blog on its KDS: 'Qu KDS also supports order navigation and bump bar functionality, allowing staff to move through orders, make check-level edits, and undo previous actions.' Shortfall: bump-bar support is asserted in a marketing post only; no supported bump-bar or programmable-keypad models are named anywhere on qubeyond.com, and support.qubeyond.com is login-walled. source |
| kitchen-all-day-counts | unknown / F / never examined against a first-party surface | resolve-to-yes | 198th sweep, marketing corpus sweep. Fall 2025 release highlights, item 10: 'KDS Item Count View: Real-Time Kitchen Insights — Kitchen teams can now see, at a glance, how many of each item or ingredient needs to be prepped... a clear view of exactly how many items need to hit the grill or fryer.' The companion Fall 2025 overview repeats 'Real-time kitchen item counts'. Per-modifier aggregation is not stated. source |
| kitchen-recall-refire | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu's KDS post says bump-bar navigation lets staff 'move through orders, make check-level edits, and undo previous actions', and that KDS cells use 'different colors for new, modified, voided, and resurrected orders' — a resurrected (recalled) order state. Shortfall: the described undo/resurrect is at check level; no per-item refire or ticket reprint without re-entering the order is documented. source |
| delivery-promise-time | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu post: 'you can dynamically adjust ready times, turning a static promise into a responsive solution that adapts to real-time conditions' with 'estimates for order readiness by considering factors like historical and current order volume, labor availability, and preparation time'; Qu's Smart Kitchen page lists 'AI-generated promised ready times — improves delivery time accuracy by factoring in all channels, labor, and prep needs.' Shortfall: marketing/roadmap material describing a kitchen ready-time estimate; no evidence the quote factors driver availability or per-zone drive time, and no configuration documentation exists (support site login-walled). source |
| digital-guest-data-ownership | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Unified Data & Reporting FAQ: 'Qu's unified data layer supports API-based integrations with external BI platforms, enabling operators to pipe Qu data into the analytics environment of their choice'; the Online Ordering page pitches 'Retain Your Guest Data — Easily access and analyze data to foster repeat visits.' Shortfall: this is access to a data layer, not a documented bulk export of first-party guest records (email, phone, consent status, order history), and Qu makes no statement about export being free of fee or vendor approval. source |
| guest-loyalty-rfm-segmentation | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu's own loyalty post describes lifecycle segmentation only inside a certified partner's product: "Incentivio's Guest Journey Dashboard leverages machine learning to automatically segment based on guest's visit frequency and spending habits" and "identifies guests at risk of churning." Shortfall: the capability is the third-party loyalty partner's (Incentivio), reached through the Qu integration; Qu describes its own role as the "foundational platform" / data layer and no source shows Qu computing recency-frequency-monetary or lifecycle segments natively. source |
| guest-loyalty-campaign-attribution | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Spring 2025 release: "Qu tracks acceptance rates for both kiosk and POS, as well as the revenue impact and net sales lift for each cross-sell campaign" with "comprehensive, real-time metrics that show exactly which promotions are working." Shortfall: attribution is documented only for kiosk/POS cross-sell upsell campaigns; nothing in the corpus reports redemption or incremental sales for an issued loyalty offer or marketing campaign, which live in partner systems (Thanx, Paytronix, Spendgo). source |
| guest-loyalty-data-export-portability | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Feature page lists "Normalized guest and operational data" in the unified data layer and states: "Qu's unified data layer supports API-based integrations with external BI platforms, enabling operators to pipe Qu data into the analytics environment of their choice." Shortfall: the page never states that the guest list with contact PII is exportable, never mentions CSV or a self-serve export, and says nothing about whether a fee or a support request is required; only BI piping of Qu data generally is established. source |
| guest-loyalty-ai-offer-recommendation | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Platform page, Enterprise AI Agents: "Performance data across locations is analyzed to highlight what's working and what's not. Enterprise Management enables teams to fine-tune promotions, reduce unnecessary discounting." The April 2026 ICP announcement repeats "Enterprise AI agents to optimize decisions like promotions and discounts." Shortfall: the AI agents are described as optimising network-level promotion and discount decisions; no source shows AI/ML recommendations for offer content, a target audience, or send timing to guests, and Qu ships no send channel of its own. source |
| labor-clock-in-at-pos | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu holds punch and hours data natively: Notify can alert on "Number of Employees Clocked in ... in one or all of your stores", and the Winter 2025 release describes tip pooling "within the enterprise management solution" that distributes tips "based on hours worked" and is "closed at the end of each payroll week". Shortfall: no source in the 239-page corpus describes the punch mechanism itself - there is not a single mention of clock-in, time clock, punch or timecard at the terminal, so PIN/badge/card clock-in at the POS is not established (the word "punch" and "time clock" return zero hits site-wide). source |
| labor-demand-labor-forecast | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. "The machine learning models and AI function within Notify provide sales and labor forecasting based on previous store performance. These predictive analytics help you adjust staffing levels in advance." The Notify product page repeats "predictive analytics help you forecast trends and optimize staffing". Shortfall: the forecast is advisory output in the Notify mobile app built on the operator's own store history; the corpus never shows recommended staffing levels or labor hours broken out by daypart, and Qu ships no scheduling surface (7shifts and Altametrics sit in Qu's "Back of House + Labor" partner category). source |
| labor-realtime-labor-percent | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Notify is described as "Qu's voice-activated and AI-enabled real-time reporting app" where a manager can "check on store sales, top selling items, labor to net sales percentage", with configurable alerts on "Labor to net sales percentage". Shortfall: the only evidence is a 2022 vendor blog post; the current Notify product page reduces this to "sales, labor, and operational metrics", and no product documentation states the refresh interval or that the figure is available on the POS itself during service. source |
| labor-overtime-prevention | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Notify alerts can be configured on KPI thresholds "including staff overtime", and the listed example is "get alerted any time of the day about: Employees who are close to overtime". Shortfall: this is a threshold alert pushed to a manager's phone, not a warning or block presented at clock-in on the terminal; nothing in the corpus prevents or interrupts the punch, and the overtime threshold is described only as a configurable Notify KPI. source |
| reporting-pmix-modifier-level | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Product page FAQ: "Qu lets operators compare performance across locations, dayparts, and channels in one view, surfacing top performers, operational gaps, and revenue opportunities without exporting data to spreadsheets." Item-level sales are evidenced on the Notify blog, whose dashboard list includes "Net Sales, Check Counts, Payments, Average Check Size, Gross Sales, Discounts, Cash, Voids, Service Charges, Taxes, Item Sales & Gift Card Sales" (qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money). SHORTFALL: nothing on any of the 239 reachable qubeyond.com pages describes a product-mix report at MODIFIER level, nor an item-level gross-vs-net sales split, nor a revenue-center filter. No grade-A/B documentation exists to check: qu-api.qubeyond.com and qu-pos-api.qubeyond.com both answer with a Microsoft *.azurewebsites.net certificate (TLS altname mismatch) and support.qubeyond.com 302s every path to /login. source |
| reporting-comps-voids-audit | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Notify's dashboard metric list includes "Discounts, Cash, Voids, Service Charges" and alerts can be configured on "staff overtime, cash, voids, and more". The Winter 2025 release post adds Notify Check Search, which "allows staff to filter transaction data based on a wide range of criteria, including Date, Employee, and Order Type". SHORTFALL: voids and discounts appear only as aggregate dashboard metrics plus a generic transaction filter; no reachable Qu page describes a comps/voids/override audit report carrying reason codes, timestamps, the applying employee AND the approving manager. Qu publishes no help centre or admin guide (support.qubeyond.com login-walled; both qu-api hosts fail TLS identity), so no grade-A/B source exists to settle it. source |
| reporting-cash-over-short | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Fall 2025 release: "We've added a single 'Reports' button on the POS that consolidates End of Day, End of Shift, and Tills reports in one spot." Notify separately alerts on "Cash" as a monitored metric. SHORTFALL: a Tills report at the terminal is evidenced, but no reachable Qu surface states that it computes an over/short variance (counted cash vs expected cash from tenders and paid-outs) or attributes that variance per drawer and per employee. No vendor documentation is reachable to confirm the report's contents (support portal login-walled; both API hosts fail TLS identity). source |
| reporting-multiloc-drilldown | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Product page FAQ: "Qu lets operators compare performance across locations, dayparts, and channels in one view, surfacing top performers, operational gaps, and revenue opportunities." Notify adds "Monitor one store, a group of stores, or your full enterprise from one screen" and Check Search, which displays individual checks chronologically filtered by Date/Employee/Order Type. SHORTFALL: side-by-side location comparison and transaction-level lookup exist as SEPARATE features; no reachable page documents a continuous drill path from group total to one location to one transaction - and Qu markets Notify as delivering "Real-time insights in feed format - no drill-downs required!". Differentiator weight and the best available source is a grade-C feature page, so `yes` is not available. source |
| reporting-history-retention | unknown / F / never examined against a first-party surface | resolve-to-no | 198th sweep, marketing corpus sweep. Non-publication, measured across two product generations rather than inferred from the marketing site. Qu's help centre was public on Zendesk 2019-2021 and 210 articles survive in the Wayback CDX index; 'retention'/'retain' occurs in none of them, including every document that would carry a window -- the Reporting Guide (which enumerates each report and its calculations), Report Calculations, the Enterprise Intelligence Guide, 'How do I Set the Reporting Periods for My Store', 'Qu 3.5 Reporting Documentation', Chapter 5: Reporting, and Chapter 12: Audit Trail, which states only that 'Audit Trail can only be accessed from the Enterprise Level of Qu Enterprise Intelligence' and names no window. Live side, management/unified-data-reporting says only 'historical data' with no figure, and the privacy policy's retention clause is scoped to website visitors. The claim's verb is 'Documents', so non-publication is the finding. Caveat: the current help centre is login-gated, so a gated admin guide could state a window we cannot see; this rests on the enumerated public and archived reporting documentation. source |
| multi-location-scheduled-publish | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Fall 2025 release: "A new set of icons shows each menu's status, version, and update schedule - all available through the POS", distinguishing "what's live, what's pending, and what needs attention"; the Fall 2025 recap calls these "traffic light menu status indicators so your team always knows what's live, updating, or needs attention". SHORTFALL: a pending/scheduled menu update is evidenced, but no reachable Qu page states that the activation time is interpreted in each target location's own timezone, nor that an activated change can be rolled back. Differentiator weight with only grade-D evidence, so `yes` is unavailable regardless. source |
| multi-location-new-store-template | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Winter 2026 release, under "Enterprise Agility & Rollout Speed": "Consistent Store Creation with Templates - Pre-built configuration templates standardize new store setup across formats", with the stated advantage "Reduce human error, accelerate openings, and ensure operational consistency from day one". SHORTFALL: the claim's second half is unmet - Qu publishes no expected time-to-open for a templated new location, and the template's contents (menu, taxes, roles, printers, modifiers, tenders) are not enumerated anywhere reachable; the customer portal that would carry a setup guide is login-walled. source |
| extensibility-free-sandbox | unknown / F / never examined against a first-party surface | resolve-to-no | 198th sweep, marketing corpus sweep. Positive evidence of the opposite, from Qu's own archived API reference rather than from the marketing site. The Data Access API documents an account-issued credential model: 'If an endpoint requires an API Key, the header APIKey =[string] should be present in the Request', with the worked example framed as 'All examples assume that company integrating with Data Access API is called "GoodEatsOrdering"' -- a named, onboarded partner, not self-serve signup. 'sandbox' occurs in none of the 210 archived help-centre articles. Measured 2026-09-03: sandbox.qubeyond.com does resolve (A 3.220.47.246, 100.31.229.247) but 502s on /, /robots.txt and /swagger/index.html and has never been captured by Wayback, so it is an internal environment hostname and not an offer to developers; the archived example base URL dev-data-access-api.azurewebsites.net resolves to 23.96.112.53, the same stopped Azure app as qu-api.qubeyond.com. source |
| extensibility-published-rate-limits | unknown / F / never examined against a first-party surface | resolve-to-no | 198th sweep, marketing corpus sweep. The archived Data Access API reference's conventions section is complete and omits any quota. It reads in full: 'Message Format: All requests and responses bodies are in JSON format. API URLs: All Data Access API calls prefixed with api/v3... Important: If an endpoint requires an API Key, the header APIKey =[string] should be present in the Request.' No numeric quota, no throttling behaviour, no headers. 'rate limit', 'throttl' and 'quota' occur in none of the 210 archived help-centre articles. Re-measured 2026-09-03: docs./developer./developers./help./api./university.qubeyond.com are all ENOTFOUND; qu-api and qu-pos-api answer 403 Azure 'Web App - Unavailable' over plain HTTP and fail TLS identity; support.qubeyond.com/hc/en-us is a Document360 login page; the 239-URL live sitemap contains no developer or API-reference page. source |
| extensibility-middleware-compatibility | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu blog (dated June 19, 2019): "Qu offers the flexibility of third party integration for customers that wish to continue to use smaller third party players and when direct integration is not yet an option. Qu's customer-first and API-first approach allows customers to integrate familiar platforms like Chowly and ItsaCheckMate into their existing ecosystem." That names two of the listed aggregation middleware platforms. SHORTFALL: the statement is seven years old and current Qu marketing positions the opposite - "Cut out middleware" and "no middleware required" (ordering/third-party-ordering, ordering/pos) - and it could not be confirmed against the live partner directory, which reports "Showing 1 to 9 of 150 integrations" and does not render the remaining pages to a plain fetch. Deliverect and Otter appear nowhere on the site. source |
| extensibility-payroll-export | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu blog announcing 2024 certifications: "Labor Management Optimize your workforce with sophisticated tools from HotSchedules, Proliant, and Rippling", within "100+ industry-leading integration partners" whose "robust certification process ensures that integrations are tested and reliable". Proliant and Rippling are both payroll processors, so two named payroll providers are certified partners. SHORTFALL: no reachable Qu page states that LABOR HOURS flow to them, in which direction, or that manual re-keying is eliminated; the partner directory's Back of House + Labor category could not be enumerated past its first 9 of 150 rows; and Gusto, ADP, Paychex and Paylocity appear nowhere as Qu integrations. source |
| extensibility-api-versioning-deprecation | unknown / F / never examined against a first-party surface | resolve-to-no | 198th sweep, marketing corpus sweep. The claim is conjunctive and the deprecation half fails. Qu does publish release notes, so a 'no hits for changelog' reading would be wrong: seasonal recaps run publicly in the resource centre (Fall 2024 through Winter 2026) and dated versioned notes ran in the then-public help centre, some carrying real API changes -- 'Labor API - A store's locationId is now available with each labor schedule'; 'as of v139, Data Export API will offer a new export structure that converts Items with Portions into individual Items'. But the public recaps are feature marketing with no API section, and the only deprecation found anywhere is ad-hoc and about platform settings, not the API: 'Please review the soon to be deprecated Platform Settings (QuickSuspend, SuspendOrderAllowed, PrintOnSuspendByDefault, SendOrderOnSuspendByDefault)... they have been marked deprecated and will be deleted in the future when there are no POS running versions prior v142.' No stated deprecation or breaking-change notice policy appears on any enumerated surface: the 239-URL sitemap, the status page, the resource centre, the archived API reference, or six NXDOMAIN developer subdomains. source |
| extensibility-data-portability-exit | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Product page FAQ: "Yes. Qu's unified data layer supports API-based integrations with external BI platforms, enabling operators to pipe Qu data into the analytics environment of their choice", alongside "Access up-to-date performance data across locations through Qu or your existing reporting tools"; the multi-unit guide claims "100% First-party guest data, owned". SHORTFALL: this is an ongoing BI pipe, not an exit right - no reachable Qu page commits to a COMPLETE historical export of orders, customers, menu and payment metadata AT CONTRACT END, names a machine-readable format, or states whether a fee applies. The only Qu-authored terms published are website terms of use, with no MSA and no data-return clause; no format or endpoint can be checked because both API hosts fail TLS identity and the customer portal is login-walled. source |
| reliability-offline-card-auth | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, marketing corpus sweep. Qu Business Edge (Qube) product page asserts "Local Execution of Critical Services: POS, payments, order routing, and kitchen workflows execute on-site. There is no reliance on remote service calls for core operations", plus a "Write-Local, Sync-Global Data Model" where "All transactions are written locally at the edge and propagated to the cloud in real time... No data loss during outages" and "Resilience Without Degraded Modes... Full transaction processing continues". The Qu POS page FAQ repeats it: "Ordering, payments, and kitchen routing continue uninterrupted during connectivity outages, and data syncs to the smart cloud automatically when the connection is restored" (https://www.qubeyond.com/ordering/pos). SHORTFALL: this is asserted on grade-C vendor feature pages only. No store-and-forward mechanism, floor/ceiling limits, per-transaction or aggregate offline caps, maximum offline duration, or decline-on-reconnect handling is published anywhere on qubeyond.com; support.qubeyond.com is login-walled and there is no grade-A/B documentation. Whether card authorization is genuinely deferred and forwarded, or merely captured locally, is not documented. source |
| labor-payroll-export-formats | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, certified-partner directory. Qu's certified-partner directory (Webflow CMS, walked ?12898331_page=1..14, 121 items served against a page label reading 'Showing 1 to 9 of 150') lists under category 'Back of House + Labor': Proliant (proliant.com), Fourth/HotSchedules (fourth.com/product/hotschedules), Altametrics, 7shifts, Harri and Workstream. Qu's own post 'What Qu's Doubled Integration Network Means For You' (qubeyond.com/resource-center/what-qus-doubled-integration-network-means-for-you, grade D) groups them explicitly: 'Labor Management: Optimize your workforce with sophisticated tools from HotSchedules, Proliant, and Rippling.' So direct certified integration with at least two payroll/HCM providers exists. Shortfall: payroll reaches the operator only through those third-party partners -- Qu publishes no export file format or field list, neither the directory nor the post states that timecards, wages or tips are the data exchanged, and none of Gusto, ADP, Paychex or QuickBooks appears anywhere in the 121-partner directory or the 239-page qubeyond.com corpus (Rippling is named in the post but is absent from the directory, so the directory is not exhaustive). source |
| digital-native-app | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, certified-partner directory. Qu's first-party ordering channel is described as web, not a native app: qubeyond.com/ordering/online-ordering offers 'Multi & Virtual Brand Support -- Manage multiple brands under one parent with custom subdomains and branding' and its FAQ says orders are placed 'through a branded web or mobile experience.' Branded native apps come from certified partners instead: the integrations directory lists Lunchbox (lunchbox.io), Olo, Onosys and Paytronix under 'Digital Ordering'/'Payments', and Qu's own release 'Paytronix & Qu Further Integration' (2026-06-23) describes Paytronix as providing 'loyalty programs, online ordering, gift cards, branded mobile applications' with 'orders placed through Paytronix's online ordering platform flow automatically into Qu.' Shortfall: no first-party Qu-published iOS/Android app; a branded native app depends on a third-party ordering partner, and neither source states that such an app is published under the restaurant's own brand in the App Store and Play Store. source |
| payments-split-tender | unknown / F / never examined against a first-party surface | resolve-to-yes | 198th sweep, archived help centre. Qu 'Next Gen 3.5' help article (updated April 2020; Wayback capture 2020-08-09): 'From the Payments screen, press the + number widget until you reach the number of desired payments... The amount due for each payment will automatically divide equally by the number of payments selected. To change the amount of a payment, touch the "Due" box and enter the desired amount. The other payments will automatically adjust. There is no limit to the number of payments or the combination of payment types.' Even shares, arbitrary amount and no cap are all explicit; the First Gen 2.0 Payments guide adds the same ('You may split check payments by any number of increments and by multiple methods') and a separate First Gen article documents splitting items between seats ('Seating allows you to split the items on a check between the customers on the check'). Vintage caveat: this is the archived 2019-2021 support site for First Gen 2.0 / Next Gen 3.5, not the current Intelligent Commerce Platform, and the live site is silent; multi-tender splitting is a basic POS mechanic unlikely to have been removed. source |
| payments-tip-adjust | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu 'Next Gen 3.5' help article (updated April 2020; Wayback capture 2020-08-09) documents post-close tip adjust: check search, 'Select Payment to Adjust Tip (There could be more than one credit card on the check...)', enter the tip. It states the adjust window: 'Generally tips may only be adjusted on the same date.' The First Gen 2.0 Enterprise Configuration reference documents the pre-auth half - 'Require Credit Card Authorization: If set to "true", the terminal prints an authorization slip with tip line for credit card transactions... In Table Service mode, authorization slips are always printed for credit cards' - and a 2020 article gates tip adjust by job title so it 'will require manager approval to apply'. SHORTFALL: no on-device/customer-facing tip prompt on the EMV terminal is described in either generation's EMV payment article, and no manager screen listing unadjusted tips is documented (only a Labor 'Tip' report of tips collected by employee). Vintage: First Gen 2.0 / Next Gen 3.5 archive, 2020; live marketing site silent. source |
| order-capture-void-comp-controls | unknown / F / never examined against a first-party surface | resolve-to-yes | 198th sweep, archived help centre. Qu First Gen 2.0 Admin Guide Chapter 6: Configuration (updated April 2020; Wayback capture 2020-08-08) documents operator-defined reason codes under System Lookups - 'add your own reasons for voiding a check or discounting an item... Void Reasons, Time Entry Reasons, Return Reasons, Paid In/Out Reasons, Discount Reasons'. Reason capture is enforced per-discount ('Require to Enter Reason for Discount?' in the discount definition) and per-void at the POS ('If required, you will be prompted for a void reason. Select the reason, and Tap Void/Remove Item', Next Gen 2020). Manager gating: 'Some discounts may be configured to require manager approval' (First Gen), and a 2020 Next Gen article gates restricted actions by job title so 'the POS will present a manager prompt to the cashier when performing restricted actions'. Exception reporting: the Qu Reports Quick Guide (Next Gen, Sept 2020) lists 'Voided Items - Displays all voided items by an employee', 'Refunds - Lists all refunded checks by an employee', a 'Discounts' report, and 'Labor Red Flag - ...useful for analyzing whether the store or employee uses specific actions (e.d voids) too often'. Vintage: documented for First Gen 2.0 and Next Gen 3.5 in 2020, not verified against today's Intelligent Commerce Platform; these are basic POS controls unlikely to have been removed. source |
| payments-refund-void-controls | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu Next Gen 3.5 article (October/November 2020; Wayback capture 2020-11-28): job-title switches in Enterprise Intelligence disable 'Perform Paid in and Paid Out', 'No Sale', 'Claim Till', and 'Once this change takes effect, the POS will present a manager prompt to the cashier when performing restricted actions'; sibling 2020 articles do the same for offline credit payment types and for Tip Adjust, and manager approval can be given by swiping a manager mag card. Discounts likewise: 'Some discounts may be configured to require manager approval.' SHORTFALL: the corpus documents role gating explicitly for no-sale, paid in/out, till claim/close, offline tenders and tip adjust - not for refunds or voids - and no immutable log identifying the APPROVING manager is documented. Chapter 12: Audit Trail covers admin-side configuration changes ('a detailed activity history of changes occurring within Qu... tracked based on Date, Employee, Module, Location'), while the Voided Items and Refunds reports name the acting employee only. Vintage: 2020 Next Gen 3.5 archive; live site silent. source |
| order-capture-scheduled-orders | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu versioned release notes 'December 16th (v140)' (Wayback capture 2021-01-25) document the future-order setting: 'Future Order Acceptance Days... Minimum days - lowest number of days in advance an order can be placed. 0 = same day, 1 = tomorrow... Maximum days - highest number of days in advance an order can be placed', and 'This setting can be set with a context specific to web and/or catering to allow for differing order limits', i.e. per-channel. The same note lists 'Kitchen Buffer Lead Time' and 'Print Kitchen Ticket' among the store/group-level settings that take a per-channel context. SHORTFALL: the release note names 'Kitchen Buffer Lead Time' as a setting without describing the mechanism, so automatic injection of a future-dated order into the make queue at a computed fire time (rather than on receipt) is not documented. Vintage: Next Gen 3.5-era v140, December 2020; not verified against the current Intelligent Commerce Platform. source |
| order-capture-throttling | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu versioned release notes 'December 16th (v140)' (Wayback capture 2021-01-25) enumerate store/group-level platform settings that can be scoped to an order channel: 'Future Order Acceptance Days, Min Max Order Limits, Bucket Scheduling, Kitchen Buffer Lead Time, Print Kitchen Ticket', and state that 'all platform settings use the catering channel as well, allowing the customer to change order limits and timings to be specific to catering'. That establishes per-channel order limits and time-bucket scheduling. SHORTFALL: 'Bucket Scheduling' and 'Min Max Order Limits' appear only as setting names with no documented mechanics, and nothing in the corpus describes automatic quote-time extension when kitchen load crosses a configured threshold. Vintage: Next Gen 3.5-era v140, December 2020; live site silent. source |
| order-capture-transfer-audit | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu First Gen 2.0 Admin Guide Chapter 8, Section 4 (updated April 2020; Wayback capture 2020-08-06): 'Check Sharing Groups share checks and clock ins/outs among all of the terminals that have been added to that group.' The Enterprise Configuration reference adds 'Allow Peer Refresh: If "true", terminal will refresh display immediately whenever a check is received from another terminal', and the v140 release note records that 'a check can be suspended on one terminal after items have been added' and resumed elsewhere. Checks can also be table-assigned ('Fixed Check Label: The category label on the POS terminal for checks that are assigned to a table'). SHORTFALL: only device-level check sharing is documented; there is no documented server-to-server or table-to-table transfer action, and no audit entry naming both the transferring and receiving employee - Chapter 12: Audit Trail covers configuration changes, not check ownership. Vintage: First Gen 2.0 / Next Gen 3.5 archive, 2020. source |
| menu-pricing-topping-quantity-tiers | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu First Gen 2.0 menu-build article (updated April 2020; Wayback capture 2020-08-13) documents modifiers ON an ingredient, which is exactly the quantity/intensity tier mechanic: 'To add ingredient modifiers such as Extra cheese, 4 sugars, light mayo, etc: After the ingredient is added click "Add Modifier." Add a title, and price (if needed) for the modifier.' Chapter 1 gives the same pattern ('Espresso shot is an ingredient but multiple shots can be added. 1 shot, 2 shot, etc.'; 'Ingredients may be modified for example 1 slice, 2 slices, 3 slices'), so a tier is a distinct priced object rather than the ingredient added twice. SHORTFALL: each tier carries its own absolute price entered per price tier; no configurable price MULTIPLIER per tier is documented anywhere in the corpus. Vintage: First Gen 2.0, 2018-2020 documentation; live site silent. source |
| menu-pricing-modifier-price-by-parent-size | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu First Gen 2.0 menu-build article (Wayback capture 2020-08-13): ingredient groups and their ingredients are attached to the item and priced there - 'Add the ingredients by clicking "Add Ingredient", and add the title and the associated price (if needed)' - and 'existing ingredient group, ingredients, and modifiers can be associated with an item', so one shared modifier can carry a different price on a different parent item without being duplicated. Pricing is also multi-dimensional by price tier: 'At least one price tier is needed for pricing of modifiers, ingredients, and prep instructions.' SHORTFALL: the second axis is the price tier (meal period / location / daypart), not the parent item's selected size - item sizes are 'Portions' ('Portions allow the addition of item sizes and prices... large fries at $2.00 and small fries for $1.00'), and no per-portion modifier price or modifier-by-size matrix is documented. Vintage: First Gen 2.0, 2018-2020. source |
| menu-pricing-size-style-matrix | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu First Gen 2.0 menu-build article (Wayback capture 2020-08-13) documents one priced variant axis on the item - 'Portions allow the addition of item sizes and prices. For example, large fries at $2.00 and small fries for $1.00. Click on "Add Portion", create the title for the specific portion and set the Price' - and a second, separately priced axis for preparation style: 'Prep instructions, or modifiers, describe an item. For example, temperature of beef - well-done, medium, rare... Now add the Prep instruction by clicking "Add Prep Instruction", Add the title and the associated price (if needed).' SHORTFALL: the two axes compose additively (portion price plus prep-instruction price); no size x style grid with a per-cell base-price override is documented, and 'Portions are currently linked and will be changed for every item where the portion has been used'. Vintage: First Gen 2.0, 2018-2020; live site silent. source |
| payments-house-accounts | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu Next Gen 3.5 article (October/November 2020; Wayback capture 2020-11-28): 'Customers often use offline credit payment types to tender third-party DSP (DoorDash, Uber Eats, etc.), House Account, and other types of orders. However, managers would like to restrict their cashiers from using these without manager approval because they are not tied to a real tender type (cash, credit, or gift).' So a house account exists as an operator-created tender. SHORTFALL: it is only a payment type. The First Gen 2.0 Enterprise Configuration reference enumerates the payment-type categories available - 'Cash, Offline Credit, Check, Hotel Room Charge, Credit, Gift Card, GEM Room Charge, Marriott Room Charge, EmployeeMeal, Electronic Payment, Opera, StayNTouch' - with no house-account ledger among them, and no per-account credit limit, running balance, or statement/invoice generation is documented anywhere in the corpus. Vintage: First Gen 2.0 / Next Gen 3.5 archive, 2020. source |
| delivery-zones-polygon | unknown / F / never examined against a first-party surface | resolve-to-yes | 198th sweep, archived help centre. Qu Next Gen 3.5 release notes for v139 (17 Nov 2020; Wayback capture 2021-01-25) introduce a store-level Delivery Setting: 'New Delivery Setting at Store level that allows to set a Custom Area or a Delivery Radius.' The walkthrough is explicit: 'Besides being able to define delivery settings via a Maximum Delivery Radius, users will have the flexibility to configure their own custom delivery area... go to any Store, Delivery Settings tab and select: Custom Area. The system will request a KML file to be uploaded and once uploaded will show a map to preview the area.' The operator draws the shape in Google MyMaps ('Add lines or draw a shape. Draw the shape on the map to create your custom delivery zone'), exports KML, and sets Calculation Mode to Custom Area; the store must have a valid address 'so that the system can automatically generate coordinates.' That is an arbitrary map polygon, not a radius or ZIP list. VINTAGE: this is the 2020 Next Gen 3.5 generation, not the current Intelligent Commerce Platform; the live site (qubeyond.com/ordering/online-ordering, grade C) still advertises 'white-label delivery' as a hand-off mode but does not describe zone geometry, so persistence of the KML custom-area mechanism into the current product is not independently confirmed. Note also the article records that a drawable in-product map was then only 'in the roadmap'. source |
| delivery-address-validation | unknown / F / never examined against a first-party surface | resolve-to-yes | 198th sweep, archived help centre. Qu Next Gen 3.5 help article 'Changing Order Types from the Online Menu' (updated 19 Oct 2020; Wayback capture 2020-11-25): 'Guest will be prompted by the website to enter the delivery address to validate that delivery is available from this location. An actual physical address is required (i.e. 123 Main Street). If the store can deliver to the provided address, the user will get a success message... If the location cannot deliver to the provided address, the user will be prompted to either order pickup or search for other sites.' Out-of-zone addresses are therefore flagged and blocked before the order proceeds: 'Since a valid address is required to ensure the location can deliver, users will be required to enter and submit one before they can exit the prompt.' Geocoding against a mapping service is corroborated by the v139 delivery-area notes, which require a valid store address 'so that the system can automatically generate coordinates for the location' and use Google MyMaps/KML geometry for the area. VINTAGE: Next Gen 3.5, 2020 documentation; the live marketing site still lists delivery as a hand-off mode (grade C) but does not describe address validation, so the current implementation is not separately confirmed. source |
| delivery-zone-pricing | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. SHORTFALL: the documented model is one delivery area per store, not priced zones. Qu Next Gen 3.5 v139 (17 Nov 2020) documents a single store-level Delivery Settings tab whose Calculation Mode is either a 'Maximum Delivery Radius' or one uploaded KML 'Custom Area'; nothing in that configuration carries a fee, an order minimum or a quoted promise time. The delivery fee lives elsewhere entirely, as a service charge: Chapter 6 Configuration (First Gen 2.0) says 'Service charges such as gratuities or delivery fees may be added to Qu' with a Service Charge Category of 'Service Charge / Delivery Fee / Other Charge / Gratuity / Automatic Service Charge', configured at enterprise/store level against items, not against a geographic zone. So a fee and a validated delivery area both exist and are applied per store from the validated address, but per-zone fee/minimum/promise-time tiering is not documented anywhere in the archived corpus. VINTAGE: First Gen 2.0 (2018) settings reference plus Next Gen 3.5 v139 (2020); current product not covered. source |
| digital-account-saved-payment | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. SHORTFALL: saved payment is documented; saved addresses and one-tap reorder are not. Qu Web Ordering v139 (17 Nov 2020, Next Gen 3.5) documents guest accounts with stored cards under 'Store Saved Payment Information: (Same as Express) Saved payment is also supported with Aurus. Logged in users can save a card by clicking the checkbox. User can save multiple cards and can make payment using any single card at a time.' Card entry is through a hosted Aurus/Express iframe, i.e. the PAN is held by the processor. Logged-in accounts are further evidenced by the Punchh web-ordering flow ('Logged in users earn points by placing orders'). The archived corpus nowhere documents a saved-address book or one-tap reorder of a previous order, both of which the claim requires. VINTAGE: Next Gen 3.5 / Web Ordering 3.0, 2020-21; the current Intelligent Commerce Platform online-ordering page does not restate these mechanics. source |
| digital-scheduled-pacing | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. SHORTFALL: scheduled/future ordering is documented; per-daypart capacity throttling is not. Qu Web Ordering v140 (16 Dec 2020, Next Gen 3.5) documents the platform setting 'Future Order Acceptance Days' with two parameters, 'Minimum days - lowest number of days in advance an order can be placed (0 = same day, 1 = tomorrow...)' and 'Maximum days - highest number of days in advance an order can be placed', settable per order channel (web vs catering); v140/v141 also reference a 'Future Order Calendar prompt' and v141 a checkout 'time slot' that updates on expiry, so time-slotted future ordering exists. The store/group settings checklist names 'Bucket Scheduling' and 'Min Max Order Limits' and 'Kitchen Buffer Lead Time' but never defines them, and no article describes slot capacity limits or automatic closing of saturated slots. VINTAGE: Next Gen 3.5, Dec 2020 / Jan 2021 release notes; not confirmed for the current platform. source |
| reporting-scheduled-delivery | unknown / F / never examined against a first-party surface | resolve-to-yes | 198th sweep, archived help centre. Qu Reports Quick Guide (Next Gen 3.5, updated 2020-10-19, archived 2020-11-28): 'the user can save each report as a custom report (with the filters and customizations that you have selected), scheduled (to be emailed regularly), exported (downloaded or emailed as either an Excel file, CSV, or PDF), and printed' - i.e. any report in the catalogue, not a fixed subset. The companion article 'How do I schedule reports to auto-send? (Next Gen)' gives the mechanics: select the report, Click Schedule, then set Send Time, Time Zone, Frequency and Employees (recipients must have an email on their profile). The First Gen 2.0 admin guide documents the same Email Reports feature from 2017. Vintage: Qu Next Gen 3.5, 2020 archive; not re-verified against today's Intelligent Commerce Platform, but recurring emailed reports are a basic mechanic and the live Brand & Franchise Management page still lists 'Native reporting and notification capabilities'. source |
| reporting-guest-cohorts | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu Reports Quick Guide (Next Gen 3.5, Oct 2020) enumerates a Customers report: 'Included all customers and their information entered on the POS or the web ordering site. The collected information includes first name, last name, phone number, email address, last order date, total orders, the total dollar amount spent, and registration status.' That is guest-level lifetime spend and visit count tied to identifiable records from POS and online ordering. Shortfall: the report is a flat customer list - the guide documents no new-versus-returning guest counts, no visit-frequency cohorting and no loyalty-linked segmentation (loyalty in this vintage is the third-party Punchh integration). Vintage: Next Gen 3.5, 2020; the live site markets 'normalized guest and operational data' but publishes no cohort report. source |
| reporting-server-scorecards | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu Reports Quick Guide (Next Gen 3.5, Oct 2020): every report carries an 'Employee Filter - Each report shows data for all employees, and the user can filter them to display data for a specific employee'; the Labor group includes a Tip report ('Displays all tips collected by each employee') and a Labor Red Flag report ('Displays the total activity for several KPIs... useful for analyzing whether the store or employee uses specific actions (e.d voids) too often'); Voided Items 'Displays all voided items by an employee' and Refunds 'Lists all refunded checks by an employee'. Shortfall: there is no per-server scorecard object - average check appears only on Hourly Sales (by hour, not by server), and items per check, category attachment rate and tips as a percentage of sales are not documented anywhere in the catalogue. Vintage: Next Gen 3.5, 2020. source |
| labor-server-performance-metrics | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu Reports Quick Guide (Next Gen 3.5, Oct 2020) documents per-employee exception metrics - 'Voided Items - Displays all voided items by an employee', 'Refunds - Lists all refunded checks by an employee', 'Labor Red Flag - Displays the total activity for several KPIs. This report is useful for analyzing whether the store or employee uses specific actions (e.d voids) too often' - plus an employee filter on every report so sales can be sliced per cashier. Shortfall: void and refund activity by employee is documented but average check per server, items-per-check and category attachment rate are not; comps are folded into discounts ('Discounts generally include manager comps and coupons', Report Calculations) with no per-employee comp rate. Vintage: Next Gen 3.5, 2020 archived help centre. source |
| labor-qualified-tips-w2-reporting | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Report Calculations (First Gen 2.0, updated 2020-04-20, archived 2020-12-01) shows the Tip Track report separating the two tip populations explicitly: 'Total Receipts = Gross Sales + Charged Tips + Cash Tips' and 'Total Direct Tips = Charged Tips + Cash Tips'; the Next Gen Labor reports add a Tip report that 'Displays all tips collected by each employee' and a Payroll Summary of regular/overtime hours and earnings per employee. Shortfall: cash-versus-charged separation is present but nothing in the corpus carries a Treasury tipped-occupation code, a W-2 Box 12 code TP field or Box 14b output, and no payroll-export format is documented at all. Vintage: First Gen 2.0 / Next Gen 3.5, 2017-2020 - this documentation predates the TY2026 requirement entirely, so the missing conjunct is untested rather than refuted. source |
| labor-manager-override-audit | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Chapter 12: Audit Trail (First Gen 2.0, updated 2020-04-20): 'The Qu audit trail provides a detailed activity history of changes occurring within Qu. Changes can be tracked based on Date, Employee, Module, Location and any combination of the above. The report can also be exported as a csv document. Audit Trail can only be accessed from the Enterprise Level of Qu Enterprise Intelligence.' Approver attribution exists at the POS: restricting till functions means 'the POS will present a manager prompt to the cashier when performing restricted actions', and per 'Assigning an Employee Mag Card to a User' (Jan 2021) the manager clears it by swiping their own card. EI time-entry edits are attributed (a 'Last Edit By' field and an 'Edited shifts' filter in Labor Summary, v141-v143 release notes) and 'you are required to enter a comment to indicate the reason for manually updating the entries'. Shortfall: the docs never state that POS manager overrides themselves land in the audit trail, and immutability or tamper-evidence is nowhere asserted. Vintage: First Gen 2.0 (2018-2020) and Next Gen 3.5 (2020-21). source |
| multi-location-config-audit-log | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Chapter 12: Audit Trail (First Gen 2.0, updated 2020-04-20) documents a corporate-level change log: 'a detailed activity history of changes occurring within Qu. Changes can be tracked based on Date, Employee, Module, Location and any combination of the above. The report can also be exported as a csv document. Audit Trail can only be accessed from the Enterprise Level of Qu Enterprise Intelligence.' Who / when / where / which module, queryable and CSV-exportable by corporate, is therefore established. Shortfall: the article does not enumerate which configuration objects the 'Module' axis covers - price, tax, permission and discount are each configurable per Chapter 6 but none is named as audited - and immutability is not claimed. Vintage: First Gen 2.0, article dated 2018-02-27 and updated 2020; the live site markets 'Centralized Data Governance' and 'Granular permissioning and user administration' but publishes no audit-log page. source |
| multi-location-central-labor-policy | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. What is a Payroll Profile? (Next Gen 3.5, April 2020): payroll profiles are created under Employee Groups and configure 'Weekly Overtime Starts After' plus an overtime multiplier, a daily overtime threshold, a double-overtime threshold and multiplier, and break rules (Paid or Unpaid, maximum paid time on break, minimum time on break before paid, minimum work time for paid-break eligibility). Terminal-level enforcement is documented separately in Chapter 6: Configuration, whose Labor setting reads 'Clock in Tolerance Minutes - When labor management is in use, this value limits an employee clockin to the scheduled shift time +/- the specified tolerance in minutes. Default 5' - and Chapter 6 settings are set at Enterprise level and overridden per store or revenue centre. Shortfall: the overtime and break rules attach to employee groups rather than location groups and are pay calculations applied after the fact; only clock-in tolerance is enforced at the terminal, and predictive-scheduling compliance appears nowhere in the corpus. Vintage: Next Gen 3.5 and First Gen 2.0, 2018-2020. source |
| hardware-commodity-devices | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. The archived Hardware Videos section documents Qu running on a general-purpose Windows PC terminal built by a third-party OEM rather than a Qu-proprietary device: 'Swap SSD Hard Drive on Touch Dynamic Acrobat Terminal', 'Replace Terminal MSR (Magnetic Stripe Reader)' on a Touch Dynamic terminal, 'Removing terminal cable and port covers', and a troubleshooting step reading 'Tap the windows icon in the bottom left of the screen'. The MSR driver article names the part as a 'Magtek MagneSafe Magnetic Stripe Reader Device' reinstalled from Windows Device Manager. Shortfall: nothing documents an operator buying or supplying their own terminal - Chapter 7: POS Terminals states flatly 'Activating a new terminal must be completed by Qu' - and no iPad or Android tablet POS client appears anywhere in the 210 archived articles. Vintage: First Gen 2.0 / Next Gen 3.5, 2020 captures; today's product is the Qu Business Edge (Qube) edge appliance, which this archive predates. source |
| commercial-hardware-not-locked | unknown / F / never examined against a first-party surface | resolve-to-yes | 198th sweep, archived help centre. Qu's own help centre documents the product operating on third-party, non-proprietary hardware throughout: a 'Manual Transaction Guide for Ingenico IPP320' PIN pad (First Gen 2.0, March 2020); a 'Magtek MagneSafe Magnetic Stripe Reader Device' as the terminal MSR, whose driver the operator uninstalls and reinstalls from Windows Device Manager (Nov 2020); Touch Dynamic Acrobat Windows terminals with operator-serviceable SSD and MSR swaps; and ChefTab as the KDS, configured by the operator through 'Cheftab Settings/Preferences' ('How do I Prevent Bumping a Chit on the KDS?', Oct 2020). No Qu-branded terminal, printer or reader appears anywhere in the 210 archived articles. Corroborated live: ChefTab and Logic Controls both appear in Qu's certified-partner directory today, under Kitchen/KDS and Hardware + Digital Signage respectively. Vintage: First Gen 2.0 / Next Gen 3.5, 2020, with live partner-directory corroboration. source |
| hardware-printer-compatibility | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Chapter 8: Printing (First Gen 2.0, updated 2020-04-20): 'Qu supports two types of printers: Receipt printers and kitchen printers'; receipt printers are configured per terminal by 'Scroll to Printer, select POS Printer Model... Select the desired printer model', and kitchen printers by 'Select the printer model' plus a path and routing into kitchen print groups and terminal print groups. Network attachment is documented in troubleshooting: 'Ensure the Ethernet cord is securely fastened at the printer port and the wall/switch', and disconnecting the POS 'will affect the communication between POS and any network printers'. Shortfall: a selectable model list implies more than one supported device, but the archive never names a printer manufacturer, never says ESC/POS, and publishes no compatibility list - so multi-manufacturer support is implied, not established. Vintage: First Gen 2.0, 2018-2020. source |
| hardware-peripherals | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Chapter 6: Configuration (First Gen 2.0) enumerates a Barcode Scanner settings block ('Number of sentinel characters at end of string provided by symbol/barcode scanner (if any). These characters are removed from the scan output. Default 3', plus a start-sentinel length) and a Tills block whose 'Require Till Assignment' setting governs whether 'users must claim till in order to accept cash transactions or open, or pop, the cash drawer'. Scales are supported for by-weight items - 'Why is the Scale Not Weighing? (Next Gen)' instructs 'Remove all items from the scale, Power down the scale for thirty seconds... ensure that the scale is showing a 0.00 weight'. Customer-facing displays are a first-class output surface in the v139 release notes: modifiers 'now display with their portion amount on the same line on the Detail screen, KDS, Printers, and Customer Facing Displays.' Shortfall: no published compatibility list of any kind, and multi-drawer-per-terminal is nowhere documented. Vintage: First Gen 2.0 / Next Gen 3.5, 2018-2021. source |
| extensibility-custom-fields-scripting | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Chapter 6: Configuration (First Gen 2.0) documents two operator-defined extension surfaces inside Enterprise/Store Configuration. The Client settings block carries 'Prompt for Check Extension Data - Specify JSON Format Extension Data', i.e. operator-specified JSON fields prompted for and carried on a check. System Lookups let the operator 'Add custom values using System Lookups. For example, add your own reasons for voiding a check or discounting an item', covering Void Reasons, Time Entry Reasons, Return Reasons, Paid In/Out Reasons, Discount Reasons, Order Types and Inventory Units. Shortfall: these are configuration-driven custom values plus a custom JSON payload on one object, not user-defined fields across POS objects, and no vendor-hosted scripting or custom-logic runtime appears anywhere in the 210 archived articles or the v139-v143 release notes. Vintage: First Gen 2.0, 2018-2020. source |
| commercial-export-customer-and-loyalty | unknown / F / never examined against a first-party surface | resolve-to-partial | 198th sweep, archived help centre. Qu Reports Quick Guide (Next Gen 3.5, Oct 2020): the Customers report covers 'all customers and their information entered on the POS or the web ordering site... first name, last name, phone number, email address, last order date, total orders, the total dollar amount spent, and registration status', and every report can be 'exported (downloaded or emailed as either an Excel file, CSV, or PDF)' - so guest records are operator-exportable in machine-readable form. Shortfall: no loyalty point ledger or balance is exportable from Qu itself (loyalty in this generation is the third-party Punchh integration, whose 'LifetimePoints and totalActivePoints' live on Punchh's side per the v142 release notes), and while First Gen listed a Gift Cards report, no gift-card liability balance export is documented. Vintage: Next Gen 3.5, 2020. source |
| commercial-month-to-month-contract | no / B, cited to /terms-and-conditions — 'Qu publishes no POS subscription terms of any kind... there is no publicly offered month-to-month tier' | downgrade-to-unknown | I confirmed the factual premise myself: /terms-and-conditions is website terms of use only ('regarding the use of our website'), and 20 probed contract paths (/msa, /master-subscription-agreement, /subscription-agreement, /terms-of-service, /legal, /customer-agreement) all return the same 71,964-byte 404. But the inference does not follow. The claim asks whether a month-to-month tier is publicly OFFERED; Qu publishes no pricing and no subscription contract at all, so the offer is unobserved, not absent. Corpus precedent is decisive against the sweep: all twelve `no`s on this cell rest on a published agreement stating a term, whereas olo ('No public MSA and no published pricing. Enterprise-negotiated.') and speedline ('No subscription term for the core POS is published anywhere public') are the identical fact pattern and are scored unknown/F. The Adyen User Agreement's indefinite-term clause governs payment processing and is not Qu's POS subscription. source |
| commercial-privacy-dsar-tooling | no / B, cited to /privacy-policy — conjunctive claim fails on the published-DPA conjunct | upheld | Located the supporting text myself and the verdict survives, because unlike the hardware cells this claim's failing conjunct is a PUBLISHED artifact, which public-surface exhaustion can genuinely settle. /dpa, /data-processing-agreement, /data-processing-addendum, /legal/dpa, /gdpr and /ccpa all 404 to a live probe; the 199-page sitemap dump contains no DPA; the Adyen document's clause 9.2 allocates controller/processor roles between Adyen and the merchant and points to Adyen's own Privacy Statement, not to a Qu DPA. I read the privacy policy directly: it expressly carves the product data plane OUT of its scope ('Information processed on behalf of our customers through Qu products and services, where separate contractual terms may apply') — Qu itself pointing at unpublished contractual terms — and routes every request to email, with no self-serve intake and no guest-record lookup or delete tool. Matches the restaurant365 precedent exactly. source |
| hardware-rma-sla | no / B, cited to /terms-and-conditions — 'the surface is now exhausted... Nothing is published' | downgrade-to-unknown | The measurements are right and the conclusion is too strong. I re-ran the string search with word boundaries (the sweep's own scan would have false-matched 'RMA' inside 'information'/'transformation'): 'advance exchange', 'next-business-day', 'depot', \bRMA\b and 'return merchandise' are genuinely zero across the 1.85 MB dump, and the four \bwarrant hits are Adyen boilerplate. But the surface is NOT exhausted for this proposition. Qu supplies hardware — the Smart Edge device — and a warranty term and RMA turnaround live in the customer contract and in support.qubeyond.com, which 302s to a Document360 login on every path. Corpus precedent confirms: the only grade-B `no`s are agilysys, where the published sales terms positively DECLINE the claim, and vendors that sell no hardware at all. Qu's pattern is lightspeed-restaurant, spoton and touchbistro — searched a fuller surface, found nothing, scored unknown. source |
| hardware-usable-after-churn | no / B, cited to /terms-and-conditions — 'No Qu documentation confirms the position in either direction' | downgrade-to-unknown | The sweep's own note states the finding correctly and then records the wrong value: 'No Qu documentation confirms the position in either direction' is the definition of unknown, not of no. I verified the underlying facts — the three-document legal set has no title, ownership or post-termination hardware clause, and the thought-leadership line about proprietary hardware is Qu describing competitors, not committing on its own equipment. Nothing here enumerates alternatives or says the capability is unsupported; the vendor is simply silent, and the contract that would settle it is unpublished. speedline is the governing precedent on this cell with the same reasoning and sits at unknown/F. source |
| payments-qr-guest-pay | partial / C, cited to the Winter 2025 release — tableside QR ordering read as partly satisfying scan-to-pay-the-check | downgrade-to-unknown | I read the source page myself and this is a different object credited toward the wrong claim. The claim requires a guest to scan a code on the printed check or table tent 'to view and pay THE CHECK', with the payment 'closing the check in the POS automatically' — a server-fired check that already exists. What Qu describes is an online-ordering channel: the QR opens a menu; the guest authors the order and pays for it at creation. There is no check to view, no check to close, and no evidence about whether a POS-originated check can be surfaced by a scan. The only overlap with the claim is 'a QR code and a guest's phone'. A partial whose named shortfall removes the claim's entire distinguishing mechanic is not a partial. source |
| order-capture-bar-tab-preauth | no / C, cited to /multi-unit-pos-guide — 'Built exclusively for QSR and Fast Casual' read as a capability denial | downgrade-to-unknown | I pulled the cited sentence in context and it will not bear the weight. It is one cell of a two-column competitive comparison table under the heading 'What Changes with Qu', in a row labelled 'Industry Focus', sitting between 'Built For Who' and 'Menu Management' and paired with an attack on rivals. That is a market-positioning statement about who Qu sells to and prioritises on its roadmap, not an enumeration of check-handling features and not a statement that card pre-authorization is unsupported — precisely the marketing-sentence-as-denial failure the evidence rules warn about, and grade D material besides. The corroboration is also absence, not enumeration: a single seasonal release-notes page describing Combine Checks and Check Search enumerates one release's changes, not the product's capability set. source |
| kitchen-order-throttling | partial / C, cited to /resource-center/qus-smart-kitchen-vision — 'AI-generated promised ready times' read as satisfying the 'extends quoted prep times' branch | downgrade-to-unknown | I read the cited page in full. It is a six-bullet marketing announcement dated October 9, 2024, titled 'Qu's Smart Kitchen VISION', opening 'Another industry first from Qu' and closing with a broken 'Learn more' link — a roadmap teaser, not documentation, and it establishes a claim rather than a fact. The credited bullet's stated purpose is delivery ETA ACCURACY, not shedding load; an estimator that predicts when food will be ready is a different object from a control that extends quotes to protect the kitchen. The claim's threshold clause governs both of its branches — 'once a configurable order-volume or ticket-time threshold is crossed' — and there is no threshold, nothing operator-configurable, and no pacing or delayed release anywhere. The sweep's own note concedes the extension is 'not gated on an operator-configurable threshold', which removes the claim's defining mechanic rather than naming a limit within it. source |
| delivery-86-sync | yes / grade B — I verified the program requirements page independently: Preferred partners 'must support all of the following features' including real-time menu syncing, real-time 86ing, order ready signal, item polling, and detailed error reporting, with 'supporting' defined as built, launched, and used by at leas | downgrade-to-unknown | DoorDash partner-integrations registry pass. yes/B -> unknown/F. A `yes` at grade B stood here on a syllogism DoorDash's own data falsifies, and no sound replacement exists. The reasoning was that Preferred partners must support a feature set including real-time 86ing, and Qu is Preferred, therefore Qu supports it. DoorDash's partner registry shows the major premise does not hold: of the 12 PREFERRED providers 10 carry featuresCompleted=8, but `qubeyond_v2` carries 7 and `checkmate` 6 — and Qu's single missing feature is exactly `ITEM_LEVEL_86`, real-time item 86ing. The one vendor the inference was applied to is one of the two for which it fails. The cell cannot simply flip to `no`: a false flag is an unreliable negative (Lavu documents a DoorDash store pause while its store-availability flag reads false), and the claim reads on connected third-party channels generally while Qu documents Uber Eats, Grubhub, ezCater and Monkey, about which this instru source |
| delivery-86-sync | unknown / grade F — A `yes` at grade B stood here on a syllogism DoorDash's own data falsifies, and no sound replacement exists. The reasoning was that Preferred partners must support a feature set including real-time 86ing, and Qu is Preferred, therefore Qu supports it. DoorDash's partner registry shows the major premise does not hold: o | resolve-to-partial | 260th session, DoorDash partner-integrations feature-flag pass. unknown / grade F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. Re-probed 2026-09-12: the registry payload is byte-identical to the 259th’s frozen copy (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers) and every quotation below was confirmed verbatim-present in the bytes fetched that day. The flag `ITEM_POLLING`, which DoorDash labels ‘Real-time availability checking’, is TRUE for `qubeyond_v2`, inside the PREFERRED_PARTNER collection, which is active for this provider. It is one of the eight high-quality features and the programme page defines it: ‘Allows DoorDash to verify item availability in real time, helping reduce out-of-stock cancellations’. So item-level availability does reach DoorDash in real time for this integration. TWO NAMED SHORTFALLS. First, the mechanism is the wrong direction for the claim as written: the claim requires the POS to PUSH item-level out-of-stock status out to the channel, and `ITEM_POLLING` is DoorDash pulling. The push flag is `ITEM_LEVEL_86` (‘Real-time item 86ing - updates item availability across systems when items are marked unavailable’) and it reads false for `qubeyond_v2` — this is Qu’s single missing high-quality feature, the one that made it 7 of 8 and falsified the Preferred syllogism this cell previously rested on. That false is not read here as positive evidence of absence; it is read only as the absence of the certified push mechanism inside this integration, which is why the verdict is not `yes`. Second, the claim reads on connected third-party channels generally while Qu documents Uber Eats, Grubhub, ezCater and Monkey, about which this instrument is silent. source |
| delivery-store-pause | partial / grade D — Operators can pause third-party integrations from the Channel Management dashboard; timed auto-reactivation is not documented. | upheld | 260th session (regrade-D-to-B), DoorDash partner-integrations feature-flag pass. partial / grade D -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. Re-probed 2026-09-12: the registry payload is byte-identical to the 259th’s frozen copy (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers) and every quotation below was confirmed verbatim-present in the bytes fetched that day. The flag `STORE_AVAILABILITY_WEBHOOKS`, which DoorDash labels ‘Integrated close/pause store’, is TRUE for `qubeyond_v2`, inside an active collection. This replaces a grade-D marketing citation: Qu’s own Channel Management page (https://www.qubeyond.com/management/channel-management, retrieved 2026-08-01) asserts that operators can pause third-party integrations from one dashboard, and the registry now attests the same capability for DoorDash from the counterparty side. SHORTFALL UNCHANGED: the claim requires the pause on EACH connected marketplace plus a timed auto-reactivation, and neither source carries a reactivation timer — no flag in the registry covers one — while only DoorDash is attested of the connected channels. source |
| kitchen-channel-pause-propagation | yes / grade B — Channel Management pauses third-party integrations and re-syncs menus from one dashboard; item 86ing to DoorDash is a DPIP requirement Qu meets. | upheld | 260th session (note-correction-verdict-stands), DoorDash partner-integrations feature-flag pass. yes / grade B -> yes/B. Channel Management pauses third-party integrations and re-syncs menus from one dashboard, which satisfies the claim’s store-pause disjunct on the vendor’s own documentation. CORRECTED 2026-09-12: this note previously added ‘item 86ing to DoorDash is a DPIP requirement Qu meets’. That clause was an instance of the Preferred syllogism and DoorDash’s own registry (https://merchants.doordash.com/api/partner-integrations) falsifies it — `ITEM_LEVEL_86` reads false for `qubeyond_v2`, which carries 7 of the 8 high-quality features, not 8. The clause is removed. The verdict is unaffected because the claim is a disjunction (‘a store or 86ing an item’) and the pause disjunct is independently documented by the vendor. The registry separately reads `STORE_AVAILABILITY_WEBHOOKS` TRUE for this provider, which corroborates that disjunct on DoorDash. source |
| delivery-86-sync | partial / grade B — resolved from unknown on 2026-09-12 off `ITEM_POLLING` reading TRUE for `qubeyond_v2`, with two named shortfalls, the first of which was that "the mechanism is the wrong direction for the claim as written: the claim requires the POS to PUSH item-level out-of-stock status out to the channel, and `ITEM_POLLING` is DoorDash pulling" | downgrade-to-unknown | This cell should not have been scored. I re-fetched the registry (byte-identical, md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers, tiers 12/47/5, 23 distinct flags) and both DoorDash pages, and the flag states are exactly as recorded — ITEM_POLLING true, ITEM_LEVEL_86 false. The defect is scope, not measurement. DoorDash itself separates the two capabilities in the feature-copy dictionary carried verbatim on both its integrations page and its programme page: realTime86ing is "86 items on your POS or middleware and see the changes on your DoorDash store in real-time, reducing cancellations" — the atlas claim verbatim — while realTimeItemAvailability is "Validate item availability in real time, reducing out-of-stock cancellations.", which is order-time validation and leaves the DoorDash menu state untouched. The flag that IS the claim reads false; the flag scored is the publisher-distinguished sibling. A `partial` whose own first named shortfall is that the cited mechanism is not the claim's mechanism is not a partial — it is an unknown with a citation attached, and it is the same homonym error the 260th correctly rejected for MENU_CONTAINS_ITEM_LEVEL_BASE_PRICE. The 259th pass had already killed this cell on a fuller reading and named item polling among the DPIP features without treating it as evidence here; reinstating a score on it is a regression. Not `no`: a false flag is not positive evidence of absence. source |
| delivery-store-pause | partial / grade B — regraded from D on 2026-09-12 off `STORE_AVAILABILITY_WEBHOOKS` TRUE for `qubeyond_v2`, shortfall unchanged (no timed auto-reactivation; DoorDash only) | upheld | Independently confirmed. STORE_AVAILABILITY_WEBHOOKS is true for qubeyond_v2 inside FEATURE_COLLECTION_NAME_LIVE_ORDER_MANAGEMENT with active:true, and the label "Integrated close/pause store" is verbatim-present in the feature dictionary inside a <script> block on merchants.doordash.com/en-us/integrations — DoorDash's own merchant-facing gloss, so the direction question the flag name raises is answered by the publisher. The regrade D->B is sound: this is counterparty-published integration documentation, and B is correctly treated as the ceiling. I also checked the shortfall is not contradicted: none of the 23 flag names bears on a reactivation timer, and only the DoorDash leg is attested of the "each connected third-party marketplace" the claim requires. Value unchanged; I tightened the note to name the collection explicitly and to record the robots directives read in full. source |
| kitchen-channel-pause-propagation | yes / grade B — note corrected 2026-09-12 to withdraw "item 86ing to DoorDash is a DPIP requirement Qu meets", verdict held on the vendor's Channel Management page as the store-pause disjunct | downgrade-to-partial | The withdrawal is warranted — ITEM_LEVEL_86 is false for qubeyond_v2, so the Preferred syllogism clause had to go — but removing it removed the basis. What is left is www.qubeyond.com/management/channel-management, a first-party product feature page written to sell, which is grade C under the evidence rules, not B; the same page underwrites other Qu cells graded C and D, so the B here is an internal inconsistency as well as an over-grade. A differentiator `yes` requires grade A or B, and this no longer has one. On the merits the page establishes an operator action in one dashboard, not automatic propagation to each of the three marketplaces the claim names; the registry attests only the DoorDash leg (STORE_AVAILABILITY_WEBHOOKS true, active collection), and the claim's 86 disjunct is unattested with ITEM_LEVEL_86 false. Downgraded to partial at grade C with three named shortfalls. Nothing here supports a `no`. source |
| delivery-injection-error-visibility | yes / grade B — Channel Management provides error visibility and validation reporting; detailed order error reporting is a DPIP requirement Qu meets. | downgrade-to-partial | 260th session, Preferred-syllogism residue sweep. yes / grade B -> partial/C. RE-BASED 2026-09-12: this cell stood at `yes`/B on a note reading ‘Channel Management provides error visibility and validation reporting; detailed order error reporting is a DPIP requirement Qu meets.’ The second clause was an instance of the DoorDash Preferred syllogism, which DoorDash’s own partner registry (https://merchants.doordash.com/api/partner-integrations) falsifies as a general inference — 10 of the 12 PREFERRED providers carry 8 of 8 high-quality features but `qubeyond_v2` carries 7 and `checkmate` 6, so Preferred membership does not entail any particular feature. The clause is removed. What the cited page does carry, read 2026-09-12, is a Channel Health and Error Visibility section: ‘Built-in validation reports and error logging give operators full visibility into menu mismatches, sync failures, and integration issues, so teams can identify and resolve issues before they impact guests.’ It also lists ‘Channel-level controls for availability, routing, and status’ and ‘Downloadable reports for rapid issue resolution’. That is two of the claim’s three components — a failed-sync view and per-channel status. SHORTFALL: the third component, alerting on failure, is not attested; the string `alert` occurs zero times on this page, and that zero is bounded to this one page rather than to Qu’s corpus, so it is a shortfall and not a `no`. GRADE: C, not B. The page is a first-party product page written to sell — it carries a Schedule a Demo call to action and capability bullets rather than configuration instructions — and a differentiator `yes` requires grade A or B, which this does not reach. CORROBORATION, not the basis: the registry reads `DETAILED_ERROR_SPEC` TRUE for `qubeyond_v2`, whose feature-copy dictionary on https://merchants.doordash.com/en-us/integrations glosses it ‘Provide actionable error reasons for failed orders, reducing repeat order failures.’ That describes what the provider transmits into DoorDash’s contract, not what the vendor shows the operator, so it cannot carry this claim’s subject on its own. source |
| delivery-menu-push | yes / grade B — Single menu pushes to third parties with channel-specific pricing; real-time menu syncing is a DPIP requirement Qu meets. | upheld | 260th session, Preferred-syllogism residue sweep. yes / grade B -> yes/C. RE-BASED 2026-09-12: this cell stood at `yes`/B on a note reading ‘Single menu pushes to third parties with channel-specific pricing; real-time menu syncing is a DPIP requirement Qu meets.’ The second clause was an instance of the DoorDash Preferred syllogism, which DoorDash’s own partner registry (https://merchants.doordash.com/api/partner-integrations) falsifies as a general inference: `qubeyond_v2` carries 7 of the 8 high-quality features, not 8, so Preferred membership entails no particular feature. The clause is removed and the verdict re-based on the page’s own words, read 2026-09-12: ‘Real-time synchronization of menu data and availability’ and ‘Centralized configuration for menus, pricing, and rules’, with the channel scope set by ‘From pausing a third-party integration to re-syncing menus, control every channel in real time from a single dashboard.’ GRADE: C, not B — the page is a first-party product page written to sell, not documentation. The claim is table-stakes weight, so a `yes` at grade C is within the grade floor, which binds differentiator claims only. NOT attested on this page and therefore the honest limit of the verdict: photos and modifiers specifically, which the claim names. CORROBORATION, not the basis: the registry reads `MENU_PULL_SUPPORTED` TRUE for `qubeyond_v2`, glossed in the feature-copy dictionary on https://merchants.doordash.com/en-us/integrations as ‘Automatically pull the most up-to-date version of your menu from your provider into DoorDash, reducing cancellations’ (the doubled space is the publisher’s). That attests the DoorDash leg from the counterparty side at grade B; the other marketplaces rest on the vendor page alone. source |
| reliability-menu-build-service | unknown, grade F | upheld | Proposed partial from Qu's retired blog / HubSpot / archived www surface (267th session); rejected on verification: Quote match (node String.includes on raw bytes after stripping <!-- --> comments): span 1 "Optimized online menu build and marketing launch services" = true in orderup.live.html and orderup.raw.html, false in the flyer; but the note quotes it as "Optimized online menu build and marketing launch services, at no cost.", which is false in both HTML files because the raw bytes are "...launch services</strong>, at no cost." -- the note quote spans a </strong> close (disallowed). Span 2 (flyer, 72 hours / Qu resources doing menu configuration) = true in orderup-flyer.raw.txt. Liveness: curl of https://go.qubeyond.com/qu-orderup returned 200, 29375 bytes, no redirect (byte-identical size to the local live copy); soft-404 control https://go.qubeyond.com/qu-orderup-zz9-nonexistent-7731 returned 404 (29719 bytes), so the 200 is a real page, not a catch-all. Grounds for rejection: (1) Off-subject. OrderUP is a separate promotional product: the page H1 is "Free Online Ordering to Survive COVID & Beyond", it calls it "a dedicated online-only, all-digital POS product, available to any restaurant and free for 90 days", and a heading says "No Changes to Your Existing POS". The flyer calls it a "quick-start, all-virtual online ordering product that requires no hardware and no changes to your current technology". It is sold to restaurants on someone else's POS, so its free set-up says nothing about how Qu POS is onboarded. The cell asks whether the vendor builds the initial menu during onboarding of the rated product. Configuring an online-ordering menu under a promotion is a different act done for a different product. (2) Stale, not present tense. The flyer ties the offer to "no charge for 90 days (thru July 31)" and to surviving COVID (spring 2020). The live page is an orphaned HubSpot landing page (its body still carries a 2022 copyright block beside the 2026 footer) advertising an offer that has visibly expired, and nothing shows the service is still performed. (3) A partial has to be a partial of the cell subject. The proposal's own Shortfall concedes that nothing on Qu's open surface says Qu builds the initial menu for a POS deployment. That concession leaves no conjunct of the cell met for the subject, so the partial undercuts itself (per the rule that a partial falling short on every conjunct refutes itself). The quotes are genuine grade-C marketing and could appear in the unknown's rationale as scope-rejected context (an expired 2020 OrderUP promotion included free online-menu configuration), but they cannot move the cell. Keep unknown/F. source |
| menu-pricing-included-allowance | unknown, grade F | resolve-to-partial | Span checks (node String.includes over RAW bytes of the local copy, md5 fb5fbe2fe87489185db5eb3496feee3b, 142260 bytes, matching the proposal): 'FreeQuantity: 0,' x3, 'MinSelectQty: 0,' x1, 'MaxSelectQty: 0,' x1, 'IsRequired: false,' x2, 'SelectedQuantity: 0,' x2, all proposal quotes also match with stated counts. FreeQuantity uses: line 780 (new modifier group initialiser), line 1168 (new ingredient group initialiser), line 1489 (new ingredient-modifier group initialiser) - all three are literal defaults of 0; there is no read, comparison, validation, snackbar, or price computation on it, and a grep over the whole .cache/q267-qu tree finds FreeQuantity only in item.js (and the proposal). Price code in item.js only fills per-tier Prices arrays for items/portions/modifiers/ingredients; none references FreeQuantity. ComboRules and Services modules do not mention it. Trap 1: the field name makes an included-allowance reading plausible but not proven (could be a free-choice count or unused field); the proposal's 'an item can carry a configured free (included) quantity' asserts semantics the code does not show. Trap 2: DefaultToInclude validation (lines 1133-1150, 1390-1422) is about default recipe ingredients vs min/max selection counts, not an allowance; the proposal leaned on those messages, so they were removed from the evidentiary chain. Trap 4: modules are namespaced Gusto.POSAdmin.* ('GUSTO:' message prefixes), Qu's former name, on ei.qubeyond.com - first-party admin source. Trap 5: partial kept only because the first conjunct is weakly evidenced by a first-party data-model field literally named FreeQuantity on modifier and ingredient groups; the note now states that the semantics rest on the identifier alone and names the overage-charging and substitution shortfalls. Grade A (source code), archived so capped at partial. No Wayback refetch was done; the local copy's md5 matches the proposal. source |
| delivery-daas-fallback | unknown, grade F | upheld | Proposed partial from the admin.qubeyond.com back office source maps / pay-admin bundle (305th session); rejected on verification: Re-fetched 2026-09-15 (robots 404): 87c2a3b01adfe10ed9b8.js 200 98,750 B, 8fc0d1fe5de12dff9911.js 200 3,033,026 B, c74faad8e8452f6f5259.js 200 166,776 B. The quotes are in the served bytes, though offsets drift slightly ('"DoorDash Drive"' @63484 not 63475, 'In-House' @76122 not 76119). The taxonomy claim is only about automatic overflow rules: no in-house driver available, out of zone, or past a wait threshold. The analyst admits none of those conditions exists, so the proposed partial falls short on every one of them and cancels itself out. Tokenised controls over the chunk find zero courier/driver/overflow/fallback. The one 'Threshold' is the guest-tracking 'ETA Alert Threshold (minutes)', not a dispatch rule. Qu also has no in-house driver entity at all, so 'no driver available' cannot even be expressed. The proposal's claim that web availableDeliveryMethods 'also holds OwnDelivery methods' is not in this chunk. The web section (@61570-62500) only pushes or splices the DoorDash ThirdParty entry. The only OwnDelivery push (@78974) is in Web Catering, where the provider is an exclusive either/or on availableDeliveryMethods[0] (@79344). That works against hybrid dispatch, not for it. Flipdish's partial/A precedent had first-class in-house drivers (AssignDriverToOrder) alongside a courier config; Qu has neither drivers nor a documented overlap. What the chunk does show is a native DoorDash Drive toggle, with required service-charge and gratuity IDs. That is evidence for delivery-daas-dispatch, which is already scored partial/B for qu, so scoring it here as well would count one toggle twice. Send it to a delivery-daas-dispatch re-grade, not to this cell. Leave the cell at unknown/F, with the rationale updated to say the admin client shows a DoorDash Drive method toggle and no overflow rule. source |
| payments-chargeback-tooling | unknown, grade F | resolve-to-partial | I re-fetched the bundle live: 6,357,923 B, byte-identical to the cache. robots.txt and the .js.map both return the 452 B SPA shell (title 'Payments Portal'), so there is no robots file and no source map. All quotes are verbatim. Three offsets were off: 'Defend chargeback' is at 5734508, not 5734461, and both UnscheduledCardOnFile hits sit 26 B later than cited. @3007327 is inside the Danish translation dictionary, not UI code, but the English key still proves the string exists. The first conjunct (a dispute list with defend/accept) is met. The second (evidence assembled from the POS record) is not. Peers score the same shape the same way: Revel Advantage merchant portal disputes page and NCR merchant portal self-service chargebacks are both partial/B. On attribution: Qu's qu-pay and Adyen-terms pages never name Zentact, disputes or a portal. The tie rests on the first-party host plus Qu being the Adyen Platform, which is enough for partial, not for yes. source |
| payments-card-on-file | unknown, grade F | resolve-to-partial | I checked against the claim text in data/taxonomy/restaurant.yaml: a tokenised card on file for a guest profile, reusable across online, phone and in-store, with no merchant PAN (differentiator). All quotes are verbatim in the live, byte-identical bundle; one offset was corrected, 2214168 -> 2214194. Stored-card evidence is real, but only the tokenisation and 'chargeable later' conjuncts are met. Guest-profile linkage and cross-channel reuse are unmeasured. Grep found 'guest' once, and that hit is a dispute-document label for a hotel guest folio. There is no Add Customer or Save card string. The researcher's shortfall names the gap correctly, and peers give single-channel or back-office vaults partial (Linga 'Tokenize the Credit Card' setting, Flipdish online-only, Lavu storefront-only). I did not upgrade to yes and did not reject: a vaulted, rechargeable card on a customer record reached through a Qu-hosted payments product is present but materially limited. The attribution caveat (a white-label Zentact product on a Qu host, merchant eligibility unproven) keeps it at partial. source |
| kitchen-prep-time-pacing | unknown, grade F | upheld | Proposed partial from the admin.qubeyond.com back office source maps / pay-admin bundle (305th session); rejected on verification: Quote CONFIRMED verbatim in served bytes (live re-fetch 2026-09-15, 1,087,889 B, robots.txt 404; string starts @928628 not @928722), with validators integer/min 0/max 99999 @927423 and the same field in src/components/versioning/attributes/forms/operational/attr.vue. So conjunct 1 (a per-menu-item Prep Time value is configurable) is met at A, though the unit is unlabelled and there is no help text. But the claim is 'per-item cook times AND the KDS staggers item start/display so items finish together' (differentiator; why_it_matters is the staggering). A census of src for prep|stagger|pacing|cookTime|fireDelay|readyTime|quoteTime finds prepTime only in its own form, its type (operational.ts, typed string), and operationalAttributeService.js which nulls empty values; NOTHING in the back office consumes it, ties it to a KDS device, a preparation mode, Fire Mode or productionBoardTimeSlot, or even says it reaches the kitchen. It could equally feed Qu's marketed 'AI-generated promised ready times' (order-level quoting), which is not pacing. Peer partials on this claim carry a documented CONSUMER of the prep time (linga-pos B: sent to KDS and used for due-time sort; gotab B: drives auto-timed coursing); a bare admin input with no consumer is the baseline field, not a limited form of the capability, and a partial whose shortfall is the entire staggering core is self-refuting. The admin client is not the KDS runtime, so this is not evidence of absence either: cell stays unknown/F. Suggested rationale addition: 'Qu admin back office (public source map, build 3.6.234-260914.1) exposes a per-menu-item Prep Time integer (0-99999, unit unlabelled) in operational attributes; no client code consumes it and no KDS stagger/pacing setting exists in the admin, so whether the KDS uses it to stagger items is undetermined.' No url on an F row; final_url given only because the harness requires one from notes.json. source |
| kitchen-printer-fallback | unknown, grade F | resolve-to-partial | Live re-fetch 2026-09-15 (node from PowerShell): admin.qubeyond.com/robots.txt 404 (0 B, allow); https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/749bc93baeb2fdcfa467.js 200, 128,879 B (matches proposal); sibling 56bec5f7f2cdecc30a94.js 200, 118,859 B at /_nuxt/3.6.234-260914.1/ (the proposal's 'lazy/' path is a local corpus dir only; /lazy/... serves 404 22 B); fabricated 0000deadbeef0000.js 404 22 B. Verbatim in served bytes: 'Backup Device' @103736 (exact), bound to model printer.backupPrinterId @103878; 'No Backup Device' @104069 (proposal said 104072); 'Set in milliseconds. After this time the network printer will be considered offline' @73400 (proposal said 73377, which is the helpTimeout key); delete dialog 'The device you are about to delete is being used as backup printer. If you delete it, it will be unassigned everywhere' @82136 in 56bec5f7 (proposal 82150); isBackupPrinter filters table rows with backupPrinterId===t.id @83637. CORRECTION: the isVisible map @77150-78150 reads R.Timeout,"receipt"===this.printerType -- the offline Timeout field is shown ONLY for receipt printers, not kitchen devices, while R.BackupDevice is shown when isKitchenDevice&&!ProductionOptimizationBoard&&!LoadBalancer. So the proposal's pairing of a kitchen backup with an offline-detection timeout is not supported by the served code; the two are on different device types. CHALLENGE (automatic vs manual): no help string, tooltip or source comment anywhere in the unpacked src (grep -i backup over src/*.vue,*.ts returns only printer.ts fields backupPrinterId on KitchenDeviceBase and backupPrinterIds on PrinterRoute) says WHEN the backup is used. Failover/fallback/reroute tokens near print/kds/device: zero outside the receipt timeout string. The route model carrying backupPrinterIds alongside printerIds shows backups are part of routing data sent to the POS, and the name is conventionally a failover target (peer focus-pos documents 'Backup Printer - the Printer that will be used if the status of the original printer is offline'), but the trigger is not stated in Qu's own bytes, and the POS/KDS runtime that acts on it is not served. Peers: hungerrush partial/B (manual reroute), arryved partial/B (documented automatic 'Fallback To', alerting/no-loss missing), clover partial/A (single-hop), agilysys partial/B. Existing qu rows: both cells unknown/F; no prior verification row for either id (only reliability-offline-kds-printing mentions them). Partial is not self-refuting: the designated-backup conjunct is positively met at grade A (first-party served client code); the automatic-trigger conjunct is unproven rather than contradicted. yes is barred (trigger undocumented). DECISION kitchen-printer-fallback: amended -- value partial/A kept, note rewritten to drop the timeout-as-kitchen-offline-detection linkage and to state the trigger as undocumented. source |
| reliability-printer-fallback | unknown, grade F | resolve-to-partial | Live re-fetch 2026-09-15 (node from PowerShell): admin.qubeyond.com/robots.txt 404 (0 B, allow); https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/749bc93baeb2fdcfa467.js 200, 128,879 B (matches proposal); sibling 56bec5f7f2cdecc30a94.js 200, 118,859 B at /_nuxt/3.6.234-260914.1/ (the proposal's 'lazy/' path is a local corpus dir only; /lazy/... serves 404 22 B); fabricated 0000deadbeef0000.js 404 22 B. Verbatim in served bytes: 'Backup Device' @103736 (exact), bound to model printer.backupPrinterId @103878; 'No Backup Device' @104069 (proposal said 104072); 'Set in milliseconds. After this time the network printer will be considered offline' @73400 (proposal said 73377, which is the helpTimeout key); delete dialog 'The device you are about to delete is being used as backup printer. If you delete it, it will be unassigned everywhere' @82136 in 56bec5f7 (proposal 82150); isBackupPrinter filters table rows with backupPrinterId===t.id @83637. CORRECTION: the isVisible map @77150-78150 reads R.Timeout,"receipt"===this.printerType -- the offline Timeout field is shown ONLY for receipt printers, not kitchen devices, while R.BackupDevice is shown when isKitchenDevice&&!ProductionOptimizationBoard&&!LoadBalancer. So the proposal's pairing of a kitchen backup with an offline-detection timeout is not supported by the served code; the two are on different device types. CHALLENGE (automatic vs manual): no help string, tooltip or source comment anywhere in the unpacked src (grep -i backup over src/*.vue,*.ts returns only printer.ts fields backupPrinterId on KitchenDeviceBase and backupPrinterIds on PrinterRoute) says WHEN the backup is used. Failover/fallback/reroute tokens near print/kds/device: zero outside the receipt timeout string. The route model carrying backupPrinterIds alongside printerIds shows backups are part of routing data sent to the POS, and the name is conventionally a failover target (peer focus-pos documents 'Backup Printer - the Printer that will be used if the status of the original printer is offline'), but the trigger is not stated in Qu's own bytes, and the POS/KDS runtime that acts on it is not served. Peers: hungerrush partial/B (manual reroute), arryved partial/B (documented automatic 'Fallback To', alerting/no-loss missing), clover partial/A (single-hop), agilysys partial/B. Existing qu rows: both cells unknown/F; no prior verification row for either id (only reliability-offline-kds-printing mentions them). Partial is not self-refuting: the designated-backup conjunct is positively met at grade A (first-party served client code); the automatic-trigger conjunct is unproven rather than contradicted. yes is barred (trigger undocumented). Alert conjunct: tokens alert/notif near printer in the editor chunk give no staff-alert setting; bounded to this config client only, so it is recorded as undocumented, not as absent. DECISION reliability-printer-fallback: amended -- partial/A kept, consistent with kitchen-printer-fallback; note corrected on timeout scope and names both unmet conjuncts (automatic trigger, alert). source |
| multi-location-royalty-calculation | unknown, grade F | upheld | Proposed partial from the admin.qubeyond.com back office source maps / pay-admin bundle (305th session); rejected on verification: Re-fetched live 2026-09-15 (robots.txt 404, 0 B = allow). The quotes are verbatim in the served bytes. 85b8f000ea1ba917931f.js (200, 38,649 B): name:"FeeEditor" @33950, netSalesPercentage @34223, "Net Sales %" @36677, "Report Fee created successfully" @34942, "Effective From" @37191, reporting_fees.create @38244. 015621cce7f2c63eedae.js (200, 8,264 B): FeesList @3120. Main 8fc0d1fe5de12dff9911.js: report-configurations @12602, configuration-reports-fees @37369. Main-chunk offsets run about 12-32 B later than the proposal says, which is immaterial. The unpacked source is the whole feature: store/fees.js (LIST+CREATE on report-configurations), components/reports/fees/{editor,list}.vue and two thin pages. The Fee model is {title (free text, max 30), netSalesPercentage, location (reportingGroups|operationalUnits), effectiveFrom, effectiveTo}. There is no help copy, no example names, no type or category, and no ad-fund or marketing split. Nothing else in the client reads a fee: it has no report column, no amount and no schedule. Tokenised controls royalt*/ad fund/advertis*/commission* = 0 in the served chunks and the source. 'Franchise' appears only as the versionHistory scope label 'Franchise Group Level', and ThirdParty only as fulfilment/sentry, so both are unrelated. So the purpose of a 'Report Fee' cannot be tied to franchise royalty or ad fund. A store-scoped, dated %-of-net-sales fee fits royalty, but it fits management fees, percentage rent, or delivery/aggregator and card-cost allocation in a P&L report just as well, and the client never says which. This is the flipdish precedent (a rate with no visible consumer and no royalty tie meets no conjunct), and it is weaker than par-brink's partial, whose guide names 'royalty entries' feeding a 'Royalties by Location' report. The enterprise Gross/Net Sales equation (4d3bef03) is a global reporting-basis setting and is not shown to feed these fees. The proposal's own shortfalls (a)-(c) concede the royalty naming, per-fee basis, amount and schedule, so its partial refutes itself on a differentiator/conclusion-flipping cell. Leave unknown. The Reports > Fees editor is a lead only: look for a server-side report or help article that consumes report-configurations fees. source |
| multi-location-enterprise-sso | unknown, grade F | upheld | Proposed partial from the admin.qubeyond.com back office source maps / pay-admin bundle (305th session); rejected on verification: Re-fetched live 2026-09-15 (robots 404 = allow; chunk 200, 3,033,026 B). The quotes are real in the served bytes: x-amzn-oidc-accesstoken @614741, x-amzn-oidc-identity @614796, loginSSO @558061, sso:!0 @558287, "/sso-error" @161877. Tokenised SAML, SCIM, Okta, 'Azure AD', 'identity provider' and 'single sign' are all 0. The one 'openid' hit is the Font Awesome .fa-openid icon class. The unpacked source does not tie this flow to a customer IdP. (1) middleware/sso.js only reads the headers an AWS ALB injects after OIDC auth, then posts {sso:true, host, token, data, identity} to the ordinary 'local' login strategy. Which IdP is used and how users map to accounts lives on Qu's load balancer and backend, and none of it is visible. (2) The Vuex module that stores the headers is named 'poc' (proof of concept). (3) pages/login.vue renders only the password login and forgot-password forms, with no 'sign in with SSO' button, IdP picker or email-domain discovery. (4) No settings page lets a customer configure an IdP. (5) sso-error.vue says 'This account is not authorized to access Enterprise Intelligence. Please contact your support team', with a hidden debug AUTH ID. (6) CT logs show *.eisso-dev.qubeyond.com and *.eisso-stg.qubeyond.com. The wildcards hint at per-tenant subdomains, but only dev and staging exist, and no production eisso host or brand-named host appears among 672 names. That fits an internal or pilot federation as well as a customer IdP, so it cannot tell the two apart. No deprovisioning (SCIM or equivalent) is shown either. A differentiator needs A/B evidence for both conjuncts, and this shows neither: the customer IdP conjunct is not established, and the SCIM conjunct is missing entirely. The prior unknown/F stands. source |
| guest-loyalty-privacy-rights-tooling | unknown, grade F | resolve-to-partial | Re-fetched both files live with a Chrome UA (both 200, sizes match). Every quote is verbatim. Two offsets were corrected: the 'delete account' literal is at @53294, not @53287, and the Deactivating paragraph is at @53099. The block renders on the Preferences tab, the button has no disabled binding, and neither ngIf:false binding covers it, so it is live. I weighed rejecting to unknown, because the claim asks for admin tooling. I kept partial because peers set the precedent: guest self-deletion earned partial at flipdish (partial/C, self-delete only), olo and chownow (partial/B), and lightspeed (partial/B). Rejecting here would be inconsistent. Grade A stands because the source is served client code. The note now names all four shortfalls, so it cannot be read as operator DSAR tooling. source |
| digital-surcharge-transparency | unknown, grade F | resolve-to-partial | Re-fetched both files live at 200 with a Chrome UA; byte sizes match (2,207,208 and 175,897). Every quote is there word for word. Three offsets were a few bytes early: 220546->220560, 151128->151155, 148032->148041. The note also claimed dual.?pric=0, but a raw 'dual' count gives 12 false hits, so I rewrote that line. On substance, showing service charges as labelled line items is the fee-disclosure conjunct in its weakest form, and some would call it a baseline. But peer precedent scores exactly this shape as partial: deliverect partial/B (service charges per channel, no surcharge), chownow partial/B (service fee by amount or percentage, no dual pricing or brand engine), olo partial/B (fees as separate guest-facing line items, no jurisdiction handling), otter partial/D. Downgrading qu to no would break that consistency. Unlike microworks and odoo (no), qu has a real fee engine. The time-slot re-check and the third-party refusal go beyond a bare static line item. Partial stands, with a note that names every unmet conjunct. Grade A holds because the evidence is the vendor's own served client code, not marketing. source |
Sources
Every URL this record cites. 116 in total.
- https://www.qubeyond.com/ordering/pos
- https://www.qubeyond.com/kitchen-solutions/kitchen-display-system
- https://www.qubeyond.com/ordering/drive-thru
- https://www.qubeyond.com/ordering/kiosk
- https://www.qubeyond.com/ordering/third-party-ordering
- https://www.qubeyond.com/products/
- https://www.qubeyond.com/ordering/online-ordering
- https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/
- https://www.qubeyond.com/management/unified-menu-management
- https://www.qubeyond.com/management/channel-management
- https://www.qubeyond.com/management/brand-franchise-management
- https://www.qubeyond.com/ordering/third-party-ordering/
- https://www.qubeyond.com/resource-center/qu-named-first-excellent-pos-in-doordashs-new-preferred-integrations-program
- https://status.qubeyond.com/
- https://www.qubeyond.com/payments/qu-pay
- https://www.globenewswire.com/news-release/2026/06/23/3316041/0/en/paytronix-and-qu-further-integration-enabling-advanced-omnichannel-ordering-and-menu-management.html
- https://www.qubeyond.com/management/notify-mobile-insights
- https://www.qubeyond.com/qu-business-edge
- https://www.qubeyond.com/kitchen-solutions/order-status
- https://qubeyond.com/products/
- https://www.qubeyond.com/management/unified-data-reporting
- https://www.qubeyond.com/about/qu-technology-partners/
- https://www.restaurant365.com/partners/qu-pos/
- https://www.marketman.com/partner/qu
- https://qu-pos-api.qubeyond.com/
- https://www.globenewswire.com/news-release/2025/10/07/3162505/0/en/paytronix-and-qu-partner-to-deliver-smarter-more-personalized-guest-experiences.html
- https://www.qubeyond.com/get-a-demo
- https://qu-api.qubeyond.com/
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026
- https://www.zuppler.com/qu-beyond-pos
- https://www.qubeyond.com/platform
- https://www.qubeyond.com/support
- https://www.qubeyond.com/privacy-policy/
- https://www.qubeyond.com/case-studies/blaze-pizza
- https://www.kioskmarketplace.com/news/qu-unveils-kiosk-upgrades-to-boost-revenue-ease-staffing-for-restaurants/
- https://qu-api.qubeyond.com/swagger/v1/swagger.json
- https://kb.7shifts.com/hc/en-us/articles/35540967177875-Tip-Pooling-for-Qu-POS
- https://go.qubeyond.com/qu-orderup
- https://www.qubeyond.com/resource-center/the-who-what-why-of-the-restaurant-api
- https://www.qubeyond.com/solving-for-in-store-stability-with-edge-computing/
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program
- https://merchants.doordash.com/en-us/preferred-integrations
- https://support.qubeyond.com/
- https://www.qubeyond.com/sitemap.xml
- https://www.qubeyond.com/ordering
- https://www.qubeyond.com/integrations
- https://www.qubeyond.com/management
- https://www.qubeyond.com/kitchen
- https://www.qubeyond.com/resource-center/qus-winter-2026-product-release-highlights
- https://www.qubeyond.com/become-a-partner
- https://www.qubeyond.com/resource-center/qus-fall-2025-product-release-highlights
- https://web.archive.org/web/20220724113646/https://qu-pos-api.qubeyond.com/
- https://support.qubeyond.com/hc/en-us
- https://web.archive.org/web/20220630222951/https://qu-api.qubeyond.com/
- https://www.qubeyond.com/resource-center/onosys-achieves-certification-for-production-use-with-qu-launches-seamless-enterprise-integration
- https://support.qubeyond.com/robots.txt
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026
- https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/
- https://www.qubeyond.com/kitchen-solutions/order-status
- https://www.qubeyond.com/ordering/third-party-ordering
- https://www.qubeyond.com/robots.txt
- https://support.qubeyond.com/
- https://qu-api.qubeyond.com/robots.txt
- https://qu-pos-api.qubeyond.com/robots.txt
- https://www.qubeyond.com/robots.txt
- https://www.qubeyond.com/sitemap.xml
- https://www.qubeyond.com/integrations
- https://www.qubeyond.com/resource-center/what-qus-doubled-integration-network-means-for-you
- https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us
- https://web.archive.org/web/20220724113646/https://qu-pos-api.qubeyond.com/
- https://sandbox.qubeyond.com/
- https://www.qubeyond.com/resource-center/dynamic-stores-transforming-menu-management-to-serve-a-new-decade
- https://www.qubeyond.com/third-party-terms
- https://www.qubeyond.com/pci-dss-compliance-guide
- https://www.qubeyond.com/resource-center/qus-kds-delivering-a-holistic-view-of-your-ordering-production-capabilities
- https://www.qubeyond.com/resource-center/5-reasons-why-your-kitchen-needs-a-smart-upgrade-now
- https://www.qubeyond.com/resource-center/loyalty-3-0-elevating-guest-engagement-through-deeper-insights
- https://www.qubeyond.com/resource-center/qus-spring-2025-product-release-highlights
- https://www.qubeyond.com/resource-center/finally-an-app-that-saves-your-store-managers-time-money
- https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360049022511
- https://www.qubeyond.com/resource-center/third-party-delivery-blessing-or-technology-curse-for-operators
- https://www.qubeyond.com/resource-center/what-qus-doubled-integration-network-means-for-you
- https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360052896691-November-17th-v139
- https://web.archive.org/web/20200809111311/https://support.qubeyond.com/hc/en-us/articles/360041247211-How-do-I-add-an-Additional-Tender-Next-Gen-
- https://web.archive.org/web/20200809112540/https://support.qubeyond.com/hc/en-us/articles/360042453371-How-Do-I-Adjust-a-Credit-Card-Tip-Next-Gen-
- https://web.archive.org/web/20200808111044/https://support.qubeyond.com/hc/en-us/articles/360001267211-Chapter-6-Configuration-First-Gen-2-0-
- https://web.archive.org/web/20201128163422/https://support.qubeyond.com/hc/en-us/articles/360051880871-How-do-I-Prevent-a-Cashier-from-Performing-Manager-Related-Till-Functions-No-Sale-Paid-In-Out-and-Claim-Close-Till-
- https://web.archive.org/web/20210125175255/https://support.qubeyond.com/hc/en-us/articles/360054441371-December-16th-v140-
- https://web.archive.org/web/20200806003551/https://support.qubeyond.com/hc/en-us/articles/360001252212-Chapter-8-Printing-First-Gen-2-0-
- https://web.archive.org/web/20200813234817/https://support.qubeyond.com/hc/en-us/articles/360001492972-How-do-I-add-a-Menu-Menu-Items-Ingredients-and-Prep-Instructions-First-Gen-2-0-
- https://web.archive.org/web/20201128162138/https://support.qubeyond.com/hc/en-us/articles/360051880331-How-do-I-Prevent-Cashiers-from-Applying-Offline-Credit-Payment-Types-
- https://web.archive.org/web/20210125165411/https://support.qubeyond.com/hc/en-us/articles/360052896691-November-17th-v139-
- https://web.archive.org/web/20201125102417/https://support.qubeyond.com/hc/en-us/articles/360048239071-Changing-Order-Types-from-the-Online-Menu-Next-Gen-
- https://web.archive.org/web/20201128174707/https://support.qubeyond.com/hc/en-us/articles/360049022511-Qu-Reports-Quick-Guide-Next-Gen-
- https://web.archive.org/web/20201201062202/https://support.qubeyond.com/hc/en-us/articles/115006316228
- https://web.archive.org/web/20200809112957/https://support.qubeyond.com/hc/en-us/articles/360001271931-Chapter-12-Audit-Trail-First-Gen-2-0-
- https://web.archive.org/web/20200806012955/https://support.qubeyond.com/hc/en-us/articles/360042408211-What-is-a-Payroll-Profile-Next-Gen-
- https://web.archive.org/web/20200920081822/https://support.qubeyond.com/hc/en-us/articles/360038050532-Swap-SSD-Hard-Drive-on-Touch-Dynamic-Acrobat-Terminal
- https://web.archive.org/web/20200809113433/https://support.qubeyond.com/hc/en-us/articles/360040852811-Manual-Transaction-Guide-for-Ingenico-IPP320-First-Gen-2-0-
- https://support.qubeyond.com/api/v2/help_center/en-us/articles.json?per_page=1
- https://docs.qubeyond.com/robots.txt
- https://qu-api.qubeyond.com/
- https://web.archive.org/cdx/search/cdx?url=support.qubeyond.com*&output=text&fl=original,timestamp,statuscode&collapse=urlkey&limit=40000
- https://www.qubeyond.com/sitemap.xml
- https://www.qubeyond.com/terms-and-conditions
- https://www.qubeyond.com/adyen-for-platforms-terms-and-conditions
- https://www.qubeyond.com/privacy-policy
- https://www.qubeyond.com/integrations
- https://www.qubeyond.com/modules
- https://merchants.doordash.com/api/partner-integrations
- https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program
- https://merchants.doordash.com/en-us/integrations
- https://pay-admin.qubeyond.com/assets/index-B_60PuKx.js
- https://admin.qubeyond.com/_nuxt/3.6.234-260914.1/749bc93baeb2fdcfa467.js
- https://wo.qubeyond.com/65.cc643fc074acac2b.js
- https://wo.qubeyond.com/main.4b6c92ee3e2b2618.js