Vendors / Mainstream commercial restaurant POS
Revel Systems
dossier live
- Claims in scope
- 278
- Scored
- 278
- Assessed
- 275
- Unknown
- 3
- Not applicable
- 36
- Values challenged
- 56
Identity
- Owner
- Shift4 Payments (NYSE: FOUR). Welsh, Carson, Anderson & Stowe took majority control Feb 2017; Wikipedia records a Shift4 acquisition in June 2024. Corroborating direct observation on 2026-08-01: every revelsystems.com marketing URL (including /pricing/, /pos-solutions/pizza-pos/, /apiterms/) 301-redirects to https://www.shift4.com/food-beverage. Only developer.revelsystems.com and status.revelsystems.com remain live under the Revel domain. CAVEAT: Shift4 newsroom and IR pages returned 403, so the June 2024 date and any price are secondary-source (Wikipedia) only; the ownership itself is strongly corroborated by the domain redirect. This is consistent with Shift4's 2026 brand-consolidation pattern (SkyTab POS renamed Shift4 Dine on May 12, 2026).
- Founded
- 2010, San Francisco, by Lisa Falzone and Christopher Ciabarra (Wikipedia).
- Scale
- unknown. No current location count, customer count, ARR or market-share figure is published, and Revel is not broken out in any Shift4 disclosure I could reach. Wikipedia cites a ~$500M valuation before the founders' 2017 exit and offices in Atlanta, San Francisco, Vilnius and London - both historical, not current.
- Who it is for
- Historically multi-location QSR, pizza, convenience/fuel and mid-market retail on iPad. Wikipedia names Shell, Little Caesars Pizza, Smoothie King, Popeyes and Dairy Queen as customers - a chain/enterprise-leaning book, not independents. Present-day ICP is unknown: Revel no longer operates its own marketing site, so there is no current vendor positioning to cite.
- Site
- https://revelsystems.com/pos-solutions/pizza-pos/
Pricing
transparency: quote-only · unit: unknown · processor lock-in: no
- Software
- quote-only. Revel's own pricing page (https://revelsystems.com/pricing/) no longer exists - it 301-redirects to https://www.shift4.com/food-beverage, which publishes no Revel pricing. Gartner Digital Markets' vendor profile lists 'Pricing available upon request' with no starting price. Merchant Maverick's Dec 2, 2025 review lists equipment as 'Quote-based / Call for quote'. I found NO currently published dollar figure for Revel software from any first-party source and did not substitute a third-party roundup estimate.
- Card processing
- unknown / not published. Revel operates an in-house processing program branded 'Revel Advantage' (named as an incident component on status.revelsystems.com on 2026-05-07), but no rate card is published.
- Contract
- unknown. Merchant Maverick (Dec 2, 2025) characterizes Revel as requiring 'a long-term commitment' but states no term length. No first-party MSA or terms page is reachable - revelsystems.com terms URLs redirect to Shift4.
- Early termination
- unknown - no publicly reachable contract terms.
API posture
public API: partner-gated
- Cost to integrate
- unknown. No published partner fee, revenue share, certification cost or per-location API surcharge was found. Revel's platform guidelines reference 'fair usage guidelines we publish' and instruct partners to 'respect our rate limits' without stating numeric quotas or fees.
- Webhooks
- Yes, and unusually well documented for this tier. Nine event types including order.finalized, customer created/updated, rewards card created, inout.stock (inventory status), menu updates, timesheet entries, integration changes, plus a ping test event. Delivered as HTTPS POST with JSON. Signed with HMAC-SHA1 in X-Revel-Signature, alongside X-Revel-Instance, X-Revel-Event-Type, X-Revel-Event-Id, X-Revel-Message-Id and X-Revel-Establishment-Id headers. Endpoints must return 2XX within 10 seconds. Retry is exponential backoff at 60s / 5min / 15min / 15min - four attempts over roughly 36 minutes. A message-log API allows querying delivery history filtered by state (invoked/failed/retrying), instance and timestamp. Source: https://developer.revelsystems.com/revelsystems/docs/webhooks
- Data export on exit
- unknown. The REST API can read and write orders, web orders, customers, house accounts, employees, departments, payroll declared tips, inventory, purchase orders, products/attributes/pricing, discounts, tax, tables, scheduling and cash management - so a technically capable operator can extract most of their data while the account is live. But no post-termination retrieval window, no bulk/warehouse export product, and no merchant data-ownership clause are publicly documented; the API Terms of Service page (revelsystems.com/apiterms/) is now a dead redirect.
- Notes
- Docs are genuinely public and self-serve - no login, NDA or sales call needed to read the reference. Credentials are NOT self-serve: OAuth 2.0 bearer tokens replace the older API key/secret, and partners receive Client ID and Client secret via a single-use emailed recovery link valid 72 hours. Critically, the SAME partner credentials work across all merchants; the merchant is identified by a Client-Id header derived from their tenant subdomain (e.g. 'exampleurl' from https://exampleurl.revelup.com/). That is a partner-key model, not per-merchant operator-granted OAuth consent with individually revocable scopes. Tokens must be regenerated every 24 hours. A QA environment exists at authentication.qa.revelup.com alongside PROD at authentication.revelup.com, but whether it is freely obtainable without a production account is not documented. Source: https://developer.revelsystems.com/revelsystems/docs/api-platform-authentication
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
A real graphical editor is documented. In the Management Console under Establishments > Tables an operator gets a grid, adds named sections via '+Add New Section' (the POS sorts sections alphabetically), picks 'the most appropriate table shape from the options in the top section', drags it into place, then sets the 'Table Name' field and a 'Capacity' field for 'the number of guests the table seats', and clicks Save. Tables can be dragged to move, marked Inactive (grey, hidden from the POS but visible in the console), and whole sections deleted. Table Tags (Wheelchair Accessible, Patio, Booth) can be assigned per table but must be switched on by Revel Support and are only useful with Table Reservations. Shortfall, and it is the reason this stays partial: the documentation describes ONE layout per establishment with sections inside it - there is no save/select of multiple named floor-plan layouts - and no assignment of sections to servers is documented anywhere, including in Table Service Settings, which covers only course prompts and auto-gratuity. https://support.revelsystems.com/s/article/Building-Your-Table-Layout-1583149094553 · retrieved 2026-08-02 adversarially verified
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
Quick Course/Seat Menu adds a Course/Seat widget on the POS: after an item is added, +/- controls set the seat (and course) number per line, with the widget stickied at top right since v2.78. Split Bills then offers 'Split By Seat Number' alongside Split Evenly / Split Manually / Split By Item, so the check divides by the seats tagged at entry without re-keying items. https://support.revelsystems.com/s/article/Split-Bills-1582901435396 · retrieved 2026-08-04
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
TSR: Course Fire documents 'Prompt for course' at item entry, per-course release to the kitchen (Send to Kitchen > Send Course), and a Fire Next Course action on the POS ('tapping Fire Next Course on the POS will print a simple Fire Course X receipt to the kitchen'), plus optional 'Automatic course firing from Done on KDS' with a configurable delay and per-order manual override. https://support.revelsystems.com/s/article/TSR-Course-Fire-1582902249374 · retrieved 2026-08-04
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
Four split modes are documented by name, and they cover the split half of the claim well: 'Split Evenly' (prompts for a headcount and 'the system will automatically create 3 evenly split checks'), 'Split Manually' (prompts for a headcount then an explicit amount per check, with the last check taking the remaining balance), 'Split By Item' ('add as many checks as needed as well selecting which items to put on each check'), and 'Split By Seat Number'. The feature must first be enabled in the Management Console Settings. Shortfall: merging is the weak half. The only documented merge is 'Clear Split Bills', which 'merges split bill back into one total' but 'because it also refunds all payments on the order, clearing a split bill requires a security PIN from an employee with refund permission' - so merging after partial payment is destructive and permission-gated rather than an ordinary operation, and no documentation describes merging two separate checks or two tables into one. https://support.revelsystems.com/s/article/Split-Bills-1582901435396 · retrieved 2026-08-02 adversarially verified
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
Bar tabs link a card and preauthorize a configurable 'Preauthorization Amount' (blank = prompt per tab; Bar Tabs setting supports 104 tabs per page), and swiping the card re-opens the tab. Shortfalls: preauth-and-link requires the Revel Advantage or FreedomPay integrations; 'Incremental authorizations are supported with our Freedompay iFCC integration' only; and no automatic end-of-day close of stale tabs is documented - the End of Day wizard offers manual 'Reconcile Open Orders' presets instead. https://support.revelsystems.com/s/article/Preauthorizations-and-Linking-Cards-to-Bar-Tabs-Tables-and-Orders-1582901172680 · retrieved 2026-08-04
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
A Transfer Owner action moves an open order between logged-in employees ('A list of logged in employees will appear. Tap on the employee and tap the Transfer button'), tables can be moved/merged, and a 'Transfer Orders' POS role permission gates who may transfer. Shortfall: no audit-log entry naming both employees is documented - the Action Log Report's enumerated actions (Item Deleted, Login Attempt, Price Override, etc.) do not include order transfers. https://support.revelsystems.com/s/article/TSR-Transferring-Order-Owners-1582902249371 · retrieved 2026-08-04
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
Revel version 2.77 added an IPORT 'mobile order taker (MOT)' case: a handheld iPad case whose features are listed as 'Full protection for card swipe', 'Fast charging', 'Highly reduced cabling' and 'Support for Link 2500 and Moby 5500 payment devices', with a CONNECT PRO PayCase that magnetically attaches the payment device to the iPad case so both charge together in a MultiDock. The paired readers are documented as full tableside acceptance devices - the Moby 5500 'enables all payment methods - including EMV chip, magstripe NFC/contactless cards, or mobile wallets - anywhere, anytime that a merchant and consumer interaction may take place', and the Link 2500 is a portable device over WiFi and/or Bluetooth. The ordering app is the first-party Revel POS iOS app running natively on the iPad (App Store listing by Revel Systems INC: 'Requires iPadOS 15.0 or later'), not a mirrored desktop session. Caveat worth recording: the form factor is an iPad Mini in an accessory case rather than a purpose-built handheld terminal, and there is no iPhone or Android POS build - the only Revel iPhone app is Insights, which is reporting-only. https://support.revelsystems.com/s/article/iPort-stands-and-cases · retrieved 2026-08-02 adversarially verified
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
Re-homed from the customer-gated Zendesk URL onto the live Salesforce help centre. Revel's outage best-practices article publishes a three-tier matrix per outage type. Under 'ISP / Network Outage' it states that 'When ISP/Network is down, you'll still be able to access the following functions: Create and close orders; Operate tills and take cash payments; Print to kitchen and receipt printers (ethernet or BT connected)', with 'Process CC / Debit Payments in offline mode' listed as available-but-limited, and under 'Revel Server Outage' it adds 'Use CDS & KDS'. It then lists what will NOT work (loyalty/rewards/gift cards, manual credit card or debit payments, EOD, house accounts, customer order history, frontend inventory). The companion Offline Mode article (https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418) documents the settings side. So both halves of the claim hold: offline order entry and cash tender are documented, and the vendor does publish what does and does not work. https://support.revelsystems.com/s/article/outage · retrieved 2026-08-09 adversarially verified
Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator
order-capture-qr-same-check
NEW SURFACE, and it settles this cell: Revel's ANONYMOUS production OpenAPI 3.0 spec set, version 2025.3.0, listed by its own Swagger UI index at https://developer.revelsystems.com/ (retrieved 2026-09-17, HTTP 200): 14 suite yaml files on https://oas-prod.s3.amazonaws.com/oas/2025.3.0/, 1,751,580 bytes, 198 documented paths. Bounded: the index's url[] array names exactly 14 specs (Cash Management, Customers, Discounts, Employees, General, House Accounts, Inventory, Orders, Products, Purchase Orders, Scheduling, Tables, Tax, Weborders) and all 14 fetched at 200; the nonsense control /oas/2025.3.0/zzz_nonsense_suite.yaml returns 403 AccessDenied, so a 200 here is a real object, not a catch-all. CLAIM: guest QR at-table ordering writes items onto the SAME open check as server-entered items rather than creating a separate order ticket. VERDICT: no. EVIDENCE: (1) Smart Order IS Online Ordering XT in a mode - 'Revel Smart Order is our fully contactless dine-in solution. By leveraging Online Ordering XT, you can give your customers the ability to scan a QR code, order, and pay at the table'; 'Must use same payment processor as your Online Ordering XT'; 'Must use same branding skin as Online Ordering XT' (https://support.revelsystems.com/s/article/Smart-Order, modified 2026-05-21, re-read live 2026-09-17). (2) The weborders spec is that channel's contract and its mode enum on GET /weborders/system_settings/ is closed: 'Application modes: 0 - Online, 1 - Bar, 2 - Kiosk, 3 - Menu Board, 4 - Online - Catering, 5 - SmartDining, 6 - Multi-Channel'. (3) Order submission is POST /specialresources/cart/submit, 'Handles order submission and returns info about the order'. Its whole input is WeborderBaseCartInput {skin, establishmentId, items, orderInfo, notifications, customMenuInfo, serviceFees, discounts, discount_code} and orderInfo is WeborderCartInputOrderInfo, whose complete 12-field list is {created_date, pickup_time, pickup_data, lastPickupTime, dining_option, notes, asap, customer, call_name, is_tax_exempt, selected_table, local_id}. The only check-identity field is selected_table ('An ID of a selected table') - there is NO field for an existing order, bill, check or bill_parent - and the response WebordersSubmitOrderResponse returns a NEW 'orderId'. (4) The POS Order resource CAN nest checks (Order carries bill_parent, bills_info, bills_type, table, table_owner in orders_suite.yaml) so the absent field is a capability the same API models elsewhere; the web-order path simply cannot address it. BOUND/CONTROLS: corpus = the 14/14 published suites (denominator 14 files, 198 paths) PLUS the live 100% census of support.revelsystems.com via the Salesforce guest Knowledge REST API (698/698 articles fetched with layoutItems bodies, .cache/q325/revel-systems/kb/bodies.jsonl). Tokenised, word-boundary, case-insensitive: `open check` 0/14 suites and 0/698 articles; `smart order` 18 hits in 2/698 (Smart Order and Custom Menus only); `smart dining` 0/698 (the SmartDining label exists only in the API mode enum - naming differs between spec and KB, stated so nobody re-derives it as a second product). POISON: a raw grep for `table` in weborders_suite.yaml returns 19 hits of which all but selected_table are the word 'table' inside timetables/EstablishmentAddress prose; `header` returns 201 hits across 14/14 files and every one is an HTTP header parameter, not a receipt header. Retrieved 2026-09-17. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/weborders_suite.yaml · retrieved 2026-09-17 adversarially verified
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
Kiosk XT is Revel's first-party self-service kiosk driven by the same Management Console catalog: a Custom Menu with Mode/Station = Kiosk selects included products from the POS product list, and modifier classes carry over (including split modifiers, e.g. half-pizza toppings with the same Charge Full Price / half-price behavior as the POS). Shortfall: no ADA/accessibility conformance documentation for the kiosk exists anywhere in the help centre. https://support.revelsystems.com/s/article/Kiosk-XT · retrieved 2026-08-04
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
Revel Drive Through (v2.72+) provides a Drive Through dining type with vehicle-data and call-name prompts (No/Prompt/Required), a dedicated Drive Thru Queue (oldest first, time-lapsed stamp, in-queue payment via cash/gift/fast credit), and an optional 'Support Fulfilled state' so a station acts as expediter; v2.79 added vehicle data on KDS/expo chits. Shortfalls: no order-point/pay-window/pickup-window separation, no tandem-lane sequencing or lane assignment, and no pull-forward/parking-spot assignment are documented. https://support.revelsystems.com/s/article/Revel-Drive-Through · retrieved 2026-08-04
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
The Speed of Service report records per-order/per-item Start Time, KDS Complete, Expedite Complete, Time on KDS, Time on Expedite, and Total Kitchen Time (requires KDS In-Progress Mode), and the Drive Thru Queue displays a time-lapsed stamp per car. Shortfall: timing is kitchen-stage based, not drive-thru segment based - no order-point / pay-window / pickup-window segment timers are documented (the only drive-thru lane hardware doc is the Delphi OCS order-confirmation-screen integration, which has no timer function). https://support.revelsystems.com/s/article/Speed-of-Service-Report-1583149670649 · 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
Searched the complete 693-article public help-centre mirror (captured 2026-08-04) for voice, voice AI, AI ordering, phone ordering, drive-thru AI and conversational ordering: the only phone-order feature documented is the Caller ID integration (incoming caller info shown for manual order entry), and the only drive-thru peripheral is the Delphi OCS confirmation screen; no first-party voice agent appears anywhere. The developer.revelsystems.com portal home (fetched 2026-08-05) lists its full guide catalog (Getting Started, Authentication, Capabilities, Data Connector, Cash Management through Weborders) with no voice-AI content and no named voice-AI partner program. Absence from documentation is not positive evidence of absence, so this stays unknown rather than no. || 326th: 326th: NEW SURFACE, measured, does not settle the cell - recorded so it is not re-mined. The owner DOES list a voice-AI partner, but for the wrong product. https://www.shift4.com/marketplace (fetched with curl + browser UA 2026-09-18, 109,728 chars of extracted text) is a filterable integration directory whose lede reads 'Seamlessly connect your Shift4 Dine software with your favorite business management programs', with an explicit category list (Accounting, Analytics, Digital Signage, Inventory Management, Kiosk, Labor Management, Marketing & CRM, Online Ordering & Delivery, Payroll & HRM, Property Management, Reservations, Security). It carries exactly one voice-AI entry - 'Loman AI: Get 24/7 Voice AI phone answering that takes orders and reservations, answers FAQs, and syncs to your POS system with Loman', dd_tags 'Live', url https://loman.ai/integrations/shift4. The token `revel` occurs ZERO times in the whole directory, so under the standing merge rule (a sibling product's catalogue does not bound or support this vendor) it is evidence about Shift4 Dine/SkyTab, not about Revel. BOUND ADDED ANYWAY: `voice ai` 0/698 live Revel KB articles and 0 in the Revel legal set; across the 825-slug shift4.com body census (36,380,880 chars) `voice ai` fires only in that marketplace page and `voice ordering` is 0/832. Still unknown rather than no because the claim's second disjunct - 'publishes a documented API partner program for third-party voice AI' - is arguably satisfiable by Revel's general developer portal plus its writable /resources/Order/ endpoints, and I hold no Revel-scoped integration directory that asserts itself complete. Retrieved 2026-09-18. || 329th: 329th: TWO NEW SURFACES, measured, neither settles the cell - recorded so they are not re-mined. (1) APP STORE PUBLISHER CENSUS. Revel's App Store developer id is 477934007 ('Revel Systems iPad POS'); the iTunes lookup with entity=software returns its COMPLETE shipped app list, 13 apps: Revel POS (1054505108, v2.80.72, 2026-08-06), Revel POS - 2.79, Revel CDS, Revel CDS - 2.79, Revel CDS XT, Revel CDS XT - 2.79, Revel KDS, Revel KDS - 2.79, Revel Insights, Revel Inventory, Revel Assist, Revel Delivery XT Agent, Revel Delivery XT Dispatch. There is no voice-ordering, phone-agent or conversational app, and tokenised case-insensitive controls over the 14,305 chars of all 13 descriptions plus release notes give voice 0/13, AI 0/13, 'phone order' 0/13, 'drive-thru' 0/13. (2) The 698-article support.revelsystems.com Salesforce Knowledge listing was RE-PAGED live today: still exactly 698 articles and the newest lastPublishedDate is 2026-09-15T19:31:13Z, i.e. nothing has been published or revised since the 325th's census, so the 'KB articles updated since the last pass' route is empty for this vendor. WHY NEITHER SETTLES IT: a voice agent is a server-side/partner surface that needs no iOS app, and an app-store listing is vendor marketing (grade C) - so the publisher census bounds Revel's SHIPPED APPS, not its capability. Retrieved 2026-09-18. 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
Online ordering settings include 'Max number of online orders: Maximum number of online orders per time slot' and 'Online order time slot: Interval in minutes that defines available pickup/arrival/delivery time slots'. Shortfalls: the cap applies to online ordering only, not per channel, and there is no automatic quote-time extension from kitchen load - the Online Ordering FAQ answers the capacity question with the time-slot limit and states 'The functionality for multiple prep times doesn't exist at this time.' https://support.revelsystems.com/s/article/Online-Ordering-Setting-Up-Online-Ordering · retrieved 2026-08-04
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
Future-dated orders are accepted on POS and online ('Max date window for online ordering' sets how many days ahead) and can be stored as invoices, with 'Automatically turn invoices into orders on their due date' releasing them at a configured time of day; kitchen print options note this prints future orders on their due date automatically (blocked if Send to Kitchen on Demand is enabled). Shortfalls: release is a single configured time of day, not a per-order computed fire time, and there is no per-channel lead time - 'The functionality for multiple prep times doesn't exist at this time' (Online Ordering FAQ). https://support.revelsystems.com/s/article/Future-Orders-1582902249369 · retrieved 2026-08-04
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
Catering Delivery Tracking gives a Catering dining option that prompts for a delivery date/time, a Catering button on the POS dashboard opening a Catering Delivery page of active/completed orders viewable by day, week, month or all future orders - separate from the standard order queue; deposits and installment payments run through Invoices & Deposits (including a 'Catering Specific Deposits' flow and house-account billing), and a Catering Delivery Report tracks orders, products and delivery dates. Shortfall: no quote/proposal stage is documented - the flow begins directly as an order or invoice. https://support.revelsystems.com/s/article/Delivery-Catering-1583149409698 · retrieved 2026-08-04
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
CLAIM: pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. VERDICT: no. BOUND, and it is a live census rather than the 2026-08-04 mirror the other rows lean on: support.revelsystems.com serves its whole knowledge base anonymously at the Salesforce guest knowledge API, https://support.revelsystems.com/services/data/v59.0/support/knowledgeArticles?pageSize=100 - 7 pages, 698 articles, every body fetched from the article's own url (4.45 MB stripped). 121 of 121 support.revelsystems.com /s/article/ URLs already cited in this record are inside it, so it is 100% of the publisher's own manifest. ENUMERATION: Revel's only direct marketplace integration is documented with a complete Supported/Unsupported feature matrix - 'DoorDash Marketplace' (https://support.revelsystems.com/s/article/DoorDash-Marketplace, modified 2024-10-07), 'Revel now offers direct integration with DoorDash Marketplace, eliminating the need for middleware.' The matrix covers Eligibility, Custom Menus, Products, Modifiers, Inventory, Discounts, Taxes, Tips & Fees, Orders, Special Requests, Dining Options, Payments and CRM. Order state flows INTO Revel and item availability flows out ('On the fly changes using webhooks can be utilized for instantaneous updates, including item availability for products, modifiers, and ingredients'), but no order-ready or order-status event goes the other way, and the matrix says the reverse direction is explicitly broken: 'Refunds, voids and other modifications made on a DoorDash Marketplace order on the Revel POS will not update the order on DoorDash's end. The order will need to be modified in both systems for reports to be accurate.' Merchants are told to keep using the marketplace's own surface: 'Merchants will continue to use the DoorDash merchant portal and/or the DoorDash tablet for actions including: Cancellations, Order modifications and discounts, DoorDash specific reporting'. CONTROLS over all 698 bodies, tokenised case-insensitive: /\border\s+ready\s+(signal|status|event)|\bready\s+status/ 0/698; /\bOtter\b|\bItsaCheckmate|\bCuboh|\bChowly/ 0/698 (no aggregator is documented as carrying the signal either). POISON: /\border\s+ready/ does hit 6/698, and every hit is a GUEST-facing readiness surface, not a marketplace callback - 'SMS on Order Ready in the Kitchen' (Twilio SMS to the customer) and 'Order Ready XT View for Android TV' (a pickup display screen). Scoring on that 6 would have produced a false yes. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-09-17 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
Voids and comps each require a reason ('This requires the user to select a pre-existing reason or type in a new reason'; the POS Void Item(s) window prompts to 'enter the reason for the void'); Comps and Manual Discount are POS role-permission tokens, with Manager/Owner Access PINs required for restricted actions; and exceptions are reported via the Adjustments report ('a pre-payment auditing report focused on specific void, return, and exchange actions' drillable by order or employee), the Action Log, and Product Mix void/return/comp columns with an employee-sales audit mode. https://support.revelsystems.com/s/article/Loss-Management-Prevention-and-Auditing-1583149672029 · retrieved 2026-08-04
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
Verified and in fact understated: live components include Worldpay TriPOS, FreedomPay, Adyen, Worldpay, Eigen and the Revel Advantage Merchant Portal. Weakness to record: a status page proves integrations are operated, not that a merchant may freely select an acquirer at signing; no processor-choice policy document is publicly reachable. https://status.revelsystems.com/ · retrieved 2026-08-01 adversarially verified
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
No processing rate published anywhere; the vendor pricing page itself no longer exists. https://revelsystems.com/pricing/ · 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
326th: THE 325th MERGE HOLD IS ANSWERED. The hold said a no could not stand until 'the marketing and legal hosts' were bounded, because Shift4 supposedly 'sells pricing programmes heavily elsewhere'. Both hosts are now bounded and the premise is false. (1) MARKETING: revelsystems.com and www.revelsystems.com 301 to https://www.shift4.com/food-beverage (curl, browser UA, 2026-09-18), so Shift4's site IS Revel's marketing host. Its robots.txt is 'User-agent: * / Allow: /'; its sitemap INDEX resolves to exactly one child, shift4.com/sitemap-0.xml, 1,295 <loc>; 825 after dropping locale prefixes; 818 fetched at HTTP 200 and 7 are 404 (all obvious test slugs: legal-testing, 4ward-test, payment-links-test, test-spain, test-portugal, testing_greenhouse-comp, enterprise-support_kahala). This is a BODY census, 36,380,880 chars, not the URL census the 323rd had. Nonsense control: /zzz-nope-12345 returns 404 (8,433 B), so no soft-200 catch-all. EXTRACTION TRAP WORTH RECORDING: shift4.com is Next.js and the visible prose lives in the __NEXT_DATA__ JSON, so my first normaliser (which stripped <script> blocks) returned `revel` 0/825 - a FALSE zero on my own control term. Only after keeping script bodies did `revel` fire 470 times in 18 files. (2) LEGAL: https://www.shift4.com/revel-legal is Revel's own enumerated legal index - 'Privacy Policy, Agreements, and Terms & Conditions': Revel Privacy Policy, Revel Customer Agreement, Revel Freedompay Terms and Conditions, Revel Advantage XT Payment Terms, Revel Data Processing Addendum, Revel Hardware Sale Terms, Revel Reseller Customer Terms, Revel Care Terms, Revel API/XML Terms, Revel Support Services, Revel CCPA. I fetched all 7 PDFs it links (417 KB Revel Customer Agreement, 424 KB Revel Advantage XT, 400 KB Freedompay, 230 KB Reseller Terms, 11.5 MB DPA, Support Services, Modern Slavery) and extracted them with pdftotext -layout. THE DECISIVE DOCUMENT: the Revel Advantage XT Program Terms (Revel's OWN payment-programme terms, 'Version: 2024011223, Last Modified: 04-25-2024', canonical at portal.revelup.com/terms?id=g1629e23ab3101d) describes the whole programme - Sub-Merchant on-boarding, transaction limits, disputes, 'Pricing, Invoices and Changes' - and contains ZERO occurrences of dual pricing, cash discount, cash price, card price or even surcharge. If Revel sold a cash-discount programme, its payment-programme terms are where it would be. CONTROLS, tokenised, word-boundary, case-insensitive, over 832 documents (825 marketing/legal bodies + 7 Revel legal PDFs): `dual pricing` 0/832, `cash price` 0/832, `card price` 0/832, `cash discount` 1/832 and it is POISON - a casino cash-advance story, 'the significant margin between their quasi-cash discount rate and Shift4's modest service fee' (shift4.com/news/cash-advance-solution). `surcharge` 40 hits in 12/832 and every one is acquirer-side (card-scheme guidelines, DCC, online-ordering fee copy), 0 in any Revel document. And re-derived over the KB (698 articles, 2,592,423 chars, .cache/q325/revel-systems/kb/bodies.jsonl): `dual pricing` 0/698, `cash discount` 1/698 (Loyalty-XT, Como points). So the instrument now stands on three independent bounded corpora - the 14/14 anonymous OpenAPI 3.0 suites (198 paths, grade A), 698/698 live KB articles, and 832/832 marketing+legal documents - and the API evidence recorded in the 325th proposal (no cash/card price pair in Product's 145 properties; no second total in Order's 109; card cost modelled as Payment.card_surcharge / /resources/Surcharge/ / ServiceFee AUTOAPPLY_PAYMENTTYPE) is unchanged. COUNTER-EVIDENCE, still disclosed: ProductPriceTierPrice.price ('should not exceed the regular product price') invoked by an Alt Price discount, and Discount.restricted_payment_methods_array. Neither is documented as a tender-based price mode anywhere in the three corpora. Retrieved 2026-09-18. MERGE NOTE (326th): graded B: the cited URL is a vendor legal PDF; the grade-A OpenAPI suites are a supporting bound. https://www.shift4.com/pdf/Revel%20Systems%20Inc_.pdf · retrieved 2026-09-18 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
Surcharging exists but the guardrails do not: 'Creating a Surcharge' documents a flat percentage 'applied to every order' configured per establishment in Management Console Settings (Surcharge Name / Surcharge Percentage fields) with no card-type detection at all, and 'FAQ: Credit Card Surcharging' states debit/prepaid cards cannot be surcharged and cites 'a 3% surcharge cap' while making clear 'it is your responsibility as a business owner to stay current with the latest compliance rules and regulations' - i.e. the merchant, not the engine, enforces the exclusions and the cap. Named shortfall: no automatic BIN/product-code debit-prepaid exclusion or network-cap enforcement is documented anywhere in the complete help centre; the only per-card-type surcharge configuration is the Adyen AU/NZ setup, applied on the terminal and provisioned by Revel Payment Operations via email request (payments-management@revelsystems.com), not merchant-controlled. https://support.revelsystems.com/s/article/Creating-a-Surcharge-1583149094546 · retrieved 2026-08-04
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
EMV and contactless are documented across the whole active terminal fleet: the Active Supported Hardware catalogue describes the Ingenico iSMP4 as enabling 'EMV chip & sign, magstripe, and NFC/contactless cards or mobile wallets', the Lane 3000 as accepting 'EMV chip and pin, card swipes, NFC, and all contactless payments', the Lane 3600 with 'advanced NFC and contactless capabilities', the Moby 5500 with 'EMV chip, magstripe NFC/contactless cards, or mobile wallets', and the Verifone V400m, Adyen P400 Plus and Adyen AMS1 each as an 'EMV, contactless-enabled payment device'. Named shortfall, which is why this is not yes: wallet coverage is gateway-dependent, not universal. The full list of 'Mobile Wallets: ApplePay, GooglePay, Samsung' alongside types 'Manual Entry (MKE) / Swipe / Insert EMV / Contactless-Tap' appears only in the Revel Advantage INTERNATIONAL FAQ, covering the Adyen/Verifone estate. The general Payment Gateways & Processors Overview lists supported methods as 'Mobile Wallets (Apple Pay, etc.)' without naming Google Pay, and Revel's release notes record Apple Pay being added per gateway (FreedomPay at the 2.73 release). No document establishes Google Pay across all first-party terminals on the domestic TriPOS/FreedomPay estate. https://support.revelsystems.com/s/article/Revel-Advantage-International-FAQ · retrieved 2026-08-02 adversarially verified
Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator
payments-softpos-tap-to-pay
CLAIM: accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. VERDICT: no. ENUMERATION, and it is current: 'Active Supported Hardware' (https://support.revelsystems.com/s/article/Active-Supported-Hardware, modified 2026-04-23) opens 'Here you can find all the active and supported hardware by Revel Systems' and sections it as Printers, Scanners, Scales, Payment Devices and Accessories, Networking, Screens & Additional Peripherals, Stands & Cash Drawers. The complete Payment Devices list is ten separate physical terminals - Ingenico iSMP4, Ingenico Link 2500, Ingenico Lane 3000, Ingenico Lane 3600, Ingenico MOBY5500, Verifone V400m, Adyen P400 Plus, Adyen AMS1 - plus the iPad Air (6th generation) and iPad Mini (7th generation) as POS tablets, which are listed as tablets and never as acceptance devices (e.g. 'The iPad Air (6th generation) features a big 11" Liquid Retina display, USB-C connection, and the powerful M2 chip'). Every acceptance path in the list is a discrete reader; the closest thing to phone acceptance is the Adyen AMS1, 'a small, battery-operated payment terminal running on an Android operating system', which is still a Revel-sold terminal rather than the merchant's commodity phone. BOUND: the 100% live census of support.revelsystems.com via the Salesforce guest knowledge API (https://support.revelsystems.com/services/data/v59.0/support/knowledgeArticles?pageSize=100, 698/698 articles with bodies; 121/121 already-cited article URLs inside it). CONTROL over all 698 bodies, tokenised case-insensitive: /\btap\s+to\s+pay|\btap.to.phone|\bsoftPOS/ 0/698. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-09-17 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
The mobile hardware is documented: the Moby 5500 'provides a smaller, more cost-effective way to accept payments and is optimized for mobility', pairing over Bluetooth with the iPad POS to 'accept contactless, inserted, or swiped payments', and Revel documents an IPORT mobile order taker (MOT) case (added in 2.77) plus MOT operating practices (Revel Wi-Fi requirement, single-dock charging) for iPads running the full POS app - so orders can be taken and EMV/NFC payment accepted away from the counter, with the POS app's split-bill and tip-entry features available on that device. Named shortfall: no article documents a guest-facing tip prompt on the handheld flow - customer-facing tip prompts are documented only on the countertop CDS XT ('tip suggestions by thresholds'), on Adyen terminals of the international estate (tipping options configured via the Adyen portal), and in the SmartPay guest-phone flow - and no dedicated pay-at-the-table workflow article exists. https://support.revelsystems.com/s/article/Moby-5500 · retrieved 2026-08-04
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
'Revel SmartPay lets guests pay for their orders from their smartphones, either by scanning a QR code or by following a link sent through SMS'. Enabling 'Print QR Barcode on Receipt' prints a QR on the customer receipt copy; scanning it 'will take the customer to the order status page, where they can see details of their order' and, if enabled, add a tip via Suggested Tip Amounts prompts (e.g. 10/15/20%), then pay and receive a confirmation page. SmartPay is enabled per establishment in the Management Console for Adyen, TriPOS, or Revel Advantage FreedomPay; the SMS variant additionally requires the Twilio integration. Separately, Revel Smart Order is 'our fully contactless dine-in solution' where customers 'scan a QR code, order, and pay at the table, all without ever having to talk to a waiter' via Online Ordering XT. https://support.revelsystems.com/s/article/Revel-SmartPay · retrieved 2026-08-04
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
Both flows and the window are documented. Post-auth tip adjust: tips are added on the payment screen ('the tip amount can only be added after the initial order transaction has been processed') or in bulk on the Payments Waiting to Batch screen, whose Tip field is editable per transaction and searchable by Order ID, Transaction #, last-4 or cardholder name; the adjust window is explicit - tips must be entered before capture ('all tips must be entered before the auto capture time'; 'Make sure to add any tips prior to capturing your payments for the day'), after which a tip can only be run as a separate authorization via the Revel Advantage portal (bulk tip-adds not supported). On-device prompts: the Revel Advantage International FAQ documents 'adjusting tipping options on our payment terminals instead of the POS' (configured in the Adyen portal), and the CDS XT customer display supports 'tip suggestions by thresholds'. The batch screen is permission-gated (Batch Process permission), serving as the manager screen for unadjusted tips. https://support.revelsystems.com/s/article/How-to-Add-Credit-Card-Tips-on-the-Point-of-Sale-1582900280542 · retrieved 2026-08-04
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
Fully documented native module: Settings offer Tip In Based On Tips or Sales, Tip Share Even (allocated by hours worked) or Percentage by role, Treat Declared Tips As Total/Cash Only/Ignore, periodicity By Week/Day/Shift, and per-role tip-in %/tip-share % tables; the Schedules > Tip Pooling tool computes a per-employee breakdown (Declared Tips, Payment Tips, Tip In Amount, Tip Share Amount, Final Tips - 'their final take home tips and the amount that should be reported to the IRS') that a manager must submit, and a Final Tips column plus Tip Pool Results then appear on the Payroll report ('The saved results will be updated in the Payroll tab'). Points-based allocation is not offered, but the claim's enumerated methods (hours worked, sales, role percentage) are all covered and the allocation flows to payroll reporting. https://support.revelsystems.com/s/article/Tip-Pooling-1583150213556 · 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
Re-homed onto the live Salesforce URL and re-quoted - the previously recorded setting names were not the ones the article uses. Offline Payment Settings in the Management Console are 'Enable offline credit card payments', 'Request customer data when accept payment offline' and 'Show warning message before approve offline payment', with three configurable ceilings: 'Max amount for single offline payment', 'Max total amount for all unprocessed offline payments' ('Once your system reaches this threshold, you can only take any more offline credit card payments once the system is back online and all offline payments are processed') and 'Max threshold of total amount for all outstanding declined payments'. Store-and-forward is named as such in the Adyen section: 'Store-and-forward payments: the payment terminal approves payments without any verification.' Forwarding on reconnect is documented in the manual-batching article, where an Offline Payments tab holds transactions 'authorized but not yet validated by the system' with a Force control. Real limitations: 'Debit payments can't be accepted in Offline Mode' (Apple Pay does work), and per Revel POS Payments Overview 'Offline mode is not available for all payment integrations' - TriPOS and FreedomPay iFCC cannot toggle offline processing at all and must be forced by unplugging the ethernet cable, and Adyen requires Capture on Swipe plus vendor enablement. https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418 · retrieved 2026-08-09 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
Liability is stated in the vendor's own docs: 'Forcing offline payments is performed at the Merchant's risk. As with any payment taken offline, there is a risk of authorization failure based on card status and available funds which can only be determined once reprocessed when online', with enumerated risk factors borne by the merchant (chargebacks - 'your chances of winning are meager', credit card fraud, additional processing fees per attempted re-authorization). Post-reconnect failures are surfaced: the POS Operations tab includes a Declined Payments tab with a per-status counter, Retry All/Retry and Delete controls, and (since 2.79) an offline-replay UI showing replay status and daily replay count, with declined offline transactions automatically retried daily for up to 10 days; the Management Console Payments Summary report is the prescribed review ('It is a mandatory practice for merchants to check credit card transactions regularly'). https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418 · 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 management listed; Givex is a monitored integration. Cross-location and online redemption unverified. https://status.revelsystems.com/ · retrieved 2026-08-01
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
House accounts are first-class API resources -- HouseAccount, HouseAccountPayment and HouseAccountTransaction -- readable with patch/put (no post). The schema carries `balance` and `end_balance`, so the claim's running-balance conjunct is met. Shortfall re-measured on the new surface rather than carried over: the spec contains no credit-limit field and no statement or invoice generation operation, so two of the claim's three conjuncts are unmet and partial holds. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/house_accounts_suite.yaml · retrieved 2026-08-10
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
The Split Bills article (already cited elsewhere in this record, support.revelsystems.com/s/article/Split-Bills-1582901435396, retrieved 2026-08-02) documents four named split modes - Split Evenly, Split Manually, Split By Item, and Split By Seat Number - each producing multiple separate checks from one order. That is real evidence a single order can be divided many ways. Named shortfall: the article documents splitting the ORDER into checks, not the settlement of ONE check across multiple tenders (cash+card, gift+card, etc.), and states no numeric cap on split count, so 'no hard cap below eight ways' cannot be confirmed either way. support.revelsystems.com is otherwise inaccessible this pass (401/JS shell), so a dedicated tender-splitting article could not be located. https://support.revelsystems.com/s/article/Split-Bills-1582901435396 · retrieved 2026-08-04
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
The Split Bills article (support.revelsystems.com/s/article/Split-Bills-1582901435396, already cited in this record, retrieved 2026-08-02) states that 'Clear Split Bills' (merging split checks back together) 'requires a security PIN from an employee with refund permission' because it refunds all payments on the order - real evidence that refunds are gated behind a named permission. Named shortfall: this is the only documented authorization control found; void, discount, and no-sale specifically are not addressed in any page this pass could open, and no immutable audit log identifying the approving employee is described anywhere - only that a PIN is required at the point of action. support.revelsystems.com (help centre) returned either HTTP 401 (the /hc/en-us Zendesk-style path) or an unrendered client-side app shell with no server-delivered article text (the /s/article/ Salesforce help-site path, which shows only a loading spinner and a 'CSS Error' notice to every fetch method available this pass); reveluniversity.revelsystems.com returned HTTP 403; web.archive.org is blocked outright to the fetch tool; www.shift4.com/food-beverage, where revelsystems.com's own marketing pages now redirect, returned HTTP 403/429. https://support.revelsystems.com/s/article/Split-Bills-1582901435396 · retrieved 2026-08-04
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
The Revel Advantage merchant portal (portal.revelup.com) has a Disputes page (Dashboard > Disputes or Dashboard > Notifications) listing each chargeback with a Transaction Details screen and three actions - Respond (add contact name/note, attach documentation such as receipts, order information or a signed invoice as PDF, and Submit Response), Accept Liability, and Mark as Unread - plus configurable email Chargeback Alerts and per-dispute reason codes (Disputes > Dispute Details > Reason Code). Named shortfall: this dashboard exists only for Revel Advantage (in-house processing) merchants - users of other processors are pointed to the processor's own portal (e.g. Adyen Risk > Disputes) - and dispute evidence is manually uploaded PDF documentation, not assembled from the POS transaction record. https://support.revelsystems.com/s/article/Managing-Chargebacks-Disputes-in-Your-Revel-Advantage-Portal · retrieved 2026-08-04
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
Documented only for online ordering: guests with an account on the Online Ordering site can check 'Save for future payments' at checkout - card entry happens on the Vantiv (Mercury) Hosted Checkout page, so the PAN is captured on the processor-hosted page rather than by the merchant - then reuse the stored card from a Choose Card drop-down on later orders and manage/remove cards under Payment Methods in their profile (cards can only be added at checkout, not from the profile). Named shortfall: the tutorial is explicitly 'for Mercury/ Vantiv hosted checkout' only, and no article documents reusing a stored card for phone orders or in-store POS payments, so the cross-channel half of the claim is not established. https://support.revelsystems.com/s/article/Saving-and-Changing-Credit-Card-Details-for-Online-Ordering-1583152074721 · retrieved 2026-08-04
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
A next-day option exists but no deposit schedule is published: the Revel Advantage XT fee schedule lists a 'Next Day Funding Fee: Charges for receiving funds from transactions on the next business day, offering faster access to your funds. Not all clients or transactions are eligible for next-day funding', and the Batching Payments article states funding times 'can depend on your processor and other factors, such as your processor's standard funding schedule and any additional funding services you may have signed up for' - i.e. the standard deposit schedule itself is nowhere published. (On the Adyen international estate the Sales to Payouts report shows daily disbursement totals, but as reconciliation reporting, not a committed schedule; no same-day/instant option is documented.) https://support.revelsystems.com/s/article/Revel-Advantage-XT-Payment-Processing-Fees · retrieved 2026-08-04
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
Both halves are partly there: the FreedomPay setup article states 'FreedomPay fully protects the merchant environment with validated P2PE (Point-to-Point Encryption)', and the PCI FAQ states 'Revel Systems is fully PCI DSS compliant and can provide an attestation of compliance (AOC) upon request' via the customer success manager or risk-payments@revelsystems.com. Named shortfall: no document anywhere in the complete help centre states the PCI DSS version - '4.x'/'4.0' never appears in a PCI context - and validated P2PE is documented only on the FreedomPay gateway path; the Adyen estate is described only as using Adyen encryption on Revel-supplied devices, with no P2PE listing named. https://support.revelsystems.com/s/article/Revel-Advantage-FAQ-for-Merchant-PCI-Compliance · retrieved 2026-08-04
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
Re-homed onto the live Salesforce slug (the Zendesk article is customer-gated). Per-item routing is self-serve: in the Management Console under a product's Display/Print Options, 'enter the printer and/or display unit names you want to assign to this product. If a printer or display unit is assigned, that means the product will print or show when it's ordered and sent from the Point of Sale', and the same field is settable in bulk through Products > Import/Export > Products (Advanced export, Printers in Column K). Routing by order type is separately documented as 'Printer Setup by Dining Type' under Settings, which sends chosen dining options to the kitchen (https://support.revelsystems.com/s/article/How-to-Send-to-the-Kitchen-by-Dining-Option-1582898971400). Shortfall worth recording, though it does not defeat the claim: multi-station kitchen FLOWS - the ordered sequence of displays an item traverses - must be created by Revel Support ('Please contact the Support team to help to set up a kitchen flow'), after which the merchant may assign products to a flow and modify it without vendor involvement. https://support.revelsystems.com/s/article/How-to-assign-products-to-kitchen-printers-display-unit-KDS-1583149941086 · retrieved 2026-08-09 adversarially verified
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
Re-evidenced; the sentence previously quoted is not present in the migrated help centre and is withdrawn. The Automated Expo Experience article states the consolidation and the completion condition in its own words: 'A single order may have food coming from several different kitchen prep/cook stations and the person standing at the expo window needs an easy way to know when food is ready', solved by 'Automatically printing a ticket from the expo view KDS when all items are marked done on the kitchen view KDS', with a companion setting 'Auto Close Tickets/Orders. This will automatically close an order on the expo screen once all items are completed.' Expo is a first-class configured role, not a view: Kitchen Views are assigned a 'Default Kitchen View: Line Expedite' or 'Line Kitchen', and 'You can set up multiple kitchen views that use one expedite view' (https://support.revelsystems.com/s/article/Kitchen-Flow-Bump-Feature-Setup-1582899129146). Products that need no station work can be flagged 'Auto Complete on KDS' so they still appear on the expo ticket. https://support.revelsystems.com/s/article/Automated-Expo-Experience · retrieved 2026-08-09 adversarially verified
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
Documented TSR Course Fire feature: 'Prompt for course' assigns each item to a course; courses are held and fired manually via Fire Next Course / Send Course on the POS ('To send each course to the kitchen separately... Tap Send to Kitchen: Tap Send Course'), with an optional 'Automatic course firing from Done on KDS' with a configurable delay that employees may override on the POS. Optimize KDS for Coursing 'will only send products to the KDS when that course is ready for preparation.' https://support.revelsystems.com/s/article/TSR-Course-Fire-1582902249374 · retrieved 2026-08-04
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
Prep/Cook Time article: a per-product 'Prep/Cook Time' field (minutes) is set in Products; 'The Use Prep Time to display items on KDS setting displays items with longer prep times on the KDS before items with shorter prep time, so all items will be ready and can go to the table together.' The Dynamic Prep Times option additionally shows the next item(s) immediately if an item finishes early rather than waiting out the set prep time. https://support.revelsystems.com/s/article/Prep-Cook-Time-1583152074715 · retrieved 2026-08-04
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
Online ordering settings include 'Max number of online orders: Maximum number of online orders per time slot' and 'Online order time slot: Interval in minutes that defines available pickup/arrival/delivery time slots', which caps incoming digital orders per interval. Shortfall: the cap is a fixed configured number, not driven by live kitchen load or ticket times, and quoted prep times cannot be extended dynamically - the Online Ordering FAQ states 'The functionality for multiple prep times doesn't exist at this time.' https://support.revelsystems.com/s/article/Online-Ordering-Setting-Up-Online-Ordering · retrieved 2026-08-04
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
DoorDash Marketplace integration: 'Item availability (86ing) for products / modifiers / ingredients' is supported and 'On the fly changes using webhooks can be utilized for instantaneous updates, including item availability'; store pause 'can be done on Revel via the management console setting Pause orders from DoorDash Marketplace'. Uber Eats onboarding: 'Item availability feature can be utilized to update product inventory on Uber Eats. The Item availability Webhook needs to be enabled.' 86ing is performed from the POS Item Availability feature; group-combo 86ing to DoorDash was not yet supported at time of writing. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
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
CLAIM: 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. VERDICT: no. BOUND: the same 100% live census of support.revelsystems.com (Salesforce guest knowledge API, 698/698 articles with bodies, 121/121 already-cited article URLs present). EVIDENCE: Revel documents exactly what a KDS bump triggers, and the destinations are internal or guest-facing only. 'SMS on Order Ready in the Kitchen' (https://support.revelsystems.com/s/article/SMS-on-Order-Ready-in-the-Kitchen): 'This feature sends an SMS to a customer when their order is ready... select if the SMS should be sent on Done or Complete on an Expo KDS... this feature requires a Twilio integration.' 'Order Ready XT View for Android TV' (https://support.revelsystems.com/s/article/Order-Ready-View-for-Android-TV) drives a customer display from the same Expo state: 'Order Ready XT Delay in Seconds: Input the number of seconds from tapping Complete on the Expo that the order will move from being prepared to being ready on the Order Ready XT Screen.' Neither emits anything to a marketplace. The DoorDash Marketplace feature matrix (https://support.revelsystems.com/s/article/DoorDash-Marketplace) is the complete statement of what Revel exchanges with a marketplace and contains no readiness event in the outbound direction, while stating that even refunds and voids made on the Revel POS 'will not update the order on DoorDash's end'. CONTROLS over the 698 bodies: /\border\s+ready\s+(signal|status|event)|\bready\s+status/ 0/698. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-09-17 adversarially verified
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
Withdrawing the previous note's claim that no supported-hardware list exists - it does. Revel's Active Supported Hardware page ('all the active and supported hardware by Revel Systems') lists a Bump Bar under Screens & Additional Peripherals: 'Protect your kitchen display system (KDS) screen with a 20-key bump bar. Boasting a sealed membrane input surface, this durable bump bar enables your staff to update orders on the KDS without touching the screen directly', connection 'Plug and Play', with a vendor-hosted spec sheet at revelup-techpubs.s3.us-west-2.amazonaws.com/support/hc/en-us/000002619/bumpbar.pdf. Physical bump bars are also treated as standard equipment in the KDS setup documentation, which includes an 'Updating Your Bump Bar Layout' procedure and ships a printable key layout (https://support.revelsystems.com/s/article/Kitchen-Flow-Bump-Feature-Setup-1582899129146). Honest limit: it is one Revel-branded 20-key SKU rather than a compatibility matrix of third-party models. https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-08-09 adversarially verified
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
Production View on the KDS: 'shows the queued orders on the left and the individual products or tags from those order on the right... an easy-to-read view of ordered items (and their quantities)' as 'a running list of products'; selecting Tagged shows 'tags of how many products and modifiers are in the current orders', covering modifier-level counts. Voided items are excluded from production totals. Configured per KDS under Establishment > Kitchen Views > Kitchen > Production View. https://support.revelsystems.com/s/article/Production-View-on-the-KDS-1582899129813 · retrieved 2026-08-04
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
Colored Timing on Tile Expedite View: per Kitchen View, 'enter a time in HH:MM:SS... to indicate when you want the order to turn green, yellow, or red', with configurable Reset Expedite Timers behavior (never / after each item / after all items / from initial item); timers are independent per view and can be set from the Management Console or on the KDS itself. Visual color escalation only - no audible alert is documented (claim accepts visual and/or audible). https://support.revelsystems.com/s/article/Colored-Timing-on-Tile-Expedite-View-1582899129853 · retrieved 2026-08-04
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
Auto Redirect (Printing Failover) provides 'temporary and automatically redirect a receipt from non-working or busy printer', with an ordered list of failover printers retried in a loop 3 times. Shortfall: it works for Epson ePOS LAN printers only, only between matching printer models and types, and 'is configured per POS and configuration is not shared between POS'; there is no documented automatic failover for a KDS screen going offline - screen/other-printer redirection is a manual Redirect setting per station that must be re-established after app updates. https://support.revelsystems.com/s/article/Printing-Failover · retrieved 2026-08-04
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
Outage best-practices article: 'When Server is down, you'll still be able to access the following functions: Create and close orders... Print to kitchen and receipt printers (ethernet or BT connected); Use CDS & KDS.' During an ISP/Network outage, 'Create and close orders' and 'Print to kitchen and receipt printers (ethernet or BT connected)' remain available - Revel runs on the establishment's local network, with POS and KDS devices on static local IPs (192.168.22.x). https://support.revelsystems.com/s/article/outage · retrieved 2026-08-04
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
KDS Styles Overview: as of 2.79 a 'list view option for modifiers... will display all modifiers for the item in a list' (full modifier breakout), enabled under Establishments > Peripherals > Kitchen Views > [Device] > Tile Expedite > Modifier List View. KDS Tags additionally let stations show per-component tags on products and modifiers - 'useful for employees who are responsible for only one section of the kitchen line and only need to know what items they need to prepare' - including quantity tagging (e.g., the burger tag added twice for a double hamburger). Recipe-step display is not documented; the claim accepts full modifier breakout. https://support.revelsystems.com/s/article/KDS-Styles-Overview-1582899129825 · retrieved 2026-08-04
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
Split Modifiers are documented: 'On the bottom of the modifier pop-up, tap First Half or Second Half. Tap a modifier to add to that half of the pizza', with split or full pricing options ('a pepperoni topping priced at $.50 will ring up as $.25 if a customer orders pepperoni on only half'). Shortfall: only halves (First Half / Second Half) are supported - no quarters or arbitrary sections - and the kitchen ticket/KDS shows the half assignment as text labels; no graphical make-line rendering is documented. https://support.revelsystems.com/s/article/Advanced-Modifier-Features-1583154976185 · retrieved 2026-08-04
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
'Revel allows items or entire orders to be reprinted to the kitchen, if necessary. When reprinted, the receipt will indicate that it is a reprint' - gated by the Manual Receipt Print permission, with order lookup by Order ID, customer name, card, or date range so nothing is re-rung. On the KDS side, completed orders can be recalled: Tile Expo has a Recall Mode ('you no longer need to recall the order to get the reprint - you can instead simply go into Recall Mode, press the Print button'), and the Speed of Service report explicitly accounts for recalled orders. https://support.revelsystems.com/s/article/How-to-Reprint-to-Kitchen-Receipts-1582901899083 · retrieved 2026-08-04
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
KDS Styles Overview, 'Send New Tickets on Send After the Order Reopened/Modified': 'as a new item is added to an existing order, a sub ticket will be created... labelled with the original order number, and consist of a ticket count (e.g., 1235-1, 1235-2, 1235-3). This enhancement will ensure your kitchen staff can easily view new items, so that nothing is missed.' Shortfall: additions surface as separate sub-tickets rather than flagged changes on the live ticket, and only additions are covered - the article states 'After an order has been sent, it cannot be modified'; removed/changed items are not flagged at item level (voided orders show red only in the Expedite Status section). https://support.revelsystems.com/s/article/KDS-Styles-Overview-1582899129825 · retrieved 2026-08-04
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
'Send SMS on Order Ready in the Kitchen' sends a customizable SMS 'on Done or Complete on an Expo KDS', filterable by order type - but 'this feature requires a Twilio integration.' The branded Order Ready XT split-screen preparing/ready board for Android TV 'requires a paid subscription.' Included without extra purchase is only the basic Order Display KDS style ('Normally used as a customer display to show customers when their order is completed'). Shortfall: SMS depends on a third-party Twilio account and the flagship status board is a paid add-on; no app push exists. https://support.revelsystems.com/s/article/SMS-on-Order-Ready-in-the-Kitchen · retrieved 2026-08-04
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Product Setup on the Point of Sale lets staff 'update quantities for Received, Actual and Wasted amounts... Use Wasted if a product has been broken or expired to deduct from inventory numbers', so waste entry depletes inventory from the front-of-house device. Shortfall: entry happens in the POS Product Setup screen (or the separate Revel Inventory mobile app), not at the kitchen/KDS screen, and there are no reason codes - only a single Wasted quantity field. https://support.revelsystems.com/s/article/How-to-Use-Product-Setup-on-the-Point-of-Sale-1582899333978 · retrieved 2026-08-04
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
The Speed of Service report 'records the time an item spent on the Kitchen Display Screen (KDS) until the time it was delivered to the customer', with columns for Start Time, KDS Complete, Expedite Complete, Time on KDS, Time on Expedite, and Total Kitchen Time, viewable by item or order and filterable by Employee, Product Class, and custom date/time range (requires In-Progress Mode on the KDS). Shortfall: no percentile statistics and no slicing by daypart, station, or order channel is documented; the report itself warns that recalled orders inflate reported KDS times. https://support.revelsystems.com/s/article/Speed-of-Service-Report-1583149670649 · retrieved 2026-08-04
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
Item Tracking / Product Forecasting 'allows users to plan for how many of those items to have prepared and ready before the customer orders': forecast prep amounts are computed from a configurable number of weeks of Net or Gross sales history per time-slot interval, and scheduled prep reports print automatically to a designated kitchen printer - Start of Day Report (X minutes before open, with per-time-slot forecast totals), Interval Prep Reports (every 15 min to 4 hours, with prior-hour and cumulative totals and next-slot forecast), and a Closing Prep Report summarizing 'what will need to be prepared for the next day.' https://support.revelsystems.com/s/article/Item-Tracking-Product-Forecasting-1583149672017 · 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
A Driver employee role exists and gates access to the Delivery XT Agent app; Manager/Dispatcher is a distinct role gating the Dispatch app. Driver is a first-class entity, not a workaround. https://apps.apple.com/us/app/revel-delivery-xt-dispatch/id1531919449 · retrieved 2026-08-01 adversarially verified
Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).
delivery-dispatch-board
Revel ships Delivery XT: a Dispatch iPad app (Manager/Dispatcher role only) giving a single dashboard to assign orders, estimate delivery times and track drivers, plus a Driver Agent app on iOS and Android. Published by 'Revel Systems INC' on the App Store, last updated 2025-08-25, and both 'Delivery XT' and 'Driver XT' are live monitored components on status.revelsystems.com as of 2026-08-01. Material caveat the dossier could not flag because it missed the product entirely: Delivery XT is a separate add-on module and is powered by Captain AI, so it is white-labelled rather than wholly in-hous https://apps.apple.com/us/app/revel-delivery-xt-dispatch/id1531919449 · retrieved 2026-08-01 adversarially verified
Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator
delivery-route-map
Delivery Management's Map View shows all orders as geocoded pins with ready-time/distance detail and 'the best route'; a Delivery Optimization setting recommends which unassigned orders a driver should batch into their run (green flag, with 'Max time between addresses' and 'Max wait for next order' fields), and driver check-out can print/email 'Order & Route Info' with directions. Shortfall: explicit stop-sequencing/turn-order optimization within a multi-stop run is never documented, and the newer Delivery XT dispatch app documents manual assignment only ('The system does not assign drivers automatically') with per-order navigation via Google/Apple/Waze. https://support.revelsystems.com/s/article/Delivery-Management-Written-Instructions · retrieved 2026-08-04
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
Live driver tracking is the headline documented function — 'Watch your drivers move around the city' / 'Know when they are returning' — with in-app navigation for the driver. https://apps.apple.com/us/app/revel-delivery-xt-dispatch/id1531919449 · retrieved 2026-08-01 adversarially verified
Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator
delivery-zones-polygon
'Delivery area by GeoJson' — a GeoJSON string describing the delivery area, drawn with tools such as geojson.io and pasted into the Management Console Delivery settings; 'Only polygon strings are supported. Revel does NOT support line strings.' A postcode-list alternative also exists, and zone-based delivery service fees use additional GeoJSON polygon zones. https://support.revelsystems.com/s/article/Delivery-Management-Settings-1583149409705 · retrieved 2026-08-04
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
Zone-based delivery fees are documented: draw GeoJSON zones, attach each set of zones to its own service fee (e.g. all $7.99 zones on one fee, $9.99 zones on another), and fees are 'assessed according to the zone that includes the customer's address' (where zones overlap, the lower fee is charged); distance-based fee tiers (e.g. 'Delivery Fee 5-10 Miles') auto-apply by the Delivery dining type. Shortfall: per-zone order minimums and per-zone quoted promise times are not documented — order minimums exist only as global Online Ordering 'Order Rules', and delivery-time estimation is prep-plus-drive-time based, not per zone. https://support.revelsystems.com/s/article/Delivery-Zone-Service-Fees · retrieved 2026-08-04
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
Delivery-area checks run at address entry: with 'Delivery area by post codes', 'The POS will check delivery addresses against the list of acceptable post codes. If the post code is not found, the system will warn the user that delivery cannot be made to this address'; with a GeoJSON area, 'an error will occur when trying to enter in a customer's Delivery address' outside it. The Driver Manager role holds an explicit permission to 'approve a delivery to an address outside the approved delivery area', and delivery mileage defaults come from the Google Maps service. https://support.revelsystems.com/s/article/Delivery-Management-Settings-1583149409705 · retrieved 2026-08-04
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
Per-run mileage is captured at driver check-in ('Enter the mileage value in the Enter Total Mileage of Delivery pop-up' — default value is the Google Maps trip distance), credit-card tips are entered per driver at check-in, and a Delivery Drivers report (Reports > Other Reports > Delivery Drivers) holds 'total trips, delivery time, cash payments, tips, etc.'. Shortfall: no per-delivery flat reimbursement rate is documented, and no payroll export separating reimbursement lines from wage lines is documented. https://support.revelsystems.com/s/article/Delivery-Management-Written-Instructions · retrieved 2026-08-04
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
Drivers carry per-employee Virtual Tills; check-in prompts credit-card tip entry, closing unpaid orders to cash, and mileage; the End Shift process counts the till (sum total or per-bill quantities), shows a checkout summary, submits payment for all open orders ('close to cash'), and prints a driver Sales Summary plus manager/driver-signed clock-out receipts. The Tills Report Variance column is the per-till over/short: 'Positive numbers mean a cash overage, negative numbers means less cash than expected' (Tills Reports, https://support.revelsystems.com/s/article/Tills-Reports-1582899801519). https://support.revelsystems.com/s/article/Delivery-Management-Written-Instructions · retrieved 2026-08-04
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
'Driver XT Powered by DoorDash' natively hands first-party delivery orders to DoorDash Drive: after checkout 'a request for a DoorDash driver at your location will be sent to DoorDash', the courier tracking link is 'available in the sidebar for each order' on the POS, and 'Delivery fee and driver tip do go into Revel and DoorDash reporting'. Shortfalls: dispatch fires only for orders placed on the Online Ordering XT site (OOXT subscription required — 'DoorDash Drive cannot operate without it'), delivery radius is capped at 5 miles ('Max Delivery distance' must be 1-5), it 'must not' be combined with Delivery XT, and it is QSR/TSR-only in US/CA/AU. No Uber Direct, Nash or Relay equivalent is documented. https://support.revelsystems.com/s/article/Driver-XT · retrieved 2026-08-04
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
Documented mutual exclusivity rules out hybrid dispatch: Driver XT (DoorDash Drive) requirements state 'Must not use Delivery XT', so the in-house driver product and the DaaS courier product cannot run together, and under Driver XT every OOXT delivery order is sent to DoorDash with no overflow rules. Conversely, Delivery XT documents 'All drivers must be assigned by the dispatcher or manager. The system does not assign drivers automatically', and both marketplace integrations state self-delivery is not supported. No overflow/fallback rule engine (driver-unavailable, out-of-zone, or wait-threshold) appears anywhere in the complete public help centre. https://support.revelsystems.com/s/article/Driver-XT · retrieved 2026-08-04
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
'Revel now offers direct integration with DoorDash Marketplace, eliminating the need for middleware' ($20/month/establishment subscription, 'no additional transaction or order fees from Revel') and 'direct integration with Uber Eats, eliminating the need for middleware' (UberEats-Onboarding, which even instructs ex-middleware merchants to return their Uber Eats tablet). Shortfall: Grubhub is not among them — zero Grubhub mentions across the complete 693-article public help centre; marketplaces other than DoorDash and Uber Eats route through Revel's online-ordering partner integrations. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
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
DoorDash Marketplace orders sync to the POS in real time as normal tickets under the 'DD Marketplace' dining option: 'a notification will appear at the top of your point of sale screen', orders arrive fully paid ($0.00 due), Auto-close paid orders closes them automatically, the 'Print online orders' setting fires them to printers, and special requests display on the KDS; no tablet re-keying or manual accept step is part of the documented flow. Uber Eats orders likewise 'arrive to POS fully paid under the Uber Eats dining option'. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).
delivery-86-sync
Item availability (86ing) syncs for products, modifiers and ingredients: 'On the fly changes using webhooks can be utilized for instantaneous updates, including item availability'; 'Items marked as unavailable on the POS will not be displayed on DoorDash. Once the item is marked as available again on the POS, then it will be displayed on DoorDash' — even removing an in-cart item mid-checkout. Uber Eats supports the same via the Item Availability webhook, and zero/negative-stock items are withheld on both channels. Caveat: 86ing group combo products is not yet supported on DoorDash. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
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
A Management Console setting 'Pause orders from DoorDash Marketplace' pauses the store from Revel's side, documented as an alternative to the DoorDash merchant portal or tablet. Shortfalls: no timed auto-reactivation is documented (and while the setting is enabled, menu changes stop syncing to DoorDash until it is disabled); no equivalent Revel-side pause is documented for Uber Eats; and the control lives in the Management Console rather than on the POS station. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
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
The data a payout reconciliation needs is documented as absent from Revel: 'Any fees collected by DoorDash will not be reported to Revel: Delivery fee, Dasher tips, Other fees collected by DoorDash'; the Uber Eats article states the same ('Any Fees collected by Uber Eats will not be reported to Revel (Delivery fee, tips, Tax on delivery fee, other fees)'); DoorDash-applied discounts 'will not report the discount in Revel', refunds/voids 'will need to be modified in both systems for reports to be accurate', and merchants are directed to the marketplace portals 'for more robust reporting on DoorDash specific orders and other DoorDash related data'. Revel reporting shows 3P sales via the DD Marketplace/Uber Eats order and payment types only — no commission, marketing-fee or payout-matching reconciliation report exists. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
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
Failure modes are documented as silent on the operator side: DoorDash orders containing out-of-stock items 'will not be processed, will be canceled after submission, and will not show up on the POS or in reports'; orders containing products created manually in DoorDash 'will cause the order to fail and not sync to Revel'; Uber Eats orders violating the global order rules 'will get canceled after' checkout. No operator-facing integration-health view, per-channel connection status, or injection-failure alert is documented anywhere in the complete 693-article help centre — the only failure surface is the developer-facing webhook message-log API noted in the prior pass. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
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
A customer tracking link showing order status and driver proximity is documented as part of Delivery XT. https://apps.apple.com/us/app/revel-delivery-xt-dispatch/id1531919449 · retrieved 2026-08-01 adversarially verified
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
UPGRADE TO PARTIAL ONLY (schema lacks that verdict). Delivery time estimation is a documented Delivery XT function; the estimation model, whether promise times feed the POS/KDS, and load-based adjustment are undocumented. https://apps.apple.com/us/app/revel-delivery-xt-dispatch/id1531919449 · retrieved 2026-08-01 adversarially verified
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
Partial: Revel documents delivery-specific degraded-mode behaviour, but scoped to a Delivery XT service outage rather than to an internet outage, and it never addresses driver settlement. The Delivery XT Outage section lists as still working "Manage delivery orders via the Revel Delivery Management feature on the POS", "Create and close delivery orders" and "Operate tills and take cash payments" - so cash delivery orders are covered - and lists as unavailable "Use the Delivery XT Dispatcher app", "Use the Delivery XT agent app" and "Track delivery order status", the symptom for which is that you cannot assign delivery orders to drivers in the Dispatcher app; driver assignment falls back to POS Delivery Management. The separate ISP / Network Outage section covers order creation and cash but says nothing delivery-specific, and no section covers driver cash reconciliation or settlement. https://support.revelsystems.com/s/article/outage · retrieved 2026-09-05 adversarially verified
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
Weborders is its own suite: /specialresources/cart/calculate, /validate and /submit alongside /weborders/menu/, products, modifiers, attributes and product_categories (8 GET, 3 POST). Orders written this way land in the POS. Own-domain branding and commission-free terms remain unverified -- an OAS spec is a technical reference and establishes neither, so partial holds. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/weborders_suite.yaml · retrieved 2026-08-10
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
The Custom Commerce App is a Revel-built, restaurant-branded native ordering app 'supported on both iOS and Android platforms', submitted to the App Store/Play Store under the merchant's own Apple ID, with Revel Loyalty, Revel Gift Card, customer profiles, order history and reorder, stored tokenized cards, and Apple Pay (via Stripe). However the article opens: 'The Custom Commerce App is not currently available for purchase' — it exists only for existing users, so new merchants cannot buy a branded native app from Revel. https://support.revelsystems.com/s/article/Custom-Commerce-App-FAQ-1582893045686 · retrieved 2026-08-04
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
Online Ordering XT accounts save name/email/phone and multiple delivery addresses (auto-synced to the CRM, pre-filled at checkout), and guests can check 'Save for future payments' to store a tokenized card and later pick it from a Choose Card drop-down — but the card-saving tutorial states 'This tutorial is for Mercury/Vantiv hosted checkout', so saved cards are gateway-dependent, and one-tap reorder of a previous order is documented only in the discontinued Custom Commerce App, not in the OO XT web flow. https://support.revelsystems.com/s/article/Saving-and-Changing-Credit-Card-Details-for-Online-Ordering-1583152074721 · retrieved 2026-08-04
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
Kiosk XT documents a rules-based upsell: after item/modifier selection 'a Make it a combo! window will appear. It will show what's included in the combo and the price', with Yes/No choice. Online Ordering XT documents group combos as orderable products but no upsell/cross-sell prompt at checkout, and no algorithmic recommendations or attach-rate reporting on suggestions is documented anywhere in the help centre. https://support.revelsystems.com/s/article/Kiosk-XT · retrieved 2026-08-04
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
Online Ordering Order Rules include 'Max number of online orders: Maximum number of online orders per time slot', a configurable 'Online order time slot' interval ('if you set this to 5 - you will have time slots available every 5 minutes'), 'Max date window for online ordering' (days orders can be placed in advance), estimated order preparation time, and max products/transaction-value caps; the Online Ordering XT checkout surfaces errors when 'selected order time is no longer available, or order maximum has been reached', i.e. saturated slots close to further orders. https://support.revelsystems.com/s/article/Online-Ordering-Setting-Up-Online-Ordering · retrieved 2026-08-04
Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.
digital-fulfillment-modes
One Online Ordering XT flow covers pickup (Walk Up), curbside (Drive Up with vehicle make/type/color capture and an order-status link the guest uses 'to notify your establishment when they've arrived', badging the POS) and delivery (with configurable delivery constraints, estimated prep time, and tax/service-fee options). Dine-in QR ordering exists but only as the separately activated Revel Smart Order mode, which 'cannot change order dining option', cannot use customer accounts, and must share the OO XT processor/branding — not the same single flow. https://support.revelsystems.com/s/article/Pickup-Ordering · retrieved 2026-08-04
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
Revel Smart Order is 'our fully contactless dine-in solution... scan a QR code, order, and pay at the table' via per-table QR codes generated in the Management Console, and Revel SmartPay lets guests scan a receipt QR code or follow an SMS link to view an existing POS order's status and pay it with suggested tip prompts. However Smart Order places a new online order rather than attaching to an open server check, and guest-side check splitting is not documented for either flow. https://support.revelsystems.com/s/article/Smart-Order · retrieved 2026-08-04
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 XT is a brandable self-order kiosk driven by the same Management Console products, modifier classes (including split modifiers with the same 'Charge Full Price for Split Modifiers' pricing rules), min/max modifier restrictions, group and upsell combos, discount codes and suggested-tip settings as the POS, with card payment via pin pad ('the kiosk will connect to card swipe, prompt you to follow the directions on the pin pad'). Shortfalls: payment processors limited to Vantiv/TriPOS and FreedomPay; no accessibility (ADA/WCAG) compliance for the kiosk UI is documented; and it does not support customer accounts, CRM data, or loyalty programs other than Revel Loyalty and Punchh. https://support.revelsystems.com/s/article/Kiosk-XT · retrieved 2026-08-04
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
CLAIM: 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. VERDICT: no. BOUND: the live 100% census of support.revelsystems.com (Salesforce guest knowledge API, 698/698 articles with bodies; 121/121 already-cited article URLs present). CONTROL over all 698 bodies, tokenised case-insensitive: /\bgroup\s+order/ 0/698 - zero across every Online Ordering XT, Ordering XT, FIS Online Ordering XT and kiosk article in the corpus. POISON named: /\bgroup\b/ alone is heavily populated and every relevant hit is a DIFFERENT sense - 'group combo' products, 'modifier class/group', 'establishment group' in the Establishment Hierarchy Tree, and QBO 'tax groups'. A substring reading of 'group' would have produced a false yes; the tokenised two-word control is what settles it. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/DoorDash-Marketplace · 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
Catering exists as a distinct POS dining option scheduled to a future day/time with delivery-range validation, and can be billed to a House Account so 'a customer or company with multiple orders, can be billed in one lump sum'; separately, the online ordering Order Rule 'Future Orders shall be created as invoices' makes payments on far-out orders come in 'marked as deposits'. However no guest-facing catering ordering portal, separate catering menu/minimums, lead-time rules, or quote/proposal workflow is documented. https://support.revelsystems.com/s/article/Catering-Overview-1583149409691 · 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
CLAIM: 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. VERDICT: no. BOUND: the live 100% census of support.revelsystems.com (Salesforce guest knowledge API, https://support.revelsystems.com/services/data/v59.0/support/knowledgeArticles?pageSize=100, 698/698 articles with bodies; 121/121 already-cited article URLs present). EVIDENCE: the ONLY telephony feature in the entire census is 'Caller ID' - staff answer the call and the POS surfaces the caller's CRM record, which is transcription-assisted order entry, the opposite of the claim. CONTROLS over all 698 bodies, tokenised case-insensitive: /\bvoice\b/ 1/698 (that Caller ID article); /\bvoice\s+AI|\bAI\s+(agent|phone)/ 0/698. POISON: /\bAI\b/ 5/698, all of them Captain AI, the Delivery XT driver-dispatch portal - not a phone agent. No certified voice partner is named anywhere in the census. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Caller-ID-1582898972497 · retrieved 2026-09-17 adversarially verified
Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.
digital-drivethru-ai
CLAIM: supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff. VERDICT: no. BOUND: the live 100% census of support.revelsystems.com (Salesforce guest knowledge API, 698/698 articles with bodies; 121/121 already-cited article URLs present). EVIDENCE: Revel's documented drive-thru stack is staff-operated and display-based. The drive-thru articles in the census are 'Revel Drive Through' and 'Delphi OCS Integration' (an outdoor customer-display/order-confirmation board), and the drive-thru mentions in the version notes are lane and KDS routing. CONTROLS over all 698 bodies, tokenised case-insensitive: /\bvoice\s+AI|\bAI\s+(agent|phone)/ 0/698; /\bdrive.?thru/ 8/698, none of them a voice agent. POISON, and it is the reason this needed a tokenised run: /\bAI\b/ returns 5/698 and every hit is 'Captain AI', Revel's DELIVERY dispatch/driver-routing portal for Delivery XT ('Delivery XT: Captain AI Manager Portal Overview') - an AI product in the corpus that has nothing to do with voice ordering. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Revel-Drive-Through · retrieved 2026-09-17 adversarially verified
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
CLAIM: supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS. VERDICT: no. BOUND: the live 100% census of support.revelsystems.com (Salesforce guest knowledge API, https://support.revelsystems.com/services/data/v59.0/support/knowledgeArticles?pageSize=100, 698/698 articles with bodies; 121/121 already-cited article URLs present). EVIDENCE: Revel's entire SMS surface is OUTBOUND notification, and the vendor enumerates it. 'Twilio Integration' (https://support.revelsystems.com/s/article/Twilio-Integration-1583146701088, modified 2024-03-27): 'Revel integrates with Twilio, allowing you to send SMS messages to your customers when their order or table is ready', with contents limited to Connecting Your Twilio Account, Setting Up Your Messaging, Enabling SMS on Done from KDS, and the Waitlist/Reservation integration. The only inbound message the platform handles is a waitlist opt-out: 'your customers can text back Remove (not case sensitive), and they will be removed from the waitlist'. 'SMS on Order Ready in the Kitchen' is likewise one-way. CONTROLS over all 698 bodies, tokenised case-insensitive: /\bText\s+to\s+order|\btext.a.link/ 0/698. /\bSMS\b/ hits 23/698 and is the POISON to name - the hits are order-ready and waitlist notifications, Revel SmartPay receipts, Como/Punchh loyalty messaging and consumer marketing opt-in, none of them an ordering channel. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Twilio-Integration-1583146701088 · retrieved 2026-09-17 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
326th: MOVED to no; the 324th's rejection of a PARTIAL off the Zuppler partner entry stands and is not re-proposed - this is the opposite verdict on a new bound. What was missing in every prior pass was the marketing host: revelsystems.com 301s to www.shift4.com/food-beverage, and shift4.com had only ever been URL-censused. BODY census now complete: 825/825 non-locale sitemap slugs (818x200, 7 hard-404 test slugs), 36,380,880 chars, sitemap index has exactly one child, robots 'Allow: /', nonsense control 404. Plus 698/698 live KB articles and the 7 Revel legal PDFs from /revel-legal. CONTROLS, tokenised, case-insensitive: `order with google` 0/832 and 0/698; `google business profile` 2 hits in 1 of 832 and it is POISON - a small-business-Saturday blog telling merchants to claim their own listing, with no Revel ordering link; `google business` 0/698 KB. Revel's own documentation still documents no provisioning of its first-party ordering link onto a Google Business Profile, and now neither does the only marketing surface Revel has. Note for the adjudicator: the Shift4 marketplace page (shift4.com/marketplace) IS a live integration directory, but it opens 'Seamlessly connect your Shift4 Dine software' and contains the token `revel` ZERO times in 109,728 chars - it is the SkyTab/Shift4 Dine catalogue, a sibling product, so it neither supports nor bounds Revel. Retrieved 2026-09-18. https://www.shift4.com/revel-legal · 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
326th: MOVED to no on the same new bound as digital-google-order. The prior note left this unknown because only the help centre had been searched. Now: 825/825 non-locale shift4.com sitemap slugs body-fetched (818x200, 7x404 test slugs, 36,380,880 chars; one-child sitemap index; robots Allow: /; nonsense control 404) + the 7 Revel legal PDFs enumerated at /revel-legal + 698/698 live KB articles (2,592,423 chars). CONTROLS, tokenised, case-insensitive: `apple business connect` 0/832 documents and 0/698 KB articles; `order food` 0 as an Apple Maps action anywhere. The Apple tokens that do fire are Apple Pay, Apple Wallet and App Store distribution, plus the KB's iPad Guided Access articles - all POISON for a place-card ordering action. Revel does not support, document or market an Apple Business Connect 'Order Food' placement on any surface it or its owner publishes. WEAKEST LINK, stated honestly: this is an absence over a complete PUBLISHER census rather than a closed feature enumeration; if the atlas requires an enumerated integration list for a no on a niche channel claim, downgrade to unknown with this corpus recorded. Retrieved 2026-09-18. https://www.shift4.com/revel-legal · 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 XT (powered by Como) redemption works inside the Online Ordering XT checkout: a 'Pay with loyalty' payment method spends 'the points that they have accumulated with Como' against the same Como member account used in-store (customer must be logged in and phone-confirmed with Como; SMS 2FA at redemption). Shortfalls: points accrual is documented only for the in-store POS/CDS flow, not for online orders; and the Smart Order QR dine-in flow 'cannot use a loyalty integration'. https://support.revelsystems.com/s/article/Loyalty-XT · retrieved 2026-08-04
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: Revel's anonymous production OpenAPI 3.0 set v2025.3.0 (14/14 suites, 1,751,580 bytes, 198 paths, listed by https://developer.revelsystems.com/; nonsense control 403). 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 data model is fully enumerated and has no subscription construct. Customer carries 60 properties (account_balance, account_limit, contract_expiration, customer_groups, discount, gift_card_numbers, loyalty_number, loyalty_ref_id, reward_card_numbers, total_purchases, total_visits, ...) with no plan, membership, entitlement, renewal or recurring field; account_balance/account_limit/contract_expiration belong to the house-account (A/R) feature, which house_accounts_suite.yaml confirms is merchant-invoiced credit. The discount model's function scope is a CLOSED enum - EnumDiscountFunctionType '0 - CORE, 1 - CUSTOMER, 2 - LOYALTY, 3 - GIFT_WITH_PURCHASE' - with no subscription or membership scope, and EnumDiscountMethodType's 8 values are all vouchers/point redemptions. Tender is a closed 33-value enum (EnumPaymentType 0-32: OTHER, CASH, CREDIT, CHECK, GIFT, ... STORE_CREDIT, COMO, LOYALTYPLANT, VOUCHER, ... DEPOSIT) with no recurring/stored-plan tender. BOUND/CONTROLS: 14/14 suites + the live 100% census of support.revelsystems.com (698/698 articles via the Salesforce guest Knowledge REST API). Tokenised, word-boundary: `membership` 0/14 suites and 6 hits in 5/698 articles; `recurring billing` 0/14 and 0/698; `subscription` 1/14 and 48 hits in 29/698. POISON, and it is the whole risk on this cell: every one of those hits is MERCHANT-side. The single API hit is EnumClientType, 'Where the customer bought their subscription from: 0 - Revel, 1 - Intuit' - i.e. who resold Revel to the operator. The KB hits are the operator's own Revel/Revel Guard XT MDM subscription ('If you have a Revel Guard XT subscription for mobile device management'), 'Online Ordering XT subscription required' for Driver XT, and Revel Advantage's 'Annual Membership Fee: A yearly fee for administrative services'; the `membership` hits are the Customer Groups screen's 'Membership section' (a UI section for adding customers to a group) in Creating Customer Groups and How to Use Customer Groups. No guest-facing recurring charge exists in either corpus. Retrieved 2026-09-17. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/customers_suite.yaml · 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
Discounts and discount codes are defined once in Products > Discounts and redeemable on the POS (scan or manual entry), on Kiosk XT ('a discount code must be set up in the Management Console under Products>Discounts>Details>Discount Code Enabled'), and in online ordering via the Promotion Code field at checkout. Parity is not identical: 'At this time, Revel does not support the Apply Multiple Times setting in web ordering', discount codes are single-establishment, and loyalty offer support differs by channel (Kiosk XT supports only Revel Loyalty and Punchh; Smart Order supports no loyalty integration). https://support.revelsystems.com/s/article/Discount-Codes-1583151656831 · retrieved 2026-08-04
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
Customer is readable AND writable (11 GET, 5 POST, 5 PATCH, 5 PUT, 2 DELETE), so bulk extraction is technically possible. What the claim actually asks for -- that the vendor DOCUMENTS operator ownership and fee-free bulk export -- is established by no live surface: the spec is silent on ownership and on fees. Partial holds. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/customers_suite.yaml · retrieved 2026-08-10
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
Online ordering card entry is documented as gateway-hosted ('You will be brought to the Vantiv Hosted Checkout page, enter your credit card information'), and the v2.73 release added AVS plus 3DS to Online Ordering XT — but with the stated limit '3DS feature is only available for merchants using FreedomPay with Online Ordering XT in the United Kingdom'. No PCI DSS 4.0 attestation or client-side script-integrity documentation for the digital checkout was found in the help centre. https://support.revelsystems.com/s/article/Version-2-73 · 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
Credit-card surcharges are configurable and reach digital channels: the v2.73 release notes state 'Surcharges will now be displayed at checkout in OOXT' (guest-facing disclosure), and Revel's surcharging FAQ confirms online/CNP orders 'are acceptable options for surcharging as long as disclosures and/or signage are shared clearly'. Shortfall: the FAQ repeatedly places jurisdiction and card-brand compliance on the merchant ('it is your responsibility as a business owner to stay current with the latest compliance rules') — no automatic blocking in prohibited states or for prohibited card types is documented, and dual pricing is not documented for digital channels. https://support.revelsystems.com/s/article/FAQ-Credit-Card-Surcharging · retrieved 2026-08-04
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
One CRM across Management Console, POS and CDS; dedup is via an 'Enforce Customer Uniqueness' (phone/email) setting, but 'If you would like to set up customer uniqueness, contact Revel Support' — it is not operator-self-serve, and detailed merge behavior is only summarized (v2.78 change log: 'Improved CRM uniqueness and record merge functionality for online ordering customers'). Kiosk XT explicitly 'does not currently support ... Creation of customer accounts [or] CRM data (login, order history)' — kiosk guests get loyalty lookup/redeem only, not a full CRM identity. https://support.revelsystems.com/s/article/CRM-Automated-Server-Search · retrieved 2026-08-04
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
Splits by marketplace, and the vendor documents both halves. Uber Eats works: the Uber Eats Onboarding article's CRM row states 'A CRM profile will be created for each Uber Eats order in the following format: First name, First letter of Last name, Phone number, Email format: UberSupport<last5digitsofUberOrderID>@uber.com', and the What to Expect - Point of Sale section confirms Uber Eats orders 'have a unique customer linked to them. The customer name and phone number will be the actual customers contact information while the email is going to be in the UberSupport(last5digitsofUberOrderID)@uber.com format'. A real per-order native CRM profile carrying the guest's actual phone number is usable guest identity. Shortfall, and the reason this is not yes: DoorDash Marketplace behaves the opposite way. Its integration article states 'Only the customer's first name and first letter of their last name are synced to Revel and are reported in the Call Name field', 'All DDM orders will have the same phone number and email address' (the phone number 'will always be the DoorDash support number: 855-973-1040', the email ordernumber@doordash.com), customer uniqueness by phone or email is 'not recommended' because 'all customer orders for DoorDash will be merged to the same CRM account in Revel', and 'the customer name on all previous DoorDash Marketplace orders will be overridden by the new customer's name'. The guest's address does not sync at all. Grubhub has no direct Revel integration documented. So native guest identity attaches on one of the two supported marketplaces, not across marketplace volume generally. https://support.revelsystems.com/s/article/UberEats-Onboarding · retrieved 2026-08-06 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
Native rewards program offers three configurable reward types: 'Visit: one Visit reward point every time the customer makes a purchase', 'Purchase: points based on the total amount of the customer's purchase', 'Item: points based on the products purchased' (with per-product Point Value and Purchase Reward Multiplier fields). Configured in Management Console under Gift, Rewards, and Admin Cards / Loyalty; the desired reward type is enabled by contacting Revel Support, but no custom development or bolt-on loyalty vendor is needed. https://support.revelsystems.com/s/article/Creating-a-Loyalty-Program-1583151656809 · retrieved 2026-08-04
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
CRM tab has a Loyalty Tiers page 'to segment customers into tiers that are eligible for special discounts or deals', with tier-based payment/discount restrictions and a 'Stacking of Loyalty Tier Rules' (Competitive vs Stacked) accrual setting — but tier membership is defined by rewards-card number ranges ('Card Range From and Card Range To'), i.e. static assignment. No automatic promotion/demotion driven by rolling-window spend or visit counts is documented anywhere in the complete help centre. https://support.revelsystems.com/s/article/CRM-Tab-Overview-1583148889940 · retrieved 2026-08-04
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
Revel's outage best-practices article states the behaviour explicitly and in the blocked direction, not queue-and-reconcile. Under the ISP / Network Outage heading it lists, among the functions you will NOT be able to access, "Use Loyalty/rewards/gift cards"; the Revel Server Outage section repeats the same item. A dedicated Loyalty / Gift Card Outage section then enumerates the three sub-capabilities the claim names as unavailable: "Look up reward balances", "Accrue loyalty points", "Redeem rewards", plus "Create new loyalty account". Loyalty is therefore documented as blocked while connectivity is lost, with no queued accrual described. This article is uncited by the prior record, which scored the cell from Offline Mode / Always On Mode alone. https://support.revelsystems.com/s/article/outage · retrieved 2026-09-05 adversarially verified
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
Per-discount 'Stacked Discount Type' drop-down: Competitive, Competitive Not Stacked, or Stackable. Docs state stackable discounts 'can be assessed against objects that already have discounts on them. They do not compete', Competitive Not Stacked discounts are 'the only discount on the object', and give explicit application-order rules (stacked % applies against the original item price; against the reprice amount for reprice/alt-price; against combo reprice only for combos). Additionally 'Tiered discounts' allow ranking discounts so 'Only one discount per tier will be applied', and loyalty-tier accrual has a Competitive-vs-Stacked setting. https://support.revelsystems.com/s/article/Stackable-Discounts-1583151656823 · 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
Loyalty XT's Campaign Center supports one-time actions issued to a filtered audience: 'Select which members to perform the action on by specifying criteria ... based on the members attributes, or actions (like: member that performed a purchase that included a coffee item in the last week)', and flexible campaigns can be limited 'to specific members ... by their attributes'. Shortfall: this requires the separately purchased Loyalty XT add-on (powered by Como, managed in the Como Hub, sales-assisted onboarding); Revel's core loyalty/discount engine has no audience targeting, and message sends need an additional Marketing Communications subscription. https://support.revelsystems.com/s/article/Loyalty-XT · retrieved 2026-08-04
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
Loyalty XT: 'All members are automatically segmented in the system based on their Days since last visit', driving the Win Back Members campaign (1/2/3-month lapsed thresholds with automatic SMS/email when members enter the segment). Shortfall: only recency-based lapsed segmentation is documented — no automatic frequency/monetary or full lifecycle segments (new, regular, VIP) — and it requires the separately purchased Loyalty XT (Como) add-on. https://support.revelsystems.com/s/article/Loyalty-XT · retrieved 2026-08-04
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
Loyalty XT ships always-on lifecycle rules: a joining gift 'sent using a Rule, upon joining the program', a birthday gift 'sent to the member's once a year on its birthday', and a Win Back Members deal that applies automatically to guests returning after 1/2/3 months, with optional automatic SMS/email. Shortfall: these exist only in the separately purchased Loyalty XT (Como) add-on — core Revel loyalty has no triggered campaigns — and the SMS/email sends require an additional Marketing Communications subscription. https://support.revelsystems.com/s/article/Loyalty-XT · retrieved 2026-08-04
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
Loyalty XT can send both SMS ('choose the Send SMS action and simply type your SMS', with @-parameter merge fields) and email (template builder, 'choose the Send Email action and select which template') campaigns. Shortfall: sends happen from the Como Hub of the Loyalty XT add-on, not from Revel's Management Console, and 'an additional Marketing Communications subscription is needed for this functionality to be available' — core Revel has no campaign sending at all. https://support.revelsystems.com/s/article/Loyalty-XT · 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
'Consumer Marketing Opt-in/out & Logging' captures per-channel consent (separate Email, Phone/SMS, and Mail drop-downs) editable on the Management Console and POS, and 'Every time a change is made to the Marketing Opt In/Out settings on a CRM entry, the changes will be tracked in your Action Log' (which records who, when, and before/after values); online-ordering signup also offers opt-out at account creation (v2.74). Shortfalls: the feature must be enabled by Revel Support, and no documented linkage suppresses Loyalty XT/Como messaging from these CRM flags — consent SMS for Como is managed separately in the Como Dashboard. https://support.revelsystems.com/s/article/Enabling-Consumer-Marketing-Opt-in-out-Logging-1583148890442 · retrieved 2026-08-04
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
CLAIM: handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform. VERDICT: no, and the vendor's own set-up instruction is the positive evidence rather than mere silence: Revel does not own the messaging relationship at all. 'Twilio Integration' (https://support.revelsystems.com/s/article/Twilio-Integration-1583146701088, modified 2024-03-27) tells the operator to bring their own carrier account - 'Please make sure you have an existing Twilio account. If you don't yet have an account, visit the Twilio Website to get started' - and then to paste 'your Twilio SID, Token and the Phone Number you'd like messages to send from' into the Revel Management Console. Registration therefore sits with the operator and Twilio, and Revel documents no part of it. BOUND: the live 100% census of support.revelsystems.com (Salesforce guest knowledge API, 698/698 articles with bodies; 121/121 already-cited article URLs inside it). CONTROL over all 698 bodies, tokenised case-insensitive: /\b10DLC|\bA2P\b/ 0/698 - and the A2P control was run tokenised precisely because a bare substring match for it is a known trap (a minified symbol elsewhere in the corpus). Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Twilio-Integration-1583146701088 · retrieved 2026-09-17 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
The Discounts report ties every redeemed discount (including loyalty reward discounts, filterable as 'Loyalty Discounts') to the specific Order #, item, SKU, quantity, and date, grouped by Order/Reason/Item/Discount Type — i.e. redemption reporting against actual checks. Shortfall: no incremental-sales measurement per campaign is documented anywhere in the help centre; campaign-level analytics for Loyalty XT live in the third-party Como Hub ('Data & BI' dashboard), documented only by Como's own knowledge base. https://support.revelsystems.com/s/article/Discounts-Report-1583149669643 · retrieved 2026-08-04
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
The customers suite reads and writes guest records, so an API export path exists. The claim's self-serve conjunct is unmet: nothing on any live surface shows an operator obtaining credentials without a partner arrangement, and the page that documented credential issuance has been withdrawn (see extensibility-oauth-partner-apps, now quarantined). Partial holds -- on an unestablished conjunct, not a disproved one. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/customers_suite.yaml · retrieved 2026-08-10
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
Searched the complete 693-article public help-centre mirror (captured 2026-08-04) for feedback, survey, review site, Yelp, Google review, NPS, net promoter: the only hit is a marketing bullet in the third-party Open Dining online-ordering integration article ('Feedback surveys help the client correct service issues'), which describes no score-based routing and is not a Revel capability. No native post-transaction feedback request or score-routing feature is documented, but the vendor's marketing site (now redirecting to shift4.com, HTTP 403 to fetch tools) could not be checked, so this stays unresolved rather than absent. || 324th: CLAIM: Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. VERDICT: proposal partial/C REJECTED; stays unknown. The claim's core conjunct is score-based routing (low to private recovery, high to public review sites); neither Guest Feedback partner is described doing it. Entries (https://revelup-techpubs.s3.us-west-2.amazonaws.com/support/hc/en-us/000002620/Revel+Partners-2.pdf, retrieved 2026-09-16): "Ovation / Category: Guest Feedback / Description: Find out how your on- and off-premises customers are feeling, fix any issues in seconds, get more 5-star reviews, and have an easy-button for insight and retention. Ovation is your Digital Table TouchTM." (printed p.70); "Tattle / Category: Guest Feedback / Description: Tattle offers a customer experience improvement (CXI) platform designed to help brands collect actionable data by interacting with their guests where they make transactions. Uncover opportunities that matter most for increasing guest satisfaction, operational performance, and revenue." (printed p.105). "get more 5-star reviews" is a marketing outcome, not a routing mechanism; inferring routing from it is analyst inference, and nothing says the Revel integration triggers a request from a Revel transaction. Also Momos (printed p.62) only consolidates feedback. The analyst's shortfall (2) concedes routing is "only implied". SOURCE CHECKED: KB article https://support.revelsystems.com/s/article/Revel-Partners (How_To__kav, versionId ka2VV0000001ICbYAM, scm_Description__c re-fetched live via Aura 2026-09-16; whole body: "To view the full list of Revel's partners, view this document.") linking https://revelup-techpubs.s3.us-west-2.amazonaws.com/support/hc/en-us/000002620/Revel+Partners-2.pdf (re-fetched 2026-09-16: HTTP 200, 4,463,744 bytes, Last-Modified 2025-01-17; pdftotext re-run, 122 PDF pages, one partner per page, each giving only Category and Description plus "Visit Partner"; printed page numbers are one less than PDF page numbers). All quoted strings below confirmed verbatim in the re-extracted text; each is a single-page entry, no column interleaving. The directory is Revel-published marketing (a partner list whose Descriptions are the partners' own copy) and documents no integration behaviour. Poison noted: a raw grep for "ovation" in the KB mirror hits "innovation"; tokenised Ovation/Tattle are 0 in the KB. || 326th: 326th: NEW SURFACE, does not settle it. The marketing/legal host is now body-censused (825/825 non-locale shift4.com sitemap slugs, 818x200 + 7 hard-404 test slugs, 36,380,880 chars, nonsense control 404, plus the 7 Revel legal PDFs enumerated at /revel-legal). Tokenised, case-insensitive: `net promoter` 0/832 and 0/698 KB articles; `review site` 0/832 and 0/698. Shift4's marketplace directory has a 'Marketing & CRM' category but no guest-feedback entry and no Revel scope (`revel` 0 times in it). So no score-based routing is documented or marketed anywhere the vendor or its owner publishes. NOT proposed as a no only because the claim is a behavioural capability rather than a publication, and the 324th already rejected the Ovation/Tattle partner entries as marketing copy in a directory that does not describe integration behaviour - so the absence has no closed instrument behind it. Retrieved 2026-09-18. || 329th: 329th: NEW SURFACE, measured, does not settle it. Revel's COMPLETE App Store publisher census (developer id 477934007, iTunes lookup entity=software) is 13 apps - Revel POS, POS 2.79, CDS, CDS 2.79, CDS XT, CDS XT 2.79, KDS, KDS 2.79, Insights, Inventory, Assist, Delivery XT Agent, Delivery XT Dispatch - with no guest-feedback, survey or reputation app. Tokenised controls over the 14,305 chars of all 13 descriptions and release notes: feedback 0/13, survey 0/13, review 0/13, NPS 0/13, rating 0/13. Also re-grepped, for this cell specifically, the 14-suite anonymous production OpenAPI 3.0 set on oas-prod.s3.amazonaws.com (v2025.3.0, 198 paths, 1.7 MB) that no prior pass had queried with this vocabulary: feedback 0/14, survey 0/14, NPS 0/14, 'net promoter' 0/14, sentiment 0/14, yelp 0/14 (POISON: 'review' hits 4 in inventory_suite and 1 in general_suite, all inventory-review wording; 'rating' hits 2 in general_suite, both inside 'operating system'). And the 698-article Knowledge listing re-paged today is unchanged (698, newest lastPublishedDate 2026-09-15). The absence still has no closed instrument behind it: score-based routing would be the partner's behaviour (Ovation/Tattle), and neither an app catalogue nor a REST spec can witness it. 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
NEW SURFACE: Revel's anonymous production OpenAPI 3.0 set v2025.3.0 (14/14 suites, 198 paths, listed by https://developer.revelsystems.com/; nonsense control 403). CLAIM: a native referral mechanic with PER-GUEST codes or links, attribution of the referred guest's first order, and two-sided rewards. VERDICT: no. EVIDENCE: the code-issuing object is fully enumerated and cannot be per-guest. DiscountCode has exactly five fields - code, discount, id, resource_uri, type, used - where type is the closed EnumDiscountCodeTypes '0 - DISCOUNT_CODE_TYPE_MULTIPLE (multiple time use), 1 - DISCOUNT_CODE_TYPE_SINGLE (one time use)'. There is no customer, issued_to, referrer or referred_by relation on DiscountCode, none on Customer (60 properties, listed on digital-subscriptions), and none on Order (109 properties) or OrderItem, so a referred guest's first order cannot be attributed to a referring guest, and a two-sided reward has no second party to pay. The discount function scope is closed - EnumDiscountFunctionType '0 - CORE, 1 - CUSTOMER, 2 - LOYALTY, 3 - GIFT_WITH_PURCHASE' - and the reward accounting enum is closed at EnumDiscountRewardType '0 - PURCHASES, 1 - ITEMS, 2 - VISIT'. BOUND/CONTROLS: 14/14 suites (1,751,580 bytes) + 698/698 live KB articles via the Salesforce guest Knowledge REST API. Tokenised, word-boundary, case-insensitive: `referral` 0/14 suites and 1 hit in 1/698 articles; `referrer` 0/14 and 0/698; `refer a friend` 0 in both. POISON: the one KB hit is a gateway response label in 'Supported Gateway/Processor Payment Error Codes', not a feature; and a substring grep for `ref` in customers_suite.yaml hits Customer.ref_number, Customer.loyalty_ref_id and every resource_uri, which is why the controls above are word-boundary. Retrieved 2026-09-17. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/discounts_suite.yaml · retrieved 2026-09-17 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
CLAIM: issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. VERDICT: no. BOUND: the live 100% census of support.revelsystems.com (Salesforce guest knowledge API, https://support.revelsystems.com/services/data/v59.0/support/knowledgeArticles?pageSize=100, 698/698 articles with bodies; 121/121 already-cited article URLs present). CONTROL over all 698 bodies, tokenised case-insensitive: /\bwallet\s+pass|Apple\s+Wallet|Google\s+Wallet|\bpassbook/ 0/698 - zero, with no near-miss to disambiguate. Revel's documented loyalty surface is Loyalty XT plus the named third-party integrations the census carries (Punchh Loyalty Configuration, Como Loyalty Integration, Synergy Loyalty Rewards, LevelUp), and the guest identifier in every one of them is a CRM account, phone number or barcode rather than a wallet pass. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Loyalty-XT · retrieved 2026-09-17 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
Customer Anonymization 'searches for and permanently removes all key information about a customer (name, email, address, phone, date of birth, etc.) from the entire system', iterating all customer database fields and related models with documented replacement formats (e.g. noreply+anonymous_<ID>@revelup.com), plus photo deletion and forced POS refresh to clear local data; the CRM Export/Import tool covers data access requests. Shortfalls: the feature must be enabled by Revel Support, 'there is no way to perform this action in bulk', the anonymized record remains reachable by customer ID, and no deletion propagation into the Como-hosted Loyalty XT marketing records is documented. https://support.revelsystems.com/s/article/Customer-Anonymization-1583148890445 · retrieved 2026-08-04
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
Manual point changes are permission-gated: the 'Reward Cards' POS role permission 'Allows user to manually add or subtract rewards points from a card', and 'Create Gift/Rewards Cards' is a separate grantable permission. Shortfalls: no redemption velocity limits and no employee self-redemption flagging are documented anywhere in the help centre, and the Action Log report's enumerated recorded actions (item deleted, price override, product change, etc.) do not include loyalty point adjustments or redemptions — no loyalty audit trail is documented. https://support.revelsystems.com/s/article/Employees-Roles-and-Permissions-Guide-1583149941746 · retrieved 2026-08-04
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
326th: MOVED to no. This claim is explicitly claim-level and documentation-shaped ('Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing'), so a complete census of what the vendor documents and markets settles it. The 323rd had bounded only the URLs of shift4.com and said so. CORPUS as on commercial-wcag-kiosk-accessibility: 825/825 non-locale shift4.com sitemap slugs body-fetched (818x200, 7x404 test slugs, 36,380,880 chars; nonsense control 404), plus the 7 Revel legal PDFs enumerated at /revel-legal, plus 698/698 live KB articles (2,592,423 chars) re-derived from bodies.jsonl. CONTROLS, tokenised, case-insensitive: `offer recommendation` 0/832 and 0/698; `send time` 0/832 and 0/698; `machine learning` 0/698 KB and 36 hits in 14 of 832 files, every one a Shift4 payments-side blog about chargebacks, fraud scoring or smart routing (from-data-to-dollars, protect-business-from-fraud, streamline-your-payment-flow-with-smart-routing, online-payments) with no loyalty or offer subject; `artificial intelligence` 0/698 KB and 12 hits in 6 of 832, all payments/fraud or sports-sponsorship news. `recommendation` in the KB fires 13 times in 8 articles and ALL are POISON - hardware cleaning recommendations, 'recommended' image sizes, certificate-key advice, loss-prevention advice - none is an offer or audience recommendation. The one AI product in Revel's own documentation remains Captain AI, which is Delivery XT driver routing/dispatch. Nothing in the vendor's or the owner's published surface documents AI/ML offer content, audience or send-time recommendations for Revel. Retrieved 2026-09-18. https://www.shift4.com/revel-legal · retrieved 2026-09-18 adversarially verified
Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.
guest-loyalty-stored-value-gift
Gift card management listed; Givex and Paytronix monitored as integrations. Brand-wide redemption tied to one guest profile unverified. https://status.revelsystems.com/ · 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
TimeSheetEntry is a first-class readable/writable resource alongside TimeSchedule and TimeScheduleRule, implying the POS holds timekeeping. PIN/badge punch mechanics remain undocumented, so partial holds. CORRECTION on re-check 2026-08-10: the dossier previously rested this on a timesheet-entry WEBHOOK. The vendor's current webhook surface enumerates six event types and timesheets is not among them, so that half of the note is withdrawn rather than re-pointed. The resource inference stands on its own. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/scheduling_suite.yaml · retrieved 2026-08-10
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
Advanced POS Settings documents a 'Photo clockin' setting: 'This setting forces employees to take their picture as a part of the clock in process. A manager/owner must allow the POS to store photos on the iPad's photo library in addition to enabling this setting.' Photo-only capture with no facial verification or biometric template anywhere in the docs. Shortfall: the documentation describes storage in the iPad's local photo library, not attachment of the photo to the timecard entry for later manager review, and no verification mode exists. https://support.revelsystems.com/s/article/Advanced-POS-Settings-1583149942304 · retrieved 2026-08-04
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
Upheld with the missing quotations supplied. Under ISP / Network Outage the playbook sorts functions into three affirmative lists, and clock-in sits in the middle one: "you'll still be able to access the following functions but they will be limited", whose first entry is "Clock In/Out". The same placement recurs under Revel Server Outage. So punching offline is affirmatively documented rather than inferred. It stays partial on two grounds: the article never says how the limitation manifests, and the claim's second half, reconciliation on reconnect without loss or duplicates, is nowhere documented; the vendor's stated remedy for the ISP case is "Enabling offline Mode for CC payments", which addresses payments and not timekeeping. https://support.revelsystems.com/s/article/outage · retrieved 2026-08-04 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
Employees: Roles and Permissions Guide documents per-action POS permission tokens assignable per role: Comps, Item Discount, Manual Discount, Open Cash Drawer, Void Items ('Allows users to void or return items without a password'), Refund Payment, Price Override, Override Void/Return/Exchange Limits, iPad Reports, plus separate Management Console permission sets. Custom permission sets can be created and copied ('If the default permissions aren't sufficient... you can further customize or add additional permission sets'). Permissions are managed per establishment, with a brand-level Employee Permissions Audit export across locations via the EMS Establishment Hierarchy Tree. https://support.revelsystems.com/s/article/Employees-Roles-and-Permissions-Guide-1583149941746 · retrieved 2026-08-04
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
The Action Log report 'displays specific employee actions done on the POS and Management Console' with Date, Employee ('The employee who performed the action'), Action, Target, and Description of Change columns. Logged actions include Price Override, Time Worked Created/Edited/Deleted Manually on POS, Administrator Permission Change, Role Permission Change, Item Deleted and Login Attempt. The report is filterable by POS station, employee and action, groupable by employee, and exportable in various formats — an after-the-fact queryable, individually-attributed audit trail. https://support.revelsystems.com/s/article/Action-Log-Report-1583149671561 · retrieved 2026-08-04
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
Scheduling is a distinct suite -- TimeSchedule, TimeScheduleRule and TimeSheetEntry, all readable and writable (6 GET, 2 POST/PATCH/PUT, 2 DELETE) -- held in the same platform as the timekeeping data, which is what the claim asks. The publish/notify workflow is undocumented: the spec exposes no publish or notification operation, so partial holds. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/scheduling_suite.yaml · retrieved 2026-08-10
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 scheduling documentation enumerates the entire Shift Schedules toolset: manual shift creation, Excel import, week-to-week shift copying, and a 'Wage/Forcasting' view that only displays projected payroll and sales for shifts already entered by the manager. No function generates recommended staffing levels or labor hours from the operator's sales history; the Labor Report defines 'Projected Hours' as 'the hours scheduled through the Shift Schedule tab'. Revel's only sales-history forecasting (Item Tracking / Product Forecasting) drives food-prep quantities, not labor. Complete public help centre searched. https://support.revelsystems.com/s/article/Creating-Shift-Schedules-1583150213550 · retrieved 2026-08-04
Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator
labor-realtime-labor-percent
The Labor Report is available on the Point of Sale itself via the drop-down reports: 'This report will display labor data, including your labor costs, labor percentage, and total sales per hour. As of the 2.79 update, we have added a labor hours column and a sales per man hour (SPMH) column.' Printable POS reports can additionally include 'man hours, wages and percentage of labor'. Access is gated by the iPad Reports role permission, so managers can view labor percentage intraday during service. https://support.revelsystems.com/s/article/Viewing-Reports-on-the-Point-of-Sale-1582899334000 · retrieved 2026-08-04
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
Shift alerts 'for late employees and for employees in or nearing overtime' can be configured on the Settings > Reports > Insights Application page and appear on the Schedules screen of the Insights by Revel iPhone app. Shortfalls: the alert surfaces only in the separately licensed Insights app (per-device license keys purchased through Revel Sales), is a manager-side notification, and nothing warns or blocks the employee at clock-in on the POS — Time Sheet Rules set overtime thresholds and multipliers for pay calculation only. https://support.revelsystems.com/s/article/Insights-by-Revel-1582893045693 · retrieved 2026-08-04
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
Time Sheet Rules provides configurable break rules: 'Calculate Paid/Unpaid Breaks By Rules' (documented explicitly around California's 5-hour meal rest period requirement, with the note that 'Businesses in California must be able to produce a report that reflects these breaks'), Work Time To Qualify For Paid Break, Duration Of Paid Break, Employee Declares Break Type, and 'Prevent Employee Clock-In Before Break End' requiring a manager PIN. Shortfalls: a single rule set per establishment with no per-state/jurisdiction rule library, no required break attestation prompt, and no missed-break premium-pay flagging documented. https://support.revelsystems.com/s/article/Time-Sheet-Rules-1583150213539 · retrieved 2026-08-04
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
Upheld, and strengthened by a same-API control the analyst did not use. The claim requires enforcement at BOTH scheduling and clock-in. The clock-in half is settled by an on-point closed enumeration: TimeScheduleRule is the entire clock-in rule surface and every gate in it is time-based or approval-based, for example "If set to True, will allow employees to start their shift before the scheduled time." and "If set to True, employees that are late to clock-in by a certain amount of time will need manager approval to start their shift." and "If set to True, employees that work seven days in a row will have their entire seventh working day considered overtime." No age, minor, school-day or prohibited-window property exists. The scheduling half is settled by the absence of any age datum: the Employee schema in the companion employees suite carries no date of birth, while the Customer schema in the customers suite and the order payload in the orders suite both do carry a birthdate field. The vendor therefore models birthdates where it has them, so the absence on Employee is a modelling decision and not a documentation convention. An age-derived rule cannot be evaluated at either point without that datum. No integration partner can rescue this, because clock-in gating executes inside Revel's own closed rule object. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/scheduling_suite.yaml · retrieved 2026-08-10 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
Tip Pooling is a documented native feature: pool contributions computed from configurable rules — Tip In Based On Tips or Sales, per-role Tip In % ('servers might tip in 50% of their tips'), Tip Share distributed Even (based on hours worked) or by Percentage per role, Periodicity By the Week, By the Day, or By the Shift, and Treat Declared Tips As Total Tips / Cash Only / Ignore. The Tip Pool tool (Schedules > Tip Pooling) calculates the Share Plan and per-employee breakdown automatically from these rules; a manager reviews and submits each pool. No spreadsheet required. https://support.revelsystems.com/s/article/Tip-Pooling-1583150213556 · 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
The Tip Pool tool retains submitted pools per day or per shift ('You may also view past submitted pool here'); the Employee Breakdown records each employee's tips, Tip In Amount owed to the pool, and Tip Share received, with role-level Share Plan detail (hours, sales/tips, tip-in %, adjusted share %). Final tips post to the Payroll report ('Adding Final Tips to Payroll'), which shows per-employee Declared Tips and Non-Cash Tips columns and exports in multiple formats for audit. https://support.revelsystems.com/s/article/Tip-Pooling-1583150213556 · retrieved 2026-08-04
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
Upheld with one factual correction to the note. The first limb is met and published: TimeScheduleRule carries two independent payroll-report switches, "If set to True, will cause the payroll report to include employee declared tips (usually cash tips)." and "If set to True, will cause the payroll report to include tips left by customers (usually credit/debit tips)." Cash and charged tips are separately controlled and separately reported. The second limb fails: no Treasury tipped-occupation code exists anywhere in the fourteen published suites. In the companion employees suite the DeclaredTips resource carries an amount, an employee, an establishment and a tips date plus audit fields only, and Role carries name, department and rank, with no occupation-code attribute, so there is nothing to populate W-2 Box 12 code TP or Box 14b from. Correction to the prior note: DeclaredTips also carries id, uuid, created_date, updated_date and resource_uri, so the earlier list of four was incomplete, though none of them is an occupation code. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/scheduling_suite.yaml · retrieved 2026-08-10 adversarially verified
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
Revel's 'Payroll' is a reporting tab (Schedules > Payroll) that summarizes employee hours, wages and tips with export links — 'Your Payroll can easily be managed in Revel as long as you have your employees clock in and clock out.' The documented paths to actually pay employees are third-party: the ADP export (Workforce Now / Total Force) and the QuickBooks Online Payroll integration, where 'QBO payroll does not allow Revel to send any other information other than hours worked' and payroll is run inside QuickBooks ('go to QuickBooks > Payroll and select to Run Payroll'). No first-party tax filing or direct deposit exists anywhere in the help centre. https://support.revelsystems.com/s/article/Payroll-Guide-1583150213542 · retrieved 2026-08-04
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
Two named major providers with documented formats/integrations: (1) ADP — 'You can export the hours your employees worked (in CSV or XLSX form) to import into ADP. We support both Workforce Now and Total Force formats', exported from Schedules > Payroll with each employee's ADP number stored in the External ID field; (2) QuickBooks Online Payroll — the integration 'will automatically populate employee worked hours to Payroll on QuickBooks' (Employees: QBO article). The Payroll report itself also exports hours, wages, declared and non-cash tips in multiple formats. https://support.revelsystems.com/s/article/How-to-Export-Employee-Hours-to-ADP-1583150213536 · retrieved 2026-08-04
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
Downgraded from no. What the spec closes is real: the Scheduling suite is three resources, TimeSchedule, TimeScheduleRule and TimeSheetEntry, and the schedule lifecycle is a published four-value enumeration, "0 - TimeSchedule was created", "1 - TimeSchedule was emailed", "2 - TimeSchedule was approved", "3 - TimeSchedule was rejected". There is no swap-request, shift-trade, open-shift or availability entity anywhere in the fourteen suites. The help centre describes the same shape positively rather than by silence: a manager builds the schedule, emails it, and the employee logs in with a PIN to confirm or reject. So an employee self-service step exists, which is why this is partial and not unknown, but it is accept-or-reject on a manager-authored schedule, with no swap, no open-shift claim and no eligibility enforcement. It is not a no because the claim's locus is a self-service app, which is precisely what a workforce-management integration supplies, and Revel publishes a Deputy integration article whose partner is a scheduling and mobile-workforce product. Revel's spec closes Revel's model; it does not close the integrated surface, and no Revel document states that swaps are unavailable. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/scheduling_suite.yaml · retrieved 2026-08-10 adversarially verified
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
The Employee Profit Report gives per-employee Sales, Sales/h., Trans., Avg Trans. (average check), QTY/Trans. (items per transaction), Cost, Profit, %Profit and Profit/h., filterable by role/department and date range — solid per-server sales metrics. Shortfall: no documented per-employee void and comp rate; voids, returns and comps are reported in aggregate sections of the Operations and Adjustments reports rather than as an employee scorecard metric. https://support.revelsystems.com/s/article/Employee-Profit-Report-1583149670660 · retrieved 2026-08-04
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
Multi-level BOM costing is documented natively: 'Use ingredient cost to calculate product cost — If a product is assigned ingredients through a recipe, the total cost of the product is derived from the sum total of all ingredients... the ingredient itself will have a dynamic cost based on the inventory cost' (Introduction to Inventory settings). Ingredients can themselves carry recipes of other ingredients for house-made prep items ('housemade sauces, buns, or ice cream... track your inventory to the micro-ingredient level' — Attaching Recipes to Ingredients), and Total Recipe Cost is system-computed (view-only in the import/export tool). https://support.revelsystems.com/s/article/Introduction-to-Inventory-1583148890898 · retrieved 2026-08-04
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
Inventory Stock Unit Conversions documents per-product stock units with explicit conversion factors ('enter how many individual units of this item go into the stock unit. For example, 24 units (cans) of soda make up a case'), a Primary unit flag, and per-stock-unit default reorder prices; POs are placed in reorder units while receiving and sales depletion post in individual units. Prep recipes carry a Recipe Yield and per-batch Actual Yield. Shortfall: no per-item yield/waste percentage applied to raw-to-usable conversion — yield exists only as a batch output quantity on prep recipes. https://support.revelsystems.com/s/article/Inventory-Stock-Unit-Conversions-1583149942770 · retrieved 2026-08-04
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
The Physical Inventory Report keeps history per completed count cycle and 'summarizes the expected count versus the actual count (variance)': Total Quantity Expected/Counted, Variance in Quantity, Total Value Expected/Counted, Variance in Value, drillable by Category or Class, where expected on-hand derives from recipe-driven sales depletion plus receipts. Shortfall: this is an on-hand shrink/variance report per count cycle, not a per-item usage decomposition showing theoretical usage (POS sales x recipe) versus actual usage for the period as separate figures. https://support.revelsystems.com/s/article/Physical-Inventory-Report-1583149672025 · retrieved 2026-08-04
Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator
inventory-realtime-depletion
The vendor's own webhook request form enumerates 'In/Out Stock' as a selectable event type, so inventory status changes are pushed rather than polled. Modifier-driven depletion granularity is still unverified, so partial holds. Re-pointed 2026-08-10: the inout.stock event previously cited on the withdrawn developer portal survives on this form, which additionally shows webhooks are enabled BY REQUEST (partner name, establishment ID, target URL, environment) rather than self-serve. https://support.revelsystems.com/s/webhook-access · retrieved 2026-08-10
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
With 'Track in Inventory' plus 'Do not allow sale of this product without stock on hand', items become unsellable at zero stock. Online Ordering XT tracks by product or recipe ingredient — 'the pizza will show as out of stock when you... are out of pepperoni, mozzarella, or any other item in the recipe. Modifiers with recipes attached will be tracked too. If an item becomes unavailable before the customer checks out, it will show as unavailable in their cart' (ingredient-level tracking is enabled by Revel Support on request; not yet supported for linked/split combos). The DoorDash Marketplace integration honors the same state: 'Items with zero or negative stock count in Revel cannot be ordered on DoorDash if the product, modifier, and or ingredient as part of a recipe... has track in inventory enabled.' https://support.revelsystems.com/s/article/Online-Ordering-XT-Product-and-Ingredient-Inventory-Tracking · retrieved 2026-08-04
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
Full or subset counts are documented: Physical Inventory sessions select Group/Class/Category to count and divide the store into sections; the successor Stocktake feature adds reusable templates, sections with variance handling, in-progress viewing, per-section recounts, count-figure editing, and a list of completed stocktakes; the Physical Inventory History report retains each cycle's expected-vs-counted variance separately in quantity and value. Shortfall: no scheduled recurring cycle-count automation is documented — every count is started manually (templates ease repetition but nothing runs on a schedule). https://support.revelsystems.com/s/article/Stocktake-1583149941735 · retrieved 2026-08-04
Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.
inventory-mobile-count-offline
The Revel Inventory App (iOS) supports section-based counting with barcode scanning by wired scanner, Bluetooth scanner, or the iPhone's internal camera, with expected-vs-counted per item, blind-scan and require-count-by-scan options, and sync of finalized counts to the Management Console. Shortfalls: 'The physical inventory itself is done on the Revel Inventory App and requires a separate paid subscription', and no documentation states that the app continues accepting counts with no network connectivity and syncs on reconnect. https://support.revelsystems.com/s/article/Physical-Inventory-1583149941728 · retrieved 2026-08-04
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
PO transmission is documented as email of a PDF ('Enable Emailing Purchase Orders: If checked, user will have the option to email a PDF of a purchase order upon completion') or print; the Inventory FAQs' answer for getting an order list into 'a wholesale order site' is 'You can export your inventory list to Excel'. The complete Inventory tab tour (Vendors, Reorder, Purchase Orders, RMAs, Transfer...) contains no distributor catalog or EDI order/invoice integration, and no broadline distributor (Sysco, US Foods, PFG) appears anywhere in the complete public help centre. https://support.revelsystems.com/s/article/Inventory-FAQs · retrieved 2026-08-04
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
Every documented invoice-entry path is manual: receiving against POs (with the 'Require Invoice number when receiving' setting), the Periodic Inventory Purchase Ledger where users key invoice number, date, vendor, products, quantities ('This field can currently only support whole numbers') and cost line by line, and Excel import/export. No photo, PDF, or email ingestion with line-item extraction exists anywhere in the complete public help centre, whose Inventory tab tour enumerates all receiving surfaces. https://support.revelsystems.com/s/article/Periodic-Inventory-1583149942773 · retrieved 2026-08-04
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
The Inventory FAQs state the limitation directly: 'Will Revel show the last purchased price when creating purchase orders? — No. The purchase order will display the cost as entered on the product or ingredient list.' No per-item purchase price history is surfaced at ordering, and no received-price-vs-prior/contract alerting exists anywhere in the help centre; the Vendor Invoices report lists invoices without any price-comparison or threshold alert. https://support.revelsystems.com/s/article/Inventory-FAQs · retrieved 2026-08-04
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
Reorder to PAR is documented: per-product/ingredient PAR via the Default Reorder Quantity field with 'Reorder to PAR' checked; the Inventory > Reorder tab computes the suggested quantity as PAR minus current stock and generates the PO ('if the Default Order Quantity is set to 144, and you have 14 of the product in stock, 130 will appear on your purchase order'). Shortfall: static PAR only — Revel's only sales-history forecasting (Item Tracking / Product Forecasting) drives prep-report printing for QSR item prep, and is not linked to purchase-order suggestion. https://support.revelsystems.com/s/article/Reorder-to-PAR-1583149943286 · retrieved 2026-08-04
Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.
inventory-waste-logging
Revel Inventory (App Store listing, published by 'Revel Systems INC', bundleId com.revelsystems.inventory) states in its own description: 'Manage Your Inventory. Quickly receive items, input waste and spoilage, and update item cost and price right from the app.' That documents a waste/spoilage entry workflow that debits inventory (the app's stated purpose is updating on-hand quantities). Named shortfall: the listing does not mention reason codes on waste entries, nor does it say waste cost is reported separately from usage variance - both required by this claim - and an App Store description is vendor marketing copy, not an admin guide, so it is capped at grade C regardless. https://apps.apple.com/us/app/revel-inventory/id1051198587 · retrieved 2026-08-04
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
The vendor's own Inventory FAQs state the absence directly. Q: 'If we follow FIFO and know the shelf life of ingredients, is there a way for the system to estimate the wastage / spoilage given receivables vs. sales?' A: 'No. There is no way to automate shelf life/expiration dates and wastage.' No expiration-date tracking or expiring-soon report exists anywhere in the help centre. https://support.revelsystems.com/s/article/Inventory-FAQs · retrieved 2026-08-04
Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.
inventory-bar-partial-bottle
Bottle-fraction tracking, using Revel's own beverage example. An ingredient is tracked in its unit of measurement and a bottle is defined as a stock unit above it: "Primary Stock Units allow you to track your inventory in larger quantities or smaller quantities", and in the stock unit setup step, "In the Conversion field, enter how many individual units of this item go into the stock unit. For example, 1 bottle of wine equals 25 ounces". Depletion is fractional per serving via recipes - "Enter the quantity of the ingredient in one serving of the product" - with the worked example instructing the user to "enter 7 oz. in the QTY field". So a bottle is countable and depletable in ounces, i.e. by bottle fraction. The disjunct the claim allows for scale-based weighing is not met: no bar liquor scale integration is documented (the Detecto and Brecknell scale articles are retail point-of-sale weighing). https://support.revelsystems.com/s/article/Ingredients-Recipes-Guide-1583150212848 · retrieved 2026-09-05 adversarially verified
Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.
inventory-cogs-gl-export
The cost side does reach QuickBooks Online in QBO's own format: selecting the Inventory module 'will send Purchase Orders and Inventory Cost of Goods to QBO Daily. No Quantity on Hand or inventory lists will sync.' The GL targets are documented as specific QBO account types and subtypes - COGS Account = Cost of Goods Sold / 'Supplies Materials-COGS', Asset Account = Other Current Asset / Inventory, Payable Account = Accounts payable (A/P), plus a POS Inventory Adjustment account - and Location Tracking stamps the establishment name on each entry. Named shortfall, and it is the operative one: the claim requires GL account mapping configurable PER ITEM CATEGORY, and the documented mapping is a single fixed set of account slots. Revel states 'our integration does not allow you to choose accounts that would conflict with the business logic of QuickBooks. Accounts available within the QBO Settings drop-down are accounts that fit the integration requirements' and 'Customers cannot change these to any account that is not available in those drop downs'. Product-class breakout ('Summary by Product Classes') exists only on the sales side, not as per-category COGS mapping, and quantity on hand never syncs. https://support.revelsystems.com/s/article/QBO-Mapping-Account-Types-1583148425273 · retrieved 2026-08-02 adversarially verified
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
UPGRADED partial -> yes on 2026-08-10. The claim asks that inventory AND recipe costing be native rather than a separately-contracted third-party product. Inventory is 32 paths (37 GET) beside a 20-path purchase-orders suite; recipes are first-class and writable (ProductRecipe, IngredientRecipe, ModifierRecipe, all get/post/patch/put); and costing is explicit in the schema -- `costing_method` ("Can be avg, lifo, fifo"), `total_value`, a reorder/par `threshold`, `adjust_cost`, and `cost_override` ("Override of the modifier cost for this Product"). The dossier's "recipe costing depth unverified" shortfall is REFUTED. The 'Inventory X' product the dossier referenced is confirmed live rather than dropped: /inventoryx/api/inventory/{CurrentStock,Product,Ingredient} paths, including receive operations, are published in this spec. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/inventory_suite.yaml · retrieved 2026-08-10
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
The off-premise mobile dashboard is 'Insights by Revel' (the documented replacement for the Manager App), whose Dashboard screen 'provides insights on transactions, payments, top selling products, labor trends, and shift alerts', supports day-over-day trending percentages, drill-down reports in Data/Pie/Graph views, and filtering by trend, employee or role. Named shortfalls, all from Revel's own article: (1) it is a PAID add-on, not included - 'Upon purchasing the app, you will receive an email containing a license key... A license key is required to active Insights', and additional device keys require a call to Revel Sales; (2) 'The Insights by Revel app is available on the iPhone via the App Store. This app is not available for Android devices'; (3) 'The reporting range is one day' and trending is only available on a single-day report; (4) access requires POS role plus Manager permission. Critically for this claim, no refresh latency is stated in any Revel document I could retrieve - the article never says how current the dashboard is, so 'reflecting transactions within minutes of the sale' remains unestablished. https://support.revelsystems.com/s/article/Insights-by-Revel-1582893045693 · retrieved 2026-08-02 adversarially verified
Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.
reporting-eod-closeout
The Operations Report is 'a combination of various reports all rolled into one... reconciles the essentials from each report into one large report': Gross Product Sales, Discounts, Net Sales, Taxes (with rates), Tips (cash/credit/auto gratuity/adjustments), Adjustments, Voids/Returns/Comps/Exchanges with reason and total, Payments by method (grand total equals the Sales Summary's Net To Account For), Cash Summary with pay-ins/pay-outs and cash deposits, and Labor wages. The companion Sales Summary Report adds Cash Due house/employee and refunds detail. https://support.revelsystems.com/s/article/Operations-Report-1583149671565 · retrieved 2026-08-04
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 Mix Report has a Modifier display field and a documented Modifier Totals section ('the total displayed for each modifier will be the number of products with that modifier sold', with a pepperoni-pizza worked example), plus item-level sales, discounts, tax, and margin columns, filterable by Employee, Day of the Week, Dining Options, Online Orders, and Product Class. Shortfall: modifier rows are documented as quantity counts only — per-modifier gross/net sales columns are not documented — and there is no daypart filter (day-of-week and dining-option filters only). https://support.revelsystems.com/s/article/Product-Mix-Report-1583149670668 · retrieved 2026-08-04
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
The Discounts Report houses item/order/exchange discounts and coupons with Order #, Item, QTY, Date, and 'Reason: The reason entered on the POS when the discount was applied', filterable by Employee and groupable by Order/Reason/Item/Discount Type; the Operations Report shows voids, returns, comps, and exchanges by reason, quantity and total and points to the Discounts report for detail; the Action Log Report records Price Override and Item Deleted actions with Date and Employee columns. Shortfall: no documented attribution of the approving manager on comps/voids/discounts — attribution is to the employee only. https://support.revelsystems.com/s/article/Discounts-Report-1583149669643 · retrieved 2026-08-04
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
Cash management exposes BankDrop, CashOffice, Payout and Till (8 GET, 4 POST/PATCH/PUT), implying drawer reconciliation. Shortfall re-measured, not carried: the spec contains no over/short field and no over/short report operation, and nothing addresses the claim's per-shift or per-employee dimensions. Partial holds. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/cash_management_suite.yaml · retrieved 2026-08-10
Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.
reporting-labor-productivity
The Labor Report 'shows your labor cost compared to the amount of sales done per hour', with per-hour rows for Actual Hours ('Based on clock ins/ clock outs'), Wage, Sales, Sales Per Man Hour, and Qty. Per Man Hour, filterable by roles/departments; the Employee Profit Report gives per-employee Labor, Hours, Sales, % Sales (Sales/Labor), Sales/h., and transactions, filterable by role. Shortfall: no documented labor-cost-as-a-percentage-of-sales column — the hourly report shows wage and sales side by side and the per-employee report shows the inverse Sales/Labor ratio, split across two reports rather than one hourly/department/employee view. https://support.revelsystems.com/s/article/Labor-Report-1583149671122 · retrieved 2026-08-04
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
The Employee Profit Report displays per-employee Sales, Trans., Avg Trans. (average sales per transaction), QTY, QTY/Trans. (average items per transaction), Sales/h., Profit/h., and % Profit, filterable by role and date range. Shortfall: no documented attachment-rate metric for named categories and no tips-as-a-percentage-of-sales metric — tips appear per employee in the Payroll report, not in this per-server sales scorecard. https://support.revelsystems.com/s/article/Employee-Profit-Report-1583149670660 · retrieved 2026-08-04
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
Marketplace channels are tracked through named custom objects: for Uber Eats, 'The custom payment option, dining option, and discount will also be named Uber Eats. These are all used for tracking and reporting of Uber Eats orders and sales', and reports filter by Dining Options and Online Orders, so per-channel revenue is reportable. Shortfall: no commission-netted margin view — the DoorDash Marketplace article states merchants 'will continue to use the DoorDash merchant portal and/or the DoorDash tablet for... DoorDash specific reporting', so marketplace-fee-net profitability lives in the marketplace's portal, not Revel. https://support.revelsystems.com/s/article/UberEats-Onboarding · retrieved 2026-08-04
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
Auto Delivery of Reports documents Email Report Jobs with named jobs, daily/weekly/monthly/quarterly/yearly cadences, CSV/Excel/PDF formats, multiple comma-separated recipients, per-establishment selection, and even an HTTP web-server target. Shortfall: only seven reports are schedulable — Sales Summary, Product Mix, Operations, Product Inventory Summary, Ingredient Inventory Summary, Labor, and Trending Sales (weekly only) — not any report, and the auto-delivered Product Mix arrives with default columns, ignoring customized selections. https://support.revelsystems.com/s/article/Auto-Delivery-of-Reports-1583149669622 · retrieved 2026-08-04
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 public Swagger UI serves 14 OAS 3.0 suite specs (v2025.3.0) covering orders, payments and cash management, products/pricing, customers, employees and scheduling -- the claim's coverage conjunct, established more completely than the withdrawn ReadMe did. The self-serve-credentials conjunct is unmet: the page that documented credential issuance is gone, and the specs declare only an `API-AUTHENTICATION` apiKey header plus a placeholder OAuth2 block. Partial holds on an unestablished conjunct -- the vendor is NOT recorded as having withdrawn self-serve credentials, only as no longer publishing how credentials are issued. https://developer.revelsystems.com/ · retrieved 2026-08-10
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
DOWNGRADED yes -> partial on 2026-08-10. The claim needs outbound webhooks for order and payment lifecycle events AND documented retry behaviour AND payload signature verification. The vendor's live webhook surface is a request form enumerating six event types -- In/Out Stock, Menu Updated, Order Finalized, Customer Created, Customer Updated, RewardCard Created -- which establishes the push mechanism but publishes nothing about retry or signing. The retry schedule and HMAC-SHA1 signature the dossier verified verbatim were on developer.revelsystems.com/revelsystems/docs/webhooks, now withdrawn; that reading is preserved under extensibility-webhook-reliability, which is quarantined rather than deleted. This is a downgrade of what is CURRENTLY PUBLISHED, not a finding that the vendor removed retry or signing. https://support.revelsystems.com/s/webhook-access · retrieved 2026-08-10
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
Upheld. Raw-data access is documented as included to a point and paid beyond it: "12 month access is included at no additional cost with your base Revel subscription", with an export control next to every report at no stated charge, but for anything older the merchant must "purchase a paid data plan for enhanced access", and the tier is fixed at the legal entity rather than per establishment, "Unfortunately, Revel cannot enable different data access tiers for specific establishments." That is a genuine upcharge on historical raw data, though not the per-location API fee or revenue share the claim's worst case describes. Whether API credentials themselves carry a fee remains unanswered: the published API/XML Terms grant the licence for the duration of the subscription and state no consideration, and the developer FAQ is silent on cost. https://support.revelsystems.com/s/article/Data-Access-changes · retrieved 2026-08-04 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
Upheld, with the capture's status corrected. Revel's pricing page shows a single software SKU, "$99/monthly fee" per terminal, and lists reporting inside it, "Maintain a complete view of your business with access to real-time insights from anywhere." The help centre documents Sales Summary, Product Mix, Labor, Discounts and Operations reports in the management console with no plan gating. But the same page puts multi-location comparison outside that SKU under Additional Services and Products, "Manage all locations from a single dashboard with Enterprise Management solutions." One of the four report families the claim names is therefore a separate product, and history beyond twelve months is a separately purchased data tier. Evidence discipline: this is a Wayback capture dated 2023-05-28. I queried the Wayback CDX index for revelsystems.com/pricing/ on 2026-09-05: this is the LAST capture returning 200, and the next capture, 2024-07-15, is a 301. So this is not a superseded revision but the terminal published revision of a page that was subsequently withdrawn; the live URL now redirects to shift4.com and whether a post-acquisition successor pricing document exists is unknown and was not read. https://web.archive.org/web/20230528073202/https://revelsystems.com/pricing/ · retrieved 2026-09-05 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
Upheld against the precedent, on the claim's own wording. The claim asks for at least 24 months of transaction-level detail queryable in the reporting UI with no silent truncation AND no archive retrieval fee. Revel publishes the window and it is half that: historical data is "accessible for a period of 1 year after they have been processed", "12 month access is included at no additional cost with your base Revel subscription", and, answering the year-over-year objection directly, "In practice, 12-month access includes rolling 13 month + current month data that allows for YoY analytics". Beyond that the merchant must export and self-store or "purchase a paid data plan for enhanced access". A purchasable longer window does not convert this to partial, because the paid tier is exactly the archive retrieval fee the claim disallows; the claim would still fail even if a tier reached 24 months, and no tier's window is stated anywhere. The article also refuses per-establishment tiering outright, "Unfortunately, Revel cannot enable different data access tiers for specific establishments." The one limb Revel does satisfy is transparency: the truncation is documented, not silent, so the no rests on the window and the fee, not on concealment. https://support.revelsystems.com/s/article/Data-Access-changes · retrieved 2026-08-04 adversarially verified
Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator
reporting-anomaly-alerts
Operator-configured threshold alerts are documented for cash: Till Alerts fire 'when the dollar amount in the cash drawer reaches this amount' with an Alert Email field ('Enter your email address to get your till alerts via email'), day/night thresholds, and a Deny Transaction Amount; Low Stock Alerts cover inventory, and the Insights app surfaces configurable late-employee/overtime shift alerts (Settings > Reports > Insights Application). Shortfall: no documented alerting on sales, void, or discount metrics, and no historical-pattern deviation detection — the claim's example anomalies are not covered. https://support.revelsystems.com/s/article/Tills-How-to-Setup-Till-Alerts-1582899801523 · retrieved 2026-08-04
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
326th: MOVED to no. The 323rd left this unknown solely because it had a URL census of shift4.com and not a body census ('a URL census is not a census of page BODIES'). Body census now done. CORPUS: 825/825 non-locale shift4.com sitemap slugs (818x200, 7x404 test slugs; 36,380,880 chars; sitemap index has exactly one child; robots Allow: /; nonsense control /zzz-nope-12345 = 404) + the 7 Revel legal PDFs enumerated at /revel-legal + 698/698 live KB articles (2,592,423 chars) + the 14/14 anonymous OpenAPI 3.0 suites (198 paths). CONTROLS, tokenised, case-insensitive: `natural language` 0/832 documents AND 0/698 KB articles; `ask revel` 0/832; `conversational` 2 hits in 1 of 832 and both are a careers-page job description, not a product. `artificial intelligence` 12/832 are payments fraud/routing blogs only. The documented reporting surface in Revel's own KB is entirely fixed reports plus the Insights iPhone app, and the API surface exposes no query-by-question endpoint. So neither the vendor nor its owner ships or markets a natural-language query or AI assistant over the operator's own sales and labor data. Retrieved 2026-09-18. https://www.shift4.com/revel-legal · retrieved 2026-09-18 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
Upheld. Guest-level reporting exists and is tied to identifiable CRM records: "This report houses all customers' orders." and, per customer, "The number of orders attached to the customer will be show in parentheses right next to the customer name.", with per-customer order detail, an optional tip-inclusive total, a date-range filter and Excel or CSV export. That yields per-guest visit counts and spend for a chosen window, the raw material the claim asks about. Absent from this report and from every other report article in the mirror is the derived analytics the claim names: no new-versus-returning counts, no visit-frequency distribution, no lifetime-spend cohorting. The operator would build those from the export. https://support.revelsystems.com/s/article/Customers-Orders-Report-1583149670658 · retrieved 2026-08-04 adversarially verified
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
Item Tracking / Product Forecasting documents forward forecasting from the location's own history: 'Forecast Item Quantities Based on Number of Weeks', 'Forecast Sales Based on Number of Weeks', net-or-gross basis, 'Hourly Forecasting Sales - Includes the forecast hourly sales for the day', per-time-slot forecasts at 15/30/60-minute intervals, safety factors, and auto-printed Start of Day/Interval/Closing prep reports; the report lives at Reports > Other Reports > Item Tracking Report. Shortfall: the forecast drives kitchen prep printing only — no documented consumption by labor scheduling (Labor Report's Projected Hours come from the manually built Shift Schedule) or purchase-ordering workflows. https://support.revelsystems.com/s/article/Item-Tracking-Product-Forecasting-1583149672017 · retrieved 2026-08-04
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
The Payroll report (Schedules > Payroll) shows per-employee Declared Tips ('employees can input the value of cash tips received on the Point of Sale') alongside Non-Cash Tips from credit transactions, toggled via Time Sheet Rules 'Display Declared Tips in Payroll' / 'Display Payment Tips in Payroll', and exports for payroll use; the Tip Pooling tool documents full distribution detail per employee (Declared Tips, Payment Tips, Tip In Amount, Tip Share Amount, Final Tips — 'the amount that should be reported to the IRS'); the Tax Report separates each tax rate with totals and offers By Zipcode/By State/By Country breakdowns (breakdown drop-down appears only when shipping is enabled). https://support.revelsystems.com/s/article/Payroll-Guide-1583150213542 · 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
The EMS Establishment Hierarchy Tree is a first-class structure of brand > divisions ('Divisions can have numerous layers of sub divisions') > establishments, plus cross-cutting groups (an establishment can belong to many groups); clicking a division or group enables EMS mode for all establishments under it, EMS pushes and locks employee roles/permissions across establishments, and enterprise reports read data across levels. EMS is a paid add-on at $29/month per establishment. https://support.revelsystems.com/s/article/EMS-Establishment-Hierarchy-Tree-1582898526017 · retrieved 2026-08-04
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
Per-location prices exist without duplicating the item: EMS links the same product across establishments and lets price be set or locked per establishment from the base. Shortfalls: no channel or daypart price zones on the item record - third-party channel pricing is only a '3rd party price upcharge (%)' (DoorDash Marketplace) or a Weborder API price override, and Price Tiers are alternate prices attached to discounts (VIP/employee/promotion style), not location-group/channel/daypart price books. https://support.revelsystems.com/s/article/Products-in-EMS-1582898526007 · retrieved 2026-08-04
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
Above-store reporting exists as a named report. The Establishment Payments Report, reached from Management Console > Reports > Other Reports > Establishment Payments, 'is used mainly by business owners with multiple establishments to view a condensed version of the Sales Summary report for each establishment' and is 'also used for chain or franchise owners who collect a percentage of payments for royalties'. Basic columns are Establishment, Gross Sales, Total Discounts, Net Sales, Total Taxes, Total Liabilities, Total Payments, % of Total Payments, Total Transactions and Total Invoices; the All view adds Taxable/Non-Taxable Sales, service fees, Average Check, Item Discounts, Order Discounts, Coupons, Surcharges, house-account payments, gift card and store-credit activity. It filters by date range and exports. Named shortfalls: the claim asks for sales, labor, discounts, voids AND item mix in one cross-location view - labor, voids and item mix are not columns here and live in separate single-report surfaces (Labor Report, Product Mix Report) - and no store-vs-store ranking and no variance flags are documented in this report or in the Insights app, whose multi-store view is a plain per-store Total Payments list. https://support.revelsystems.com/s/article/Establishment-Payments-Report · retrieved 2026-08-02 adversarially verified
Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.
multi-location-cross-location-giftcard
Gift cards are redeemable across establishments and sales are reported as liabilities, but settlement is manual: 'Revel Systems' Gift Cards do not handle royalties... the establishment in which a gift card is purchased receives the full amount of the gift card, even if the gift card is redeemed at a separate location. For this reason, Revel provides a gift transactions report that shows the variance between establishments and allows merchants to keep track of a central bank and manually calculate royalties for individual locations.' https://support.revelsystems.com/s/article/Overview-of-Revel-Gift-Cards · retrieved 2026-08-04
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
'Data that Updates for All Establishments' lists Customers and Customer Groups, Gift Cards, and Rewards Cards as data that updates across all establishments on the account URL - so a customer's CRM profile and rewards-card balance are account-wide rather than per-location, and the CRM's customer item/order export can be pulled across selected establishments. https://support.revelsystems.com/s/article/Data-that-Updates-for-All-Establishments · retrieved 2026-08-04
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
NEW SURFACE and it closes the cell the 324th left open: Revel's anonymous production OpenAPI 3.0 set v2025.3.0 (14/14 suites, 198 paths, listed by https://developer.revelsystems.com/; nonsense control 403). CLAIM: a single location/terminal operates two or more distinct brands with separate menus, separate receipts/branding, and separately reportable revenue, on the same hardware and drawer. VERDICT: no. EVIDENCE - brand is modelled ABOVE the store and is single-valued at the store: EnumHierarchyType on /enterprise/Establishment/ is closed at three levels, '0 - Client - Represents the brand of the location. Acts as a folder. 3 - Division - Represents the franchise of the location. Acts as a sub-folder. 5 - Store - Represents a single, physical location.' The Establishment resource's 76 properties include exactly ONE brand ('brand: URI of a Brand resource that specifies the location brand. Most non-enterprise accounts will have a signle brand', example '/enterprise/Brand/1/'), ONE brand_name ('Name of the brand this location is part of'), and ONE logo_img ('URI of a RevelImage resource that stores the business logo') - none of them arrays. The guest-facing channel reads the same singletons: GET /weborders/system_settings/ returns SystemSettings with single brand, brand_name, business_name, logo_img and favicon_image per establishment. And revenue cannot be attributed to a brand inside a location: the Order resource's 109 properties carry establishment, table, revenue-side totals and reporting_id but NO brand, concept or virtual-brand field, and RevenueCenter (general_suite) groups pos_stations, not brands. So separate branding and separately reportable revenue are both unreachable within one establishment, even though separate menus are (CustomMenu.stations / mode). CORROBORATION from the KB census: 'You can only have one store integrated with DoorDash Marketplace per establishment in Revel... If the virtual store / ghost kitchen shares an establishment in Revel, then it cannot be integrated' (https://support.revelsystems.com/s/article/DoorDash-Marketplace). BOUND/CONTROLS: 14/14 suites (1,751,580 bytes) + 698/698 live KB articles. Tokenised: `virtual brand` 0/14 and 0/698; `ghost kitchen` 0/14 and 2 hits in 1/698 (the DoorDash article); `concept` 0/14; `brand` 20 hits in 5/14 suites, all of them the Establishment/SystemSettings singletons, Product.product_brand ('Brand name of this product', example Gucci) or Order.vehicle_make ('Car brand for pickup_type = DRIVE_UP'). POISON WORTH RECORDING: a non-tokenised grep for `brand` in general_suite.yaml hits Brandon, Branden and Brandy inside a 1,200-name call-name default list; the count above is word-boundary only. Retrieved 2026-09-17. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/general_suite.yaml · retrieved 2026-09-17 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
Multiple simultaneous individual taxes stack per product (worked example: 10% state + 5% county on one item), tax groups scope taxes to selected products with tax rules and effective dates, Tax by Dining/Order Option applies jurisdiction rules like prepared-food eat-in vs take-out, tax-inclusive products are supported ('removing the tax on all tax included products'), and tax-exempt products are selected per tax group. Configuration is per establishment: EMS deliberately does not push tax settings globally ('This is for security purposes (i.e. tax settings, etc.)'), and establishment groups are recommended where 'you need your tax rates to vary for one state to the next', with station/order-level prevailing-rate overrides gated by permission. https://support.revelsystems.com/s/article/Taxes-Implementing-Different-Tax-Types-1583152075662 · retrieved 2026-08-04
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
Time Sheet Rules (per establishment, under Schedules) set daily/weekly overtime and doubletime thresholds and multipliers, seventh-day overtime, auto clock-out, and break rules ('Calculate Paid/Unpaid Breaks By Rules', explicitly referencing California meal-period law), with terminal-level enforcement: 'Prevent Employee Clock-In Before Break End' requires a manager PIN and clock-in-before-shift limits block early punches. Shortfalls: no predictive-scheduling compliance is documented, and Schedules/Time Sheet Rules are not among the documented EMS-pushable scopes, so centrally enforced group-level labor policy is not documented. https://support.revelsystems.com/s/article/Time-Sheet-Rules-1583150213539 · retrieved 2026-08-04
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
Substantively right (iPad-based POS on off-the-shelf Apple hardware), and the live help site and Revel University document iPad-based operation directly, so confidence can rise above an aggregator claim. Not downgraded, but the citation should not be an aggregator profile. https://reveluniversity.revelsystems.com/s/advanced-features/kds · retrieved 2026-08-01 adversarially verified
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
iOS/iPadOS identified as the client platform; minimum OS versions and device specs not published (vendor docs site removed). https://sourceforge.net/software/product/Revel-Systems/ · 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
Revel's documented mobile order taker (MOT) is not a purpose-built handheld: v2.77 introduced an 'IPORT mobile order taker (MOT) case' - an iPad in an IPORT CONNECT PRO case with an optional hand strap, paired with a magnet-attached CONNECT PRO PayCase holding a separate Link 2500 or Moby 5500 payment device - exactly the case-add-on architecture this claim excludes. The 'Active Supported Hardware' catalogue ('all the active and supported hardware by Revel Systems') lists no handheld with an integrated card reader, and no drop rating or IP ingress rating is published for the MOT assembly anywhere in the complete help centre. https://support.revelsystems.com/s/article/iPort-stands-and-cases · 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
The handheld is an iPad in an IPORT CONNECT PRO case; the vendor's documented uptime strategy is dock charging, not battery swap: CONNECT MultiDock 6 'simultaneously charges up to 6 devices, each with its own 5V 3A power source' and the CONNECT Dock 'provides PD fast charging to iPad allowing for rapid recharging for minimal downtime of iPads in the field'. No hot-swappable or field-replaceable battery option exists in the Active Supported Hardware catalogue or MOT documentation (the only quick-swap battery mentioned anywhere belongs to the CipherLab 2564 scanner), and no vendor-published full-shift battery rating exists. https://support.revelsystems.com/s/article/iPort-stands-and-cases · retrieved 2026-08-04
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
Archived revelsystems.com hardware catalogue page (Wayback capture 2014-05-02). Grade C: vendor hardware marketing page. Revel's own hardware pages once documented cellular connectivity on the iPads it sold for mobile POS. The 2014 iPad Air page cites the 'Wi-Fi + Cellular model' with 'more LTE bands' 'for Mobile POS users' and lists carriers 'for mobile POS'. The 2013-10-08 /hardware/idevices page says 'Mobile POS users should use iPads with a 3G or 4G data plan ... A 2GB plan per location will be sufficient for all mobile POS needs.' The 2015-03-23 'Verizon Cellular Broadband Router' page (Connectivity 'LTE – B13') was a Revel-sold LTE hotspot: 'Stay connected to a reliable Wi-Fi signal whether you are cruising around in a food truck or putting on an event.' The newest capture carrying a cellular spec is the 2016-02-17 iPad Pro page ('WiFi + Cellular: ... LTE', 'Sim Card Nano-SIM'). The 2011-05-26 FAQ (https://web.archive.org/web/20110526113722/http://revelsystems.com:80/faq/) required 'a 3G redundant card for a backup Internet connection in case your DSL goes down'. That is a vendor-specified cellular failover, but for the store's uplink. SHORTFALLS: (1) the handheld cellular material presents LTE as the PRIMARY link for mobile or food-truck use, not as a documented fallback when store Wi-Fi drops. The only explicit backup language (the 2011 FAQ) is about the internet uplink, not handhelds. (2) Newer captures dropped it. The 2021-09-18 /hardware/ catalogue (https://web.archive.org/web/20210918041642/https://revelsystems.com/hardware/) lists iPad, iPad Pro and iPad Mini 5 with no cellular or LTE wording, and its networking section is Wi-Fi access points only (Meraki MR33/MR74, Linksys E1200). This matches the help-centre catalogue's empty Connection column for iPads. DATE CAVEAT: the evidence is 2011-2016, 10-15 years old; Shift4 acquired Revel in 2024. Treat this as historical capability, not current. POISON: 'lte' as a substring hits 198 files ('alternative', 'filter', 'multi-location', 'salted'); tokenised \bLTE\b hits only 4. The 22 'cellular' hits are mostly the 2015 hardware sidebar link 'Verizon Cellular Broadband Router' repeated across category pages. 'handheld' (32 files) is mostly handheld barcode scanners or the Inventory App 'use your phone as a handheld barcode scanner'. VERIFICATION (278th): the fallback conjunct is unmet and the newest hardware capture (2021-09-18) drops all cellular wording, so this records historical 2014-2016 capability on vendor-sold cellular iPads, not a current documented failover. Scored consistently with peers holding partial where cellular-capable handheld variants exist but Wi-Fi-drop failover is undocumented (pdq-pos, toast). https://web.archive.org/web/20140502004303/http://revelsystems.com:80/hardware/idevices/ipad-air · retrieved 2026-09-13 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
Withdrawing the reference to the 'Manual Offline Mode on the Point of Sale' article - it did not survive the migration to the Salesforce help centre and is not in the 693-article corpus. It is not needed. The outage best-practices article documents continuity and degradation together, per outage type: with the server down, 'Create and close orders; Operate tills and take cash payments; Take credit card payments; Print to kitchen and receipt printers (ethernet or BT connected); Use CDS & KDS' remain available, while Clock In/Out and reports are 'limited' and the Management Console, 'Use Loyalty/rewards/gift cards', EOD, House Accounts, customer order history and frontend inventory are explicitly NOT available. With ISP down the same shape applies, with 'Process CC / Debit Payments in offline mode' limited and 'Take manual credit card or Debit payments' unavailable. Card-auth degradation is documented separately and at length in the Offline Mode article (offline transactions 'do not communicate with the server or cardholders' bank'). Refund behavior offline is the one item in the claim's parenthetical that Revel does not address. https://support.revelsystems.com/s/article/outage · retrieved 2026-08-09 adversarially verified
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
Re-homed off the customer-gated Zendesk section onto vendor hardware and KDS documentation, and the first-party question is now settled by Revel's own catalogue rather than inferred from a docs section existing. Active Supported Hardware lists the 'IC-215P-AA2 MicroTouch (KDS)' all-in-one ('equipped with Rockchip's latest architecture, the RK3399', Ethernet, spec sheet) alongside a 20-key Bump Bar and a Vesa Mount (KDS); the KDS also runs on iPad and on the ViewSonic VSD243, both of which have their own Revel KDS app articles. Station routing: products are assigned to named printers/display units per item or in bulk (https://support.revelsystems.com/s/article/How-to-assign-products-to-kitchen-printers-display-unit-KDS-1583149941086). Course/fire timing: 'Optimize KDS for Coursing... will only send products to the KDS when that course is ready for preparation', with Send to Kitchen on Hold or on Done, and per-product automatic coursing (https://support.revelsystems.com/s/article/Optimize-KDS-for-Coursing-1582899129817). Multi-station flow and expo behavior are documented separately again. https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-08-09 adversarially verified
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
Kiosk XT is a first-party self-order kiosk running the same menu and modifier engine as the POS - split modifiers with left/right coverage, group and upsell combos, discount codes, gift cards, Revel and Punchh loyalty, and 'Kiosk XT uses the same settings UI as the regular POS app' - with integrated card payment via Vantiv/TriPOS and FreedomPay pin pads. Named shortfalls: no ADA/accessibility compliance documentation; no documented countertop-vs-freestanding enclosure options (the hardware catalogue lists only iPad stands); payment processors limited to TriPOS and FreedomPay; and documented feature limitations (no customer account creation, no CRM login/order history, most third-party loyalty unsupported, no matrix inventory, no split combos). https://support.revelsystems.com/s/article/Kiosk-XT · retrieved 2026-08-04
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
Two elements are documented: an order confirmation display via the Delphi OCS integration ('offer an industry standard drive through order display system ... send order details to a customer-facing drive-thru screen', one POS to one OCS, with a connection-loss alert on the POS; https://support.revelsystems.com/s/article/Delphi-OCS-Integration) and a dedicated Drive Thru Order Queue (v2.72+) that 'places the oldest orders at the top and displays a clear time lapsed stamp', with vehicle-data and call-name prompts and in-queue payment. Named shortfalls: no speaker/headset integration is documented; Digital Menu Boards are documented as indoor flat-screen TVs with no outdoor-rated option; and there is no drive-thru lane timer or speed-of-service measurement (the Speed of Service report measures KDS/kitchen time only). https://support.revelsystems.com/s/article/Revel-Drive-Through · retrieved 2026-08-04
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
The Active Supported Hardware catalogue lists thermal receipt/kitchen printers from multiple manufacturers, predominantly LAN/Ethernet: Epson T88VII ('Ethernet'), TM-U220, M-M30III (Ethernet/Bluetooth), TM-M30II-SL, P60 (Bluetooth mobile) and TM-L90 Plus, plus the Star MCP31L (Ethernet), alongside Zebra ZD411 and Dymo 550 Turbo label printers - none vendor-branded. The Auto Redirect article separately confirms native Epson ePOS LAN printer support. https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-08-04
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
The Active Supported Hardware page is a published compatibility list covering the full peripheral set: M-S 16-inch cash drawers, CipherLab 2200/2504/2564 barcode scanners, Brecknell 6702U/6720U scales and the Magellan 9400i scanner-scale for by-weight items, and customer-facing displays (Revel L Stand + CDS). Multi-drawer per terminal is separately documented: 'Revel supports dual cash drawers for one printer' using a CD-D1D2EP splitter, an 'Enable two cash drawers' POS setting, and per-employee drawer assignment with drawer locks (https://support.revelsystems.com/s/article/Running-Dual-Cash-Drawers-Setup-1582902926329). https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-08-04
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
Card entry happens on dedicated PCI PTS payment terminals: the SAQ merchant-profile guide states 'The only payment terminals Revel merchants can use are' Ingenico iPP350, iSMP4, Lane 3000, Link 2500, Moby 5500 and Lane 3600, describes them as 'ingenico encrypted swipes', and states merchants 'cannot view full card numbers' and that Revel 'cannot access any Cardholder Data Environment (CDE)'. Named shortfalls: no PCI-validated P2PE solution listing is claimed; the vendor does not state a single merchant SAQ type ('initial business profiling determines which SAQ type must be completed by the merchant'); and quarterly ASV vulnerability scans of the merchant CDE 'under which all POS and payment devices are communicating' are required, indicating the POS environment is not descoped the way a validated P2PE listing would allow. https://support.revelsystems.com/s/article/Merchant-Profile-Questionnaire-guide-for-RA-XT-TriPOS-and-FreedomPay · 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
CLAIM: supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. VERDICT: no, on the same evidence as payments-softpos-tap-to-pay. The vendor's own current equipment enumeration, 'Active Supported Hardware' (https://support.revelsystems.com/s/article/Active-Supported-Hardware, modified 2026-04-23, 'all the active and supported hardware by Revel Systems'), lists ten payment devices and every one is a discrete Ingenico, Verifone or Adyen terminal; the two Apple devices in the list (iPad Air 6th gen, iPad Mini 7th gen) are described purely as POS tablets. BOUND: the live 698/698-article support.revelsystems.com census (Salesforce guest knowledge API; 121/121 already-cited article URLs present). CONTROL over all 698 bodies: /\btap\s+to\s+pay|\btap.to.phone|\bsoftPOS/ 0/698. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-09-17 adversarially verified
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
Verdict correct, sourcing improper: an affiliate-monetized review site cannot carry 'documented' confidence. The defensible evidence is first-party — the vendor pricing and hardware pages no longer exist (301 to shift4.com/food-beverage) and no SKU pricing is published on any Revel-controlled domain. https://revelsystems.com/pricing/ · retrieved 2026-08-01 adversarially verified
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Hardware is documented as sold: the Operations FAQ describes DocuSign 'purchase documents', shipment 'within five (5) business days' after payment, defective-item exchanges and RMA credits for returned items; the Hardware Manufacturer Warranty page states 'Revel ONLY covers the FIRST year of the manufacturer's warranty. After that, please contact the manufacturer directly' - an ownership relationship with the OEM. Named shortfall: no published statement of purchase-versus-lease options or any hardware pricing exists on a Revel-controlled page, so the claim's requirement that 'the vendor states which' is only half met. https://support.revelsystems.com/s/article/Operations-FAQ · 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
GRADE HELD AT B BY SOURCE TYPE, not raised on currency: grade C in this taxonomy means a vendor pricing or feature page written to sell, and this is neither - it is Revel's own binding Additional Terms and Conditions of Hardware Sale. Value upheld, grade downgraded, note trimmed. Revel's Additional Terms and Conditions of Hardware Sale answer the claim directly at section 2.10, used here as a locator only, with the operative language quoted: "Upon expiration or termination of the Agreement, Customer may retain possession of all Purchased Hardware for which Customer has made full payment", the only condition being that the customer must "cease using the Purchased Hardware as part of the Revel POS Platform" and disable access to or de-install the software, APIs and the service. There is no return obligation, no remote disable and no software lock. Evidence discipline: this is a Wayback capture dated 2021-07-28. I queried the Wayback CDX index for revelsystems.com/hardwaresaleterms/ on 2026-09-05 and this is the last capture returning 200, so it is the terminal archived revision rather than a known-superseded one; the live URL now redirects to shift4.com and whether a post-acquisition successor exists is unknown and was not read. I removed the prior note's Revel Guard XT and Apple Configurator argument because those facts are not in the document this row cites. https://web.archive.org/web/20210728100505/https://revelsystems.com/hardwaresaleterms/ · retrieved 2026-09-05 adversarially verified
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
A warranty term is published - 'Revel ONLY covers the FIRST year of the manufacturer's warranty', with a per-device manufacturer warranty table (https://support.revelsystems.com/s/article/Hardware-Manufacturer-Warranty-1582902925055) - and the exchange process has stated turnarounds: after support confirms an item 'defective and within warranty, we'll send the exchange documents within two (2) business days', exchange orders ship 'within five (5) business days', and RMA credits issue '5-10 business days after receipt and assessment'. Named shortfall: this is a confirm-then-ship depot exchange, not an advance-exchange or next-business-day swap, and no committed end-to-end replacement turnaround is published. https://support.revelsystems.com/s/article/Operations-FAQ · retrieved 2026-08-04
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
The 324th note asked the next pass to read 'Payment Device Purchase Policy' and the Revel Guard XT device articles before deciding. Read, live, in the 698/698 Salesforce Knowledge REST census (2026-09-17), and they split the claim rather than closing it - so this moves to partial, not no. ORDERING HALF IS DOCUMENTED ON A PHONE: 'Advanced POS Settings' (https://support.revelsystems.com/s/article/Advanced-POS-Settings-1583149942304) enumerates a Management Console setting 'iPhone App: Menu Mode - Activate to enable menu access and order taking from the Revel Point of Sale iPhone app.' That is a documented, per-establishment permission switch that lets staff take orders on a phone, and it is why a `no` on this cell would be wrong (it also falsifies the earlier note's claim that all POS documentation assumes iPads in IPORT cases). PAYMENT HALF IS DOCUMENTED SHUT: 'Payment Device Purchase Policy' (modified 2024-02-21) - 'any form of payment should only be performed through a supported and authorized payment device purchased directly from Revel Systems', with named risks 'Internal Component Tampering', 'Encryption Key Injection', 'Chain of Custody Breach'. So the payment app on a staff-owned device is excluded by policy. NAMED SHORTFALL (this is the partial): (a) payments may not be taken on a device the merchant did not buy from Revel; (b) there is no documented security model for a personally-owned device - Revel's only device-security path is the opposite of BYOD: 'in order to be able to use all functionality of Revel Guard XT, iPads need to be enrolled in Revel's MDM', and a device bought 'from a 3rd party retailer (regardless of when purchased)' must be supervised through Apple Configurator 2 and FACTORY WIPED ('Select Erase to wipe the device and continue') before 'Reach out to Revel Support to have them install the Revel apps' (https://support.revelsystems.com/s/article/Revel-Guard-XT-3rd-Party-iPad-MDM-Enrollment); (c) the iPhone app has no article of its own in the 698-article census - the single setting line above is its whole documentation. CONTROLS over the 698/698 bodies: `BYOD` 0/698, `personal device` 0/698, `iPhone` 12 hits in 7/698 (the others are Insights by Revel, the Inventory/Stocktake iPhone app, and Bluetooth scanner pairing). Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Payment-Device-Purchase-Policy · retrieved 2026-09-17 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
Revel Guard XT is 'the single source for managing all the devices in your establishment' - iPads (POS, Kiosk, CDS, KDS, MOT), printers, payment terminals, scanners, scales - reporting Device Status and Connectivity Status per device plus firmware version, iOS version, installed apps and battery charge, with MDM remote actions (test print, 'Reboot Payment Terminal', lock device, install/remove applications, assign restriction profiles, network scans) via the RGXT Canopy portal, and Revel-coordinated 'unattended, overnight App update across all locations' on the Pro tier. Named shortfalls: it requires the separately purchased Revel Guard XT appliance; capabilities are tiered (client-performed updates and self-managed custom profiles only on the White Label tier; Single App Mode unavailable on Baseline); and remote reboot is documented for payment terminals and the Guard device but not for iPads. https://support.revelsystems.com/s/article/RevelGuard-1582903575827 · retrieved 2026-08-04
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
Overturned from no, on the analyst's own principle. The analyst correctly declined to score tap-to-phone from this catalogue because a hardware catalogue cannot enumerate a software-only capability. The same principle disposes of this row. The claim is an INTEGRATION claim, that the platform integrates with self-pour tap walls, flow meters or pour spouts such that pours post to a tab; it is not a claim that Revel resells such a device. The catalogue's Scales section is three weighing devices, two Brecknell POS scales and a Magellan scanner-scale, and a flow meter or tap-wall controller is not a scale, it is a different hardware class that a weighing-scale section would never have carried. So the completeness sentence covers a category that does not include the claim's subject. The only other support offered was that no article in the mirror mentions self-pour, PourMyBeer or pour-to-tab, which I reproduced and confirmed, but that is a grep miss and the brief forbids a grep miss as a no on this vendor. I also looked for the second leg that would have saved it, a closed integrations directory naming the partners: the mirror carries only individual partner articles, Como, Deputy, Delphi OCS, Kosmos, LoyaltyPlant, Open Dining, Paytronix, QBO and Twilio, with no directory asserting itself complete, and the Integration Partners page lives on the dead marketing host. No closed instrument exists for this claim. || 324th: 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: proposal partial/C REJECTED; stays unknown. The claim's core conjunct is pour-to-tab; the directory evidences only loss-control hardware partners and never says a pour posts to a check. Entries (https://revelup-techpubs.s3.us-west-2.amazonaws.com/support/hc/en-us/000002620/Revel+Partners-2.pdf, retrieved 2026-09-16): "BarVision / Category: Inventory Management / Description: Realize more revenue, deliver a more consistent customer experience, and sell more profitable drinks with BarVision. Our wireless liquor pour spouts are just the beginning of a powerful and impactful solution." (printed p.12); "US Beer Saver / Category: Inventory Management / Description: The US BeerSAVER Beer Control System is the #1 draft beer flow metering system in hospitality. Monitor unaccounted pours and over pours by tracking every ounce of draft beer poured by your staff on every tap." (printed p.111); BeerBoard ("complete alcohol management", Inventory Management, printed p.14). All three are staff-pour monitoring / inventory reconciliation, the opposite use case from guest pours charged to a tab, and the analyst's own caveat concedes the pour-to-tab payload is unmet. A partial whose shortfall is the claim's whole core is not a partial. No self-pour vendor (PourMyBeer, iPourIt, Table Tap) appears in the 120-entry table of contents. SOURCE CHECKED: KB article https://support.revelsystems.com/s/article/Revel-Partners (How_To__kav, versionId ka2VV0000001ICbYAM, scm_Description__c re-fetched live via Aura 2026-09-16; whole body: "To view the full list of Revel's partners, view this document.") linking https://revelup-techpubs.s3.us-west-2.amazonaws.com/support/hc/en-us/000002620/Revel+Partners-2.pdf (re-fetched 2026-09-16: HTTP 200, 4,463,744 bytes, Last-Modified 2025-01-17; pdftotext re-run, 122 PDF pages, one partner per page, each giving only Category and Description plus "Visit Partner"; printed page numbers are one less than PDF page numbers). All quoted strings below confirmed verbatim in the re-extracted text; each is a single-page entry, no column interleaving. The directory is Revel-published marketing (a partner list whose Descriptions are the partners' own copy) and documents no integration behaviour. Not scored no: the directory is not a closed census of integrations and the marketing host is unreadable. || 325th: NEW SURFACE, measured, and it still does not settle this cell - recorded so the next pass does not re-fetch it. Revel's anonymous production OpenAPI 3.0 set v2025.3.0 (14/14 suites listed by https://developer.revelsystems.com/, 198 paths; nonsense control 403) contains the POS's CLOSED peripheral enumeration, EnumDeviceTypes on /resources/Device/: '-1 no_printers, 0 kitchen_view, 1 printer, 2 coin_dispenser, 3 display_unit, 4 scale, 5 cardswipe, 6 secondary_cardswipe, 7 barcode, 8 secondary_barcode, 9 rfid_reader, 10 kitchen_flow, 11 forecourt_controller, 12 bumpbar, 13 electronic_payment_system'. There is no flow-meter, tap-wall or pour-spout device class, and the scale class is itself closed to six weighing brands (EnumScaleTypeOptions '0 Avery, 1 CAS, 2 Mettler Toledo, 3 Megellan 8400, 4 Datec, 5 CAS AD'). Tokenised controls over the 14 suites: `self pour` 0/14, `flow meter` 0/14, `tap wall` 0/14, `keg` 0/14, `pour` 0/14 (note `kitchen_flow` is a KDS routing device, not a flow meter - that near-miss is the poison here). WHY THIS IS STILL NOT A no: the claim is that pours post to a tab, and a pour-tracking partner does not need a Device record to do that - orders_suite exposes writable /resources/Order/ and /resources/OrderItem/, so BarVision (pour spouts) and US Beer Saver (draft flow metering), both already in Revel's own partner directory, could post items through the REST API without appearing in any device enum. The absence of a native device class is therefore not positive evidence that no integration posts a pour to a tab. Retrieved 2026-09-17. || 326th: 326th: NEW SURFACE, does not settle it; recorded so it is not re-mined. https://www.shift4.com/marketplace lists 'US BeerSAVER: Eliminate waste and theft with BeerSAVER's automated beer flow meter system, seamlessly tracking every ounce poured in real time' and BarVision ('wireless free-p[our]...'), both under category 'Inventory Management' - i.e. the SAME loss-control framing the 324th already rejected, with no pour-to-tab statement. And the directory is scoped to Shift4 Dine (its lede says so, and `revel` appears 0 times in its 109,728 chars), so it is a sibling product's catalogue and cannot carry a verdict for Revel either way. Tokenised over the 825-slug shift4.com body census plus the 7 Revel legal PDFs (832 documents): `self-pour` 0/832, `pourmybeer` 0/832, `flow meter` 2 hits in 1 file (the US BeerSAVER entry above). Retrieved 2026-09-18. || 329th: 329th: the last open retrieval lead on this cell is now CLOSED as unusable, measured - record it so nobody hunts it again. Three notes (including this one) say the Integration Partners page 'lives on the dead marketing host' and the 325th hold recorded revelsystems.com as answering a Vercel challenge and therefore unread. Measured today with curl + browser UA + Sec-Fetch-* + Upgrade-Insecure-Requests: www.revelsystems.com and revelsystems.com are a WILDCARD 302 to https://www.shift4.com/food-beverage - /, /robots.txt and /sitemap.xml ALL return the identical 162,848-byte Shift4 'Restaurant Solutions' Next.js page (36,697 bytes on the wire, same byte length for all four probes), so the host serves no content of its own and no Revel integrations directory survives anywhere. That is the soft-200 catch-all shape, not a readable page. Also new: Revel's complete App Store publisher census (developer id 477934007, 13 apps) contains no beverage-control or tap-wall app, and its 7 full-resolution Revel POS iPad screenshots (mzstatic /1000x0w.png, read as images) show the order, checkout/tip and dashboard screens with no peripheral or beverage-hardware configuration list. 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
First-party Caller ID with dedicated hardware: a Basic analog unit ('Whozz Calling? POS', available through Revel), a Deluxe analog unit, and Vertex VOIP Caller ID for SIP lines; 'Whozz Calling ID for Revel POS' also appears in the Active Supported Hardware catalogue (Ethernet). On an incoming call, 'tap the green New Order button. If the number belongs to a customer in your system, the new order will be automatically attached to that customer. If it's a new number, Caller ID will convert it to a new customer account', with per-station enablement under Establishment > Stations, hold/recall of calls, and a month-long call log on the POS. https://support.revelsystems.com/s/article/Caller-ID-1582898972497 · retrieved 2026-08-04
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
developer.revelsystems.com serves a public Swagger UI listing 14 OAS 3.0 suite specs (v2025.3.0: orders, weborders, products, customers, employees, scheduling, inventory, purchase orders, cash management, house accounts, discounts, tables, taxes, general), readable with no login, NDA or sales call. CORRECTION on re-check 2026-08-10: the guides and changelog the dossier previously credited are gone with the ReadMe tree. An API changelog topic still exists on the support site, so the claim -- which asks only for readable public reference docs -- is met more narrowly than before but is still met. https://developer.revelsystems.com/ · retrieved 2026-08-10
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
Read the pre-Shift4 Zendesk help-centre FAQ 'Does Revel have an open API?' (support.revelsystems.com/hc/en-us/articles/203244339, Wayback capture 2015-02-25, raw HTML checked) and the archived revelsystems.com marketing pages on the API; none of these had been cited by the record, which holds only the current 693-article Salesforce help centre and developer.revelsystems.com (whose FAQ, read 2026-08-05, states no commercial terms). The FAQ enumerates API access closed-form: 'There are different levels of API access which have corresponding price differences, revenue sharing and API call limitations... These levels are: Free, Silver Partner, Gold Partner, Platinum Partner.' Free is 'Intended for API evaluation and solutions development', 'Limited to 25 API calls daily', 'Only for existing clients'; Silver Partner allows '100 API calls daily' with no price printed; unlimited calls begin at Gold Partner, '$2,500 initial fee and $250/month ongoing or revenue sharing of at least $5,000 a month'; Platinum requires 'Revenue Sharing of at least $15,000 a month'. Revel's own marketing page of the same month (https://web.archive.org/web/20150315131651/https://revelsystems.com/ipad-pos/api) headlines 'Open API at no extra cost' - 'Current clients can access Revel Systems API at no cost.' - and the 2021-07-21 /features/open-api/ and 2022-06-24 /products/open-api/ captures say 'With unlimited integrations for one flat price, your ROI grows exponentially.' PARTIAL, not yes or no: a merchant's own API access is included at no extra cost (marketing, corroborated by the FAQ's no-fee client level), so the claim is not simply false; but the vendor's own FAQ caps that included level at 25 calls a day for evaluation and puts unlimited, production-volume access behind a partner tier with an upfront and monthly fee or revenue share, which is the upgraded-plan/fee requirement the claim excludes. The 'one flat price' wording does not say the price is the base subscription. Supporting: the 2019 Version 2.31 release notes (https://web.archive.org/web/20190721212018/https://support.revelsystems.com/hc/en-us/articles/115005136963-Version-2-31) meter 'API Developer Support' minutes, and 'the client will be charged and billed for the extra time' beyond the allocation - support billing, not access billing. DATE CAVEAT: the tier list and no-cost headline are 2015 captures, eleven years old; the flat-price line is 2021-2022; the 2024 /why-revel/open-api-integrations/ capture lists 'Pricing and business model transparency' among RTN principles Revel says it adheres to but prints no price. Revel's API commercial terms may have changed, particularly after Shift4 acquired Revel in 2024. https://web.archive.org/web/20150225065145/http://support.revelsystems.com:80/hc/en-us/articles/203244339-Does-Revel-have-an-open-API- · retrieved 2026-09-13 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
developer.revelsystems.com's FAQ states: 'If you have signed up as an API partner with Revel Systems, you will be provided a testing instance with a login and password.' Shortfall: the testing instance is issued only after signing up as an API partner (credentials are partner-issued by email, not self-serve), the docs do not state whether partnership or the instance is free, and seeded data is not mentioned. CITATION QUARANTINED 2026-08-10: https://developer.revelsystems.com/revelsystems/docs/frequently-asked-questions is DELETED (404, S3 NoSuchKey) and NO REPLACEMENT WAS LOCATED. The verdict and its reasoning are KEPT -- the page was read and quoted on the date recorded -- but the URL is moved to dead_url and stamped do-not-refetch, because a live URL is an instruction to future tooling. https://developer.revelsystems.com/revelsystems/docs/frequently-asked-questions · retrieved 2026-08-05 · not refetchable · page gone · graded A when read
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
Verified verbatim: 'The same Client ID and Client secret will be used for all merchants', and 'The Client-Id is the merchant's Revel URL without .revelup.com'. Correct and appropriately harsh. The docs describe partner-credential recovery by automated email and no operator-granted, individually revocable scopes. CITATION QUARANTINED 2026-08-10: https://developer.revelsystems.com/revelsystems/docs/api-platform-authentication is DELETED (404, S3 NoSuchKey) and NO REPLACEMENT WAS LOCATED. The verdict and its reasoning are KEPT -- the page was read and quoted on the date recorded -- but the URL is moved to dead_url and stamped do-not-refetch, because a live URL is an instruction to future tooling. https://developer.revelsystems.com/revelsystems/docs/api-platform-authentication · retrieved 2026-08-01 · not refetchable · page gone · graded B when read adversarially verified
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
DOWNGRADED yes -> partial on 2026-08-10. The claim asks for real-time pushes across the ORDER LIFECYCLE (created, modified, paid, voided, refunded). The vendor's live webhook request form enumerates six selectable event types -- In/Out Stock, Menu Updated, Order Finalized, Customer Created, Customer Updated, RewardCard Created -- of which exactly one, Order Finalized, is an order-lifecycle event. Webhooks are real and pushed, so the mechanism conjunct is met; lifecycle coverage is not. The dossier's "nine push event types including timesheet entries" came from the withdrawn developer docs and cannot be re-verified. Caveat recorded honestly: this form is a REQUEST form and its event list may not be an exhaustive enumeration of what the platform supports -- it is, however, the only enumeration the vendor currently publishes. https://support.revelsystems.com/s/webhook-access · retrieved 2026-08-10
Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator
extensibility-webhook-reliability
Verified verbatim against the vendor docs: retry delays '1st: 60sec; 2nd: 300sec; 3rd: 900sec; 4th: 900sec'; HMAC-SHA1 X-Revel-Signature plus X-Revel-Instance / Event-Type / Event-Id / Message-Id headers; message log at GET https://api.revelsystems.com/external/message-log. Nine event codes confirmed. One correction: X-Revel-Establishment-Id is documented as OPTIONAL, so the dossier's per-location scoping claim (repeated in multi-location-org-hierarchy) is slightly overstated. CITATION QUARANTINED 2026-08-10: https://developer.revelsystems.com/revelsystems/docs/webhooks is DELETED (404, S3 NoSuchKey) and NO REPLACEMENT WAS LOCATED. The verdict and its reasoning are KEPT -- the page was read and quoted on the date recorded -- but the URL is moved to dead_url and stamped do-not-refetch, because a live URL is an instruction to future tooling. https://developer.revelsystems.com/revelsystems/docs/webhooks · retrieved 2026-08-01 · not refetchable · page gone · graded B when read 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
Orders is writable (41 GET, 15 each of POST/PATCH/PUT) and weborders adds /specialresources/cart/submit, so a public write API accepts externally originated orders. Whether injected orders fire to KDS/printers as first-class tickets and land in reporting is stated on no live surface, so partial holds. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/orders_suite.yaml · retrieved 2026-08-10
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means when it says the roster is tracked in real time, and it is a CENSUS rather than a floor: every provider integrated with DoorDash appears in it with a tier, so a vendor that is absent altogether is not in the programme at any tier. This vendor appears nowhere in the 64 entries, under any provider id or friendly name — checked mechanically against both fields, with the only near-misses being substring coincidences (Speedline against Lightspeed, vroom_restaurant against Restaurant365) that were read and rejected. SUPERSEDES the 2026 announcement post most of this corpus cited: that post introduces its ten names with the word `include`, which makes it a floor and never a ceiling, and reading it as a ceiling is what produced this cell's prior grade. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11
Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator
extensibility-first-party-delivery-integrations
Direct, middleware-free integrations are documented for two of the three marketplaces: 'Revel now offers direct integration with DoorDash Marketplace, eliminating the need for middleware' ($20/month per establishment Revel subscription, no per-order fees, menu sync via Store Onboarding Webhook) and 'Revel now offers direct integration with Uber Eats, eliminating the need for middleware' (Uber Eats add-on subscription with custom menu/payment/dining option). Shortfall: no Grubhub direct integration is documented anywhere in the complete 693-article help centre, and each direct integration is a paid Revel add-on. https://support.revelsystems.com/s/article/DoorDash-Marketplace · retrieved 2026-08-04
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
Two of the named aggregation middleware platforms list Revel as a supported POS endpoint on their own public integration directories: Otter (tryotter.com/integrations) names Revel among its Point of Sale integrations, and Checkmate/ItsaCheckmate (itsacheckmate.com/integrations) lists Revel among its Point of Sale partners. Both checked 2026-08-05. Revel's own Uber Eats article also references merchants 'previously integrated to Uber Eats through a middleware provider', confirming middleware paths exist. https://www.itsacheckmate.com/integrations · retrieved 2026-08-05
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
QuickBooks Online is a genuine native, vendor-maintained connector pushing mapped journal entries, not a CSV drop. Revel documents selectable modules - Sales (required), Payment Reconciliation, Payroll, Inventory, Payout, Location Tracking, and sales granularity as Summary, Summary by Product Classes or Summary by Product - and a mapping screen reached via 'Integration on Revel URL and Select Advanced View Mode' with Revel accounts on the left and QBO accounts on the right. The mapping is deliberately constrained: 'The integration is designed to only allow customers to change accounts to those that make accounting sense and no others', and a companion article enumerates the required QBO account types and subtypes (Income / Sales Of Product Income, Cost of Goods Sold / Supplies Materials-COGS, Other Current Asset / Inventory, Accounts payable (A/P), Discounts/Refunds Given). Named shortfall: the claim requires QBO plus at least one OTHER native vendor-maintained GL connector, and I could not find one. Xero - the second system the original record named - is delivered by Amaka, a third-party middleware vendor whose own site markets the Revel-to-Xero sync, not by Revel. 'Summary by Product' additionally 'will break integration if there are more then 999 products (active and inactive) in Revel'. https://support.revelsystems.com/s/article/QBO-Mapping-and-Modules-1583148058187 · retrieved 2026-08-02 adversarially verified
Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.
extensibility-payroll-export
A native ADP export is documented: enable 'Enable ADP Report' under Time Sheet Rules with an ADP Company Code, choose Workforce Now or Total Force format, map each employee's ADP number to the External ID field, then export CSV (ADP) or XLSX (ADP) from Schedules > Payroll. Shortfall: ADP is the only named payroll provider in the complete 693-article help centre — searches for Gusto, Paychex, Paylocity, and 'payroll provider' return nothing — so the claim's two-named-provider threshold is not met; other providers get only generic CSV/XLSX payroll exports. https://support.revelsystems.com/s/article/How-to-Export-Employee-Hours-to-ADP-1583150213536 · retrieved 2026-08-04
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
Archived US revelsystems.com marketing site (Wayback). Grade C: vendor marketing pages, not documentation. Revel ran a public, browsable directory of named third-party apps for years. The 2015 'Revel Marketplace' (https://web.archive.org/web/20150317150903/https://revelsystems.com/marketplace/page/2) sorted named apps into 13 categories: QuickBooks, USAePay, FreedomPay, Shopify, Magento, Open Dining, Zuppler, Avero, Ctuit, DigitalPour, Xero and DAVOTAX among them. It said 'Through the Revel POS Marketplace, you can connect with a multitude of third party add-on application services to expand your Point of Sale capabilities' (non-breaking spaces normalised). The 2016 'Become a Partner' page (https://web.archive.org/web/20160326022101/http://revelsystems.com:80/become-a-revel-partner/) said 'Once you are integrated and approved by Revel your solution will be available on Revel's Developer Marketplace for all Revel clients.' The cited 2020-04-20 capture of /partners/online-mobile-ordering/ still lists named third parties: atwareTech, Cuboh, Waitrr, RSVT, Chowly, Incentivio, ItsaCheckmate, Mobi2Go, LevelUp, Pepper, Open Dining, Bar Pass, Olo and Zuppler. A 2022-06-28 capture of /partners/drive-thru/ lists Delphi Display Systems, and /partners/kitchen-management/ lists QSR Automations. The newest capture, 2024-04-20 /why-revel/open-api-integrations/ (https://web.archive.org/web/20240420201840/https://revelsystems.com/why-revel/open-api-integrations/?hss_channel=lcp-2855734), keeps a 15-category 'Partner Solutions' list with a 'View Partners' link. SHORTFALL, the self-install conjunct: no capture says an operator can install or enable a listed app themselves. Every page routes through Revel. The 2024 page says 'Connect with a Revel product expert today to inquire about specific integrations', and its RTN open-API principles list marks 'Self-service sign-up for API partners*' as '*Not yet available at Revel, but on the roadmap for development' (that is partner onboarding, not merchant install, but it points the same way). The complete help-centre mirror likewise documents each integration as enabled through Revel support. So the directory is established and self-install is not. A listing also never establishes a native capability. DATE CAVEAT: captures run 2015-2024; revelsystems.com now 301s to shift4.com (Shift4 acquired Revel in 2024), and no post-acquisition capture shows whether the directory survives. POISON: 'marketplace' appears in 420 files, but 276 hits are the 2013-2016 site-nav label 'Revel Marketplace'. Many others are the generic 'competitive marketplace' sense or DoorDash/Grubhub marketplaces. 'partner' also matches Revel's reseller, channel and referral-partner programs (/partnerships/certified-resellers/, /partnerships/channel-partners/), which are sales channels, not apps. VERIFICATION (278th): quotes re-read byte-for-byte in the 2020 /partners/online-mobile-ordering/ capture and the 2024 /why-revel/open-api-integrations/ capture ("Connect with a Revel product expert today to inquire about specific integrations"; "Self-service sign-up for API partners*" / "*Not yet available at Revel, but on the roadmap for development"). Scored consistently with the 22 peers holding partial where a public named-partner directory exists but installation is vendor-mediated (e.g. agilysys, par-brink, chownow, speedline). https://web.archive.org/web/20200420042219/https://revelsystems.com/partners/online-mobile-ordering/ · retrieved 2026-09-13 adversarially verified
The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.
extensibility-headless-embedded
The WebOrders API is documented as the path for external ordering UIs to drive orders into Revel: 'The third party will submit the order to Revel with the price set within their platform. Revel will then accept this price as the product price for that particular order' (WebOrders API Price Override), with a companion WebOrders API Tax Exemption article; the Uber Eats and DoorDash direct integrations run over the same mechanism. Shortfall: this covers order injection by third-party ordering platforms only — no documented full headless mode where a third-party kiosk/drive-thru UI drives the transaction engine including payments, and price override must be enabled by Revel Support account-wide. https://support.revelsystems.com/s/article/WebOrders-API-Price-Override · retrieved 2026-08-04
A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator
extensibility-data-portability-exit
Self-service export is documented: 'Revel provides clients the ability to export any of the 35+ reports available on the Revel Management Console' in six formats (PDF, CSV, Excel, Short, JSON, XML/XLS), and separate tools export customers (Customer CRM Import/Export), products/modifiers (Excel import/export), and order history. Shortfall: exports are one report at a time, capped at a one-year date range per pull (with documented timeouts pushing large accounts to 3-6 month chunks), and no article documents a complete historical bulk export or any contract-end export process. https://support.revelsystems.com/s/article/Exporting-Sales-Data · retrieved 2026-08-04
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
Revel documents Offline Mode (Always On Mode) as processing transactions through three distinct failure classes: loss of the ISP connection ('Revel runs on a Local Network powered by your ISP'), loss of the management console server ('POS data can't reach the cloud during a server outage'), and loss of the payment gateway/processor. Configurable guardrails are documented in the Management Console - 'Enable offline credit card payments', 'Show warning message before approve offline payment', 'Max amount for single offline payment', 'Max total amount for all unprocessed offline payments', 'Max threshold of total amount for all outstanding declined payments', plus 'Notify if station is offline' with a 5/10/15 minute POS offline interval and Offline Tills Management. Shortfalls: (1) the claim covers ticket routing and check printing during an outage, and neither is separately documented in the offline article - only transaction and payment processing is; (2) 'Offline mode is not available for all payment integrations' per the Payments Overview; (3) on applications older than 2.79 with TriPOS, the POS 'must be physically forced into offline mode by unplugging the ethernet cable', and 'offline mode will not trigger during a partial ISP outage if DNS servers are reachable' - a manual 'Enforce Offline Payments' toggle only arrived at 2.79. https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418 · retrieved 2026-08-02 adversarially verified
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
Re-homed onto the live Salesforce URL. Cards are captured while the POS has no path to the gateway and forwarded afterwards, not merely refused: 'Enable offline credit card payments' is a Management Console setting, the Adyen section describes 'Store-and-forward payments: the payment terminal approves payments without any verification', and the manual-batching article defines the resulting state as 'Offline (Not Captured in Offline Mode): Customers' payment transaction data has been authorized but was not yet validated by the system... ready for an attempt to be captured once the system is back to online mode', with a Force control on the POS Offline Payments tab. The outage article independently lists 'Process CC / Debit Payments in offline mode' as available during an ISP or gateway outage. Named limits rather than a vague caveat: 'Debit payments can't be accepted in Offline Mode' (Apple Pay does work); offline mode is not available for all payment integrations; TriPOS and FreedomPay iFCC cannot toggle it and must be forced physically; Adyen needs Capture on Swipe and vendor enablement. https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418 · retrieved 2026-08-09 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
Re-homed and re-argued. Who bears the loss is published without euphemism: 'Forcing offline payments is performed at the Merchant's risk. As with any payment taken offline, there is a risk of authorization failure based on card status and available funds which can only be determined once reprocessed when online', with the consequences enumerated as the merchant's - chargebacks ('Your chances of winning are meager if your customer disputes the new authorization... This may result in additional chargeback fees on top of the lost transaction'), credit card fraud, higher processing fees per re-authorization attempt, and PCI DSS exposure. The manual-batching article adds 'Merchants are responsible for their transaction monitoring' and warns that capturing transactions over 30 days old 'carries a high probability of a chargeback. Merchants get fined by fixed rates for each chargeback.' Caps are stated, and there are three: 'Max amount for single offline payment', 'Max total amount for all unprocessed offline payments' and 'Max threshold of total amount for all outstanding declined payments'. Remaining limit: this is operational disclosure, not contractual - no merchant-agreement liability or chargeback-protection language is publicly reachable, and FreedomPay iFCC's automatic daily replay for up to 10 days is the only recovery mechanism documented. https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418 · retrieved 2026-08-09 adversarially verified
Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator
reliability-lan-degraded-multi-terminal
Station syncing is documented as local: 'Synced Point of Sale systems share order data in real time through a Main Syncing Station' over the local network using shared network keys, 'so that an order placed on one station can be accessed on another'; and the outage best-practices article documents that during an ISP/network outage stations can still 'Create and close orders', operate tills and 'Print to kitchen and receipt printers'. Named shortfall: no article explicitly states that cross-station check/table sharing keeps working while the internet is down - LAN syncing and offline operation are documented separately, never jointly. https://support.revelsystems.com/s/article/Syncing-and-Non-Syncing-Stations-1582903575834 · retrieved 2026-08-04
The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator
reliability-local-transaction-engine
The ordering path is documented as local rather than cloud request/response: during a full Revel server outage the POS can still 'Create and close orders', 'Operate tills and take cash payments', 'Take credit card payments', 'Print to kitchen and receipt printers (ethernet or BT connected)' and 'Use CDS & KDS'; the Offline Mode article states 'Revel runs on a Local Network powered by your ISP'; and the Syncing and Non-Syncing Stations article documents an on-premise Main Syncing Station (any designated POS station) through which stations 'share order data in real time' and handle credit-card batch processing. https://support.revelsystems.com/s/article/outage · retrieved 2026-08-04
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
The outage best-practices article states that during a Revel server outage you can still 'Print to kitchen and receipt printers (ethernet or BT connected)' and 'Use CDS & KDS', and during an ISP/network outage you can still 'Create and close orders' and 'Print to kitchen and receipt printers (ethernet or BT connected)' - kitchen ticket routing and KDS operation continue offline. https://support.revelsystems.com/s/article/outage · retrieved 2026-08-04
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
Auto Redirect (POS 2.70.13+) 'allows temporary and automatically redirect a receipt from non-working or busy printer': an ordered list of fallback printers is retried in a loop three times, and 'if printing fails on all Auto Redirect printers a standard error is displayed'. Named shortfalls: 'Auto Redirect is available for Epson ePOS LAN printers only' and only between matching printer models and types (m30 fails over to m30, U-220 to U-220); configuration is per-POS and 'not shared between POS'; failover to a KDS station is not supported; and staff are alerted only after every redirect printer has failed. https://support.revelsystems.com/s/article/Printing-Failover · retrieved 2026-08-04
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
CLAIM: the vendor DOCUMENTS its conflict-resolution behaviour for edits made on two devices during a network partition (last-write-wins, merge, or operator prompt). Because the claim is about the existence of documentation, a bounded census of the vendor's documentation settles it directly. VERDICT: no. BOUND: 100% of the publisher's own manifest - support.revelsystems.com's Salesforce guest knowledge API (https://support.revelsystems.com/services/data/v59.0/support/knowledgeArticles?pageSize=100), 7 pages, 698 articles, all bodies held; 121 of 121 already-cited article URLs from this record are inside it. EVIDENCE: Revel documents the multi-station architecture in detail and stops short of conflict semantics. 'Syncing and Non-Syncing Stations' (https://support.revelsystems.com/s/article/Syncing-and-Non-Syncing-Stations-1582903575834, modified 2024-04-11): 'Synced Point of Sale systems share order data in real time through a Main Syncing Station so that an order placed on one station can be accessed on another'; 'For each network key there should be only one Main Syncing Station. Two main syncing stations with the same network key can cause problems with syncing payment data'; 'Non-Syncing Stations do not share order information in real time, so an order placed on one station will not be accessible on any other station.' The consequence of two writers is named as 'problems', with no resolution rule. 'Offline Mode' (https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418, modified 2024-05-31) is the vendor's fullest partition document and covers only payment risk and thresholds (Max amount for single offline payment, Max total for all unprocessed offline payments, Offline Tills Management), never simultaneous edits. CONTROLS over all 698 bodies, tokenised case-insensitive: /\bconflict\s+resolution|\blast.write/ 0/698; /\bconflict\b/ 2/698 and both are POISON - QuickBooks Online account-mapping conflicts ('Employees: QBO', 'QBO Mapping: Account Types'), nothing about device partitions. Grade B. Retrieved 2026-09-17. https://support.revelsystems.com/s/article/Syncing-and-Non-Syncing-Stations-1582903575834 · retrieved 2026-09-17 adversarially verified
The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).
reliability-offline-feature-matrix
The article previously cited no longer exists in the migrated help centre; this replaces it with a stronger source. Revel's outage best-practices article is a genuine matrix, structured per outage type (Revel Server, ISP/Network, Payment Processor/Gateway, Loyalty/Gift Card, Revel Guard XT, Delivery XT, Auth0, Power) into three explicit tiers: works, 'still be able to access... but they will be limited', and 'will NOT be able to access the following functions'. The unavailable list during an ISP/network outage names the items this claim asks about: 'Use Loyalty/rewards/gift cards', 'Take manual credit card or Debit payments', 'Receive Online Orders on the POS', 'Complete EOD', 'Use House Accounts', 'View customers past orders', 'Utilize inventory management on the frontend'. The Loyalty/Gift Card section goes further and enumerates 'Sell / activate new gift cards; Process gift card payments; Look up gift card balances; Look up reward balances; Accrue loyalty points; Create new loyalty account; Redeem rewards'. The Offline Mode article supplies the payment-side detail ('Debit payments can't be accepted in Offline Mode', 'Apple Pay works in Offline Mode'). Two items in the claim's parenthetical are not addressed anywhere: refunds and text-to-pay. https://support.revelsystems.com/s/article/outage · retrieved 2026-08-09 adversarially verified
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
Verified, but the dossier's component list is incomplete in a way that cost it findings. Actual components also include Delivery XT, Driver XT, Revel Guard XT, Revel Data Connector, Loyalty XT, Como, Punchh, Loyalty Plant, Session M, Valutec, SVS, Synergy, Eigen, QSR Automations and User Authentication (Auth0). Loyalty XT (a Revel-branded, Como-powered in-house loyalty product) and Revel Data Connector (a reporting/warehouse feed) are first-party products the dossier never discovered and which likely lift several guest-loyalty and reporting-raw-warehouse-export cells off unknown. No uptime per https://status.revelsystems.com/ · retrieved 2026-08-01 adversarially verified
24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.
reliability-247-live-support
The Revel Resource Snapshot lists Technical Support by phone (+1 415.744.1433, Ext. 1, Option 1) and email with 'Hours of operation: 24/7', with no premium-tier qualifier; the 24/7 designation is deliberate, since the same page gives restricted weekday hours for billing (7am-6pm PT M-F), operations (5am-5pm PT M-F) and payments support. The Offline Mode article likewise refers to 'our 24/7 technical support'. https://support.revelsystems.com/s/article/Resources-and-Contacts · retrieved 2026-08-04
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
The onboarding Welcome Checklist states: 'We offer full Management Console Training with either a Remote Installation or Full Onsite Installation depending on the Size and Amount of Equipment being Installed', coordinated through Revel Navigators with a scheduled Welcome Call to 'discuss the full roll out of your New Revel Platform' - first-party onsite installation is offered, with allocation depending on deployment size. https://support.revelsystems.com/s/article/Welcome-Checklist · retrieved 2026-08-04
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
A warranty exchange program with stated turnarounds is included: once support confirms an item is 'defective and within warranty, we'll send the exchange documents within two (2) business days'; orders 'new or exchange' are 'shipped within five (5) business days'; and RMA credits issue 'approximately 5-10 business days after receipt and assessment of the item'. Revel covers the first year of each manufacturer's warranty per the published Hardware Manufacturer Warranty table. https://support.revelsystems.com/s/article/Operations-FAQ · retrieved 2026-08-04
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
First-party compliance statement only: 'Yes, Revel Systems is fully PCI DSS compliant and can provide an attestation of compliance (AOC) upon request' (via a customer success manager or risk-payments@revelsystems.com). Named shortfalls: the AoC itself is not published, only supplied on request; Revel states no DSS version anywhere for its own attestation, so v4.0/4.0.1 currency and post-March-2025 future-dated requirement coverage are unevidenced; and no validated P2PE listing is claimed - the only P2PE mentions in the 693-article help centre are gateway/terminal setup pages for FreedomPay and the iPP350, not a Revel listing. CORRECTED 2026-08-06: the previous note inferred that Revel is on PCI v4.0 from the title of the SaferPayments guide 'Merchant Profile Questionnaire guide for RA XT PCI v4.0 June 2024'. That document is scoped to the Revel Advantage XT MERCHANT compliance programme - it walks a merchant through choosing an SAQ type - and says nothing about the version of Revel's own attestation. Same product-scope error as the RA XT terminal list this audit already refuted. https://support.revelsystems.com/s/article/Revel-Advantage-FAQ-for-Merchant-PCI-Compliance · retrieved 2026-08-06
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Role-based permissions are documented in depth: POS Roles with a rank hierarchy (1-999; 'A POS role with a lower rank cannot view or edit roles of higher rank'), a full permission matrix under Employees > Role Permissions (Owner Access, Manager Access, Batch Process, Offline Payments, Point of Sale Settings, etc.) and separate Administrator Permission Sets for the Management Console. Named shortfall: MFA is documented as required only on the Revel Advantage Payment Portal - 'Starting March 18, 2024, Multi-Factor Authentication setup will be available for enablement and will be a required measure moving forward', via SMS or authenticator app (https://support.revelsystems.com/s/article/Revel-Advantage-Portal-User-Logins) - and no article documents enforceable MFA on Management Console or POS administrative logins (the Management Console runs on Auth0, but its MFA is undocumented). https://support.revelsystems.com/s/article/Employees-Roles-and-Permissions-Guide-1583149941746 · retrieved 2026-08-04
A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.
reliability-self-serve-training
Revel University (reveluniversity.revelsystems.com) is a live, publicly reachable structured training library with per-feature courses, alongside the login-free help site. https://reveluniversity.revelsystems.com/s/advanced-features/kds · retrieved 2026-08-01 adversarially verified
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
'You can designate any Point of Sale station as the main station' - so any terminal can hold the master (Main Syncing Station) role - but assumption of the role is not automatic: setup goes through a Revel agent ('To set up syncing stations, contact your Revel agent'), each network key must have exactly one main station ('Two main syncing stations with the same network key can cause problems with syncing payment data'), and no article documents automatic failover of the main-station role when the designated station fails. https://support.revelsystems.com/s/article/Syncing-and-Non-Syncing-Stations-1582903575834 · retrieved 2026-08-04
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
Upheld, and it does not fall with the handheld row. The claim is automatic cellular failover for connectivity, first-party or documented, which is a network-appliance function, and Networking is one of the seven categories this catalogue actually enumerates. The catalogue states "Here you can find all the active and supported hardware by Revel Systems." and its Networking section is four Cisco Meraki devices, the MX64 security appliance, the MR36 and MR78 access points and the Z4 router. No cellular modem, LTE gateway or failover appliance is offered. A second, independent and affirmative leg confirms it: Revel's outage playbook prescribes what to do when the WAN drops, and the prescription is manual degradation, not failover, enabling offline mode for card payments plus printing reports from local data. A vendor that answers the ISP-outage question in writing and does not answer it with failover is making a positive statement, not a silence. Counterweight stated rather than hidden: Cisco documents the MX64 accepting an approved 3G/4G USB card for failover, so the capability is latent in a device Revel resells; Revel neither supplies, provisions nor documents it. https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-08-04 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
Upheld under the 207th ruling, with condition 2 rewritten because its literal form would have been false. The claim is about what the vendor PUBLICLY OFFERS, which is measurable from published pages. Revel's pricing page shows one software price, "$99/monthly fee" per terminal, and conditions it in a footnote, "This rate is available to clients billed annually who include a 3-year Revel Advantage contract." together with "Minimum purchase of two terminals required." No published Revel page offers a month-to-month tier, and the separately published Revel Care programme terms run a thirty-six month initial enrolment. This is an affirmative-presence finding, a multi-year term requirement that EXISTS in the text, not an absence. Evidence discipline, all four conditions addressed: the url is the capture, not the live page; the capture is dated 2023-05-28; I queried the Wayback CDX index on 2026-09-05 and this is the LAST capture returning 200, with the next, 2024-07-15, returning 301, so no later revision exists in the archive and the honest statement is that the page was withdrawn rather than revised, and whether a post-acquisition successor exists is unknown and was not read; the language is quoted and no section number carries any weight; and no reading of a current revision exists in the record to re-home onto. Weight, stated plainly: this predates the June 2024 Shift4 acquisition by thirteen months, the footnote's own wording implies other unpublished contract structures at higher prices, and the master Customer Agreement is a PDF with zero captures, so this is graded C and should not be read as a statement about what Shift4 sells today. https://web.archive.org/web/20230528073202/https://revelsystems.com/pricing/ · retrieved 2026-09-05 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
Value upheld, grade downgraded from B to C, evidence discipline rewritten. The claim asks whether published terms STATE that there is no early termination fee. No published Revel document does, and one published Revel document affirmatively imposes the opposite. The Revel Care Program Additional Terms set an initial enrolment of "thirty-six (36) months" and provide that if the customer cancels during it, or if "the Agreement is otherwise terminated during the Initial Enrollment Period", the customer shall pay "as liquidated damages, and not as a penalty, the balance of all Revel Care Program monthly fees which would otherwise have been payable", in addition to and not in lieu of Revel's other legal rights. The second trigger is the load-bearing one: terminating the software agreement early itself fires the liquidated-damages clause. The published legal family was surveyed via the Wayback index of revelsystems.com, namely apiterms, payment-terms, hardwaresaleterms, supportservicesterms, revel-care-terms, both customer-agreement landing pages and the 2016 Terms of Service, and none contains a no-ETF statement. Evidence discipline: this is a capture dated 2024-04-24; per the CDX index queried 2026-09-05 it is the last capture of that page returning 200, so it is the terminal archived revision rather than a known-superseded one, the live URL now redirects to shift4.com, and whether a post-acquisition successor exists is unknown and was not read. Caveats: the master Customer Agreement is a linked PDF with zero captures, so the software subscription's own termination clause was never read, and the capture predates the June 2024 Shift4 acquisition by about two months. https://web.archive.org/web/20240424081106/https://revelsystems.com/revel-care-terms/ · retrieved 2026-09-05 adversarially verified
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
Revel Systems, Inc. publishes its Customer Agreement (Online SMB edition, file revision v.6.2 with the 8.12.2024 CPI markup to s.4.3; page footers read 'Confidential v.6.1'). shift4.com/revel-legal links it as 'Revel Customer Agreement - Download PDF', in both the 20250327040026 capture and the newest (cs-CZ, 2026-06-11) capture. The live shift4.com host answers a 429 Vercel Security Checkpoint, so the PDF was read from Wayback capture 20260116190514. Section 11.1 states both halves of the claim. The term: "Unless otherwise specifically set forth in the Order Form, Revel's standard Order Form term is thirty-six months from the date upon which Revel first bills Customer for monthly Software and/or Revel POS Platform subscription services". The renewal and the notice window: "Thereafter, the Initial Order Form Term will automatically renew for one year every year until such time as a party gives thirty days prior written notice of termination of the applicable Order Form". The published default gives way to a signed Order Form, but it is still publicly stated rather than living only in a signed quote. Context: s.11.3 makes an early-terminating customer pay "the greater of the sum of either: i) six (6) months of monthly recurring revenue; or ii) the total amount of monthly recurring revenue which would have been paid to Revel had Customer fulfilled its financial obligations under the then current Order Form Term" as liquidated damages. The 693-article KB mirror carries no renewal clause, which is why this cell was unknown. Precedent: agilysys, chowly and acrelec are yes/B on published auto-renew-plus-notice clauses. https://www.shift4.com/pdf/Online-SMB-Revel-Customer-Agreement--12.10-revision--7.9.2024-LCT-v.6.2-LCT-CPI-Markup-Sect-4.3-8.12.2024.pdf · retrieved 2026-09-12 adversarially verified
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
Adyen, Worldpay and FreedomPay are monitored as live processor integrations alongside in-house Revel Advantage. https://status.revelsystems.com/ · retrieved 2026-08-01
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
No processing rate of any structure is published; the pricing page no longer exists. https://revelsystems.com/pricing/ · 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
Scored against Revel's published fee-change paper. That is corpus practice for this cell (46 peer scorings; see xenial's 2026-09-05 verdict): where the card-processing terms are not public, the vendor's own fee-change terms are scored and the gap is disclosed. The paper is the Online SMB Revel Customer Agreement (12.10 revision 7/9/2024, with the Section 4.3 CPI markup of 8/12/2024). shift4.com/revel-legal links it as 'Revel Customer Agreement' in both the 20250327040026 capture and the newest capture. It was read from Wayback capture 20260116190514, because live shift4.com answers a 429 Vercel checkpoint. It is already the citation for commercial-autorenew-terms-published and commercial-data-ownership-clause. It reserves uncapped unilateral increases. Section 4.3 Price Increases: 'Revel shall have the right to increase fees for the Service, Software, API/XML, Hardware and Professional Services at any time during the Term of this Agreement upon thirty (30) days advance written notice.' The CPI sentence that follows is not a cap. It opens 'Without limiting any other rights of Revel' and grants an additional right: from the first anniversary, Revel may raise aggregate fees by the greater of CPI-U plus 1% or 4%. The whole agreement can also change unilaterally. Section 12.11: 'From time to time, Revel may modify this Agreement and/or the URL Terms and such modifications will become effective as of the date such modification is made by Revel', and 'continued use of the Service after an updated version of the Agreement or URL Terms goes into effect will constitute Customer's acceptance'. NO PENALTY-FREE EXIT: no clause makes a price increase or a modification a termination or objection trigger. Section 11.2 allows termination only for an uncured material breach after thirty days' notice, or on insolvency. Section 4.1 says 'all payment obligations under any and all Order Forms or SOWs are non-cancelable'. Section 11.3 makes early termination by the Customer cost 'the greater of the sum of either: i) six (6) months of monthly recurring revenue; or ii) the total amount of monthly recurring revenue which would have been paid to Revel had Customer fulfilled its financial obligations under the then current Order Form Term', as liquidated damages. The only non-breach exit is the Section 11.1 thirty-day notice against auto-renewal at the end of an Order Form Term. SCOPE, STATED PLAINLY: the agreement defines 'Service' to exclude processing: '"Service" does not include payment processing or gateway services.' Section 6.1 does touch processing. It says the Customer shall use a gateway and processor 'designated by Revel', subject to 'such terms, conditions and fees as Revel may require', and that 'Revel may bill and collect fees for such services, but Revel in no way provides payment processing or gateway services'. That reserves Revel's discretion over processing terms but does not state the processing rates or a rate-change rule. Those sit in the 'Supplemental Revel Advantage XT Program Terms and Conditions'. The revel-legal index links a 'Revel Advantage XT Payment Terms' PDF (shift4.com/pdf/Revel Systems Inc_.pdf) and a 'Revel Freedompay Terms and Conditions' PDF, but the Wayback CDX returns no capture of either, and the live host refuses us, so neither was read. This no is therefore established for software, API, hardware and services fees and is untested for card-processing rates. It is not superseded by shift4.com/pdf/POS-System-Service-Agreement.pdf, which is a Shift4 Payments, LLC agreement for Harbortouch/Shift4 Dine equipment, not a Revel document, and is not linked from revel-legal. https://www.shift4.com/pdf/Online-SMB-Revel-Customer-Agreement--12.10-revision--7.9.2024-LCT-v.6.2-LCT-CPI-Markup-Sect-4.3-8.12.2024.pdf · retrieved 2026-09-12 adversarially verified
Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).
commercial-pricing-published
Correct, but re-source to the dead first-party pricing page rather than an aggregator profile. https://revelsystems.com/pricing/ · retrieved 2026-08-01 adversarially verified
Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator
commercial-module-unbundling
Modules are separate billing objects: the Billing FAQ's cancellation entry is titled 'How can I cancel my subscription/establishments/add-ons?' - add-ons can be cancelled distinctly from the base subscription (by emailing cancellationnotice@revelsystems.com for a client-relations callback, or via an account manager) - and the Data Access article sells paid data-retention tiers as a distinct purchasable add-on chosen at the legal-entity level. Named shortfalls: cancellation is a manual email/account-manager process rather than self-serve, no a-la-carte module price list is published, and nothing documents whether dropping a module leaves the base POS subscription price unchanged - the no-repricing half of the claim is unverified. https://support.revelsystems.com/s/article/Billing-FAQ · retrieved 2026-08-04
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
Outright purchase is the documented model, but no prices are published. The Payment Device Purchase Policy requires that 'any form of payment should only be performed through a supported and authorized payment device purchased directly from Revel Systems' (purchase, not lease - no hardware rental or multi-year lease requirement appears anywhere in the complete help centre), and 'Can I set up my own card swipe, iPad, or printer?' concedes 'it is possible for a client to source their own hardware' for commodity items (iPads, printers), though Revel recommends buying pre-configured units from Revel. Named shortfall: no published hardware price list exists on any reachable Revel page, so the 'at a published price' half of the claim cannot be met. https://support.revelsystems.com/s/article/Payment-Device-Purchase-Policy · 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
Vendor's own 'Active Supported Hardware' catalogue lists commodity third-party devices throughout: Apple iPad (10th gen), iPad Air (6th gen) and iPad Mini (7th gen) as the POS screens; Epson T88VII, TM-U220, M-M30III, TM-M30II-SL, P60 and TM-L90 Plus plus Star MCP31L receipt/kitchen printers; Zebra ZD411 and Dymo LabelWriter 550 Turbo label printers; CipherLab 2200/2504/2564 scanners; Brecknell 6702U/6720U scales; Cisco Meraki networking. None of these are Revel-proprietary. The named shortfall is confined to payments: the Revel Advantage International FAQ states 'third-party terminals will not work, and only authorized devices that match Adyen encryption can be obtained from Revel', so the card terminal specifically is vendor-supplied. The claim only requires at least one documented non-proprietary option, and the iPad plus Epson/Star ESC/POS printers meet it outright. https://support.revelsystems.com/s/article/Active-Supported-Hardware · retrieved 2026-08-02 adversarially verified
Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.
commercial-data-export-self-serve
The public OAS covers orders and line items, payments and cash management, customers and employees, so a documented export API exists. The claim's "without contacting support or paying a fee" conjunct is unestablished on every live surface -- the authentication page that spoke to it has been withdrawn. Partial holds. https://developer.revelsystems.com/ · retrieved 2026-08-10
Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator
commercial-export-customer-and-loyalty
Customer records are readable and writable, and the vendor's webhook request form offers Customer Created, Customer Updated and RewardCard Created events, so guest records and reward-card activity are both machine-readable. Conjunct check, re-measured 2026-08-10: the claim requires guest records AND loyalty balances AND gift-card liability balances. There is NO gift-card resource, tag or path anywhere in the 14 specs, so the third conjunct is unmet and partial holds. https://oas-prod.s3.amazonaws.com/oas/2025.3.0/customers_suite.yaml · retrieved 2026-08-10
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
Post-termination access exists but has no defined window: the Billing FAQ entry 'I already canceled but need to access my data' instructs former customers to contact the billing team, 'and someone can help you access your data. (Fees may apply.)' - so there is documented access after cancellation rather than immediate cutoff. Named shortfall: no defined number of days is specified anywhere, access is a manual, fee-bearing request rather than a self-serve export window, and the in-term Data Access policy already limits included history to a rolling ~13 months with the advice to 'export your data and store it yourself'. https://support.revelsystems.com/s/article/Billing-FAQ · 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
The Revel Customer Agreement is linked from shift4.com/revel-legal (captures 20250327040026 and 2026-06-11). The live shift4.com host answers a 429 Vercel Security Checkpoint, so the PDF was read from Wayback capture 20260116190514. It meets each conjunct only in part. Ownership: s.5.3 says "As between Revel and Customer, Customer owns the Customer Data". But s.13 defines Customer Data narrowly, as "the electronic data submitted by Customer or Authorized Parties to the Service". Section 5.6 then carves out "access records, date and time stamps, transaction and activity records, and system performance data (\"Usage Data\")" and states "As between Revel and Customer, Revel owns the Usage Data." So the contract does not clearly vest the merchant's transaction records in the merchant. Use constraint: s.5.4 grants Revel a perpetual licence to use Customer Data for commercial purposes, including "marketing" and "industry benchmarking". It is limited by "In any such use of Customer's Data, Revel will ensure that only aggregate information is utilized, and in all cases all Customer Data will be anonymized." Usage Data carries no such limit: s.5.6 lets Revel use it "to, among other things, deliver and manage its products and services, perform maintenance and support, and develop, test, and improve the Service and other Revel products and services". Related terms: s.12.3 lets Revel pass Customer Data to Revel Vendors (Affiliates and subcontractors) for hosting, provision and administrative purposes. Under s.11.4, retrieval after termination is available only on request within thirty days, for "$599 or the Customer's monthly recurring revenue, whichever is greater"; after that Revel may delete. Precedent: gotab yes/B (merchant owns content, use confined to aggregated/anonymized); agilysys partial/B (DPA constrains Personal Data only); cake and clover no/B. Revel sits between them. https://www.shift4.com/pdf/Online-SMB-Revel-Customer-Agreement--12.10-revision--7.9.2024-LCT-v.6.2-LCT-CPI-Markup-Sect-4.3-8.12.2024.pdf · retrieved 2026-09-12 adversarially verified
Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.
commercial-pci-p2pe-tokenization
The encryption half is documented: 'FreedomPay fully protects the merchant environment with validated P2PE (Point-to-Point Encryption)' on the FreedomPay gateway path, and online ordering card storage runs on processor-hosted checkout (Vantiv Hosted Checkout) so the PAN bypasses the merchant environment. Named shortfall: no Revel document names the applicable SAQ or claims scope reduction to SAQ A / SAQ P2PE-HW - the PCI FAQ instead says initial 'business profiling determines which SAQ type must be completed by the merchant' and requires ALL Revel Advantage merchants to pass an ASV vulnerability scan of their cardholder data environment at least every three months, a regime inconsistent with a documented SAQ-A/P2PE-HW scope reduction. https://support.revelsystems.com/s/article/FreedomPay-Setup-1582893044828 · 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
One control is documented, the rest are not: 'Starting March 18, 2024, Multi-Factor Authentication setup will be available for enablement and will be a required measure moving forward in order to enhance the security of your Revel Advantage Payment Portal' (portal.revelup.com), with Text (SMS) or Authenticator App methods (Microsoft/Google/Okta recommended). Named shortfall: MFA is documented only for that payment portal - no MFA is documented for Management Console or POS logins (the POS Authentication article describes no second factor) - the string 'PCI DSS v4'/'4.0.1' never appears anywhere in the help centre, and no payment-page script integrity monitoring per Req 6.4.3/11.6.1 is documented for hosted ordering pages. https://support.revelsystems.com/s/article/Revel-Advantage-Portal-User-Logins · 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
Deletion tooling is real and in-app: the Customer Personal Data Anonymization feature 'searches for and permanently removes all key information about a customer (name, email, address, phone, date of birth, etc.) from the entire system', run per-customer from Management Console > CRM, with documented under-the-hood behavior (fields nulled; email replaced with noreply+anonymous_<ID>@revelup.com; phone zero-padded to ID; duplicates processed; customer photo deleted; POS logout/refresh required to clear local data; online-ordering account credentials reset). Named shortfalls: the feature must first be enabled by Revel Support, 'there is no way to perform this action in bulk at the moment', no dedicated locate-and-export (access request) workflow is documented beyond ordinary CRM/report exports, and no executable DPA is published in the help centre (the CCPA/privacy pages sit on revelsystems.com outside it). https://support.revelsystems.com/s/article/Customer-Anonymization-1583148890445 · retrieved 2026-08-04
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
326th: MOVED to no. The claim is a PUBLICATION claim - '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' - so a census of everything the vendor publishes settles it, and that is what was missing. The 323rd closed the retrieval gap with a URL census and correctly said 'a URL census is not a census of page BODIES'. I have now done the body census. CORPUS (re-derived, not inherited): www.shift4.com is Revel's only marketing host (revelsystems.com 301s there); robots.txt 'User-agent: * / Allow: /'; the sitemap index has exactly one child, sitemap-0.xml, 1,295 <loc>, 825 non-locale, 818 fetched at 200 and 7 hard 404s (test slugs); 36,380,880 chars of body text. Nonsense control /zzz-nope-12345 = 404, 8,433 B. Plus the 7 PDFs enumerated at https://www.shift4.com/revel-legal - the complete published Revel legal set (Customer Agreement, Advantage XT Payment Terms, Freedompay T&C, DPA, Reseller Terms, Support Services, Modern Slavery) - extracted with pdftotext -layout. Plus 698/698 live KB articles (2,592,423 chars). CONTROLS, tokenised, word-boundary, case-insensitive: `vpat` 0/832 documents AND 0/698 KB articles; `accessibility conformance` 0/832; `section 508` 0/832; `wcag` 0/698 KB and 2 hits in exactly 1 of 832 documents - https://www.shift4.com/eigen-accessibility, which is scoped to Eigen, a DIFFERENT Shift4 product, and is a one-paragraph commitment statement, not a VPAT or ACR. `accessib*` fires 181 times across 49 of 832 files and I read the top of that distribution: eigen-accessibility (32), givex-policies (17), and blogs/transit/DCC pages about card-scheme or transport accessibility - none is a conformance report and none names a kiosk. THE POISON TO RECORD: `accessib*` in the KB has exactly 3 hits in 2 articles and both are Apple's iPad 'Guided Access' feature (Enabling-Guided-Access-on-the-iPad, How-to-Clear-iPad-Cache) - an OS setting used for kiosk lockdown, not an accessibility mode. `kiosk` itself fires 184 times in 33 of 832 files, so the matcher is sound and kiosk copy exists; none of it makes an accessibility claim. Revel/Shift4 therefore publishes no VPAT, no ACR, no WCAG conformance level for the Revel kiosk or web ordering, and no non-visual access mode, across every surface they publish. Retrieved 2026-09-18. https://www.shift4.com/revel-legal · retrieved 2026-09-18 adversarially verified
POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator
commercial-dual-pricing-compliant
Surcharging is supported but the compliance automation is not documented: Revel documents surcharge creation (a flat 'Surcharge Percentage' applied to every order, configured per establishment in Management Console Settings) and, for AU/NZ on Adyen, per-card-type surcharge values applied on the terminal with an on-screen guest acceptance prompt, a printed-receipt breakdown into order amount and surcharge amount, and automatic surcharge inclusion in refunds. Named shortfall: no automatic exclusion of debit/prepaid cards is documented anywhere - the US surcharge applies to every order regardless of tender - and the surcharging FAQ makes the debit/prepaid exclusion, the 3% cap and the required point-of-entry disclosures the merchant's responsibility ('it is your responsibility as a business owner to stay current with the latest compliance rules and regulations'). Dual pricing / cash-discount mode is not documented at all. https://support.revelsystems.com/s/article/FAQ-Credit-Card-Surcharging · retrieved 2026-08-04
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 56 values — 38 upheld, 12 downgraded, 6 upgraded. It separately resolved 217 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 |
|---|---|---|
| vs_reference | downgrade-to-no | Factually wrong, and it is the load-bearing premise of the entire dossier. support.revelsystems.com (Revel Systems Help Site, Salesforce Experience Cloud, no login) is live and hosts the full product documentation library — a dedicated 'Pizza Resources' hub, a KDS section, Offline Mode articles, a payments overview, and a maintained Change Log. reveluniversity.revelsystems.com is also live. The 262 unknowns are overwhelmingly a discovery failure (WebFetch returns a 'CSS Error' shell on these JS-rendered pages, so they must be reached via search snippets or the legacy /hc/en-us/ paths), not genuine vendor opacity. The claim that an operator 'cannot verify half-and-half pricing rules, offline degradation behavior, delivery dispatch' is refuted on all three counts below. source |
| pricing.software | upheld | Confirmed: revelsystems.com/pricing/ 301s to shift4.com/food-beverage. Third-party sources widely repeat $99/terminal/month at two terminals with a three-year Revel Advantage commitment and implementation from ~$674, but every instance traces to affiliate roundups or resellers, not a vendor page. Refusing to launder those in was the right call. source |
| pricing.contract_length | upheld | No first-party MSA or terms page is reachable. The commonly repeated three-year Revel Advantage term is third-party only and correctly excluded, though it should be flagged as a strong directional signal rather than a pure blank. source |
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| menu-pricing-fractional-placement | unknown — 'Revel's pizza page now redirects to Shift4 and publishes nothing; half/quarter placement cannot be verified either way.' | resolve-to-yes | Documented natively. Split Modifiers apply modifiers to fractions of a product; Revel documentation states products can be split by halves, thirds and quarters, with split prices displayed as the order develops. The POS flow is documented ('tap First Half or Second Half on the modifier pop-up'), splitting is enabled per modifier class, and a parallel 'Split Modifiers for Online Ordering XT' article covers the digital channel. source |
| menu-pricing-half-and-half-rule | unknown — 'No reachable documentation of a configurable higher-half / average / fractional rule.' | resolve-to-yes | UPGRADE TO PARTIAL ONLY (the schema offers no upgrade-to-partial verdict — do not record this as yes). A configurable pricing rule is documented: 'Charge Full Price for Split Modifiers' makes a topping ring at full price regardless of fractional placement (a $0.50 pepperoni still rings $0.50 on half), with proportional split pricing as the alternative. So fractional-vs-full is operator-configurable. Not yes: I found no documentation of a higher-half or average-of-halves rule, which is the discriminating case for specialty-pizza pricing. source |
| payments-offline-store-and-forward | unknown — "'Always On Mode' is claimed for transaction continuity, but whether card auth is stored-and-forwarded, and under what caps, is not documented." | resolve-to-yes | Explicitly documented, caps included. Revel's Offline Mode / Always On Mode article describes collecting card data offline and forwarding it to the processor on reconnect, gated by an 'Enable offline credit card payments' setting plus two configurable ceilings: 'Max Amount for Offline Payments' (per payment) and 'Total Offline Payments May Not Exceed' (aggregate stored). The docs also state offline mode is not available for all payment integrations — a real limitation the dossier missed entirely. source |
| reliability-offline-card-auth | unknown | resolve-to-yes | One of the flagged conclusion-flipping cells, and it resolves affirmatively on vendor documentation rather than marketing copy: cards are captured offline and batched to the processor on reconnect, with merchant-set per-payment and aggregate caps. Carry the caveat that availability is processor-dependent. source |
| reliability-offline-decline-liability | unknown | resolve-to-yes | UPGRADE TO PARTIAL ONLY (schema lacks that verdict — do not record as yes). Revel documents the risk position in plain language: offline-captured cards 'run the risk of the credit card getting declined once the credit card data has been sent to the processor', and there is a manual-batching article for uncaptured, offline and declined transactions. The docs disclose that the merchant eats the decline, but no contractual liability or chargeback-protection language is publicly reachable. source |
| reliability-offline-feature-matrix | unknown | resolve-to-yes | UPGRADE TO PARTIAL ONLY (schema lacks that verdict). A dedicated Offline Mode / Always On Mode article plus a separate 'Manual Offline Mode on the Point of Sale' article enumerate what continues to work and what degrades (cards captured but not authorized; offline unavailable on some payment integrations). Not a formal per-feature matrix, so partial. source |
| order-capture-offline-order-entry | partial / claimed — sourced to a Software Advice aggregator profile | upgrade-to-yes | Right verdict from the wrong evidence. Replace the aggregator citation with vendor documentation: Revel documents Offline Mode/Always On Mode as processing sales and payments while the POS has lost connection to the Revel network. source |
| hardware-offline-mode | partial / claimed — "'Always On Mode' claimed for outage continuity; no published list of which functions degrade" | upgrade-to-yes | The published list the researcher said does not exist does exist — see the Offline Mode article and the manual-offline-mode article. Vendor-documented, not claim-level. source |
| hardware-kds | partial / claimed — sourced to SourceForge; 'bump-bar input, station routing and course timing unverified' | upgrade-to-yes | First-party KDS with an entire documentation section: product-to-KDS assignment (station routing), bump-bar layout configuration, and Kitchen Flow/Bump where items advance display-to-display and must be Completed on all bumping kitchen views before reaching Expo. Aggregator sourcing was unnecessary. source |
| kitchen-station-routing | unknown | resolve-to-yes | Documented: products are assigned to specific kitchen printers / kitchen display units, and Kitchen Flow defines which displays an item traverses. source |
| kitchen-expo-consolidation | unknown | resolve-to-yes | Expo is a documented first-class role: items must be Completed on all bumping kitchen views before moving to the Expo(s). source |
| kitchen-bump-bar-hardware | unknown | resolve-to-yes | UPGRADE TO PARTIAL ONLY (schema lacks that verdict). Bump-bar layout configuration is documented inside the KDS section, but I found no supported-hardware model list, so partial rather than yes. source |
| delivery-dispatch-board | unknown | resolve-to-yes | Revel ships Delivery XT: a Dispatch iPad app (Manager/Dispatcher role only) giving a single dashboard to assign orders, estimate delivery times and track drivers, plus a Driver Agent app on iOS and Android. Published by 'Revel Systems INC' on the App Store, last updated 2025-08-25, and both 'Delivery XT' and 'Driver XT' are live monitored components on status.revelsystems.com as of 2026-08-01. Material caveat the dossier could not flag because it missed the product entirely: Delivery XT is a separate add-on module and is powered by Captain AI, so it is white-labelled rather than wholly in-house. source |
| delivery-driver-roster | unknown — "'Delivery Management' appears in an aggregator feature list; no driver-entity, clock-state or run-history documentation reachable." | resolve-to-yes | A Driver employee role exists and gates access to the Delivery XT Agent app; Manager/Dispatcher is a distinct role gating the Dispatch app. Driver is a first-class entity, not a workaround. source |
| delivery-driver-tracking | unknown | resolve-to-yes | Live driver tracking is the headline documented function — 'Watch your drivers move around the city' / 'Know when they are returning' — with in-app navigation for the driver. source |
| delivery-tracking-page | unknown | resolve-to-yes | A customer tracking link showing order status and driver proximity is documented as part of Delivery XT. source |
| delivery-promise-time | unknown | resolve-to-yes | UPGRADE TO PARTIAL ONLY (schema lacks that verdict). Delivery time estimation is a documented Delivery XT function; the estimation model, whether promise times feed the POS/KDS, and load-based adjustment are undocumented. source |
| reliability-self-serve-training | partial / claimed — 'Training videos named as a support channel; whether a public free library and a terminal training mode exist is unverified.' | upgrade-to-yes | Revel University (reveluniversity.revelsystems.com) is a live, publicly reachable structured training library with per-feature courses, alongside the login-free help site. source |
| extensibility-doordash-preferred | no / documented — 'absent from DoorDash's 2026 Preferred Integration Partner cohort' | downgrade-to-unknown | The cited URL is unverifiable: get.doordash.com/en-us/blog/preferred-pos-integration-partners 301s to merchants.doordash.com, which returns HTTP 404. I could not reproduce the partner list from any DoorDash-controlled page. Absence from an unverifiable list is not an affirmative statement of absence. source |
| extensibility-free-sandbox | partial / documented — 'A QA environment exists (authentication.qa.revelup.com) but access requires partner-issued credentials' | downgrade-to-unknown | I could not reproduce any mention of a QA environment on the cited authentication page, and no self-serve sandbox signup is documented anywhere on the developer portal. Nothing publicly establishes obtainability without an existing partner or production relationship. source |
| extensibility-webhook-reliability | yes / documented | upheld | Verified verbatim against the vendor docs: retry delays '1st: 60sec; 2nd: 300sec; 3rd: 900sec; 4th: 900sec'; HMAC-SHA1 X-Revel-Signature plus X-Revel-Instance / Event-Type / Event-Id / Message-Id headers; message log at GET https://api.revelsystems.com/external/message-log. Nine event codes confirmed. One correction: X-Revel-Establishment-Id is documented as OPTIONAL, so the dossier's per-location scoping claim (repeated in multi-location-org-hierarchy) is slightly overstated. source |
| extensibility-oauth-partner-apps | partial / documented — shared partner credential, not per-merchant revocable consent | upheld | Verified verbatim: 'The same Client ID and Client secret will be used for all merchants', and 'The Client-Id is the merchant's Revel URL without .revelup.com'. Correct and appropriately harsh. The docs describe partner-credential recovery by automated email and no operator-granted, individually revocable scopes. source |
| payments-processor-choice | yes / documented — status page monitors Adyen, Worldpay, FreedomPay | upheld | Verified and in fact understated: live components include Worldpay TriPOS, FreedomPay, Adyen, Worldpay, Eigen and the Revel Advantage Merchant Portal. Weakness to record: a status page proves integrations are operated, not that a merchant may freely select an acquirer at signing; no processor-choice policy document is publicly reachable. source |
| reliability-public-status-page | yes / documented, component list given | upheld | Verified, but the dossier's component list is incomplete in a way that cost it findings. Actual components also include Delivery XT, Driver XT, Revel Guard XT, Revel Data Connector, Loyalty XT, Como, Punchh, Loyalty Plant, Session M, Valutec, SVS, Synergy, Eigen, QSR Automations and User Authentication (Auth0). Loyalty XT (a Revel-branded, Como-powered in-house loyalty product) and Revel Data Connector (a reporting/warehouse feed) are first-party products the dossier never discovered and which likely lift several guest-loyalty and reporting-raw-warehouse-export cells off unknown. No uptime percentages, as stated. source |
| hardware-pricing-transparency | no / documented — sourced to Merchant Maverick | upheld | Verdict correct, sourcing improper: an affiliate-monetized review site cannot carry 'documented' confidence. The defensible evidence is first-party — the vendor pricing and hardware pages no longer exist (301 to shift4.com/food-beverage) and no SKU pricing is published on any Revel-controlled domain. source |
| commercial-pricing-published | no / documented — sourced to a Software Advice profile | upheld | Correct, but re-source to the dead first-party pricing page rather than an aggregator profile. source |
| hardware-commodity-devices | yes / claimed — sourced to Software Advice | upheld | Substantively right (iPad-based POS on off-the-shelf Apple hardware), and the live help site and Revel University document iPad-based operation directly, so confidence can rise above an aggregator claim. Not downgraded, but the citation should not be an aggregator profile. source |
| commercial-hardware-not-locked | yes / grade F rationale-only - the sole prior citation was a denylisted aggregator host | upheld | The differentiator 'yes' was standing at grade F with no retrievable evidence, which the evidence rules forbid - a differentiator yes needs A or B. I did not take the researcher's word for it. Revel's legacy /hc/ help URLs now return 401, but the current Salesforce /s/article/ knowledge base is publicly served, and its 'Active Supported Hardware' catalogue is exactly the grade-B documentation the rule demands: standard Apple iPads as the terminals, and Epson, Star, Zebra, Dymo, CipherLab, Brecknell and Meraki peripherals. I checked the counter-case too - the Revel Advantage International FAQ says third-party payment terminals will not work - but that limits the payment device, not the platform, and the claim is satisfied by the iPad and printer support. Value unchanged; evidence moved F to B, which is what makes the cell legal. source |
| order-capture-floor-plan-editor | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | Retrieved Revel's own 'Building Your Table Layout' article and confirmed a genuine drag-and-drop editor with sections, per-table shape, Table Name and Capacity - more than the prior rationale credited. But the claim has four parts and two fail: I found no documentation of saving multiple floor-plan layouts per location, and no server-to-section assignment. I checked Table Service Settings specifically for the latter and it documents only Prompt for Course and Auto Gratuity. Partial stands, now on grade-B vendor documentation instead of an unciteable rationale. source |
| order-capture-split-merge | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | Retrieved the vendor's Split Bills article. Splitting is stronger than the prior rationale allowed - even N-way, arbitrary amounts, by item and by seat are all named. Merging is weaker than the claim requires: the only merge is un-splitting a split, it refunds every payment on the order, and it needs a refund-permission PIN. Merging distinct checks or tables together is nowhere documented. The claim explicitly asks for merging 'including after partial payment', which this fails. Partial upheld, re-sourced from F to B. source |
| order-capture-native-handheld | partial / grade F rationale-only, on the reasoning that there is 'no purpose-built handheld or documented tableside card-capture flow' | upgrade-to-yes | This is the one cell where I moved against the record's direction, and only because the prior rationale asserted something I could disprove: it said no tableside card-capture flow was documented. Revel's own iPort article documents exactly that - an MOT case shipped in 2.77 whose stated purpose is mobile order taking, with a PayCase carrying a Link 2500 or Moby 5500 EMV/contactless reader attached to the iPad. The claim asks for a first-party handheld ordering app running natively (satisfied: the native iPadOS Revel POS app, per the App Store listing) that can send to kitchen and take a card payment tableside (satisfied: it is the same POS app that drives Revel's documented kitchen print and KDS routing, and the paired reader takes the card at the table). The claim does not require a purpose-built device, so the iPad-in-a-case form factor is not a disqualifier. Upgraded to yes on grade-B vendor documentation. source |
| payments-emv-nfc | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | Checked three vendor documents rather than accepting the prior rationale's guess. EMV chip and NFC contactless are comprehensively documented device-by-device in Active Supported Hardware - that part of the claim is clearly met and is stronger than the record credited. The claim's conjunction is what fails: it requires ALL first-party terminals to take Apple Pay AND Google Pay. Google Pay is named only in the international Adyen FAQ; the domestic methods list says 'Mobile Wallets (Apple Pay, etc.)' and Apple Pay arrived gateway-by-gateway. That is a material, nameable limitation, so partial is correct rather than yes. Re-sourced F to B. source |
| reliability-offline-order-entry | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | Retrieved the current Offline Mode / Always On Mode article on the live knowledge base (the /hc/ URL the record previously used now returns 401). Offline order entry and payment capture are genuinely documented, with named settings and dollar thresholds. But the claim is a three-part conjunction - order entry, ticket routing, AND check printing - and Revel documents only the first. I looked for a statement that kitchen tickets or checks keep printing during an outage and did not find one, so I will not assert it. The partial-ISP-outage caveat and the pre-2.79 unplug-the-ethernet workaround are additional real limitations. Partial upheld, moved from F to B. source |
| extensibility-accounting-connectors | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | The QBO half is better documented than the prior rationale suggested - mapped journal entries with an explicit account-mapping UI and enforced account types, clearly grade B. The claim fails on its second limb. I went looking for a Revel-maintained connector to a second GL system and found that the Xero path runs through Amaka, an independent integration platform; Revel's own help site has no Xero connector documentation. A third-party middleware product is not a 'native, vendor-maintained connector'. Partial upheld with the shortfall named precisely, re-sourced F to B. source |
| inventory-cogs-gl-export | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | Retrieved both QBO articles. Period COGS and purchase-order/AP detail genuinely do export daily into QuickBooks Online with mapped GL accounts - that much of the claim holds and is now properly sourced. The discriminating requirement is per-item-category GL mapping, and Revel's documentation is explicit that the mapping drop-downs are locked to a fixed, integration-approved account set the customer cannot extend. There is one COGS account, not one per category. Partial upheld, F to B. source |
| multi-location-consolidated-reporting | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | I looked for the above-store view rather than assuming it. It exists and is better than the prior rationale implied - a real per-establishment consolidated report with a documented column list including discounts. But the claim's specific tests fail: item mix, voids and labor are not in the consolidated view, and neither ranking nor variance flagging is documented anywhere I could reach, including the Insights mobile app which merely lists Total Payments per store. Partial upheld with the gaps named, moved F to B. source |
| reporting-realtime-dashboard | partial / grade F rationale-only - sole evidence was a denylisted aggregator host | upheld | The browser half is uncontroversial (Management Console Reports), so I tested the mobile and latency halves. Insights by Revel is real and documented, but three limitations are stated on the vendor's own page: it is a separately purchased, license-keyed app, it is iPhone-only with Android explicitly excluded, and its reporting range is a single day. Most decisive for this claim, Revel nowhere commits to a refresh interval, and absence of evidence is not evidence - so I will not certify 'within minutes'. Partial upheld with the shortfalls named, evidence F to B. source |
| payments-split-tender | unknown / grade F - "No public documentation located during the 2026-08-01 research pass." | resolve-to-partial | This cell's placeholder meant nobody had checked it against the claim wording, not that no evidence existed. The Split Bills article, already cited elsewhere in this same record for order-capture-split-merge, documents four named split modes producing multiple checks from one order (Split Evenly, Split Manually, Split By Item, Split By Seat Number). That establishes the order can be divided many ways, but the article never addresses settling one resulting check with multiple tenders, nor states any numeric cap, so the claim's specific requirements ('multiple tenders', 'no hard cap below eight ways') are only partly evidenced. Moved F to B on an already-verified vendor source; support.revelsystems.com could not be freshly re-read this pass (401/JS shell to every available fetch method). source |
| payments-refund-void-controls | unknown / grade F - "No public documentation located during the 2026-08-01 research pass." | resolve-to-partial | The same Split Bills article states that 'Clear Split Bills' requires a security PIN from an employee with refund permission because it refunds all payments on the order - real evidence of role-gated refund authorization. It does not address void, discount, or no-sale authorization, and no immutable audit log identifying the approver is described (only that a PIN is required at the point of action), so the claim's fuller requirements remain unmet. Moved F to B; support.revelsystems.com otherwise inaccessible this pass. source |
| inventory-waste-logging | unknown / grade F - "No public documentation located during the 2026-08-01 research pass." | resolve-to-partial | The Revel Inventory app's own App Store description states plainly: 'Quickly receive items, input waste and spoilage, and update item cost and price right from the app.' That documents a waste/spoilage entry workflow. It does not mention reason codes on those entries or separate waste-cost reporting apart from usage variance, both required by the claim, and an App Store listing is vendor marketing copy rather than admin documentation, so grade is capped at C. source |
| order-capture-seat-level | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-yes | Quick Course/Seat Menu documents per-line seat tagging at entry via the Course/Seat widget; Split Bills documents a 'Split By Seat Number' option, covering both halves of the claim. source |
| order-capture-coursing-hold-fire | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-yes | TSR: Course Fire documents course prompts at entry, per-course Send Course release, a Fire Next Course POS action, and optional auto-fire from KDS Done. source |
| order-capture-bar-tab-preauth | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-partial | Configurable preauth amount and card-linked bar tabs are documented, but incremental auth is FreedomPay-iFCC-only and no auto-close of stale tabs at EOD is documented (EOD wizard is manual reconciliation). source |
| order-capture-transfer-audit | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-partial | Transfer Owner between employees and a gating Transfer Orders permission are documented, but no audit log naming both employees - the Action Log's enumerated action types exclude order transfers. source |
| order-capture-qr-same-check | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-no | Smart Order (the QR at-table product) is documented as an Online Ordering XT flow in which the guest orders and pays in one pass; its published limitations include 'Does not support pay at store option' and no post-payment edits, so QR items arrive as a separate paid online order, not lines on the server's open check. source |
| order-capture-kiosk-first-party | unknown / F - Revel historically marketed a kiosk; no current documentation reachable and no ADA/VPAT found. | resolve-to-partial | Kiosk XT is a documented first-party kiosk fed by the same Management Console catalog via Custom Menus, but no ADA/accessibility conformance documentation exists anywhere in the complete help centre. source |
| order-capture-drive-thru | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-partial | Dedicated Drive Thru Queue, vehicle-data prompts, in-queue payment and Fulfilled expediter state are documented; window separation, tandem-lane sequencing and pull-forward assignment are not. source |
| order-capture-drive-thru-timers | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-partial | Per-order kitchen speed-of-service timing (Start, KDS Complete, Expedite Complete, Total Kitchen Time) and a queue time-lapsed stamp are documented, but no lane-segment (order/pay/pickup window) timers. source |
| order-capture-throttling | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-partial | Max online orders per time slot with configurable slot interval is documented; per-channel caps and automatic quote-time extension are not, and the FAQ states multiple prep times don't exist. source |
| order-capture-scheduled-orders | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-partial | Future orders as invoices auto-convert and print on the due date at a configured time of day, but there is no per-order computed fire time and no per-channel lead time (multiple prep times don't exist per the FAQ). source |
| order-capture-catering | unknown / F - Unresolved, not absence. This is an order-flow/floor-management behavior documented (if at all) in t | resolve-to-partial | Catering dining option with delivery date/time, separate Catering Delivery page and report, and deposits/installments via Invoices are documented; no quote/proposal stage is. source |
| order-capture-void-comp-controls | unknown / F - Unresolved, not absence. This requires the void/comp/discount reason-code and manager-approval workf | resolve-to-yes | Reason entry is mandatory for voids and comps, comps/manual discounts are role-permission tokens with manager PIN gating, and the Adjustments report plus Product Mix employee-sales mode provide the exception reporting. source |
| multi-location-org-hierarchy | unknown / F - Webhooks carry X-Revel-Establishment-Id, confirming per-location scoping, but no three-level named h | resolve-to-yes | The EMS Establishment Hierarchy Tree documents brand > nested divisions > establishments plus groups, with EMS mode, permission push/locks and cross-level reporting scoped to tree nodes; EMS is a $29/month/establishment add-on. source |
| multi-location-central-menu-publish | unknown / F - Unresolved, not absence. The Establishment Payments Report (cited elsewhere in this record) confirms | resolve-to-partial | EMS single-action product/menu push to selected establishments or groups is documented, but Push Settings in EMS states there is no console dashboard or history for pushes - only email verifications - so the publish/version-history half is missing. source |
| multi-location-price-zones | unknown / F - Unresolved, not absence. The Establishment Payments Report (cited elsewhere in this record) confirms | resolve-to-partial | Per-establishment prices on one linked item exist via EMS; channel pricing is only a percentage upcharge or weborder price override, and daypart pricing exists only as timed discounts, not price books. source |
| multi-location-cross-location-giftcard | unknown / F - Unresolved, not absence. The Establishment Payments Report (cited elsewhere in this record) confirms | resolve-to-partial | Cross-establishment redemption and liability reporting are documented, but Revel's gift cards 'do not handle royalties' - inter-store settlement is a manual calculation from the Gift Transactions report. source |
| multi-location-cross-location-loyalty | unknown / F - Unresolved, not absence. The Establishment Payments Report (cited elsewhere in this record) confirms | resolve-to-yes | Revel documents Customers, Customer Groups, Gift Cards and Rewards Cards as data that updates for all establishments on the URL, i.e. one account-wide customer/loyalty profile and balance. source |
| multi-location-multi-brand | unknown / F - Unresolved, not absence. The Establishment Payments Report (cited elsewhere in this record) confirms | resolve-to-no | Vendor docs require a virtual brand to be its own establishment (DoorDash: a ghost kitchen sharing an establishment cannot be integrated; store IDs cannot be shared), the Branding Tool is account-wide, and brand separation exists only per establishment in the hierarchy - the documented workaround for multi-brand is separate establishments, not one terminal. source |
| multi-location-multi-tax-jurisdiction | unknown / F - Tax management is an API resource; per-location multi-rate and prepared-food rules undocumented. | resolve-to-yes | Stacked simultaneous taxes, product tax groups with rules, tax by dining option, tax-inclusive products, tax-exempt product selection and per-establishment configuration (EMS will not push tax settings globally) are all documented. source |
| multi-location-central-labor-policy | unknown / F - Unresolved, not absence. The Establishment Payments Report (cited elsewhere in this record) confirms | resolve-to-partial | Per-establishment overtime/doubletime and break rules with terminal enforcement (manager-PIN break gate, clock-in limits, auto clock-out) are documented; predictive-scheduling compliance and EMS group-level push of Time Sheet Rules are not. source |
| menu-pricing-nested-modifiers | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Introduction to Modifiers documents per-class independent min/max ('Minimum/Maximum Modifiers per Group') and forced selection, but the complete modifier documentation shows only one level of modifier groups attached to products — no sub-modifier nesting to three levels. source |
| menu-pricing-modifier-price-by-parent-size | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Advanced Modifier Features documents Per Product Modifier Pricing (per-parent-item modifier prices, agent-enabled) but no mechanism for a modifier's price to vary with the parent's selected size within one product. source |
| menu-pricing-topping-quantity-tiers | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Advanced Modifier Features documents modifier quantities (N x unit price) and No/Side/Only/Lite descriptors, but no per-tier price multiplier: Lite has no price effect and extra is just quantity multiplication. source |
| menu-pricing-size-style-matrix | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-yes | Matrix Inventory documentation shows a two-attribute grid (explicitly size x crust for pizza) generating child products with per-cell price override — exactly the claimed capability, at grade B as required for a differentiator yes. source |
| menu-pricing-included-allowance | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-yes | Introduction to Modifiers documents Free Type Quantity/Price allowances charging only overage; Advanced Modifier Features documents per-modifier substitution whitelists — both halves of the claim, grade B. source |
| menu-pricing-combos | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Group/Linked/Upsell/Split combo docs establish component swapping with price deltas, but no article documents auto-detecting a-la-carte cart items and converting them to the combo price. source |
| menu-pricing-upsell-prompts | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Prompt for Upsell (Yes/No/Required) per base product and Kiosk XT's 'Make it a combo!' window are documented, but neither an online-channel upsell prompt nor attach-rate reporting appears anywhere in the mirror — savings report only as discounts. source |
| menu-pricing-86-propagation | unknown / F - An inout.stock webhook emits inventory status changes and a menu-update event exists, but cross-channel | resolve-to-partial | Item Availability docs plus the DoorDash Marketplace article establish cross-channel 86 propagation (POS, online ordering cart, DoorDash via webhooks, kiosk out-of-stock), but no numeric latency and no KDS propagation are documented. source |
| menu-pricing-countdown-auto-86 | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Track in Inventory + 'Do not allow sale of this product without stock on hand' gives decrement-on-sale auto-86 at zero, and Item Availability has Set Return Time auto-restore, but the scheduled restore attaches to manual 86s, not to the stock countdown path. source |
| menu-pricing-dayparting | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-yes | Custom Menus documents time-slot menus with per-menu Price Tiers, product selection and effective dates/times, and day-part menus are explicitly supported — menus, items and prices all flip on schedule. source |
| menu-pricing-channel-price-books | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Per-channel custom menus with Price Tiers plus the 3rd Party Price Upcharge (%) establish channel price books, but the percentage rule exists only for third-party delivery menus; other channels need manual per-item tier prices that cannot be bulk-imported. source |
| menu-pricing-allergen-nutrition | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-no | The complete help centre contains no allergen/nutrition fields anywhere in the menu-management docs, and the DoorDash integration article positively recommends free-text product descriptions as the workaround for ingredient details — the vendor's own docs enumerate the alternative. source |
| menu-pricing-recipe-linkage | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-yes | Ingredients/Recipes Guide documents sale-driven theoretical depletion for products and modifiers, and Dynamic Cost derives item-level cost from summed ingredient costs — both halves of the claim at grade B. source |
| menu-pricing-3p-menu-push | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Direct DoorDash and Uber Eats integrations push Revel-managed menus without middleware, but the push is manual, confirmation can take up to 2 hours, and no per-item sync status or rejection-error UI is documented. source |
| menu-pricing-dynamic-pricing | unknown / F - Unresolved, not absence. This is a menu/modifier configuration behavior that would be documented in the | resolve-to-partial | Time-scheduled price tiers and percentage channel markups are documented, but demand-driven pricing and floor/ceiling guardrails appear nowhere in the complete mirror. source |
| payments-surcharge-guardrails | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-partial | The now-readable help centre documents a native surcharge engine (Creating a Surcharge: flat percentage applied to every order, per establishment) and a surcharging FAQ, but the FAQ places debit/prepaid exclusion, the 3% cap and disclosure squarely on the merchant, and no BIN/product-code auto-exclusion or cap enforcement is documented; Adyen AU/NZ per-card-type surcharges are provisioned by Revel Payment Operations by email. source |
| payments-pay-at-table | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-partial | Moby 5500 (Bluetooth mobile reader accepting contactless/inserted/swiped payments with the iPad POS) and the IPORT mobile order taker case are documented, so mobile EMV/NFC acceptance exists; but no guest-facing tip prompt on the handheld flow and no dedicated pay-at-table workflow is documented - tip prompts appear only on CDS XT, Adyen terminals (international) and SmartPay. source |
| payments-qr-guest-pay | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-yes | Revel SmartPay is exactly this feature: 'Print QR Barcode on Receipt' prints a QR the guest scans to reach their order status page, add a tip via configured prompts, and pay from their phone; enabled per establishment for Adyen/TriPOS/FreedomPay. Smart Order additionally covers QR order-and-pay at the table via Online Ordering XT. source |
| payments-tip-adjust | unknown / F - API exposes declared tips under payroll, but no adjust/batch-window documentation. | resolve-to-yes | The help centre documents post-auth tip entry on the payment screen and on the permission-gated Payments Waiting to Batch screen, an explicit window (tips before capture/auto-capture time; afterwards only as a separate authorization via the Revel Advantage portal), and on-device tip prompts (Adyen terminal tipping options; CDS XT tip suggestions by thresholds). source |
| payments-tip-pooling | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-yes | The Tip Pooling article documents pool-in by tips or sales, share-out even-by-hours or percentage-by-role, per-shift/day/week periodicity, a manager-submitted per-employee breakdown ending in Final Tips, and a Final Tips column on the Payroll report - covering configurable rules and payroll-exportable per-employee allocation. source |
| payments-offline-decline-liability | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-yes | The Offline Mode article states offline payments are 'performed at the Merchant's risk' with enumerated merchant-borne risks (chargebacks, fraud, fees), and the manual-batching article documents the post-reconnect Declined Payments tab with counters, retry/delete, the 2.79 offline-replay UI (10 days of automatic daily retries), and the mandatory Payments Summary review. source |
| payments-chargeback-tooling | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-partial | The Revel Advantage merchant portal has a genuine Disputes dashboard with Respond (PDF evidence upload), Accept Liability, alerts and reason codes - but it is limited to Revel Advantage merchants and evidence is manually uploaded, not assembled from the POS transaction record. source |
| payments-card-on-file | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-partial | Saved cards are documented for the Online Ordering platform via Vantiv/Mercury hosted checkout (guest account, Choose Card drop-down, Payment Methods management) with the PAN captured on the processor-hosted page; no reuse in-store or for phone orders is documented, so the cross-channel requirement fails. source |
| payments-payout-timing | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-partial | A Next Day Funding Fee (eligibility-limited) is documented on the Revel Advantage XT fee schedule, but the standard deposit schedule is explicitly processor-dependent and nowhere published, and no same-day/instant option is documented. source |
| payments-p2pe-pci4 | unknown / F - Unresolved, not absence. Payment-flow specifics of this kind live in the Payment Gateways & Processors Overview and Revel Advantage articles on the help centre. | resolve-to-partial | Validated P2PE is documented on the FreedomPay gateway path and the PCI FAQ states Revel 'can provide an attestation of compliance (AOC) upon request', but no document states the PCI DSS version (no 4.x reference exists in the help centre) and P2PE is not documented across the other gateway estates. source |
| commercial-module-unbundling | unknown / F - Reviewers complain about paying separately for required modules, implying unbundled SKUs, but no a-la-carte cancellation policy is published. | resolve-to-partial | The Billing FAQ documents cancelling 'subscription/establishments/add-ons' as distinct objects via cancellationnotice@revelsystems.com, and Data Access retention tiers are a separately purchasable add-on - but cancellation is a manual process, no module price list is published, and repricing implications for the base subscription are undocumented. source |
| commercial-hardware-purchase-outright | unknown / F - Unresolved, not absence. Revel's own commercial terms pages (revelsystems.com/pricing, apiterms) are documented elsewhere in this record as dead/redirected. | resolve-to-partial | The Payment Device Purchase Policy documents purchase-from-Revel (not lease) as the required channel for payment devices, self-sourcing of commodity iPads/printers is acknowledged as possible, and no rental/lease mandate appears anywhere - but no published hardware price list exists, failing the 'at a published price' half. source |
| commercial-post-termination-export-window | unknown / F - Unresolved, not absence. Revel's own commercial terms pages (revelsystems.com/pricing, apiterms) are documented elsewhere in this record as dead/redirected. | resolve-to-partial | The Billing FAQ documents that cancelled customers can still get data access through the billing team ('Fees may apply') - so not an immediate cutoff - but no defined retrieval window in days exists and access is a manual, fee-bearing request. source |
| commercial-pci-p2pe-tokenization | unknown / F - Unresolved, not absence. Revel's own commercial terms pages (revelsystems.com/pricing, apiterms) are documented elsewhere in this record as dead/redirected. | resolve-to-partial | Validated P2PE (FreedomPay) and processor-hosted checkout for stored cards are documented, but no SAQ is named and no scope-reduction claim exists - the PCI FAQ requires business profiling to determine SAQ type plus quarterly ASV scans for all Revel Advantage merchants, which is inconsistent with a documented SAQ-A/P2PE-HW reduction. source |
| commercial-pci-dss-4-controls | unknown / F - Unresolved, not absence. Revel's own commercial terms pages (revelsystems.com/pricing, apiterms) are documented elsewhere in this record as dead/redirected. | resolve-to-partial | Mandatory MFA (SMS or authenticator app) is documented since 2024-03-18 for the Revel Advantage Payment Portal, but no MFA is documented for Management Console or POS logins, no PCI DSS 4.x reference exists in the help centre, and no Req 6.4.3/11.6.1 script-integrity monitoring is documented. source |
| commercial-privacy-dsar-tooling | unknown / F - Unresolved, not absence. Revel's own commercial terms pages (revelsystems.com/pricing, apiterms) are documented elsewhere in this record as dead/redirected. | resolve-to-partial | The Customer Personal Data Anonymization feature is documented in-app deletion tooling (per-customer, from Management Console > CRM, permanent removal of name/email/address/phone/DOB) - but it must be enabled by Revel Support, has no bulk mode, no dedicated locate/export DSAR workflow is documented, and no published DPA exists in the help centre. source |
| commercial-dual-pricing-compliant | unknown / F - Unresolved, not absence. Revel's own commercial terms pages (revelsystems.com/pricing, apiterms) are documented elsewhere in this record as dead/redirected. | resolve-to-partial | Surcharging is natively supported with receipt breakdown and (AU/NZ Adyen) on-terminal guest disclosure, but no automatic debit/prepaid exclusion is documented anywhere - the US surcharge applies to every order regardless of tender and the FAQ assigns all compliance duties to the merchant; dual pricing / cash-discount mode is entirely undocumented. source |
| kitchen-course-firing | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | TSR: Course Fire article documents per-item course assignment, holding, and on-demand firing from the POS (Fire Next Course / Send Course), plus optional automatic firing from Done on KDS with override. source |
| kitchen-prep-time-pacing | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Prep/Cook Time article documents per-item cook times and KDS staggering so all items finish together, including a dynamic mode that releases the next items early when an item finishes ahead of its set prep time. source |
| kitchen-order-throttling | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-partial | A static per-time-slot cap on online orders is documented, but there is no dynamic kitchen-load/ticket-time-triggered throttling and the FAQ confirms multiple/adjustable prep times do not exist, so the automatic-pacing half of the claim is missing. source |
| kitchen-channel-pause-propagation | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Both connected marketplaces (DoorDash Marketplace and Uber Eats) have documented automatic item-availability (86) propagation via webhooks, and DoorDash store pause is available from the Revel Management Console. source |
| kitchen-all-day-counts | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Production View is a documented constant aggregate view of outstanding item quantities (and, in Tagged mode, product-plus-modifier tag counts) across the current orders on that KDS station. source |
| kitchen-sla-alerts | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Configurable per-Kitchen-View green/yellow/red time thresholds with escalating colors as tickets age are documented, satisfying the visual-escalation branch of the claim. source |
| kitchen-printer-fallback | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-partial | Automatic printer failover exists (Auto Redirect) but is restricted to same-model/type Epson ePOS LAN printers configured per station, and KDS screens have only manual redirect, so the claim's automatic KDS/any-printer failover is only half present. source |
| kitchen-offline-operation | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Revel's outage article explicitly lists 'Use CDS & KDS' and kitchen printing as functions that continue working while the cloud server is down, and kitchen printing continues during ISP outages over the local network. source |
| kitchen-item-build-screens | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Modifier List View (full modifier breakout on the station screen) and KDS Tags (per-station component/quantity tags) are documented, satisfying the claim's 'full modifier breakout' branch. source |
| kitchen-pizza-fractional-display | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-partial | Fractional placement exists but is limited to halves via Split Modifiers, and display is textual half labels rather than a documented visual sectioned rendering, so the quarters/sections and visual-rendering parts of the claim are missing. source |
| kitchen-recall-refire | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Item- or order-level kitchen reprint without re-entry is documented, and KDS Recall Mode plus the Speed of Service report's handling of recalled orders establish that bumped tickets can be recalled. source |
| kitchen-order-modification-alerts | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-partial | Added items are surfaced to the kitchen via numbered sub-tickets, but nothing flags added/changed/removed items on the already-displayed live ticket, and item-level changes/removals have no documented kitchen alert. source |
| kitchen-guest-ready-notification | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-partial | Bump-triggered guest notification exists in two documented forms, but SMS requires a Twilio integration and the Order Ready XT display board requires a paid subscription; only the basic Order Display KDS style is included, so the 'without a separate product purchase' condition is only partly met. source |
| kitchen-waste-logging | unknown / F - Revel Inventory (App Store, com.revelsystems.inventory, published by Revel Systems INC) is a separate | resolve-to-partial | Inventory-depleting waste entry is documented on the POS (Wasted quantity in Product Setup), but not at the kitchen/KDS screen and without reason codes, which are the specific things the claim requires. source |
| kitchen-speed-of-service-reporting | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-partial | A dedicated Speed of Service report with actual per-item/order kitchen times exists, but the claim's percentile stats and daypart/station/channel slicing are not documented, so the reporting depth falls short of the claim as worded. source |
| kitchen-prep-forecasting | unknown / F - Unresolved, not absence. Revel's KDS is real and documented at a coarse level elsewhere | resolve-to-yes | Product Forecasting generates predicted prep quantities from historical sales and surfaces them to kitchen staff as automatically printed daily and interval prep reports, exactly matching the claim. source |
| delivery-route-map | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-partial | Delivery Management documents a live map with geocoded order pins, 'the best route', Delivery Optimization run-batching recommendations, and printable/emailable route info with directions — but never explicit turn-order stop sequencing, and Delivery XT states drivers are never auto-assigned. source |
| delivery-zones-polygon | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-yes | 'Delivery area by GeoJson' accepts arbitrary polygon strings drawn in geojson.io ('Only polygon strings are supported'), beyond the postcode-list alternative; zone service fees also use GeoJSON polygons. source |
| delivery-zone-pricing | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-partial | Per-zone (GeoJSON) and distance-tier delivery fees auto-assess from the customer's address, but per-zone order minimums and per-zone promise times are not documented — minimums are only global online-ordering rules. source |
| delivery-address-validation | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-yes | The POS checks entered delivery addresses against the postcode list or GeoJSON area at order time and warns/errors when the address is out of area; a Driver Manager permission exists to override out-of-area deliveries; mileage defaults come from Google Maps. source |
| delivery-driver-comp | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-partial | Mileage per run (Google Maps default) and per-driver tips are captured at check-in and reported in the Delivery Drivers report, but per-delivery flat reimbursement and payroll export split into reimbursement vs wage lines are not documented. source |
| delivery-cash-reconcile | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-yes | Per-driver Virtual Tills with check-in (tips, close-to-cash, mileage) and End Shift till count producing a checkout summary and driver Sales Summary; the Tills Report Variance column is the documented over/short figure. source |
| delivery-daas-dispatch | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-partial | Driver XT Powered by DoorDash natively requests a Dasher for first-party orders with tracking in the POS sidebar and fees/tips in Revel reporting, but only for Online Ordering XT orders, within a 5-mile cap, and it cannot coexist with Delivery XT. source |
| delivery-daas-fallback | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-no | Driver XT requirements state 'Must not use Delivery XT' — in-house dispatch and DaaS are documented as mutually exclusive, Delivery XT never auto-assigns drivers, and no overflow rules exist anywhere in the complete help centre. source |
| delivery-3p-direct-integration | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-partial | Direct middleware-free DoorDash Marketplace and Uber Eats integrations are documented in dedicated onboarding articles, but Grubhub direct integration does not exist — zero mentions in the complete 693-article help centre. source |
| delivery-3p-injection | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-yes | DoorDash and Uber Eats orders sync to the POS in real time as fully-paid tickets under custom dining options, with POS notification, auto-close, online-order printing and KDS display — no tablet re-keying or manual accept in the documented flow. source |
| delivery-menu-push | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-yes | Revel is documented as 'the source of truth for all menus and products': multi-channel menus publish items, images, modifier pricing and a 3rd Party Price Upcharge (%) markup to DoorDash (manual Push Changes) and Uber Eats (24h auto or webhook). source |
| delivery-86-sync | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-yes | 86ing products, modifiers and ingredients pushes instantly to DoorDash via webhooks and restores on availability; Uber Eats supports the same via the Item Availability webhook. Group combos are the only documented gap. source |
| delivery-store-pause | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-partial | 'Pause orders from DoorDash Marketplace' is a documented Revel-side Management Console pause, but there is no timed auto-reactivation, no Uber Eats equivalent, and pausing blocks menu sync until manually disabled. source |
| delivery-3p-reconciliation | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-no | Both integration articles state marketplace fees are not reported to Revel (delivery fee, courier tips, other fees), discounts and refund adjustments do not sync, and merchants are directed to the marketplace portals for that reporting — the inputs for a payout reconciliation report are documented as absent. source |
| delivery-injection-error-visibility | unknown / F - A webhook message-log API surfaces invoked/failed/retrying delivery state, but that is developer-facing, | resolve-to-no | Vendor docs describe silent failure as the designed behavior: failed DoorDash orders 'will not show up on the POS or in reports', bad-product orders 'fail and not sync to Revel', rule-violating Uber Eats orders cancel after checkout — and no operator-facing health view or alert is documented anywhere in the complete help centre. source |
| delivery-offline-behavior | unknown / F - Unresolved, not absence. Delivery XT (Revel's first-party driver/dispatch product, App Store id1531919449 | resolve-to-no | The Offline Mode article enumerates documented offline behaviors (payments under limits, notifications, MC-side till closure) and delivery is not among them; no delivery article documents outage behavior. The claim asks whether such documentation exists, and across the complete public help centre it does not. source |
| digital-menu-single-source | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Help-centre article 'Online Ordering: Creating a Custom Online Menu' shows digital menus draw from the same POS product catalog, but a separate custom-menu build is required, new products must be manually added to it, and updates require a manual Refresh Menu push — so one item edit does not automatically propagate. source |
| digital-native-app | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Custom Commerce App FAQ documents a genuine branded native iOS/Android ordering app built and serviced by Revel, but states it 'is not currently available for purchase' — existing users only. This also explains why no consumer app was found under Revel's App Store developer account in the earlier pass (apps ship under each restaurant's own account). source |
| digital-account-saved-payment | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Accounts, saved multiple delivery addresses ('Online Ordering XT: Personalization') and saved tokenized cards ('Saving and Changing Credit Card Details') are documented, but card saving is documented only for Mercury/Vantiv hosted checkout and previous-order one-tap reorder is not documented on the web channel. source |
| digital-upsell-engine | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Kiosk XT's documented 'Make it a combo!' prompt is a configurable rules-based upsell, satisfying half the claim; personalized recommendations and attach-rate reporting are not documented, and the web checkout has no documented upsell prompt. source |
| digital-scheduled-pacing | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-yes | Admin documentation ('Online Ordering: Settings') specifies future/scheduled orders plus per-time-slot order caps with a configurable slot interval, and the OO XT article shows checkout rejecting orders when the slot maximum is reached — the claimed capacity-throttling mechanism, natively, at grade B. source |
| digital-fulfillment-modes | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Pickup Ordering documents pickup/curbside with arrival check-in fully integrated with OO XT, and OO XT documents delivery; dine-in QR is a separate Smart Order mode with documented limitations rather than part of the same ordering flow. source |
| digital-qr-table | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Smart Order (QR scan-to-order/pay at table) and SmartPay (QR/SMS scan-to-pay of an existing POS order with tipping) are both documented; the shortfalls are no documented guest check splitting and Smart Order orders not attaching to an existing open check. source |
| digital-kiosk | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Kiosk XT admin guide proves a first-party kiosk sharing the POS menu/modifier logic with unattended pin-pad payment, but the claim's accessibility-compliant-UI requirement is nowhere documented and processor support is limited to Vantiv/TriPOS and FreedomPay, so yes as worded is not established. source |
| digital-catering-portal | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Catering Overview + Online Ordering Order Rules document scheduled catering orders, house-account/invoice billing and deposit handling, but the claim's distinct guest-facing catering flow with quotes/proposals, catering menus/minimums and lead-time rules is not documented — a named, material shortfall. source |
| digital-loyalty-attach | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Loyalty XT article documents same-identity redemption inside the first-party online checkout ('Pay with loyalty', v2.78), but online accrual is not documented and the QR dine-in channel explicitly excludes loyalty — half the claimed loop, hence partial. source |
| digital-promo-parity | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Discount Codes article shows one discount definition honored on POS, kiosk and online, but itself names web-channel behavior differences (Apply Multiple Times unsupported online) and loyalty-offer support is uneven across channels, so 'honored identically' does not hold. source |
| digital-checkout-pci-sca | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Hosted payment pages are documented (Vantiv Hosted Checkout; FreedomPay OOXT checkout) and 3DS exists but is documented as FreedomPay-UK-only; PCI DSS 4.0 script-integrity compliance for digital checkout is not published in the help centre — named shortfalls on two of the claim's three legs. source |
| digital-surcharge-transparency | unknown / F - Unresolved, not absence. Web orders is a distinct, writable API resource in the developer portal (Weborders: C | resolve-to-partial | Surcharge display at OOXT checkout (v2.73) and CNP surcharging guidance are documented, but the claim's required correct handling of prohibited jurisdictions/card brands is explicitly left to the merchant in Revel's own FAQ, so only part of the claim is established. source |
| guest-loyalty-unified-profile | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Mirror shows a single CRM spanning console/POS/CDS with phone/email uniqueness-based merging, but uniqueness must be enabled by Revel Support, merge behavior is not documented in detail, and Kiosk XT is documented as excluded from CRM data. source |
| guest-loyalty-thirdparty-identity-attach | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-no | DoorDash Marketplace article positively documents that marketplace orders carry only first name + last initial, share a single placeholder phone/email, and collapse into one shared CRM account whose name is overwritten by each new order. source |
| guest-loyalty-accrual-models | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-yes | Admin guide documents visit-count, purchase-amount (points-per-dollar), and per-item accrual as native configuration — at least two of the claim's required models, no bolt-on vendor. source |
| guest-loyalty-tiers | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Status tiers exist with tier-specific benefits/restrictions, but assignment is by loyalty-card number range; the automatic promotion/demotion half of the claim is not documented. source |
| guest-loyalty-offline-behavior | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-no | The claim is that the vendor documents loyalty offline behavior. The dedicated Offline Mode article enumerates offline-capable functions (payments, tills, notifications) with loyalty absent, and the complete help-centre mirror contains no loyalty-offline documentation — positive evidence the documentation does not exist. source |
| guest-loyalty-offer-stacking-rules | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-yes | Stackable Discounts admin doc exposes exclusive-vs-combinable as per-discount configuration with documented order-of-application semantics, plus tiered discount precedence — exactly the claimed capability, in grade-B documentation. source |
| guest-loyalty-targeted-offers | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Rule/attribute-based audience targeting is documented, but only inside the paid Loyalty XT (Como) add-on, not the core platform. source |
| guest-loyalty-rfm-segmentation | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Automatic recency segmentation is documented in Loyalty XT, but not full RFM/lifecycle segments, and only in the paid add-on. source |
| guest-loyalty-lifecycle-automation | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Birthday, joining-gift, and lapsed win-back automations are documented as always-on rules, but only in the paid Loyalty XT add-on with an extra subscription for the messaging component. source |
| guest-loyalty-native-email-sms | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Email and SMS campaign sending is documented, but it lives in the Como Hub of the paid Loyalty XT add-on and requires an additional Marketing Communications subscription — not native to the Revel console. source |
| guest-loyalty-consent-management | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Per-channel consent capture with audit logging is documented, but it is support-enabled and no documented enforcement ties the CRM flags to the Como-run messaging channel. source |
| guest-loyalty-campaign-attribution | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Order-level redemption reporting per discount/offer is documented in the Discounts report, but the incremental-sales half of the claim is not documented and campaign analytics sit in the Como Hub. source |
| guest-loyalty-privacy-rights-tooling | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Documented per-customer anonymization with field-level scrub details plus CRM export exists, but it is support-enabled, single-customer-only, and propagation to the Como loyalty/marketing store is undocumented. source |
| guest-loyalty-redemption-fraud-controls | unknown / F - Unresolved, not absence. status.revelsystems.com lists Loyalty XT (Revel's own Como-powered loyalty product) | resolve-to-partial | Role-based gating of manual point add/subtract is documented, but velocity limits, self-redemption flagging, and a loyalty-specific audit log are not — the Action Log's enumerated action list omits loyalty changes. source |
| labor-photo-punch-verification | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-partial | Advanced POS Settings documents 'Photo clockin' forcing a picture at clock-in, stored to the iPad photo library; photo-only with no biometric template, but attachment to the timecard entry is not documented. source |
| labor-granular-rbac | unknown / F - Not resolvable by automated retrieval, and recorded as such rather than left implying nobo | resolve-to-yes | Roles and Permissions Guide documents per-action tokens (Void Items, Comps, Item/Manual Discount, Refund Payment, Open Cash Drawer, Price Override, iPad Reports) per role with creatable/copyable custom permission sets and per-establishment management plus EMS brand-level audit export. source |
| labor-manager-override-audit | unknown / F - Not resolvable by automated retrieval. support.revelsystems.com returns HTTP 401 to progra | resolve-to-yes | Action Log report attributes each action to the performing employee (Price Override, manual Time Worked create/edit/delete, permission changes, login attempts) with target and change description, filterable and exportable. source |
| labor-demand-labor-forecast | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-no | Scheduling docs enumerate the full Shift Schedules toolset — manual creation, Excel import, copy, and a Wage/Forecasting view of projected payroll from already-entered shifts; no staffing recommendation from sales history exists; Product Forecasting drives food prep only. source |
| labor-realtime-labor-percent | unknown / F - Revel Insights (App Store, id1050942994, sellerName 'Revel Systems INC', minimum | resolve-to-yes | POS drop-down Labor Report 'will display labor data, including your labor costs, labor percentage, and total sales per hour' on the terminal during service, gated by the iPad Reports permission. source |
| labor-overtime-prevention | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-partial | Shift alerts for employees 'in or nearing overtime' exist but only as manager notifications in the separately licensed Insights iPhone app; nothing warns or blocks at clock-in on the POS. source |
| labor-break-compliance-by-state | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-partial | Time Sheet Rules provides configurable paid/unpaid break calculation (documented around California meal-period law) and break-end clock-in blocking with manager PIN, but a single rule set per establishment — no per-state library, attestation prompt, or premium-pay flagging. source |
| labor-tip-pooling-rules | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-yes | Tip Pooling computes pools automatically from configurable rules (tips or % of sales in, even-by-hours or per-role % out, weekly/daily/per-shift periodicity) via the Schedules > Tip Pooling tool; manager submits each computed pool. source |
| labor-tip-distribution-audit-trail | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-yes | Tip Pool tool retains past submitted pools per day/shift with per-employee tips, tip-in and tip-share amounts; final tips post to the exportable Payroll report with declared and non-cash tip columns. source |
| labor-native-payroll | unknown / F - API exposes payroll declared tips, which reads as an export shape rather than fi | resolve-to-no | Revel Payroll is a reporting tab only; the documented paths to pay employees are the ADP export and the QBO Payroll integration where payroll is run inside QuickBooks; no first-party tax filing or direct deposit exists in the help centre. source |
| labor-payroll-export-formats | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-yes | Documented ADP export in Workforce Now and Total Force formats (CSV/XLSX) plus the QuickBooks Online Payroll integration that auto-populates worked hours — two named major providers. source |
| labor-shift-swap-workflow | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-no | The employee-side scheduling interaction is fully enumerated as confirm/reject of an emailed schedule; shifts are created/edited/cancelled by managers only; no self-service swap or open-shift claiming exists in the complete help centre. source |
| labor-server-performance-metrics | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully | resolve-to-partial | Employee Profit Report delivers per-employee average check (Avg Trans.), items per transaction (QTY/Trans.), sales/hour and profit metrics, but no per-employee void/comp rate is documented — voids and comps report only in aggregate. source |
| inventory-recipe-bom-costing | unknown / F - Developer portal links an 'Inventory X' document but its contents were not reach | resolve-to-yes | 'Use ingredient cost to calculate product cost' derives product cost dynamically from summed recipe ingredient costs, and ingredients themselves can carry recipes (sub-recipes for house-made prep items) — multi-level BOM with automatic recalculation. source |
| inventory-unit-conversion-yields | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-partial | Stock units with explicit conversion factors and per-unit reorder prices are documented (order in cases, deplete in units); prep recipes carry batch Recipe Yield / Actual Yield; but no per-item yield/waste percentage for raw-to-usable conversion exists. source |
| inventory-theoretical-vs-actual | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-partial | Physical Inventory History reports expected vs counted variance in both quantity and value per count cycle with category/class drill-down, but it is an on-hand shrink report, not a per-item theoretical-vs-actual usage decomposition. source |
| inventory-86-auto-sync | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-yes | Zero-stock items become unsellable on the POS ('Do not allow sale of this product without stock on hand'), show out of stock on Online Ordering XT down to recipe-ingredient and modifier level, and 'cannot be ordered on DoorDash' per the DoorDash Marketplace integration doc. source |
| inventory-count-modes | unknown / F - Revel Inventory (App Store, id1051198587) documents 'Count Physical Inventory' g | resolve-to-partial | Full and subset (Group/Class/Category, sectioned) counts with per-cycle variance history and stocktake templates/recounts are documented, but no scheduled recurring cycle-count automation exists — every count is started manually. source |
| inventory-mobile-count-offline | unknown / F - Revel Inventory (App Store, id1051198587, 'Revel Systems INC') documents barcode | resolve-to-partial | The Revel Inventory App counts by wired/Bluetooth/camera barcode scanning, but it requires a separate paid subscription and offline counting with sync-on-reconnect is not documented. source |
| inventory-vendor-catalogs-edi | unknown / F - Purchase orders and supplier management exist as API/feature entries; no named b | resolve-to-no | POs go out as emailed PDFs; the FAQ's recommended path to a wholesale order site is Excel export; the complete Inventory tab enumeration has no distributor catalog/EDI surface and no broadline distributor is named anywhere in the help centre. source |
| inventory-invoice-ocr | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-no | All documented invoice-entry paths are manual (PO receiving, line-by-line Purchase Ledger keying, Excel import); no photo/PDF/email ingestion or line-item extraction exists in the enumerated receiving surfaces of the help centre. source |
| inventory-price-change-alerts | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-no | Vendor FAQ states POs will not show last purchased price — 'the purchase order will display the cost as entered on the product or ingredient list' — and no received-price alerting exists anywhere in the help centre. source |
| inventory-par-auto-suggest | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-partial | Reorder to PAR generates suggested PO quantities as PAR minus on-hand per vendor, but only from a static PAR; the platform's sales forecasting (Product Forecasting) drives prep reports, not purchasing. source |
| inventory-shelf-life-expiry | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-no | Vendor's own FAQ: 'No. There is no way to automate shelf life/expiration dates and wastage.' Direct positive statement of absence. source |
| inventory-menu-margin-linkage | unknown / F - Unresolved, not absence. Revel Inventory (App Store, id1051198587, com.revelsyst | resolve-to-partial | Product Mix Report joins recipe-derived cost to sales mix with COGS%, Gross Margin and Gross Margin % per item, but there is no configurable below-threshold margin flagging or alert. source |
| reporting-eod-closeout | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-yes | Operations Report article documents a single consolidated document reconciling gross/net sales, taxes, tips, discounts, voids/returns/refunds, payments by tender, and a cash summary with deposits — every element the claim enumerates. source |
| reporting-pmix-modifier-level | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-partial | Product Mix Report documents modifier-level rows, but as counts of parent products sold with each modifier, not per-modifier sales dollars; filters are day-of-week/dining-option/class, with no daypart filter, so the claim as worded is only partly established. source |
| reporting-comps-voids-audit | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-partial | Discounts Report plus Action Log document employee attribution, reason codes and dates for discounts, voids, comps, and price overrides, but nothing documents capturing the approving manager, which the claim requires. source |
| reporting-labor-productivity | unknown / F - Revel Insights (App Store, id1050942994) advertises 'real-time data, such as hourly sales, sales summary, payments, labor and product mix reports'... | resolve-to-partial | Labor Report documents sales-per-man-hour by hour from actual clocked hours with role/department filters, and Employee Profit Report documents per-employee sales-vs-labor ratios; the specific labor-%-of-sales metric at all three granularities in one place is not documented. source |
| reporting-server-scorecards | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-partial | Employee Profit Report covers average check and items per check per server, but two of the four claimed metrics (category attachment rate, tips as % of sales) are not documented in any per-server report. source |
| reporting-channel-profitability | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-partial | Per-channel revenue tracking via named custom dining/payment options is documented for Uber Eats and DoorDash, but commission-net reporting is explicitly deferred to the DoorDash merchant portal, so margin net of marketplace fees is not a Revel report. source |
| reporting-scheduled-delivery | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-partial | Scheduled email/HTTP delivery on defined cadences with recipient lists is fully documented, but it covers a fixed list of seven reports rather than 'any report' as the claim is worded. source |
| reporting-anomaly-alerts | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-partial | Threshold-based proactive email alerts exist but only for till cash amounts (plus low-stock and shift alerts); no documented alerts on sales/void/discount metrics or pattern deviation. source |
| reporting-sales-forecast | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-partial | Hourly sales and interval item forecasts from N weeks of the location's history are documented in the reporting UI, but the only consuming workflow is prep-report printing, not scheduling or ordering as the claim requires. source |
| reporting-tip-tax-compliance | unknown / F - Unresolved, not absence. The Establishment Payments Report and Insights-by-Revel articles cited elsewhere in this record show Revel ships named, structured reports... | resolve-to-yes | All three claim components are documented: declared-vs-charged tips per employee (Payroll Guide), tip pool distribution detail down to Final Tips per employee (Tip Pooling), and a tax liability summary by rate with zip/state/country breakdown (Tax Report). source |
| extensibility-free-sandbox | unknown / F - I could not reproduce any mention of a QA environment on the cited authentication page, and no self-serve sandbox signup is documented anywhere on the developer portal. | resolve-to-partial | The developer FAQ, read live today, affirmatively documents a partner testing instance with its own login — a test environment obtainable without a production account — but it is gated on API-partner signup and its cost is unstated, so the 'free, without a paid account' claim is only partly established. source |
| extensibility-first-party-delivery-integrations | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully, but its API reference pages are a client-rendered spec explorer... | resolve-to-partial | Vendor docs establish direct DoorDash and Uber Eats integrations without middleware, but the claim requires all three of DoorDash, Uber Eats, and Grubhub, and Grubhub appears nowhere in the complete help centre. source |
| extensibility-middleware-compatibility | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully, but its API reference pages are a client-rendered spec explorer... | resolve-to-yes | Both Checkmate and Otter list Revel on their public integration directories, satisfying the two-platform threshold; table-stakes weight permits a yes on these named, dated third-party sources. source |
| extensibility-payroll-export | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully, but its API reference pages are a client-rendered spec explorer... | resolve-to-partial | ADP export with provider-specific templates is documented, but the claim requires at least two named providers and no second provider is documented anywhere in the help centre. source |
| extensibility-headless-embedded | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully, but its API reference pages are a client-rendered spec explorer... | resolve-to-partial | Help-centre WebOrders API articles document third-party platforms submitting priced orders into Revel via API, which partially establishes headless operation, but no full embedded/headless transaction-engine mode (payments, kiosk contract) is documented. source |
| extensibility-data-portability-exit | unknown / F - Unresolved, not absence. developer.revelsystems.com's guide pages render fully, but its API reference pages are a client-rendered spec explorer... | resolve-to-partial | Machine-readable self-service exports of reports, customers, and menu are documented, but only report-by-report with one-year range caps and no documented contract-end complete export, so the claim as worded is only partly met. source |
| hardware-handheld-purpose-built | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-no | The iPort stands and cases article documents the mobile order taker as an iPad in an IPORT CONNECT PRO case with a separate magnet-attached PayCase for a Link 2500/Moby 5500 reader - a case add-on, not a purpose-built handheld - and the complete hardware catalogue lists no integrated-reader handheld and publishes no drop/IP ratings. source |
| hardware-handheld-battery-swap | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-no | The documented handheld is a sealed-battery iPad; the vendor's documented uptime strategy is MultiDock/Dock 'PD fast charging ... for minimal downtime of iPads in the field', with no swappable-battery option and no published shift battery rating anywhere in the help centre. source |
| hardware-handheld-lte | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-no | MOT cases are documented as WiFi (Lightning) or Ethernet (USB-C) only; the SAQ guide states Revel 'does not sell card swipes that could be used with a SIM card'; and the outage playbook's documented fallback is a manual 'Temporarily connect to a Wireless HotSpot' - no cellular failover is documented. source |
| hardware-kiosk | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-partial | Kiosk XT is a fully documented first-party self-order kiosk sharing the POS menu/modifier engine with integrated TriPOS/FreedomPay payment, but ADA compliance and countertop/freestanding form factors are not documented and feature limitations are enumerated. source |
| hardware-drive-thru | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-partial | Delphi OCS order-confirmation-screen integration and a dedicated drive-thru order queue with elapsed-time stamps are documented; speaker/headset integration, outdoor menu boards and a lane timer are not. source |
| hardware-printer-compatibility | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-yes | The Active Supported Hardware catalogue lists six Epson models plus Star MCP31L, mostly Ethernet, none vendor-branded - standard multi-manufacturer thermal printer support including LAN printers. source |
| hardware-peripherals | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-yes | Published compatibility list covers cash drawers, scanners, scales and customer displays, and a dedicated article documents dual cash drawers per printer with per-employee drawer assignment. source |
| hardware-p2pe-terminal | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-partial | Card entry is confined to dedicated Ingenico PTS terminals with encrypted swipes and merchants cannot view PANs, but no validated P2PE listing is claimed, SAQ type is determined per-merchant by profiling rather than stated, and required ASV scans of the CDE show the environment is not P2PE-descoped. source |
| hardware-tap-to-phone | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-no | The SAQ guide's exclusive enumeration of usable payment terminals (six Ingenico dedicated readers) and the hardware catalogue's standalone-terminal-only payment section are positive evidence there is no tap-on-phone acceptance. source |
| hardware-ownership-vs-lease | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-partial | Operations FAQ documents hardware purchase (DocuSign purchase documents, 5-business-day shipping, RMA credits) and warranty passes to the manufacturer after year one - a sale model - but no purchase-vs-lease terms or hardware pricing are published. source |
| hardware-rma-sla | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-partial | Warranty term and exchange turnarounds are published (exchange documents in 2 business days, shipment within 5, credit in 5-10), but it is a confirm-then-ship depot exchange with no advance-exchange or next-day commitment. source |
| hardware-remote-device-management | unknown / F - A 'Management Console' component is monitored on the status page but its device-management scope is not documented. | resolve-to-partial | Revel Guard XT is a documented remote device-management console with per-device status, versions, MDM actions and overnight update rollouts, but it requires a separately purchased appliance, is tier-gated, and remote reboot is documented only for payment terminals and the Guard device. source |
| hardware-callerid-integration | unknown / F - Unresolved, not absence. The Active Supported Hardware catalogue and iPort stands/cases article (both cited elsewhere in this record... | resolve-to-yes | Dedicated Caller ID article documents analog (Whozz Calling) and Vertex VOIP hardware, automatic attachment of new orders to the recognized customer record, per-station enablement and a call log. source |
| reliability-lan-degraded-multi-terminal | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-partial | Real-time LAN order sharing via a Main Syncing Station and continued order creation/closing plus kitchen printing during ISP outages are both documented, but no article explicitly joins the two by stating check sharing continues offline. source |
| reliability-local-transaction-engine | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-yes | The outage article documents full order creation/closing, cash and card taking, kitchen printing and KDS use during a total Revel server outage, and the Syncing article documents an on-premise Main Syncing Station for the order path - a documented local transaction architecture. source |
| reliability-offline-kds-printing | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-yes | The outage best-practices article explicitly lists 'Print to kitchen and receipt printers' during both server and ISP outages and 'Use CDS & KDS' during server outages. source |
| reliability-printer-fallback | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-partial | Auto Redirect provides automatic printer failover with an ordered fallback list, but only between matching-model Epson ePOS LAN printers, configured per-POS, no KDS failover, and staff alerted only after all fallbacks fail. source |
| reliability-247-live-support | unknown / F - Phone, live chat and training videos listed as support channels; whether 24/7 coverage is included in the base subscription is not published. | resolve-to-yes | The Resource Snapshot lists technical support phone/email 'Hours of operation: 24/7' with no tier qualifier, in deliberate contrast to weekday-only hours for billing, operations and payments lines. source |
| reliability-onsite-install | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-yes | Welcome Checklist: 'We offer full Management Console Training with either a Remote Installation or Full Onsite Installation depending on the Size and Amount of Equipment being Installed.' source |
| reliability-menu-build-service | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-no | The onboarding checklist enumerates the vendor-provided services (Navigator calls, console training, remote/onsite installation) and assigns the menu build to the operator via the Menu Build Guide and self-serve imports - vendor-performed menu build is not among the documented onboarding services. source |
| reliability-hardware-replacement-sla | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-yes | An in-warranty exchange program with stated turnarounds (exchange documents within 2 business days, shipment within 5, credits in 5-10) is documented in the Operations FAQ, with published warranty terms. source |
| reliability-pci-dss-4-attestation | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-partial | Revel states it is fully PCI DSS compliant with an AOC available on request, and its merchant program runs on PCI v4.0 (June 2024 guide), but the AoC is not published and its DSS version and post-March-2025 coverage are not stated. source |
| reliability-mfa-role-based-access | unknown / F - status.revelsystems.com lists 'User Authentication (Auth0)' as a live, monitored component, confirming Revel's login layer runs on Auth0... | resolve-to-partial | Granular RBAC (POS roles with rank hierarchy, permission matrix, admin permission sets) is fully documented; MFA is documented as required only on the Revel Advantage Payment Portal since 2024-03-18, not on Management Console or POS admin logins. source |
| reliability-failover-terminal-role | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-partial | Any station can be designated the Main Syncing Station, but designation is manual/agent-assisted and no automatic role failover is documented; running two mains is explicitly warned against. source |
| reliability-cellular-backup | unknown / F - Unresolved, not absence. The Offline Mode / Always On Mode article family (cited extensively elsewhere in this record... | resolve-to-no | The outage playbook enumerates outage mitigations and offers only a manual hotspot workaround; the networking catalogue has no cellular device; the SAQ guide states no SIM-capable devices are sold - positive evidence there is no automatic cellular failover. source |
| order-capture-qr-same-check | no / B - "Revel's QR at-table flow is Smart Order ('scan a QR code, order, and pay at the tab" | downgrade-to-unknown | Re-read the cited page. It is a Smart Order setup guide whose closing 'Revel Smart Order Limitations' list enumerates limitations without claiming to be complete and never addresses check attachment. The 'separate ticket' conclusion was an inference from 'Does not support pay at store option'; paying within the QR flow is normal for at-table QR generally and proves nothing about whether items join the server's check. Against the inference, the same article requires an Eat In dining option and 'at least one table' and issues QR codes per table, so the flow is table-bound. No positive evidence of absence survives. source |
| delivery-offline-behavior | no / B - "Revel's Offline Mode documentation enumerates what continues during an outage - card p" | downgrade-to-unknown | Re-read the cited page in full. It is scoped to transaction processing during an outage and reads as a payments-and-tills configuration guide, per-gateway, closing on Apple Pay and debit notes. It contains no completeness language - no 'the following are the only functions available offline' - so treating delivery's absence from it as positive evidence is unsound. What remains is a search of the help-centre mirror that returned nothing, which the evidence rules classify as unknown, and the mirror is complete only as to the public help centre, not as to Revel University or the Captain AI portal. source |
| guest-loyalty-thirdparty-identity-attach | no / B - "Revel's own DoorDash Marketplace integration doc: 'Only the customer's first name and f" | upgrade-to-partial | The 'no' generalized one marketplace to all of them. Revel's own Uber Eats Onboarding article, in a Supported vs. Unsupported feature table, states that a CRM profile is created for each Uber Eats order with first name, last initial and phone number, and the POS section states the order has 'a unique customer linked to them' whose 'name and phone number will be the actual customers contact information' - a native guest profile with usable identity, which is exactly what the claim asks for. The DoorDash findings the researcher quoted are accurate and still hold, so the correct value is partial with DoorDash Marketplace's shared placeholder phone/email and single overwritten CRM account named as the shortfall. source |
| guest-loyalty-offline-behavior | no / B - "Revel's dedicated Offline Mode article covers exactly what works offline - credit-card " | downgrade-to-unknown | Re-read the cited page. It is a payments-and-tills configuration guide, gateway by gateway, and it never asserts that the functions it covers are the complete set of what survives an outage - so 'loyalty is not among it' is silence, not an enumeration. The remainder of the argument is a help-centre search that returned nothing, which the evidence rules make unknown rather than no. Most of Revel's loyalty is delivered through third-party engines (Loyalty XT/Como, Punchh, Paytronix, LoyaltyPlant, Open Loyalty) whose own documentation lies outside the mirror. source |
| labor-shift-swap-workflow | no / B - "The scheduling documentation enumerates the complete employee-side interaction: schedul" | downgrade-to-unknown | Re-read the cited article. It is a six-section task guide with no completeness language, and the thing it actually enumerates is a four-colour email-status key, not the employee's capability surface; the claim that managers exclusively create, edit and cancel shifts is not in the text. What is left is that the help-centre mirror has no hit for shift swap, open shift or employee self-service, and a search returning nothing is unknown under the evidence rules. Web searching found only third-party scheduling products that integrate with Revel, which neither establishes nor excludes a native swap workflow. source |
| multi-location-multi-brand | no / B - 'Revel's docs model brand separation strictly per establishment: the DoorDash Marketplace integ' | downgrade-to-unknown | Adversarial enumeration audit. The load-bearing source is a third-party integration article whose supported/unsupported table is exhaustive only for the DoorDash Marketplace connector; it refutes virtual-brand delivery integration inside a shared establishment, not the claim's proposition about two brands with separate menus, branding and revenue on one terminal. The secondary premise is also mis-scoped: the Branding Tool governs CDS XT / Kiosk XT skins, not receipts. Nothing in the mirror enumerates Revel's brand-configuration surface, so the no rests on absence of evidence. source |
| hardware-handheld-lte | no / B - 'No cellular fallback is documented anywhere in the complete help centre: the MOT's Lightning I' | downgrade-to-unknown | Adversarial enumeration audit. The cited SAQ guide's SIM-card sentence is scoped to card swipes, not to the iPad, so it does not speak to the claim; the iPort 'charging ONLY' line describes the case, not the tablet's radios. The one document that does assert completeness about handheld devices - the iPad Compatibility chart - lists model generations only and never distinguishes Wi-Fi from Wi-Fi + Cellular iPads, so it cannot exclude a cellular handheld. The no rested on absence of evidence across the help centre. source |
| hardware-tap-to-phone | no / B - 'Positive evidence of absence: the SAQ merchant-profile guide enumerates 'The only payment termi' | downgrade-to-unknown | Adversarial enumeration audit. The SAQ guide's exclusive terminal list is refuted as exhaustive by Revel's own Active Supported Hardware catalogue, which lists Verifone V400m and Adyen P400 Plus / AMS1 in addition to the six Ingenico devices - so the SAQ list is scoped to the RA XT / TriPOS / FreedomPay questionnaire, not to the product. The hardware catalogue itself enumerates hardware and cannot establish the absence of a software softPOS feature. The record already holds payments-softpos-tap-to-pay at unknown on the same evidence. source |
| reliability-menu-build-service | no / B - 'The vendor's own onboarding checklist assigns the initial menu build to the operator: Step 5 dir' | downgrade-to-unknown | Adversarial enumeration audit. The Welcome Checklist is a merchant getting-started checklist, not a services catalogue asserting completeness, and it explicitly refers the reader out to Sales, the Revel Navigators team and a Services page. Revel demonstrably runs a Professional Services organisation - Client Training Programs makes 'Revel basic training with Professional Services' a prerequisite - and the help centre never states that organisation's scope. The services page itself is unreadable (revelsystems.com/services now redirects to shift4.com behind a Vercel checkpoint, HTTP 429 on 2026-08-06), so this is a retrieval gap, not documented absence. source |
| reliability-cellular-backup | no / B - 'No automatic cellular/LTE failover exists in the documentation: the outage best-practices articl' | downgrade-to-unknown | Adversarial enumeration audit. The outage playbook is a troubleshooting best-practices page whose mitigation bullets are advice, not an exhaustive account of connectivity design, and its hotspot line belongs to the Power Outage scenario. The SAQ sentence is about card swipes with SIM cards, not routers. The premise is affirmatively undercut by Revel's own hardware catalogue: it sells the Meraki MX64, which per Cisco documentation 'includes a USB port to support approved 3G/4G cards for failover to cellular networks'. Absence of Revel documentation about that path is not evidence the path does not exist. source |
| reliability-pci-dss-4-attestation | partial, grade B - 'First-party compliance statement: Yes, Revel Systems is fully PCI DSS c' | upheld | Value unchanged. The previous note's second premise was false: it read PCI v4.0 currency for Revel off a document title, 'Merchant Profile Questionnaire guide for RA XT PCI v4.0 June 2024', which is a merchant SAQ-selection guide scoped to the Revel Advantage XT programme and never states the version of Revel's own attestation. Re-read both articles in the local help-centre mirror and re-checked all 693 for P2PE - the only hits are FreedomPay and iPP350 terminal setup pages. What Revel actually publishes is an unversioned statement of compliance with the AoC available on request, which is what the note now says. source |
| payments-published-rates | no, grade B - No processing rate published anywhere; the vendor pricing pa | 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 |
| hardware-pricing-transparency | no, grade B - Verdict correct, sourcing improper: an affiliate-monetized r | 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 |
| commercial-interchange-plus-published | no, grade B - No processing rate of any structure is published; the pricin | 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 |
| commercial-pricing-published | no, grade B - Correct, but re-source to the dead first-party pricing page | 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-offline-order-entry | yes / B - "Right verdict from the wrong evidence. Replace the aggregator citation with vendor doc" | upheld | The cited support.revelsystems.com/hc/ URL now answers HTTP 401 at ~645 bytes under every user agent, and a fabricated /hc/ article id answers identically, so the gating is blanket rather than a deletion. Retrieved the migrated Salesforce help centre under a Googlebot UA (calibrated: a fabricated /s/article/ path returns 404 at 298KB, real articles return 200 at ~890KB). The outage article carries the offline availability list verbatim and is a stronger source than the article originally cited, which covered only payment settings. Value stands; citation and note replaced. source |
| payments-offline-store-and-forward | yes / B - "Explicitly documented, caps included ... gated by an 'Enable offline credit ca" | upheld | The /hc/ citation is customer-gated (401, ~645 bytes, blanket across the host). Retrieved the migrated article at /s/article/Offline-Mode-Always-On-Mode-1582898971418 (200, 898KB under Googlebot UA; fabricated path calibrates at 404/298KB) and read it end to end. The caps exist but under different names than recorded, and the 'store-and-forward' phrase appears only in the Adyen section - corrected both. Also corroborated the integration limitation independently at /s/article/Revel-POS-Payments-Overview: 'Offline mode is not available for all payment integrations.' Grade B holds for a differentiator yes. source |
| hardware-offline-mode | yes / B - "The published list the researcher said does not exist does exist - see the Offli" | upheld | Both cited articles were checked. The /hc/ URL is blanket-gated (401). Searched the complete public help-centre mirror and re-probed the live host: there is no migrated 'Manual Offline Mode on the Point of Sale' article, so that leg of the note is withdrawn. The claim nonetheless holds on /s/article/outage, retrieved live (200, 898KB, matrix text present in body), which is a better source than either originally cited. Noted the one gap - refunds - rather than papering over it. source |
| reliability-offline-card-auth | yes / B - "One of the flagged conclusion-flipping cells, and it resolves affirmatively on ve" | upheld | The cited /hc/ article is customer-gated under every UA. Retrieved the migrated article live at /s/article/Offline-Mode-Always-On-Mode-1582898971418 and cross-checked two further live articles (/s/article/How-to-Manually-Batch-Uncaptured-Offline-and-or-Declined-Credit-Card-Transactions-1582901172686 for the forward step, /s/article/outage for the availability list). Offline card capture with deferred authorization is documented, not marketed, so the differentiator bar is met. Converted the unquantified 'processor-dependent' caveat into the specific exclusions the docs state. source |
| kitchen-station-routing | yes / B - "Documented: products are assigned to specific kitchen printers / kitchen display u" | upheld | Retrieved the migrated article live (200, 888KB under Googlebot UA; fabricated /s/article/ path calibrates at 404/298KB) plus /s/article/How-to-Send-to-the-Kitchen-by-Dining-Option-1582898971400 and /s/article/Kitchen-Flow-Bump-Feature-Setup-1582899129146. Item-level and dining-type routing are both configurable by the merchant, which satisfies the claim. The prior note's 'Kitchen Flow defines which displays an item traverses' was true but concealed that flow creation is a support task - stated explicitly now. source |
| kitchen-expo-consolidation | yes / B - "Expo is a documented first-class role: items must be Completed on all bumping kitc" | upheld | The cited /hc/ article is gated; its migrated equivalent (/s/article/Kitchen-Flow-Bump-Feature-Setup-1582899129146, retrieved live) does not contain the sentence the record quotes - what it does say about a shared expedite view is that 'it does not matter which Line Kitchen KDS you mark an item as Complete from', which is not the same proposition. Went looking for real support and found it in /s/article/Automated-Expo-Experience, which ties the expo ticket and auto-close to all items being marked done across the prep stations. Value upheld on different evidence; the misquotation is withdrawn. source |
| kitchen-bump-bar-hardware | yes / B - "UPGRADE TO PARTIAL ONLY (schema lacks that verdict). Bump-bar layout configuration" | upheld | Two corrections to the record. First, the schema does contain upgrade-to-partial and resolve-to-partial, so the note's stated reason for recording yes-when-meaning-partial was never valid. Second, the reservation itself is wrong: retrieved /s/article/Active-Supported-Hardware live (200, 949KB under Googlebot UA) and it documents the supported bump bar with specs. The cited /hc/ section URL is customer-gated. Yes stands on the merits, not on a schema artefact. source |
| hardware-kds | yes / B - "First-party KDS with an entire documentation section: product-to-KDS assignment (s" | upheld | The cited /hc/ section is blanket-gated (401, ~637 bytes). Retrieved /s/article/Active-Supported-Hardware, /s/article/How-to-assign-products-to-kitchen-printers-display-unit-KDS-1583149941086 and /s/article/Optimize-KDS-for-Coursing-1582899129817 live under a Googlebot UA, all 200 at ~880-950KB against a 404/298KB calibration on a fabricated path. The supported-hardware catalogue is a stronger answer to 'first-party product rather than integration-only' than the existence of a docs section was, and coursing now has direct evidence instead of being asserted. source |
| reliability-offline-decline-liability | yes / B - "UPGRADE TO PARTIAL ONLY (schema lacks that verdict - do not record as yes). Revel " | upheld | The cited /hc/ troubleshooting article is customer-gated; its migrated equivalent (/s/article/How-to-Manually-Batch-Uncaptured-Offline-and-or-Declined-Credit-Card-Transactions-1582901172686) is live and I read it, along with /s/article/Offline-Mode-Always-On-Mode-1582898971418. The claim asks for two things - who bears the loss, and any stated cap - and both are published verbatim, which is a yes on grade-B vendor documentation. The note's hedge rested on a false premise about the schema (upgrade-to-partial exists) and on treating absence of contractual language as a shortfall the claim does not ask about; withdrawn. Sibling cell payments-offline-decline-liability already records the same evidence as yes, so this also removes an internal inconsistency. source |
| reliability-offline-feature-matrix | yes / B - "UPGRADE TO PARTIAL ONLY (schema lacks that verdict). A dedicated Offline Mode / Al" | upheld | Confirmed the loss first: the cited Zendesk article 360004984131 is gated, and grepping the complete 693-article Salesforce mirror plus probing the live host shows no migrated 'Manual Offline Mode on the Point of Sale'. The record's fallback - the Offline Mode article - is genuinely not an enumeration; this corpus twice concluded exactly that when leaving delivery-offline-behavior and guest-loyalty-offline-behavior at unknown/F. So the recorded reasoning had collapsed. Searched for a replacement and retrieved /s/article/outage live (200, 898KB, matrix text present in the response body), which publishes the explicit unavailable-function lists the claim requires. Yes upheld on new evidence, with the two unaddressed items named. source |
| guest-loyalty-offline-behavior | unknown / F - Re-read the Offline Mode article in the complete help-centre mirror (Googlebot capture 2026-08-04). | resolve-to-yes | Revel's outage best-practices article states the behaviour explicitly and in the blocked direction, not queue-and-reconcile. Under the ISP / Network Outage heading it lists, among the functions you will NOT be able to access, "Use Loyalty/rewards/gift cards"; the Revel Server Outage section repeats the same item. A dedicated Loyalty / Gift Card Outage section then enumerates the three sub-capabilities the claim names as unavailable: "Look up reward balances", "Accrue loyalty points", "Redeem rewards", plus "Create new loyalty account". Loyalty is therefore documented as blocked while connectivity is lost, with no queued accrual described. This article is uncited by the prior record, which scored the cell from Offline Mode / Always On Mode alone. source |
| delivery-offline-behavior | unknown / F - Re-read the Offline Mode article end to end in the complete help-centre mirror (Googlebot capture 20 | resolve-to-partial | Partial: Revel documents delivery-specific degraded-mode behaviour, but scoped to a Delivery XT service outage rather than to an internet outage, and it never addresses driver settlement. The Delivery XT Outage section lists as still working "Manage delivery orders via the Revel Delivery Management feature on the POS", "Create and close delivery orders" and "Operate tills and take cash payments" - so cash delivery orders are covered - and lists as unavailable "Use the Delivery XT Dispatcher app", "Use the Delivery XT agent app" and "Track delivery order status", the symptom for which is that you cannot assign delivery orders to drivers in the Dispatcher app; driver assignment falls back to POS Delivery Management. The separate ISP / Network Outage section covers order creation and cash but says nothing delivery-specific, and no section covers driver cash reconciliation or settlement. source |
| inventory-bar-partial-bottle | unknown / F - Searched the complete 693-article public help-centre mirror (captured 2026-08-04) for 'bottle', 'par | resolve-to-yes | Bottle-fraction tracking, using Revel's own beverage example. An ingredient is tracked in its unit of measurement and a bottle is defined as a stock unit above it: "Primary Stock Units allow you to track your inventory in larger quantities or smaller quantities", and in the stock unit setup step, "In the Conversion field, enter how many individual units of this item go into the stock unit. For example, 1 bottle of wine equals 25 ounces". Depletion is fractional per serving via recipes - "Enter the quantity of the ingredient in one serving of the product" - with the worked example instructing the user to "enter 7 oz. in the QTY field". So a bottle is countable and depletable in ounces, i.e. by bottle fraction. The disjunct the claim allows for scale-based weighing is not met: no bar liquor scale integration is documented (the Detecto and Brecknell scale articles are retail point-of-sale weighing). source |
| labor-offline-time-punch | unknown / F - Searched the complete 693-article public help-centre mirror (captured 2026-08-04) for 'offline' comb | resolve-to-partial | Upheld with the missing quotations supplied. Under ISP / Network Outage the playbook sorts functions into three affirmative lists, and clock-in sits in the middle one: "you'll still be able to access the following functions but they will be limited", whose first entry is "Clock In/Out". The same placement recurs under Revel Server Outage. So punching offline is affirmatively documented rather than inferred. It stays partial on two grounds: the article never says how the limitation manifests, and the claim's second half, reconciliation on reconnect without loss or duplicates, is nowhere documented; the vendor's stated remedy for the ISP case is "Enabling offline Mode for CC payments", which addresses payments and not timekeeping. source |
| labor-minor-labor-rules | unknown / F - Searched the complete 693-article public help-centre mirror (captured 2026-08-04) for 'minor', 'age' | resolve-to-no | Upheld, and strengthened by a same-API control the analyst did not use. The claim requires enforcement at BOTH scheduling and clock-in. The clock-in half is settled by an on-point closed enumeration: TimeScheduleRule is the entire clock-in rule surface and every gate in it is time-based or approval-based, for example "If set to True, will allow employees to start their shift before the scheduled time." and "If set to True, employees that are late to clock-in by a certain amount of time will need manager approval to start their shift." and "If set to True, employees that work seven days in a row will have their entire seventh working day considered overtime." No age, minor, school-day or prohibited-window property exists. The scheduling half is settled by the absence of any age datum: the Employee schema in the companion employees suite carries no date of birth, while the Customer schema in the customers suite and the order payload in the orders suite both do carry a birthdate field. The vendor therefore models birthdates where it has them, so the absence on Employee is a modelling decision and not a documentation convention. An age-derived rule cannot be evaluated at either point without that datum. No integration partner can rescue this, because clock-in gating executes inside Revel's own closed rule object. source |
| labor-qualified-tips-w2-reporting | unknown / F - Searched the complete 693-article public help-centre mirror (captured 2026-08-04) for 'W-2', 'Box 12 | resolve-to-partial | Upheld with one factual correction to the note. The first limb is met and published: TimeScheduleRule carries two independent payroll-report switches, "If set to True, will cause the payroll report to include employee declared tips (usually cash tips)." and "If set to True, will cause the payroll report to include tips left by customers (usually credit/debit tips)." Cash and charged tips are separately controlled and separately reported. The second limb fails: no Treasury tipped-occupation code exists anywhere in the fourteen published suites. In the companion employees suite the DeclaredTips resource carries an amount, an employee, an establishment and a tips date plus audit fields only, and Role carries name, department and rank, with no occupation-code attribute, so there is nothing to populate W-2 Box 12 code TP or Box 14b from. Correction to the prior note: DeclaredTips also carries id, uuid, created_date, updated_date and resource_uri, so the earlier list of four was incomplete, though none of them is an occupation code. source |
| labor-shift-swap-workflow | unknown / F - Re-read Creating Shift Schedules in the complete help-centre mirror (Googlebot capture 2026-08-04). | resolve-to-partial | Downgraded from no. What the spec closes is real: the Scheduling suite is three resources, TimeSchedule, TimeScheduleRule and TimeSheetEntry, and the schedule lifecycle is a published four-value enumeration, "0 - TimeSchedule was created", "1 - TimeSchedule was emailed", "2 - TimeSchedule was approved", "3 - TimeSchedule was rejected". There is no swap-request, shift-trade, open-shift or availability entity anywhere in the fourteen suites. The help centre describes the same shape positively rather than by silence: a manager builds the schedule, emails it, and the employee logs in with a PIN to confirm or reject. So an employee self-service step exists, which is why this is partial and not unknown, but it is accept-or-reject on a manager-authored schedule, with no swap, no open-shift claim and no eligibility enforcement. It is not a no because the claim's locus is a self-service app, which is precisely what a workforce-management integration supplies, and Revel publishes a Deputy integration article whose partner is a scheduling and mobile-workforce product. Revel's spec closes Revel's model; it does not close the integrated surface, and no Revel document states that swaps are unavailable. source |
| reporting-history-retention | unknown / F - Searched the complete 693-article public help-centre mirror for a retention statement (terms: retent | resolve-to-no | Upheld against the precedent, on the claim's own wording. The claim asks for at least 24 months of transaction-level detail queryable in the reporting UI with no silent truncation AND no archive retrieval fee. Revel publishes the window and it is half that: historical data is "accessible for a period of 1 year after they have been processed", "12 month access is included at no additional cost with your base Revel subscription", and, answering the year-over-year objection directly, "In practice, 12-month access includes rolling 13 month + current month data that allows for YoY analytics". Beyond that the merchant must export and self-store or "purchase a paid data plan for enhanced access". A purchasable longer window does not convert this to partial, because the paid tier is exactly the archive retrieval fee the claim disallows; the claim would still fail even if a tier reached 24 months, and no tier's window is stated anywhere. The article also refuses per-establishment tiering outright, "Unfortunately, Revel cannot enable different data access tiers for specific establishments." The one limb Revel does satisfy is transparency: the truncation is documented, not silent, so the no rests on the window and the fee, not on concealment. source |
| reporting-api-not-upcharged | unknown / F - Assessed against the complete 693-article support.revelsystems.com public help-centre mirror (search | resolve-to-partial | Upheld. Raw-data access is documented as included to a point and paid beyond it: "12 month access is included at no additional cost with your base Revel subscription", with an export control next to every report at no stated charge, but for anything older the merchant must "purchase a paid data plan for enhanced access", and the tier is fixed at the legal entity rather than per establishment, "Unfortunately, Revel cannot enable different data access tiers for specific establishments." That is a genuine upcharge on historical raw data, though not the per-location API fee or revenue share the claim's worst case describes. Whether API credentials themselves carry a fee remains unanswered: the published API/XML Terms grant the licence for the duration of the subscription and state no consideration, and the developer FAQ is silent on cost. source |
| reporting-tier-paywall | unknown / F - Searched the complete 693-article public help-centre mirror for plan tiers or paywalls around report | resolve-to-partial | Upheld, with the capture's status corrected. Revel's pricing page shows a single software SKU, "$99/monthly fee" per terminal, and lists reporting inside it, "Maintain a complete view of your business with access to real-time insights from anywhere." The help centre documents Sales Summary, Product Mix, Labor, Discounts and Operations reports in the management console with no plan gating. But the same page puts multi-location comparison outside that SKU under Additional Services and Products, "Manage all locations from a single dashboard with Enterprise Management solutions." One of the four report families the claim names is therefore a separate product, and history beyond twelve months is a separately purchased data tier. Evidence discipline: this is a Wayback capture dated 2023-05-28. I queried the Wayback CDX index for revelsystems.com/pricing/ on 2026-09-05: this is the LAST capture returning 200, and the next capture, 2024-07-15, is a 301. So this is not a superseded revision but the terminal published revision of a page that was subsequently withdrawn; the live URL now redirects to shift4.com and whether a post-acquisition successor pricing document exists is unknown and was not read. source |
| reporting-guest-cohorts | unknown / F - Searched the complete 693-article public help-centre mirror (terms: returning, lifetime, cohort, vis | resolve-to-partial | Upheld. Guest-level reporting exists and is tied to identifiable CRM records: "This report houses all customers' orders." and, per customer, "The number of orders attached to the customer will be show in parentheses right next to the customer name.", with per-customer order detail, an optional tip-inclusive total, a date-range filter and Excel or CSV export. That yields per-guest visit counts and spend for a chosen window, the raw material the claim asks about. Absent from this report and from every other report article in the mirror is the derived analytics the claim names: no new-versus-returning counts, no visit-frequency distribution, no lifetime-spend cohorting. The operator would build those from the export. source |
| hardware-handheld-lte | unknown / F - Re-checked the complete 693-article public help-centre mirror (captured 2026-08-04) for cellular, LT | upheld | Overturned from no. First, a correction to a premise put to me: the catalogue does enumerate tablets, three of them, an iPad 10th generation, an iPad Air 6th generation and an iPad Mini 7th generation, under Screens and Additional Peripherals, and it enumerates portable payment terminals with explicit connection values. So the category is not missing. The defect is narrower and fatal in a different way: the instrument the no leans on is the Connection column, and that column is EMPTY for all three iPad rows, which are exactly the devices that would carry built-in cellular, and the article never states which Apple SKU Revel resells even though Apple ships the iPad Mini in both Wi-Fi and Wi-Fi-plus-Cellular variants. The claim has two limbs, built into the device OR a vendor-supplied failover. The failover limb is genuinely closed by the Networking section. The built-in limb is not closed, it is unpopulated. A completeness sentence covers only what the document actually records, and this document records no connectivity for its tablets. What remains against the claim is that no Revel document anywhere describes cellular as a fallback, and on this vendor an absence of documentation is unknown, not no. The three iPad models also date the catalogue to no earlier than late 2024, which is worth carrying forward. |
| reliability-cellular-backup | unknown / F - Re-checked the complete 693-article public help-centre mirror (captured 2026-08-04) for cellular, LT | resolve-to-no | Upheld, and it does not fall with the handheld row. The claim is automatic cellular failover for connectivity, first-party or documented, which is a network-appliance function, and Networking is one of the seven categories this catalogue actually enumerates. The catalogue states "Here you can find all the active and supported hardware by Revel Systems." and its Networking section is four Cisco Meraki devices, the MX64 security appliance, the MR36 and MR78 access points and the Z4 router. No cellular modem, LTE gateway or failover appliance is offered. A second, independent and affirmative leg confirms it: Revel's outage playbook prescribes what to do when the WAN drops, and the prescription is manual degradation, not failover, enabling offline mode for card payments plus printing reports from local data. A vendor that answers the ISP-outage question in writing and does not answer it with failover is making a positive statement, not a silence. Counterweight stated rather than hidden: Cisco documents the MX64 accepting an approved 3G/4G USB card for failover, so the capability is latent in a device Revel resells; Revel neither supplies, provisions nor documents it. source |
| hardware-selfpour-scales | unknown / F - Still unresolved after searching the complete 693-article public help-centre mirror (captured 2026-0 | upheld | Overturned from no, on the analyst's own principle. The analyst correctly declined to score tap-to-phone from this catalogue because a hardware catalogue cannot enumerate a software-only capability. The same principle disposes of this row. The claim is an INTEGRATION claim, that the platform integrates with self-pour tap walls, flow meters or pour spouts such that pours post to a tab; it is not a claim that Revel resells such a device. The catalogue's Scales section is three weighing devices, two Brecknell POS scales and a Magellan scanner-scale, and a flow meter or tap-wall controller is not a scale, it is a different hardware class that a weighing-scale section would never have carried. So the completeness sentence covers a category that does not include the claim's subject. The only other support offered was that no article in the mirror mentions self-pour, PourMyBeer or pour-to-tab, which I reproduced and confirmed, but that is a grep miss and the brief forbids a grep miss as a no on this vendor. I also looked for the second leg that would have saved it, a closed integrations directory naming the partners: the mirror carries only individual partner articles, Como, Deputy, Delphi OCS, Kosmos, LoyaltyPlant, Open Dining, Paytronix, QBO and Twilio, with no directory asserting itself complete, and the Integration Partners page lives on the dead marketing host. No closed instrument exists for this claim. |
| hardware-usable-after-churn | unknown / F - Still unresolved after searching the complete 693-article public help-centre mirror (captured 2026-0 | resolve-to-yes | GRADE HELD AT B BY SOURCE TYPE, not raised on currency: grade C in this taxonomy means a vendor pricing or feature page written to sell, and this is neither - it is Revel's own binding Additional Terms and Conditions of Hardware Sale. Value upheld, grade downgraded, note trimmed. Revel's Additional Terms and Conditions of Hardware Sale answer the claim directly at section 2.10, used here as a locator only, with the operative language quoted: "Upon expiration or termination of the Agreement, Customer may retain possession of all Purchased Hardware for which Customer has made full payment", the only condition being that the customer must "cease using the Purchased Hardware as part of the Revel POS Platform" and disable access to or de-install the software, APIs and the service. There is no return obligation, no remote disable and no software lock. Evidence discipline: this is a Wayback capture dated 2021-07-28. I queried the Wayback CDX index for revelsystems.com/hardwaresaleterms/ on 2026-09-05 and this is the last capture returning 200, so it is the terminal archived revision rather than a known-superseded one; the live URL now redirects to shift4.com and whether a post-acquisition successor exists is unknown and was not read. I removed the prior note's Revel Guard XT and Apple Configurator argument because those facts are not in the document this row cites. source |
| extensibility-doordash-preferred | unknown / F - The mirror confirms Revel ships a direct DoorDash Marketplace integration (support.revelsystems.com/ | resolve-to-no | Upheld after independent re-reading of the fetched page. DoorDash names the 2026 cohort itself and it is a closed list of ten, Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast and UrbanPiper, "representing some of the most reliable integration providers on the DoorDash platform today." The roster is dated on the page, "The 2026 DoorDash Preferred Integration Partners was generated based on performance and feature sets as of May 8, 2026." and the announcement itself is dated May 18, 2026, with the page's own recent-posts rail running to September 2026, so it is the current roster and not a stale one. Revel is absent, and so is Shift4. This is a third-party published designation, so the no rests on a closed roster held by the awarding party and not on any silence in Revel's corpus, and the brief's no-absence constraint does not bite. Revel does ship a direct DoorDash Marketplace integration, which is a different thing from the Preferred designation. source |
| reliability-menu-build-service | unknown / F - The Welcome Checklist does direct the merchant to the Menu Build Guide, Products training videos and | resolve-to-partial | Upheld, with the capture's status corrected. The pricing page prices implementation separately, on-boarding starting at "$674.00", and enumerates what it buys, "Software Onboarding", "Management Console Training", "Menu Consultation", "Hardware Installation", "Payments Set Up". So a vendor-side menu service exists and is real, but it is a paid add-on rather than part of the subscription, and it is described as consultation rather than build. The help centre pulls the same way: the Welcome Checklist hands the merchant the Menu Build Guide, the products training videos and the Excel import. Partial rather than yes because nothing published says Revel performs the initial build. Evidence discipline: Wayback capture dated 2023-05-28; per the CDX index queried 2026-09-05 this is the last capture returning 200 and the next, 2024-07-15, is a 301, so it is the terminal published revision of a withdrawn page; the live URL redirects to shift4.com and no successor was read. source |
| commercial-month-to-month-contract | unknown / F - Still unresolved after searching the complete 693-article public help-centre mirror of support.revel | resolve-to-no | Upheld under the 207th ruling, with condition 2 rewritten because its literal form would have been false. The claim is about what the vendor PUBLICLY OFFERS, which is measurable from published pages. Revel's pricing page shows one software price, "$99/monthly fee" per terminal, and conditions it in a footnote, "This rate is available to clients billed annually who include a 3-year Revel Advantage contract." together with "Minimum purchase of two terminals required." No published Revel page offers a month-to-month tier, and the separately published Revel Care programme terms run a thirty-six month initial enrolment. This is an affirmative-presence finding, a multi-year term requirement that EXISTS in the text, not an absence. Evidence discipline, all four conditions addressed: the url is the capture, not the live page; the capture is dated 2023-05-28; I queried the Wayback CDX index on 2026-09-05 and this is the LAST capture returning 200, with the next, 2024-07-15, returning 301, so no later revision exists in the archive and the honest statement is that the page was withdrawn rather than revised, and whether a post-acquisition successor exists is unknown and was not read; the language is quoted and no section number carries any weight; and no reading of a current revision exists in the record to re-home onto. Weight, stated plainly: this predates the June 2024 Shift4 acquisition by thirteen months, the footnote's own wording implies other unpublished contract structures at higher prices, and the master Customer Agreement is a PDF with zero captures, so this is graded C and should not be read as a statement about what Shift4 sells today. source |
| commercial-no-early-termination-fee | unknown / F - Still unresolved after searching the complete 693-article public help-centre mirror of support.revel | resolve-to-no | Value upheld, grade downgraded from B to C, evidence discipline rewritten. The claim asks whether published terms STATE that there is no early termination fee. No published Revel document does, and one published Revel document affirmatively imposes the opposite. The Revel Care Program Additional Terms set an initial enrolment of "thirty-six (36) months" and provide that if the customer cancels during it, or if "the Agreement is otherwise terminated during the Initial Enrollment Period", the customer shall pay "as liquidated damages, and not as a penalty, the balance of all Revel Care Program monthly fees which would otherwise have been payable", in addition to and not in lieu of Revel's other legal rights. The second trigger is the load-bearing one: terminating the software agreement early itself fires the liquidated-damages clause. The published legal family was surveyed via the Wayback index of revelsystems.com, namely apiterms, payment-terms, hardwaresaleterms, supportservicesterms, revel-care-terms, both customer-agreement landing pages and the 2016 Terms of Service, and none contains a no-ETF statement. Evidence discipline: this is a capture dated 2024-04-24; per the CDX index queried 2026-09-05 it is the last capture of that page returning 200, so it is the terminal archived revision rather than a known-superseded one, the live URL now redirects to shift4.com, and whether a post-acquisition successor exists is unknown and was not read. Caveats: the master Customer Agreement is a linked PDF with zero captures, so the software subscription's own termination clause was never read, and the capture predates the June 2024 Shift4 acquisition by about two months. source |
| commercial-autorenew-terms-published | unknown, grade F | resolve-to-yes | Both quoted sentences are verbatim in the PDF text and are contiguous within s.11.1's column. The proposal's 'thirtysix' was a pdftotext artefact: the layout text shows 'thirty-' / 'six' hyphenated across a line break, so the quote is corrected to 'thirty-six'. The PDF's party is Revel Systems, Inc. (Delaware, Atlanta). It is the only Revel customer agreement in the shift4.com CDX, and the newest captured legal index still links it, so nothing supersedes it. The 'Online SMB' scope and the Order Form carve-out do not defeat a published default term and notice window (agilysys and chowly precedent). source |
| commercial-data-ownership-clause | unknown, grade F | resolve-to-partial | The value and grade stand, but the proposed note contained errors. It said conjunct 1 was 'met outright', yet s.13 defines Customer Data as only data 'submitted' to the Service, and s.5.6 makes Revel the owner of 'transaction and activity records'. So merchant ownership of transaction data, the very data the claim names, is not established; the shortfall now sits on both conjuncts, each partly met. The note also misdescribed agilysys as an 'MSA with vendor-owned derived/anonymized data' (its partial rests on a Personal-Data-only DPA) and made an unverified 'no transaction-record carve-out' remark about gotab; both are corrected. All quotes were checked verbatim in the PDF text, and the s.5.4 sentence was confirmed to continue past the page-4 footer without welding. source |
| extensibility-app-marketplace | unknown, grade F | upheld | Proposed partial from sources the record never cited - the Shift4-hosted Revel legal set (revel-legal index, API/XML, care, hardware, data-access-tier terms and the 2024 Online SMB Revel Customer Agreement, via Wayback because live shift4.com answers a 429 Vercel checkpoint) and 69 archived 2022+ revelsystems.com product and solution pages (273rd session); rejected on verification: The cited 20240420201840 open-api-integrations page names no third-party app. It gives 15 category names, a 'View Partners' button to /partners/ and a 'Connect with a Revel product expert' prompt. The 20240530030108 capture of /partners is a Nuxt JS shell whose raw bytes hold zero tokenised partner names (the 341 raw 'olo' hits are a substring, poison). The only named listings are the partners/drive-thru and partners/kitchen-management category pages, captured 2022-06-28, one partner each, on a site design that revelsystems.com no longer serves. Self-install is absent on every page, and the KB mirror shows integrations enabled by Revel support. The browse/named-listing conjunct is therefore evidenced only for 2022, and the current existence of any directory is exactly what the record's unknown rationale could not establish, so a partial here would rest on a stale single conjunct; the cell stays unknown. source |
| commercial-rate-increase-clause | unknown, grade F | resolve-to-no | SUPERSESSION: I ran pdftotext myself. POS-System-Service-Agreement.pdf is 'by and between Shift4 Payments, LLC ("Company") and Merchant'. It covers Harbortouch Elite/Onyx/Echo equipment and has footer S172_04272026. It is listed on shift4.com/legal under POINT OF SALE (SERVICE) TERMS next to the Shift4-Dine and Simphony variants. It appears nowhere in revel-legal (0 hits in both captures), so it is not a Revel agreement and supersedes nothing. The newest revel-legal capture still links the Customer Agreement PDF. (Its own 3.e, a change on 30 days' notice, and 3.g, CPI+1%/4%, would score no anyway.) QUOTES: the 4.3 sentence and the CPI sentence are contiguous on line 56 of the non-layout text, with no footer weld. The 11.3 liquidated-damages quote, 4.1, 12.11, 6.1 and the 'Service' definition (s.13) were confirmed verbatim. Note: the -layout extraction is two-column and was not used. CAP: 'Without limiting any other rights of Revel' makes the CPI clause additive to 4.3's any-time right, so it is not a cap. EXIT: I grepped terminat/increase/objection/convenience/renew. No price-increase exit exists. The proposal missed two things that strengthen the no: 12.11 (unilateral modification, where continued use counts as acceptance) and 4.1 (non-cancelable). SCOPE: 'Service' explicitly excludes processing, so the disclosure is accurate. But 6.1 is a processing-adjacent clause ('such terms, conditions and fees as Revel may require'; Revel 'may bill and collect fees'), and I added it. I also corrected the proposal's line that the FreedomPay and Advantage XT PDFs were 'never archived'. Wayback CDX returned [] for both (one CDX call hit an Archive 'Temporarily Offline' page, and the prefix retry returned []). And the Advantage XT document IS linked from the index, labelled 'Revel Advantage XT Payment Terms' (Revel Systems Inc_.pdf), so it is linked but unretrieved, not 'not publicly posted'. PEERS: arryved (MSA 5.1, no/B), sambapos (Terms of Use, no/B), urbanpiper (subscription, partial/B), restaurant365 (MSA 8% software cap, yes/B) and thrive-pos (absence of processing paper, no/B) all score non-processing or absent paper and disclose the gap. Revel is treated the same way. RECORD: claims.jsonl row 265 is the current unknown/F, which this replaces. It cites the unposted Supplemental Advantage XT terms, consistent with the scope note. Row 261 (no-early-termination-fee, no/C, Revel Care liquidated damages) and rows 262/273 (the same PDF) are consistent with this note, and nothing contradicts it. source |
| extensibility-api-access-cost | unknown, grade F | resolve-to-partial | Proposed no off the 2015 Zendesk API tier list; amended to partial on verification because Revel's same-month marketing page says 'Current clients can access Revel Systems API at no cost' and 2021-22 pages say 'unlimited integrations for one flat price', while the FAQ caps the no-fee client level at 25 calls/day and prices unlimited access ($2,500 + $250/month or revenue share). Included access exists; production volume needs a paid tier. source |
| extensibility-app-marketplace | unknown, grade F | resolve-to-partial | Browsable named third-party directory established on vendor marketing pages 2015-2024; self-install conjunct fails (sales-mediated, self-service sign-up explicitly not yet available). Matches peer partial precedent. Grade C: marketing. source |
| hardware-handheld-lte | unknown, grade F | resolve-to-partial | Vendor hardware pages 2013-2016 document cellular/LTE iPads for mobile POS (handheld cellular conjunct met); no documented Wi-Fi-drop fallback; newer 2021 catalogue omits cellular. Matches pdq-pos/toast partial precedent. Grade C. source |
| digital-sms-ordering | unknown, grade F | upheld | Proposed partial from sources the record never cited - Revel's archived pre-Shift4 Zendesk help centre (support.revelsystems.com/hc/en-us, Wayback captures 2015-2019) and archived revelsystems.com marketing site (278th session); rejected on verification: Two 2017-2018 blog posts about one partner bot (JoyUp Joy) over Facebook Messenger only: no SMS/text channel, orders reach the kitchen printer with no statement that they are created as Revel POS orders, and the partner never appears in any Revel partner directory capture. A single partner blog cannot establish the vendor supports chat ordering landing in the POS. source |
| guest-loyalty-ai-offer-recommendation | unknown, grade F | upheld | Proposed partial from sources the record never cited - Revel's archived pre-Shift4 Zendesk help centre (support.revelsystems.com/hc/en-us, Wayback captures 2015-2019) and archived revelsystems.com marketing site (278th session); rejected on verification: The only AI evidence is a 2019 guest post by Como's chief architect describing Como's own Comillia AI Campaigns; Revel's own 2023 Loyalty XT (powered by Como) product page has zero AI/ML/predict wording, so it is not established that Revel tenants receive the feature. No peer record scores this cell partial off a partner's AI; partner content never establishes the vendor capability. source |
Sources
Every URL this record cites. 168 in total.
- https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418
- https://support.revelsystems.com/s/article/Advanced-Modifier-Features-1583154976185
- https://status.revelsystems.com/
- https://revelsystems.com/pricing/
- https://developer.revelsystems.com/revelsystems/
- https://support.revelsystems.com/s/article/Kitchen-Flow-Bump-Feature-Setup-1582899129146
- https://apps.apple.com/us/app/revel-delivery-xt-dispatch/id1531919449
- https://developer.revelsystems.com/revelsystems/docs/api-platform-authentication not refetchable · page gone
- https://developer.revelsystems.com/revelsystems/docs/webhooks not refetchable · page gone
- https://reveluniversity.revelsystems.com/s/advanced-features/kds
- https://sourceforge.net/software/product/Revel-Systems/
- https://support.revelsystems.com/s/pizza-resources
- https://merchants.doordash.com/en-us/blog/preferred-pos-integration-partners
- https://support.revelsystems.com/s/article/Split-Modifiers-for-Online-Ordering-XT
- https://support.revelsystems.com/s/article/Active-Supported-Hardware
- https://support.revelsystems.com/s/article/Building-Your-Table-Layout-1583149094553
- https://support.revelsystems.com/s/article/Split-Bills-1582901435396
- https://support.revelsystems.com/s/article/iPort-stands-and-cases
- https://support.revelsystems.com/s/article/Revel-Advantage-International-FAQ
- https://support.revelsystems.com/s/article/Offline-Mode-Always-On-Mode-1582898971418
- https://support.revelsystems.com/s/article/QBO-Mapping-and-Modules-1583148058187
- https://support.revelsystems.com/s/article/QBO-Mapping-Account-Types-1583148425273
- https://support.revelsystems.com/s/article/Establishment-Payments-Report
- https://support.revelsystems.com/s/article/Insights-by-Revel-1582893045693
- https://support.revelsystems.com/s/article/Revel-POS-Payments-Overview
- https://support.revelsystems.com/s/article/Payment-Gateways-Processors-Overview-1582893045232
- https://support.revelsystems.com/s/article/Table-Service-Settings-1583149942760
- https://apps.apple.com/us/app/id1082280826
- https://amaka.com/integrations/revel/xero/
- https://apps.apple.com/us/app/revel-inventory/id1051198587
- https://support.revelsystems.com/s/article/Quick-Course-Seat-Menu-1582901899924
- https://support.revelsystems.com/s/article/TSR-Course-Fire-1582902249374
- https://support.revelsystems.com/s/article/Preauthorizations-and-Linking-Cards-to-Bar-Tabs-Tables-and-Orders-1582901172680
- https://support.revelsystems.com/s/article/TSR-Transferring-Order-Owners-1582902249371
- https://support.revelsystems.com/s/article/Action-Log-Report-1583149671561
- https://support.revelsystems.com/s/article/Smart-Order
- https://support.revelsystems.com/s/article/Kiosk-XT
- https://support.revelsystems.com/s/article/Revel-Drive-Through
- https://support.revelsystems.com/s/article/Speed-of-Service-Report-1583149670649
- https://support.revelsystems.com/s/article/Online-Ordering-Setting-Up-Online-Ordering
- https://support.revelsystems.com/s/article/Online-Ordering-FAQ
- https://support.revelsystems.com/s/article/Future-Orders-1582902249369
- https://support.revelsystems.com/s/article/Delivery-Catering-1583149409698
- https://support.revelsystems.com/s/article/Invoices-Deposits-1582901172674
- https://support.revelsystems.com/s/article/Loss-Management-Prevention-and-Auditing-1583149672029
- https://support.revelsystems.com/s/article/Refund-Void-Comp-or-Exchange-Items-1582901899928
- https://support.revelsystems.com/s/article/EMS-Establishment-Hierarchy-Tree-1582898526017
- https://support.revelsystems.com/s/article/Introduction-to-EMS-1582898525999
- https://support.revelsystems.com/s/article/Products-in-EMS-1582898526007
- https://support.revelsystems.com/s/article/Push-Settings-in-EMS-1582898526028
- https://support.revelsystems.com/s/article/Price-Tiers-1583149941078
- https://support.revelsystems.com/s/article/Overview-of-Revel-Gift-Cards
- https://support.revelsystems.com/s/article/Data-that-Updates-for-All-Establishments
- https://support.revelsystems.com/s/article/DoorDash-Marketplace
- https://support.revelsystems.com/s/article/Taxes-Implementing-Different-Tax-Types-1583152075662
- https://support.revelsystems.com/s/article/Time-Sheet-Rules-1583150213539
- https://support.revelsystems.com/s/article/Introduction-to-Modifiers-1583154976165
- https://support.revelsystems.com/s/article/Creating-Matrix-Inventory-on-the-Management-Console-1583150212824
- https://support.revelsystems.com/s/article/Linked-Combos
- https://support.revelsystems.com/s/article/Managing-Item-Availability-on-the-Point-of-Sale
- https://support.revelsystems.com/s/article/Custom-Menus-1583150454200
- https://support.revelsystems.com/s/article/Ingredients-Recipes-Guide-1583150212848
- https://support.revelsystems.com/s/article/Creating-a-Surcharge-1583149094546
- https://support.revelsystems.com/s/article/FAQ-Credit-Card-Surcharging
- https://support.revelsystems.com/s/article/Adyen-Surcharge-Guidelines-and-Set-Up-Australia-and-New-Zealand
- https://support.revelsystems.com/s/article/Moby-5500
- https://support.revelsystems.com/s/article/Revel-SmartPay
- https://support.revelsystems.com/s/article/How-to-Add-Credit-Card-Tips-on-the-Point-of-Sale-1582900280542
- https://support.revelsystems.com/s/article/Tip-Pooling-1583150213556
- https://support.revelsystems.com/s/article/How-to-Manually-Batch-Uncaptured-Offline-and-or-Declined-Credit-Card-Transactions-1582901172686
- https://support.revelsystems.com/s/article/Managing-Chargebacks-Disputes-in-Your-Revel-Advantage-Portal
- https://support.revelsystems.com/s/article/Saving-and-Changing-Credit-Card-Details-for-Online-Ordering-1583152074721
- https://support.revelsystems.com/s/article/Revel-Advantage-XT-Payment-Processing-Fees
- https://support.revelsystems.com/s/article/Batching-Payments
- https://support.revelsystems.com/s/article/Revel-Advantage-FAQ-for-Merchant-PCI-Compliance
- https://support.revelsystems.com/s/article/FreedomPay-Setup-1582893044828
- https://support.revelsystems.com/s/article/Billing-FAQ
- https://support.revelsystems.com/s/article/Payment-Device-Purchase-Policy
- https://support.revelsystems.com/s/article/Can-I-set-up-my-own-card-swipe-iPad-or-printer-1582902447073
- https://support.revelsystems.com/s/article/Data-Access-changes
- https://support.revelsystems.com/s/article/Customer-Anonymization-1583148890445
- https://support.revelsystems.com/s/article/Revel-Advantage-Portal-User-Logins
- https://support.revelsystems.com/s/article/CDS-XT-1582898526718
- https://support.revelsystems.com/s/article/Prep-Cook-Time-1583152074715
- https://support.revelsystems.com/s/article/UberEats-Onboarding
- https://support.revelsystems.com/s/article/Production-View-on-the-KDS-1582899129813
- https://support.revelsystems.com/s/article/Colored-Timing-on-Tile-Expedite-View-1582899129853
- https://support.revelsystems.com/s/article/Printing-Failover
- https://support.revelsystems.com/s/article/outage
- https://support.revelsystems.com/s/article/KDS-Styles-Overview-1582899129825
- https://support.revelsystems.com/s/article/How-to-Reprint-to-Kitchen-Receipts-1582901899083
- https://support.revelsystems.com/s/article/KDS-Print-Tickets-1582899130358
- https://support.revelsystems.com/s/article/SMS-on-Order-Ready-in-the-Kitchen
- https://support.revelsystems.com/s/article/Order-Ready-View-for-Android-TV
- https://support.revelsystems.com/s/article/How-to-Use-Product-Setup-on-the-Point-of-Sale-1582899333978
- https://support.revelsystems.com/s/article/Item-Tracking-Product-Forecasting-1583149672017
- https://support.revelsystems.com/s/article/Delivery-Management-Written-Instructions
- https://support.revelsystems.com/s/article/Delivery-Management-Settings-1583149409705
- https://support.revelsystems.com/s/article/Delivery-Zone-Service-Fees
- https://support.revelsystems.com/s/article/Driver-XT
- https://support.revelsystems.com/s/article/Online-Ordering-Creating-a-Custom-Online-Menu
- https://support.revelsystems.com/s/article/Custom-Commerce-App-FAQ-1582893045686
- https://support.revelsystems.com/s/article/Online-Ordering-XT-Personalization
- https://support.revelsystems.com/s/article/Online-Ordering-XT
- https://support.revelsystems.com/s/article/Pickup-Ordering
- https://support.revelsystems.com/s/article/Catering-Overview-1583149409691
- https://support.revelsystems.com/s/article/Loyalty-XT
- https://support.revelsystems.com/s/article/Discount-Codes-1583151656831
- https://support.revelsystems.com/s/article/Version-2-73
- https://support.revelsystems.com/s/article/CRM-Automated-Server-Search
- https://support.revelsystems.com/s/article/Creating-a-Loyalty-Program-1583151656809
- https://support.revelsystems.com/s/article/CRM-Tab-Overview-1583148889940
- https://support.revelsystems.com/s/article/Stackable-Discounts-1583151656823
- https://support.revelsystems.com/s/article/Enabling-Consumer-Marketing-Opt-in-out-Logging-1583148890442
- https://support.revelsystems.com/s/article/Discounts-Report-1583149669643
- https://support.revelsystems.com/s/article/Employees-Roles-and-Permissions-Guide-1583149941746
- https://support.revelsystems.com/s/article/Advanced-POS-Settings-1583149942304
- https://support.revelsystems.com/s/article/Creating-Shift-Schedules-1583150213550
- https://support.revelsystems.com/s/article/Viewing-Reports-on-the-Point-of-Sale-1582899334000
- https://support.revelsystems.com/s/article/Payroll-Guide-1583150213542
- https://support.revelsystems.com/s/article/How-to-Export-Employee-Hours-to-ADP-1583150213536
- https://support.revelsystems.com/s/article/Employee-Profit-Report-1583149670660
- https://support.revelsystems.com/s/article/Introduction-to-Inventory-1583148890898
- https://support.revelsystems.com/s/article/Inventory-Stock-Unit-Conversions-1583149942770
- https://support.revelsystems.com/s/article/Physical-Inventory-Report-1583149672025
- https://support.revelsystems.com/s/article/Online-Ordering-XT-Product-and-Ingredient-Inventory-Tracking
- https://support.revelsystems.com/s/article/Stocktake-1583149941735
- https://support.revelsystems.com/s/article/Physical-Inventory-1583149941728
- https://support.revelsystems.com/s/article/Inventory-FAQs
- https://support.revelsystems.com/s/article/Periodic-Inventory-1583149942773
- https://support.revelsystems.com/s/article/Reorder-to-PAR-1583149943286
- https://support.revelsystems.com/s/article/Product-Mix-Report-1583149670668
- https://support.revelsystems.com/s/article/Operations-Report-1583149671565
- https://support.revelsystems.com/s/article/Labor-Report-1583149671122
- https://support.revelsystems.com/s/article/Auto-Delivery-of-Reports-1583149669622
- https://support.revelsystems.com/s/article/Tills-How-to-Setup-Till-Alerts-1582899801523
- https://support.revelsystems.com/s/article/Tax-Report-1583149671124
- https://support.revelsystems.com/s/article/WebOrders-API-Price-Override
- https://support.revelsystems.com/s/article/Exporting-Sales-Data
- https://developer.revelsystems.com/revelsystems/docs/frequently-asked-questions not refetchable · page gone
- https://www.itsacheckmate.com/integrations
- https://www.tryotter.com/integrations
- https://support.revelsystems.com/s/article/Merchant-Profile-Questionnaire-guide-for-RA-XT-TriPOS-and-FreedomPay
- https://support.revelsystems.com/s/article/Delphi-OCS-Integration
- https://support.revelsystems.com/s/article/Running-Dual-Cash-Drawers-Setup-1582902926329
- https://support.revelsystems.com/s/article/Operations-FAQ
- https://support.revelsystems.com/s/article/Hardware-Manufacturer-Warranty-1582902925055
- https://support.revelsystems.com/s/article/RevelGuard-1582903575827
- https://support.revelsystems.com/s/article/Caller-ID-1582898972497
- https://support.revelsystems.com/s/article/Syncing-and-Non-Syncing-Stations-1582903575834
- https://support.revelsystems.com/s/article/Resources-and-Contacts
- https://support.revelsystems.com/s/article/Welcome-Checklist
- https://support.revelsystems.com/s/article/Branding-Tool-1582898526710
- https://support.revelsystems.com/s/article/iPad-iOS-Compatibility
- https://support.revelsystems.com/s/article/Client-Training-Programs
- https://documentation.meraki.com/SASE_and_SD-WAN/MX/Product_Information/Overviews_and_Datasheets/MX64_and_MX65_Overview_and_Specifications
- https://support.revelsystems.com/s/article/How-to-assign-products-to-kitchen-printers-display-unit-KDS-1583149941086
- https://support.revelsystems.com/s/article/How-to-Send-to-the-Kitchen-by-Dining-Option-1582898971400
- https://support.revelsystems.com/s/article/Kitchen-Flow-Bump-Feature-Setup-1582899129146
- https://support.revelsystems.com/s/article/Automated-Expo-Experience
- https://support.revelsystems.com/s/article/Optimize-KDS-for-Coursing-1582899129817
- https://www.shift4.com/pdf/Online-SMB-Revel-Customer-Agreement--12.10-revision--7.9.2024-LCT-v.6.2-LCT-CPI-Markup-Sect-4.3-8.12.2024.pdf
- https://web.archive.org/web/20240420201840/https://revelsystems.com/why-revel/open-api-integrations
- https://web.archive.org/web/20150225065145/http://support.revelsystems.com:80/hc/en-us/articles/203244339-Does-Revel-have-an-open-API-
- https://web.archive.org/web/20200420042219/https://revelsystems.com/partners/online-mobile-ordering/
- https://web.archive.org/web/20140502004303/http://revelsystems.com:80/hardware/idevices/ipad-air
- https://web.archive.org/web/20200930101253/https://revelsystems.com/blog/2017/12/28/upbeat-digital-assistant-can-sales/
- https://web.archive.org/web/20191210071714/https://revelsystems.com/blog/2019/12/04/ai-and-ml-for-your-business/